oops
 

After reviewing this thread it may appear I was taking issue with Gary. That was not my intentions at all. He gave me the opportunity to post what I had been thinking all along.

My apologies to Gary if anyone thinks I was attacking him. I hope Syd reviews this thread, including Gary's comments, before attempting to correct the problems with the data base.

RichD.

P.S. Thank you Dr. Silverman.

The worker script has been disabled. :smile:

Also, we have a "Quick ECM" button. What exactly does this do? Who does the work? (It does definitely find factors, though.)

[URL="http://factordb.com/search.php?se=1&aq=10%5E33"]10^33[/URL] (merges with [URL="http://factordb.com/search.php?se=1&aq=300559867980"]300559867980[/URL]) has the partial squared line bug. Using Repair doesn't work.

I read about all the problems with the database, sorry for that.

I'll do my best to fix them!

Btw, does anybody know how to reproduce the square-bug?

Some changes:
- disabled the worker-script to keep it from reporting more work that hasn't been done
- all reported work within the last 2 weeks archived (wont show up anymore)
- quick ecm button: Do some ECM curves on the webserver (ecm -c 30 -v -I 3 1000, 3 Threads), limited to 4 seconds

[quote=Syd;187590] Btw, does anybody know how to reproduce the square-bug? [/quote]
I don't, but I'd suggest running a few hundred lines through repeatedly (i.e. run them through then wipe them, repeat until you get what you need) until it happens, since it seems to be completely random. (or, if blanking them is too hard, use aliqueit.exe to run random sequences that don't have any status yet and submit them until you get the bug)

Here's a few facts:
in real factorizations, powers above 1 on numbers over 1000 or so are quite rare
in factorizations with the squared-line bug, not having squares well over 1000 is quite rare
factorizations can easily be multiplied back together to check if they equal the composite number

Put it all together, and you've got a decent strategy for preventing the squared line bug: if the DB thinks that a factorization includes a number over 1000 raised to a power over 1, double check it by multiplying all the numbers together and checking if they equal the original number. If so, it's a legitimate square (or other power), if not, try setting all number over 1000's powers to 1 and multiply, if still broken fix it by blanking the factorization for that number and re-reading the input that started all this.
Edit: pseudocode would be something like:
[code]if ((cofactor > 1000) & cofactor_power > 1) {
if (whole_number == find_cofactor_products()) {
//it matches, continue or break or whatever is needed
} else {
set_all_cofactor_above_1000_power(1);
if (whole_number == find_cofactor_products()) {
//it matches, continue or break or whatever is needed
} else {
blank_factorization();
reread_input();
}
}
}[/code]Of course, this isn't guaranteed to fix every case, but it will fix a HUGE majority of them. (it will still break when the only improperly-squared cofactors are <1000, which would likely only happen when the line is so small that no cofactors are over 1000, which is quite rare in aliquot sequences, or any other factorizations the DB is likely to encounter)

bug or feature ??
 

Syd,

I've noticed two changes. Not sure if they are a design feature or a bug. They both involve the page where factor(s) can be entered for a number.

1. It will not accept only tiny factors. i.e., 3 or 17 x 41 or 2 ^ 3 x 3 ^ 2 x 11

2. Before, it was OK to have a space in a long factor. Now it is not accepted. In fact, none of the other (smaller) factors are accepted either. i.e., 14 384922847311
(random number, don't know if it is prime)

Do you have any idea when the worker queue will be re-opened?

RichD.

@Syd if you want a lot of lines that are not in the database contact smh
he has loads of lines to submit
see the aliquot sequence terminations [URL="http://www.mersenneforum.org/showthread.php?t=11837"]thread[/URL]

Work Queue
 

This is an observation for Syd. It appeared someone was dumping a lot of sieve (small factorizations) into the worker queue. I'm guessing Home Prime Sequences. We are talking 10's of thousands.

Near the end the workers would only receive msieve work. This would run the sequences until it hit a c60+ where it would queue up as an ECM to low limits. This never cleared much of the queue unless the sequence went prime.

Because the workers would not receive ECM work, this effectively backed up the entire queue.

Could the workers (for now) only receive ECM work to help with the queue backlog? I think I saw another problem where certain workers would return work immediately stating the work was complete and no factors found.

Just an observation for you to decide.
RichD.

Quick ECM
 

The Quick ECM button is quite clever. I've performed a little research (that sounds better than trial and error or throwing darts blindfolded). It can pull a p33 from a c70 or a p30 from a c102 in a matter of seconds. It may not find it on the first attempt. Don't be afraid to hit the button again. Additionally, on one pass, it found all 9 primes from a c84.

It does take more attempts if the two primes are near equal in size. I doubt if it could find a > p35 because that would get your name in lights under the Latest factors. Alas, it is quite the gem. Nice work Syd.

RichD.

[quote=RichD;188576]The Quick ECM button is quite clever. I've performed a little research (that sounds better than trial and error or throwing darts blindfolded). It can pull a p33 from a c70 or a p30 from a c102 in a matter of seconds. It may not find it on the first attempt. Don't be afraid to hit the button again. Additionally, on one pass, it found all 9 primes from a c84.

It does take more attempts if the two primes are near equal in size. I doubt if it could find a > p35 because that would get your name in lights under the Latest factors. Alas, it is quite the gem. Nice work Syd.

RichD.[/quote]
[quote=Syd;187590] - quick ecm button: Do some ECM curves on the webserver (ecm -c 30 -v -I 3 1000, 3 Threads), limited to 4 seconds[/quote]
Here's what that looks like on the last two curves:[code]Run 29 out of 30:
Using MODMULN
Using B1=62853, B2=62853-20328012, polynomial x^2, sigma=1266084293
dF=1024, k=2, d=9240, d2=13, i0=-6
Expected number of curves to find a factor of n digits:
20 25 30 35 40 45 50 55 60 65
17 163 2262 42864 1040035 3.1e+007 1.1e+009 4.2e+010 3.4e+015
4.9e+020
Step 1 took 422ms
...
Step 2 took 422ms
Expected time to find a factor of n digits:
20 25 30 35 40 45 50 55 60 65
14.48s 2.29m 31.82m 10.05h 10.16d 302.68d 30.03y 1130y 9e+007y 1e+013y
Run 30 out of 30:
Using MODMULN
Using B1=66349, B2=66349-20337252, polynomial x^2, sigma=164932136
dF=1024, k=2, d=9240, d2=13, i0=-5
Expected number of curves to find a factor of n digits:
20 25 30 35 40 45 50 55 60 65
17 157 2147 39567 941999 2.7e+007 9.7e+008 3.5e+010 1.9e+015
2.8e+020
Step 1 took 422ms
...
Step 2 took 421ms
Expected time to find a factor of n digits:
20 25 30 35 40 45 50 55 60 65
14.16s 2.21m 30.17m 9.27h 9.19d 266.14d 26.03y 928.39y 5e+007y 8e+012y
[/code]Maybe you've been exceptionally lucky, or maybe Syd has changed what Quick ECM does, but it seems to me that this generally shouldn't find anything larger than 20 digits (and in fact, you shouldn't even expect that).
To expect the 30 digit level, I think you'd have to run it somewhere around 2000 times.

[QUOTE=Mini-Geek;188577]Maybe you've been exceptionally lucky, or maybe Syd has changed what Quick ECM does, but it seems to me that this generally shouldn't find anything larger than 20 digits (and in fact, you shouldn't even expect that).
To expect the 30 digit level, I think you'd have to run it somewhere around 2000 times.[/QUOTE]

You may be correct. I had several in the mid c50s that couldn't be broken but eventually Alpertron brought out p20, p21 & p24s.

I guess I was just lucky with that p33 on only 4 or 5 attempts.

My "research" has only been about 200-300 submits on 40-50 numbers.