I have noticed that the additional informations sometimes missed something.
example 246829743984355435962408390910378218537282105150086881669547
this is also a factor of (10^763-1)/9 but not listed in the additional informations.

Regards Andi_HB

Just a reminder to people: don't put cofactors of current Cunninghams in the workqueue. They have already had more ECM than the workers ever do. I have removed all the Cunningham numbers from the queue.

Someone should change the table data in the cunningham forum. They imply practically no ecm data has been done and newcomers will be misled.

---------------------

I had a thought for the database and (aliquot) sequences.

One thing I cannot change with aliquot sequences is when the next entry of the sequence is incorrect. Would it be possible for the db to check if the next term of a submitted aliquot sequence matches the one currently in the db and if they differ, then recalculate the next sigma -n?

The idea would be that (re)submitting an aliquot sequence will correct this type of db error and no longer require human intervention.

I am trying to collect the latest set of errors including one I didn't detect before - sometimes the last line is fully factored, but there is no next one.

pre-aliquot number report
 

A suggestion:

1. Would it be possible to add to individual number pages ( like
[URL]http://factordb.com/search.php?query=4434305633[/URL] ) in "Additional information" section the pre-aliquot number (a number for which s(n)-n = this)? You can check that solving such equation is hard; a database lookup could be beneficial. If you don't want to overload database for casual queries, please add a hidden URL parameter, e.g. "&prealq=yes".)
For some numbers (more than 10 digits), it is reconstructable, e.g.
[URL]http://factordb.com/search.php?query=10955390367[/URL] shows the membership in a sequence... but for less than 11 digits, explicitly suppressed, even though the database knows the answer!
Here's a challenge for you: what is the prealq number for this prime?
[URL]http://factordb.com/search.php?query=5445410143[/URL]
The answer: the database knows! Without the database, can you solve it?

To see if [URL="http://factordb.com/search.php?query=&se=1&aq=552150"]552150[/URL] or [URL="http://factordb.com/search.php?query=&se=1&aq=195528"]195528[/URL] have side-sequences, one needs to solve the equation above (or lookup database), iteratively.

Some numbers are branching. These are of great interest (and are already used for merges of course).
Some numbers, of course, cannot be reached, and can be only starting points.

Of course an alternative is obvious: screen-scrape all sequences and look for branching points, but it's ugly, taxing to the database and transient (tomorrow one would need to do that again).

2. Also, would it be possible to report "A side-sequence for <a slightly larger number>" for the sequences (of course with restrictions, let's say <100000 and less than 2-3 times larger parent sequence)? (Merges are of course reported to smaller parent sequences.) Basically, it is the same thing as question #1.

-S

Is it possible to query the DB and get only the last line of a sequence back?

The next update will contain a lot of changes - a simple user management, points for running workers that can be used to do work ("time shift"), a perl worker script thats compatible with almost all platforms, a new "work"-system and some minor changes.
It also uses a completely different database structure, so I need to export all factors and import them into the new version, which will take some time. When its ready I'll have to close the database and convert it.
Maybe you want to have a look:
[url]http://factordb.com/neu/search.php[/url]
still very buggy and works on a quite old copy of the database, not all factors are available there.


[QUOTE=mdettweiler;180283]Quick question: how exactly does the "add sequence to workers" button work? I tried it earlier today on a relatively small sequence (~20 digits, if memory serves), and it ran for a few seconds, but then disappeared from the worker queue with absolutely no additions to the sequence. Am I misunderstanding something about this?[/QUOTE]

It just starts "msieve -e" with the composites over and over again until msieve fails or a C71 or higher pops up. I'll replace this button anyway.

[QUOTE=Andi47;180429]@Syd: Do you (frequently) read [URL="http://www.mersenneforum.org/showthread.php?t=12064"]this thread[/URL] in the aliquot sequences forum? There are a few new bugs (e.g. squared line bugs) in some sequences reported there.[/QUOTE]

No, didnt read this one. I Hope most of the sequences are fixed now, if not they will be automatically fixed while converting to the new database structure.

[QUOTE=WraithX;181824]Hello Syd,

I have a couple of questions about the database:
1) How do you prove a number is prp? I see you use Miller-Rabin tests, but to which bases? Are they fixed bases, or random bases? And how many bases?

2) How do you prove a number is prime? Do you use Primo, or something built into pari/gp, or something else?

3) I've noticed that some of the Mersenne primes are not showing up as primes in your data base, they are only showing up as prp. Can this be updated? (The Mersenne primes up to M1279 are prime, after that they are prp)[/QUOTE]

