The squared-bug is still present in the new version of the DB, see for example in [URL="http://www.mersenneforum.org/showthread.php?p=187015#post187015"]this thread.[/URL]

After running fine for hours, my workers kept on crashing. They were not removed from the worker status page. There appear to be 4 running while i'm nut running one at all at the moment.

I tried running the worker.pl script yesterday, but the whole system crashed twice, so I gave it up.

[quote=Mini-Geek;186960][URL="http://factordb.com/search.php?se=1&aq=517392"]517392[/URL] is broken (partial squared line bug on line 754, it repeated c102=p6*p96).[/quote]
It's fixed now, and there's a "Repair sequence" button. :smile: Thanks Syd! Edit: which...doesn't work. :sad: [URL="http://factordb.com/search.php?se=1&aq=10000000000000"]10^13[/URL] is broken.

my workers are hardly being given any work even though there is loads of work still unassigned

Aliquot sequence 10^25 is broken with the squared line bug. I've now clicked on "Repair sequence" but I don't know how long it will take to repair it.

Also, I messed up on Aliquot sequence 21552. I accidently hit "set prime" (intending to do a P+1 factorization) on index = 631 for the 91-digit factor. It is actually composite. I've hit "Repair sequence" on that one but I suspect the DB will not find the problem since I "made" the DB "think" that the 91-digit factor was prime.

IMHO, the "set prime" is a dangerous choice and should be removed. Just about anyone could create an ID, request the appropriate permissions, and set all kinds of composites as primes, ruining the integrity of the DB in the process. That's because the DB does not actually check it for primality.

I'll post here within a day or two if the "repair sequence" worked on either of the above problems. If not, people can assume that they are still broken.

BTW, I think the squared line bug occurred because I may have submitted factorization for the same index twice. I know I submitted up through i=643 on 10^25 and was intending to submit more up to i=~800 by starting with i=643. Perhaps my second submission caused the DB to "think" that the factors for i=643 were squared. That's the only time I've thought I might have "caused" the problem. I hope this helps permanently fix it.

Therefore I would propose to everyone: Until it is known for sure that the squared line bug is fixed, please attempt to avoid submitting factorizations for the same indexes twice on a sequence.


Gary

[quote=gd_barnes;187083]Also, I messed up on Aliquot sequence 21552. I accidently hit "set prime" (intending to do a P+1 factorization) on index = 631 for the 91-digit factor. It is actually composite. I've hit "Repair sequence" on that one but I suspect the DB will not find the problem since I "made" the DB "think" that the 91-digit factor was prime.

IMHO, the "set prime" is a dangerous choice and should be removed. Just about anyone could create an ID, request the appropriate permissions, and set all kinds of composites as primes, ruining the integrity of the DB in the process. That's because the DB does not actually check it for primality.[/quote]
Syd, I've got a suggestion for this: how about you have the "Set prime" button only displayed when the number is either PRP, or too big to PRP test? This would mean that it only ever displays on numbers which are too big for the DB to automatically do this on its own, which is exactly what this feature is intended for. That, on top of limiting it to only well-trusted users (emphasis on [i]well[/i]-trusted) should keep erroneous prime listings to essentially nil.

Oh, and if it wouldn't be too hard, maybe for even the trusted users, they'd have to enter a CAPTCHA (sp.?) to verify that they really did want to mark that number as prime, and didn't just hit the button accidentally.

[QUOTE=mdettweiler;187085]
Oh, and if it wouldn't be too hard, maybe for even the trusted users, they'd have to enter a CAPTCHA (sp.?) to verify that they really did want to mark that number as prime, and didn't just hit the button accidentally.[/QUOTE]

I think it might even be better if the database requires to enter a certificate as ist is printed out by prime testing programs like Primo, Alpertrons Applet, Prime95, etc.

I'm not getting this "Set prime" button, but Syd said that I have it earlier in this thread.

Aliquot sequences 10^27 and 10^35 now also have the squared line bug.

This is a SERIOUS bug that only seems to have gotten worse! It only appears to happen on the submission of factors. This time, I made sure I didn't submit any indexes twice on the same sequence. So that is not the problem.

Once again, I've hit the "repair sequence" link to see if it fixes them. I'm still waiting on a fix for the previous 2 that I mentioned.

Funny (or not so funny) thing about 10^35 that I think is another bug: Even though I never hit "add sequence to workers", it seems to keep calculating increasing indexes on its own, right on after the squared line bug occurred for factors that I never submitted. I suppose it will stop once it gets up to 70 digits.

Question for everyone: Was the new version of the DB beta tested?

[quote=10metreh;187097]I'm not getting this "Set prime" button, but Syd said that I have it earlier in this thread.[/quote]

You can have mine. lol I don't want it there.

I would never need to set a prime because I'm not testing numbers so large that the DB couldn't quickly find them as prime on its own.