1) it uses the gmp_prob_prime function in php which uses Miller-Rabin's probabilistic test, 10 "reps"

2) the isprime() function in pari/gp

3) Sure

[QUOTE=10metreh;182681]When I enter a new factor for sequence 130396 in the "Know a factor?" box, this error appears:

[B]Fatal error[/B]: Cannot redeclare sequence() (previously declared in /var/www/sequence.php:18) in [B]/var/www/sequence.php[/B] on line [B]123[/B]

Oddly enough, when I refresh the page, it is back to normal, and the new factor is included.[/QUOTE]

Fixed. That was just a small glitch, the factor was submitted anyway.

[QUOTE=WraithX;182878]Also, I've noticed that your web page doesn't seem to be able to prove primality on numbers with over 600 decimal digits. Is this by design? It seems to run on the numbers for a few minutes and then they drop out of the queue. When I refresh the page for the number it still shows as prp and then it starts trying to prove primality again in the work queue. (and then a few minutes later it drops out of the queue again... )

Also, I've been proving primality of some numbers with primo. Can we upload these certificates to prove that these numbers are prime? Should I generate cert's with another program? Should I PM you the primo certs?[/QUOTE]

Thats by design. Numbers above 600 digits take quite some time so its disabled.
I'm trying to add buttons for "Set PrP" and "Set Prime", of cause only for registered users so I can keep track of all changes.

[QUOTE=Batalov;183746]A suggestion:

1. Would it be possible to add to individual number pages ( like
[URL]http://factordb.com/search.php?query=4434305633[/URL] ) in "Additional information" section the pre-aliquot number (a number for which s(n)-n = this)? You can check that solving such equation is hard; a database lookup could be beneficial. If you don't want to overload database for casual queries, please add a hidden URL parameter, e.g. "&prealq=yes".)
For some numbers (more than 10 digits), it is reconstructable, e.g.
[URL]http://factordb.com/search.php?query=10955390367[/URL] shows the membership in a sequence... but for less than 11 digits, explicitly suppressed, even though the database knows the answer!
Here's a challenge for you: what is the prealq number for this prime?
[URL]http://factordb.com/search.php?query=5445410143[/URL]
The answer: the database knows! Without the database, can you solve it?

To see if [URL="http://factordb.com/search.php?query=&se=1&aq=552150"]552150[/URL] or [URL="http://factordb.com/search.php?query=&se=1&aq=195528"]195528[/URL] have side-sequences, one needs to solve the equation above (or lookup database), iteratively.

Some numbers are branching. These are of great interest (and are already used for merges of course).
Some numbers, of course, cannot be reached, and can be only starting points.

Of course an alternative is obvious: screen-scrape all sequences and look for branching points, but it's ugly, taxing to the database and transient (tomorrow one would need to do that again).

2. Also, would it be possible to report "A side-sequence for <a slightly larger number>" for the sequences (of course with restrictions, let's say <100000 and less than 2-3 times larger parent sequence)? (Merges are of course reported to smaller parent sequences.) Basically, it is the same thing as question #1.

-S[/QUOTE]

Good point. I'll try to add it both, shouldn't be too hard, all it needs is another index + one query.

[QUOTE=smh;184468]Is it possible to query the DB and get only the last line of a sequence back?[/QUOTE]

not yet. To be added soon!

Thank you for submitting all these factors and bugs, it helps a lot to develop the database!

[QUOTE=Syd;185160]The next update will contain a lot of changes...[/QUOTE]

Just testing the worker.pl script.
It wants to create a .ini file and therefore - after asking for username and password - asks for the path to the ecm binary.
I enter "F:\GNU\msys1.0\home\Andreas\ecm-6.2.3\ecm.exe",

then ecm seems just to be sitting there forever and doing nothing. (according to the task manager it has a CPU useage of 0% and is still there after ~15 minutes). I guess it's supposed to do something?

(I am using Windows XP, I hope the script isn't just created for PCs running Linux.)

the worker.pl still have problems on WIN but runs on LINUX without problems.
Syd is working on that.

I hope a new worker.exe will be available for Windows users.
The old worker.exe works perfectly without trouble and is easy to use.

[QUOTE=Syd;185160]The next update will contain a lot of changes - a simple user management, points for running workers that can be used to do work ("time shift"), a perl worker script thats compatible with almost all platforms, a new "work"-system and some minor changes.[/QUOTE]

Amazing.

I hope you're able to take advantage of the time shifting as well -- let us finish some of your problems faster!

I just accidently unplugged the server's power supply :down:
Now its repairing the tables, some of them are marked crashed. If it goes wrong, last backup is just 8 hours old.