[QUOTE=schickel;240258]Back up, but still no elf files....:sad:[/QUOTE]

Elf files appear to be fixed!

wow - 25 workers connected :smile:[COLOR=Black][/COLOR][COLOR=Black]
[/COLOR]

The factor-DB seems to be down since a minute. I hope I didn't shoot it down by reporting a composite factor of 11^203+4^203.

Edit: the DB seems to have recovered.

[QUOTE=Andi47;243173]The factor-DB seems to be down since a minute. I hope I didn't shoot it down by reporting a composite factor of 11^203+4^203.

Edit: the DB seems to have recovered.[/QUOTE]

I added 1403633425066500143601563.

The remaining C155 is probably a =<4-way split.

[QUOTE=lorgix;243176]I added 1403633425066500143601563.

The remaining C155 is probably a =<4-way split.[/QUOTE]

I guess that too. I have reserved it on the [URL="http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl"]Homogeneous Cunningham Reservation page[/URL]. It has survived 600 ECM-curves at B1=11e7, switching to SNFS.

I wonder who will be the first to write a BOINC wrapper for a DB worker?

Only one is needed...

Question about sequences
 

This is a question for Syd really, since it deals with the backend code: if an aliquot sequence is uploaded and a connected worker factors the remaining composite on the last line, does the DB comtinue the sequence or does it only "discover" the continuation when someone looks at the sequence? (Sort of a DB Uncertainty Principle, if you will....:smile:)

I think that anyone wanting to BOINC-ify some DB tasks should do so only with tasks that require sufficient wall/CPU time (read: dozens of minutes), like GNFS > 95-100 and ECM > some threshold. The BOINC infrastructure does have its own overhead, too :smile:

That said, would using a BOINC infrastructure enable taking on tasks that one, or several, ad-hoc scripts of several hundreds SLOC cannot do ?

Congrats on your 68-74-split, Andi.

[QUOTE=RichD;243193]I wonder who will be the first to write a BOINC wrapper for a DB worker?

Only one is needed...[/QUOTE]

AKAIK the current worker are doing only short jobs. For Boinc the jobs should be longer. I run already ecm in Boinc: [url]http://www.rechenkraft.net/yoyo/[/url] Something which needs trial factoring before running snfs or gnfs is queued there. And there is already a Boinc project which runs gnfs/snfs. So basically we have all what we need already.

yoyo

[QUOTE=schickel;243195]This is a question for Syd really, since it deals with the backend code: if an aliquot sequence is uploaded and a connected worker factors the remaining composite on the last line, does the DB comtinue the sequence or does it only "discover" the continuation when someone looks at the sequence? (Sort of a DB Uncertainty Principle, if you will....:smile:)[/QUOTE]

I'm 99% sure that it's the latter -- when a new factorization is added to the DB, it doesn't automatically notice if that factorization happens to extend an aliquot sequence. The next time the sequence is queried, the new term is generated (or possibly several terms if they factor trivially) and whatever composite it contains is added to the DB.

I've observed this behavior many times with my workers; I query a sequence, and the resulting composite (if it's small) immediately shows up in the work queue.

As a result of all the recent scanning of the DB, all sequences <1M now have a composite >= 94 digits (the current level of the workers).

And Merry Christmas!

[QUOTE=bchaffin;243307]I'm 99% sure that it's the latter -- when a new factorization is added to the DB, it doesn't automatically notice if that factorization happens to extend an aliquot sequence. The next time the sequence is queried, the new term is generated (or possibly several terms if they factor trivially) and whatever composite it contains is added to the DB.

I've observed this behavior many times with my workers; I query a sequence, and the resulting composite (if it's small) immediately shows up in the work queue.

As a result of all the recent scanning of the DB, all sequences <1M now have a composite >= 94 digits (the current level of the workers).

And Merry Christmas![/QUOTE]So if I query the DB on everything on a regular basis, they would all end up kind of bumping along in fits and starts, since it would add new lines based on past small factoring, add more small composites to the factoring queue, rinse and repeat. Then stall when a composite was >100 digits.....

Looks like I need to work on an ECM client for the DB.....

PS. Have a safe and Merry Christmas this year!

[QUOTE=yoyo;243298]So basically we have all what we need already.[/QUOTE]

So all that is really needed is a scheduler, to move a composite from one network to another.

If it survives the local worker's work, then move it to low-medium ECM.
If it survives med-ECM, move it to high level ECM.
From high ECM to GNFS.

Syd had the beginnings of that with factordb v1.0 where the number of curves done were kept with the number. I wonder what his plans are moving forward??

[QUOTE=Andi47;229393]will there be a possibility to report ECM curves and p+/-1 runs in the new DB - to keep track of ECM work done?[/QUOTE]

[QUOTE=Syd;229511]Yes there will be. Maybe already tomorrow.[/QUOTE]

I can't see how to do this. Did tomorrow ever come?

If a number is fully factored, shouldn't its composite factors also be fully factored?

I just noticed that while 2^1024-1 is fully factored, (2^1024-1)/(2^32-1) isn't.

[b]Edited[/b] to add: I just noticed that the composite factor is newly [url=http://factordb.com/status.html]added to the database[/url], so perhaps the engine hasn't got around to checking the factors of the numerator.

[QUOTE=Mr. P-1;243876]If a number is fully factored, shouldn't its composite factors also be fully factored?

I just noticed that while 2^1024-1 is fully factored, (2^1024-1)/(2^32-1) isn't.

[b]Edited[/b] to add: I just noticed that the composite factor is newly [url=http://factordb.com/status.html]added to the database[/url], so perhaps the engine hasn't got around to checking the factors of the numerator.[/QUOTE]Sorry, that was me exploring a little bit. I think you'll find your issue is related to this discussion:[QUOTE=EdH;239838]Just out of curiosity, I explored whether the db held all the composites formed by partial factors of completed composites. My single experiment proved that it doesn't.

For example, I used a 16 digit prime and an 80 digit prime from an aliquot sequence index to form a 96 digit composite:
[code]
8459436595715687 * 14653287880309161044589092842674292343052930286602206880394528560151656381924491

= 123958559742244464497540221271690320401845288752589069609797736575128499708746594193158538190317
[/code]I then asked the db for info on the 96 digit composite. The db responded with no further info, other than the composite I supplied. I then supplied the 16 digit factor and the db completed the factorization. Now, if I enter the 96 digit composite, the db recognizes it and supplies its factors.

OK, I've taken a long way to my question, but here it is:

Would there be practical value in having the db form new composites from all the combinations of prime factors, complete with those factors?

In case all this wasn't clear enough, here's a scaled down version (assume composites [7843, 253, 341, 713] represent large numbers that are not yet in the db and the primes [11, 23, 31] are also large primes):
[code]
7843 = 11 * 23 * 31
11 * 23 = 253
11 * 31 = 341
23 * 31 = 713[/code]Would it be advantageous to supply the db (or have it create) the composites (253, 341, 713) along with the factorization of the original (7843)?

These composites would then be recognized by the db, if they turn up again. Instead of factoring these composites, the primes would already be known.[/QUOTE]Basically, if you report a factorization of a number by using "report factors" this way:[code]x = a * b * c * d[/code]the DB ends up knowing that a, b, c, & d are factors of x, but it doesn't know the other combinations like[code]ab = a * b
abc = a * b * c[/code]etc.

The problem is that if we start entering all the divisors of a composite, when does Syd run out of room?[QUOTE=Mini-Geek;239840]I think the probability that doing that would save any time at all in the long run is somewhere from 0 to very low. You're just way too unlikely to come across large numbers (say, >10^60) that are already factored, especially from its factors being parts of another. I'd think that for the most part, the previously-done numbers would usually have to be 3+ way SIQS/GNFS splits to be useful (since otherwise, most of the time, you can rarely combine factors in a way that would make a difficult-to-factor number in their own right). Just all in all: not worth the trouble IMHO.[/QUOTE]

[QUOTE=CRGreathouse;239853]There are hundreds of millions of primes in the database, call this P. Thus there are 2^P - P - 1 composites that could be formed in this way. This is too large to store in the universe, let alone in the DB.

If we look at just the semiprimes, there are P(P-1)/2 or tens of trillions, so even this is too large for the database (petabytes).

On the other hand, it would be just possible to test a given composite against all (smaller) primes in the database. If each test takes about a microsecond this would take a few minutes: too slow to do from the web page, probably, but could be done from the server.[/QUOTE]

[QUOTE=bchaffin;238511]There seems to be an error in the DB for this composite:
[URL]http://factordb.com/index.php?id=1100000000251375612[/URL]

It reports its factors as 2 * 2^4 * ... instead of 2^5. It's term 1396 of aliquot sequence 1019430, and it looks like this breaks the DB's algorithm for calculating the sum of the factors, so subsequent terms are wrong.

Is posting this here the right way to report an error, or is there some other way?[/QUOTE]Missed this one: yes, this is an error, and one that Syd will have to fix locally. There is no "repair sequence" button for the new version...

If you're working it locally, save the elf file until Syd gets this one fixed, so you can re-up it.

Anomaly in DB
 

Another anomaly in the data base. If one were to inquire into the list of "Composite numbers without known factors" from the Status page and then request Digits at 95 (leaving all other values at default), one would see a couple 7 digit numbers. Upon further investigation of the numbers, there appears to be a modular arithmetic symbol (%) in the expression.

[QUOTE=RichD;244055]Another anomaly in the data base. If one were to inquire into the list of "Composite numbers without known factors" from the Status page and then request Digits at 95 (leaving all other values at default), one would see a couple 7 digit numbers. Upon further investigation of the numbers, there appears to be a modular arithmetic symbol (%) in the expression.[/QUOTE]I noticed one of those. Clicking on the number showed it as "C", but the page had all the factors on it. After a couple of minutes, the status changed from "C" to "FF".....kinda odd.

[QUOTE=schickel;244062]I noticed one of those. Clicking on the number showed it as "C", but the page had all the factors on it. After a couple of minutes, the status changed from "C" to "FF".....kinda odd.[/QUOTE]

Hmm, I didn't notice any change (still indicates a C). The numbers in question I was looking at were 1210016 & 1210012.

The anomaly is only noticeable from the list of 95 digit composites.

Found several more.

On the 96 composite page(s) there are:
1210011
1210017
1210002
1210003

On the 97 page(s):
1210005
1210000
1210010
1210013

Note: They may not appear on the first page of each size.

[QUOTE=RichD;244063]Hmm, I didn't notice any change (still indicates a C). The numbers in question I was looking at were 1210016 & [B]1210012[/B].

The anomaly is only noticeable from the list of 95 digit composites.[/QUOTE]1210012 was the one I saw, and to make it even weirder, if you search this [URL="http://factordb.com/index.php?query=n&use=n&n=1210010&VP=on&VC=on&EV=on&OD=on&PR=on&FF=on&PRP=on&CF=on&U=on&C=on&perpage=20&format=1"]way[/URL], 1210012 shows up as "FF" which is what I saw. It looks like the expression parser is thrown off by the "%" in the [URL="http://factordb.com/index.php?id=1100000000217043267"]expression[/URL].....have you tried any other expressions with a "%" in them?

[QUOTE=schickel;244065]It looks like the expression parser is thrown off by the "%" in the [URL="http://factordb.com/index.php?id=1100000000217043267"]expression[/URL].....have you tried any other expressions with a "%" in them?[/QUOTE]

I didn't introduce the "%", I just noticed it when I inquired why a c7 was in the list of c95s.

[QUOTE=RichD;244066]I didn't introduce the "%", I just noticed it when I inquired why a c7 was in the list of c95s.[/QUOTE]I realize that; I saw it the same way. I was wondering if you had experimented with other expressions with a "%" in them....it would be interesting to see where the "%" figures in the hierarchy of symbols while parsing expressions.

[QUOTE=schickel;244049]Sorry, that was me exploring a little bit. I think you'll find your issue is related to this discussion:Basically, if you report a factorization of a number by using "report factors" this way:[code]x = a * b * c * d[/code]the DB ends up knowing that a, b, c, & d are factors of x, but it doesn't know the other combinations like[code]ab = a * b
abc = a * b * c[/code]etc.

The problem is that if we start entering all the divisors of a composite, when does Syd run out of room?[/QUOTE]Note that it need not run out of room as fast as I understand (or perhaps misunderstand) you think it will. Storing all products of all primes in the database does indeed require space exponential in the number of primes.

On the other hand, testing a submitted composite for divisibility by all primes in the data base is only linear in the number of primes. The asymptotic behaviour is [I]much[/I] better. Whether the implied constant is small enough to be acceptable remains to be seen.

The converse check may also be valuable: given a newly found prime factor of a specific composite, does it factor any other composite in the database?

FWIW, I'm at the start of implementing a PostgreSQL database to support my own factoring activities, not least to make production of reports and web updates much more reliable and less laborious than my present manual processes. Something I've been pondering over the last few days is whether to perform the checks described above.

Paul

[QUOTE=xilman;244093]On the other hand, testing a submitted composite for divisibility by all primes in the data base is only linear in the number of primes. The asymptotic behaviour is [I]much[/I] better. Whether the implied constant is small enough to be acceptable remains to be seen.[/QUOTE]

My estimate in [url=http://mersenneforum.org/showthread.php?t=11119&page=39#post239853]post #963[/url] was that this would take several minutes. This is too long to test every prime that's found (by a factor of at least 10), but certainly it could be done if there was a number that was suspected to be special.

I noticed that the DB now has a worker dedicated to "Verifying primality certificates". Does this mean there is now a system in place for submitting Primo certificates on PRPs in the database?

[QUOTE=schickel;244049]Sorry, that was me exploring a little bit.[/QUOTE]

Actually, I'm pretty certain it was me.

[QUOTE]I think you'll find your issue is related to this discussion:Basically, if you report a factorization of a number by using "report factors" this way:[code]x = a * b * c * d[/code]the DB ends up knowing that a, b, c, & d are factors of x, but it doesn't know the other combinations like[code]ab = a * b
abc = a * b * c[/code]etc.[/QUOTE]

In this case x was already in the database, but I queried x/y where y factorised as c*d x/y got added to the database, but it did not immediately recognise that x/y had to factorise as a*b.

[QUOTE]The problem is that if we start entering all the divisors of a composite, when does Syd run out of room?[/QUOTE]

well I don't know. There's obviously a limit to now many numbers he can store, and how many 'is a factor of' connections he can store between them. But given that the database is accepting new numbers wholesale*, I see no indication that we're near any kind of limit.

However I see no reason to add such numbers. If x fully-factored in the database, and someone queries x/y then the server could immediately return its factors. No need to store anything.

*I never entered (2^1024-1)/(2^32-1). I entered (2^(x^2)-1)/(2^x-1), and ended up adding a whole list of new ones.

[url=http://factordb.com/index.php?id=1100000000265624725]Here's another example[/url], currently listed as only partially factored, but with a fully factored numerator. It's even showing a scan button to let people waste workers' time on them.

[QUOTE=schickel;244068]I realize that; I saw it the same way. I was wondering if you had experimented with other expressions with a "%" in them....it would be interesting to see where the "%" figures in the hierarchy of symbols while parsing expressions.[/QUOTE]

At first, I thought it was a malicious attack on the DB (it wouldn't be the first). Then I ran across the others and noticed the pattern in the expression. I think someone was trying to build a factor table with variables and it ended up being an accidental run away.

No, I haven't tried any other symbols or any modifications using "%". I didn't want my paw prints on these incase it was later found to be malicious.

Happy New Year
 

I wonder if someone should capture a pict of the Status page for the New Year. To see how far it may have gone in the months ahead. Or capture it once every New Years Eve to see how the numbers have grown.

[QUOTE=mdettweiler;244160]I noticed that the DB now has a worker dedicated to "Verifying primality certificates". Does this mean there is now a system in place for submitting Primo certificates on PRPs in the database?[/QUOTE]

I don't see any way, but the worker has a largely-steady stream of work to do, so I'm guessing it currently is just for verifying the work done by the other workers.

The db is not accepting any of my automatic factor reports via Aliqueit from any of my machines. Am I on the wrong list?:smile:

The wget session link establishes, but the db just doesn't do anything with the provided lines.

[QUOTE=EdH;244387]The db is not accepting any of my automatic factor reports via Aliqueit from any of my machines. Am I on the wrong list?:smile:

The wget session link establishes, but the db just doesn't do anything with the provided lines.[/QUOTE]
Seems to be working right now...

Wouldn't it be nice if the "Factor Tables" could use two variables at the same time?

Another thing I'd like to see is filtering and/or sorting by size of C or CF.

Is there a listing somewhere of the urls to use with the db to retrieve data in particular formats?

i.e.
[code]
[URL]http://factordb.com/aliquot.php?type=1&aq=509466&big=1[/URL]
means to retrieve the graph for aliquot sequence 509466

[URL]http://factordb.com/sequences.php?se=1&eff=2&aq=509466&action=range&fr=1440&to=3000[/URL]
means to retrieve the range 1440 to 3000
[/code]

Where can I find the list of (available) criteria?

Thanks!

The database is offline for a few hours (full backup, optimizing tables, some updates)

[QUOTE=Andi_HB;245348]The database is offline for a few hours (full backup, optimizing tables, some updates)[/QUOTE]Looks like it's back up, and with some nifty new features.....I forgot what password I used last time, though. Is there any way to reset my password?

Awesome new stuff.


Error here though;

[URL="http://factordb.com/index.php?query=%2819%5En%2B1%29%2F20&use=n&n=1&VP=on&VC=on&EV=on&OD=on&PR=on&FF=on&PRP=on&CF=on&U=on&C=on&perpage=200&format=1&sent=Show"]http://factordb.com/index.php?query=%2819^n%2B1%29%2F20&use=n&n=1&VP=on&VC=on&EV=on&OD=on&PR=on&FF=on&PRP=on&CF=on&U=on&C=on&perpage=200&format=1&sent=Show[/URL]

[QUOTE=schickel;245417]Looks like it's back up, and with some nifty new features.....I forgot what password I used last time, though. Is there any way to reset my password?[/QUOTE]

I don't see a way, but due to the "Not working yet!" notice on the login page, and the fact that my old login isn't working even though I can't reregister the same name, I'd say don't mind that for now. :smile:
Biggest new thing I've noticed is the ability to submit a Primo certificate to tell the DB that a PRP is prime. At the current (minimum unproven PRP) size of 306 digits, using Primo on one core of my quad can average about 8.3 seconds per proof. Very cool. :cool:

[QUOTE=Mini-Geek;245542]Biggest new thing I've noticed is the ability to submit a Primo certificate to tell the DB that a PRP is prime. At the current (minimum unproven PRP) size of 306 digits, using Primo on one core of my quad can average about 8.3 seconds per proof. Very cool. :cool:[/QUOTE]

Nice! And much better than the "set prime" button in the old database.

I've just completed all 306 and 307 digit numbers. :-)

I'll run a batch of 500 starting at 309 next

I found a problem from the DB.

[url]http://factordb.com/index.php?id=1100000000217043267[/url]

This 7 digit number 1210012 is fully factored, but its status is still "C".

It's the '%' again. It has been discussed earlier in the thread.

[QUOTE=lorgix;246729]It's the '%' again. It has been discussed earlier in the thread.[/QUOTE]
Yes [URL]http://factordb.com/index.php?query=1210012[/URL] is correct.

Is there a way to get the database's known factorizations of the form p^q-1, p an odd prime, q a prime?

[QUOTE=wblipp;246839]Is there a way to get the database's known factorizations of the form p^q-1, p an odd prime, q a prime?[/QUOTE]

Maybe.
In example: http://factordb.com/index.php?query=x^3-1&use=x&x=2&VP=on&OD=on&PR=on&FF=on&PRP=on&CF=on&U=on&C=on&perpage=200&format=1&sent=Show

[QUOTE=wblipp;246839]Is there a way to get the database's known factorizations of the form p^q-1, p an odd prime, q a prime?[/QUOTE]

In the factorDB see the link [url=http://factordb.com/tables.php]Factor tables[/url] and from the listed tables choose [url=http://factordb.com/tables.php?open=9]Others[/url].

There're several terms listed, including Cunningham numbers b^n-1.

Choose 'Show' to get the screen of this table.
Deselect "b is even" and "b is composite", n is set to 1 by default (fill in a different value if needed) and click 'Show' to update the results.

Sequence 84822 is broken, see here: [url]http://www.mersenneforum.org/showthread.php?t=14859[/url]

[QUOTE=kar_bon;246962]In the factorDB see the link [url=http://factordb.com/tables.php]Factor tables[/url] and from the listed tables choose [url=http://factordb.com/tables.php?open=9]Others[/url].

There're several terms listed, including Cunningham numbers b^n-1.

Choose 'Show' to get the screen of this table.
Deselect "b is even" and "b is composite", n is set to 1 by default (fill in a different value if needed) and click 'Show' to update the results.[/QUOTE]

It looks like if a page would require numbers that have not been previously considered, they are automatically generated and trial factored - is that right?

I've noticed that the database erroneously omits some small factors of the following 77-digit numbers:

[CODE]
80978084394598568390520920252440060895670346459831516622284554518849503146397
82609404176288347510975214065063503631619108607371480044587508148396968704911
88236918639719858997946921372584311423090252002347982879826766163694271697843
88894857952232839709785628818457172955757575436001096904562755715875193607509
92250106588933435730861605431146390431716761868772836262451636991161111409211
96219970786531934764768710647149833037379504561939264511368166182316972958369
[/CODE]

[QUOTE=wblipp;247079]It looks like if a page would require numbers that have not been previously considered, they are automatically generated and trial factored - is that right?[/QUOTE]
Yes.

@Syd: just curious, what program are you using for N-1 and N+1 tests? I tried putting in a known small-ish prime with a trivial N+1 factorization ([URL="http://www.factordb.com/index.php?query=3%5E25032%2A50633872-1"]50633872*3^25032-1[/URL]) to have the DB take a whack at it, and it somewhere in the vicinity of 12-20 minutes to do the N+1 test. My computer took just 90 seconds to do it even with the old (1.2) version of PFGW, so I'm guessing you must be using something different.

Looks like the gremlins are back :no:

[URL="http://factordb.com/sequences.php?se=1&eff=2&aq=248130&action=last20&fr=0&to=100"]248130[/URL] is now MIA, too....

[QUOTE=warut;247091]I've noticed that the database erroneously omits some small factors of the following 77-digit numbers:

[CODE]
80978084394598568390520920252440060895670346459831516622284554518849503146397
82609404176288347510975214065063503631619108607371480044587508148396968704911
88236918639719858997946921372584311423090252002347982879826766163694271697843
88894857952232839709785628818457172955757575436001096904562755715875193607509
92250106588933435730861605431146390431716761868772836262451636991161111409211
96219970786531934764768710647149833037379504561939264511368166182316972958369
[/CODE][/QUOTE]Looks like not just those.....I was looking at the list of unfactored composites and found this one:[code] FF 21 (show) 476006172212715945491<21> = 49974229[/code]That should actually be:[code]476006172212715945491 = 520763 (Curve 1) x 18290533 (Curve 1) x 49974229[/code]Maybe a missing index?

[QUOTE=schickel;247167]Looks like the gremlins are back :no:

[URL="http://factordb.com/sequences.php?se=1&eff=2&aq=248130&action=last20&fr=0&to=100"]248130[/URL] is now MIA, too....[/QUOTE]

I've probably found 4-5 of these just browsing around in the last 15 minutes. The gremlins are out in force. :yucky:

[QUOTE=schickel;247167]Looks like the gremlins are back :no:

[URL="http://factordb.com/sequences.php?se=1&eff=2&aq=248130&action=last20&fr=0&to=100"]248130[/URL] is now MIA, too....[/QUOTE]
Looks fine now. Perhaps whatever the problem was has since been resolved?

Zip library broken
 

I've had a problem uploading Primo certs or getting a batch of PRPs to work on.

Uploading a zip file gives "0 certificates found, 0 certificates added." Trying to download a new batch of input files gives the source of the download page, but with a .zip extension....

[Edit: Whups, it's actually totally broken.....uploading a single cert gives an error: "Not a PRIMO certificate"]

[QUOTE=schickel;250774]
[Edit: Whups, it's actually totally broken.....uploading a single cert gives an error: "Not a PRIMO certificate"][/QUOTE]

I had that same message when I tried to upload a .cr file instead of a .out file

Luigi

[QUOTE=schickel;250774][Edit: Whups, it's actually totally broken.....uploading a single cert gives an error: "Not a PRIMO certificate"][/QUOTE]

[QUOTE=ET_;250789]I had that same message when I tried to upload a .cr file instead of a .out file

Luigi[/QUOTE]Another of those intermittent problems. The certs loaded fine just now....(and I got some more PRPs to chew on.)

db Guru Help Request
 

How do I use wget to retrieve a [B]clean[/B] elf file without leading and trailing garbage?
[code]
wget "http://factordb.com/elf.php?seq=159978" -O Test159978.elf

or

wget "http://factordb.com/elf.php?seq=159978&type=1" -O Test159978.elf

or, several other things I've tried, including the older search.php versions...
[/code]...best result for any attempts:
[code]
[COLOR=Red]5e5ef[/COLOR]
0 . 159978 = 2 * 3 * 7 * 13 * 293
1 . 235158 = 2 * 3 * 7 * 11 * 509
2 . 352362 = 2 * 3 * 58727
...
3230 . 257469686632080847016144154640723162457002040467095575936113982164854371218672945325173911559672660014950268 = 2^2 * 3 * 7 * 53 * 241279058983 * 66443697345877 * 28826034541500877367960116238060123 * 125144746913067089723410315497905716995589463
3231 . 442070594031576942610743839873687312033576217704968196906321544358946158090482751730066571082202347756787844 = 2^2 * 3 * 7 * 11 * 593 * 1993 * 440789663 * 8618858183434237 * 1943371990666116371 * 54830295787184191519985269515892871132256922604872458919
3232 . 846767987301449255217862850803252789984702997936839330116065333169340783453579157175365478554037752003094396 = 2^2 * 3 * 7 * 11 * 7677943333
[COLOR=Red]
0 [/COLOR]
[/code]I can write a filter to remove the trash, but I would rather not have to.

[QUOTE=EdH;251710]How do I use wget to retrieve a [B]clean[/B] elf file without leading and trailing garbage?
[/QUOTE]

Here's an example for sequence 4788:
[CODE]
wget "http://factordb.com/search.php?se=1&aq=4788&action
=last&text=Text&raw=1" -q -O alq_4788.elf
[/CODE]

[QUOTE=bchaffin;251715]Here's an example for sequence 4788:
[CODE]
wget "http://factordb.com/search.php?se=1&aq=4788&action
=last&text=Text&raw=1" -q -O alq_4788.elf
[/CODE][/QUOTE]That works, or you can use the format of the "Download .elf file" link from the sequence page:[code]http://factordb.com/elf.php?seq=4788&type=1[/code]

[QUOTE=bchaffin;251715]Here's an example for sequence 4788:
[CODE]
wget "http://factordb.com/search.php?se=1&aq=4788&action
=last&text=Text&raw=1" -q -O alq_4788.elf
[/CODE][/QUOTE]
Thanks, but that's what I used to use before the db upgrade and it's also one of the search.php references from my previous post. Does this actually work correctly for you guys, or do you filter out the garbage somewhere? I get the following on several WinXP, Fedora and Ubuntu machines, using your exact example (minus the crlf):
[code]
[COLOR=Red]5a7a7
[/COLOR]0 . 4788 = 2^2 * 3^2 * 7 * 19
1 . 9772 = 2^2 * 7 * 349
2 . 9828 = 2^2 * 3^3 * 7 * 13
3 . 21532 = 2^2 * 7 * 769
...
2614 . 950694750891399537774506607569227707243584239810766994617105763298134474411523552640927629495296051190146771947077202838992064785979661115875969788941362541369328266037136528 = 2^4 * 153485659 * 15001788992106204851 * 7904030188472445800999821087 * 3131857265787001920849047909972699 * 1042460735970821722717442901150875158725290458103769196335312838338655969091227313749
2615 . 891276340961619869583852578560456385845894067834432241186080795464687218769515514426271743711536845547799905030957854362094169750036091060575376106269952814372988072202863472 = 2^4 * 179 * 7793 * 50527 * 5586341 * 3700301944592570904281 * 97219622210393346158104222098978591299 * 393271649708717468267245625827714408197114509242796420944928464009313769873612586453115790508117
2616 . 845476275203580267760017766432229247474240350776638338491432287237591892584336198742892209876065652639662701929236838342591531452910872710622830879913662039251337677197712528 = 2^4 * 59 * 992659 * 902255102166423490009671343126746462171001080346755978958731265753241892572715498054792487878159386530741134577019773281284532051603184134287890966817985022169929193
2617 . 820400267269150543602962894738615578763678283519001731044671684330868467986754886573378568615803023098843518118320635207852289217689742468077694315732404243268057882314121872 = 2^4 * 23
[COLOR=Red]
0
[/COLOR][/code]Is it possible that only "I" am having this issue? It's showing up across platforms. It would have to be a pretty selective occurrence to only hit me, but still hit all my machines - ISP specific, I suppose.

The Download link is fine for manual retrieval, but it's useless for my AliWin program or the AliPerl script.

[QUOTE=EdH;251721]Is it possible that only "I" am having this issue? It's showing up across platforms. It would have to be a pretty selective occurrence to only hit me, but still hit all my machines - ISP specific, I suppose.
[/QUOTE]

I'm getting the same '5a7a7' at beginning and '0' at the end!

There's an error in the FactorDB because I know it worked fine, when I used this to download current data and make a table from those.

[QUOTE=kar_bon;251722]I'm getting the same '5a7a7' at beginning and '0' at the end!

There's an error in the FactorDB because I know it worked fine, when I used this to download current data and make a table from those.[/QUOTE]
Thanks for checking, kar_bon. It used to work for AliWin, too. But, now, aliqueit crashes when it does the initial file read.

I thought Maybe it was just that the search criteria had changed. I guess that's not the reason and I'm not singled out.

[QUOTE=kar_bon;251722]...There's an error in the FactorDB because I know it worked fine, when I used this to download current data and make a table from those.[/QUOTE]
I suppose the follow-on question would be whether anyone who is capable, considers this important enough to fix...

sorry for being late with all these bugfixes.
Just got the "5a7a7"-one. I forced the webserver to use HTTP/1.1 in the reply, but forgot that some clients like wget do not support features like chunked encoding. Now its back to 1.0-Request -> 1.0 Reply, looks like its working.

@mdettweiler
I use my self-written routines at the moment, but they are really slow, especially the N+1-one. Going to switch this over to pfgw some time.

Some bugs, as you wrote me / wrote here (thanks for your help!)
-The % in terms is handled with the wrong priority
-No limit in parallel "scan-button-clicks" could overload the server
-Some large terms exceed the memory limit
-Still no merge detection within sequences (sorry)

@gremlins:
they appear if the disk is full and pfgw cannot write its logfile :smile:

@all:
thank you for contributing so many certificates. Its more than 4GB already and growing!

Thank you for all the work, Syd! I appreciate it. I did add a step into my AliWin program to filter out extraneous lines. Now, I can take that back out.

A question - I had been having AliWin (GUI for Aliqueit) hit the db for the last line when getting ready to send data, but now I seem to only be able to retrieve the entire file. Additionally, if I retrieve the file to decide where to start sending, the subsequent send operation frequently times out. Consequently, I have changed the process to only hitting the db once, but sending the entire file each time. Any thoughts? Is there a "spam" delay that I'm hitting by retrieving the file and then turning around and sending too soon?

Thanks again for all your work.

Take Care,
Ed

Syd,
I think I might have broken something. I made the mistake with typing a wget that had 'eff=1' instead of 'eff=2' :

wget "http://factorization.ath.cx/sequences.php?se=1&eff=1&aq=276&action=last" -O last_276.http

It never came back (I ^c'd after a bit) and the database went away (not reachable by browser). I really hope I didn't damage anything.
Jay



Sorry about that chief! - Maxwell Smart

Syd is now reporting a power outage and that the DB will be back soon.

Hi everyone,

there was a power outage today, allowing the server to cool down for about 3 hours. I bought an UPS for it some time ago, but it wasnt able to keep it up long enough for a clean shutdown - instead it blew up one battery after just one minute and left a toxic smell.
Now I'm repairing the tables again. I also have a recent backup, but that wont be necessary. When done I'll tune it a little bit and add some minor updates.

@EdH
There was a high load on the server sometimes, mainly cause there is no limit on scan-queries. I think this caused the timeouts. I'll reprogram the sequence-section anyway - put this on my list. There is a spam delay, but thats set really high, about 4 pages/second. Just to catch some spambots and googlebot crawling too fast.

@Greebley
No, you didnt :smile:

[QUOTE=Syd;254339]...
@EdH
There was a high load on the server sometimes, mainly cause there is no limit on scan-queries. I think this caused the timeouts. I'll reprogram the sequence-section anyway - put this on my list. There is a spam delay, but thats set really high, about 4 pages/second. Just to catch some spambots and googlebot crawling too fast.
...
[/QUOTE]
Right now I've stopped hitting the db twice and just have the program submitting the full elf. Once I do get the last line only "wget" working correctly, I'll build in a slight delay between db check and Aliqueit send. Of course, I can't guarantee what version of AliWin others are using, but I'll try to keep the available one current. Actually, I really need to set it up to keep track of what has been sent within the current program invocation, and leave the db alone. Otherwise, the only reason for a db check is to catch merges, and neither my program nor the db are currently looking for merges.

Sorry to hear (and see) about the battery. Thanks much for all the work.

Some problems still in the DB (maybe from the power outage?). These two sequences, that I know of, show up blank (status is from the last time I polled):

282810 375. sz 113 2^3 * 3 * 5
515028 320. sz 103 2^3 * 3^3 * 5 * 73

[QUOTE=schickel;254433]Some problems still in the DB (maybe from the power outage?). These two sequences, that I know of, show up blank (status is from the last time I polled):

282810 375. sz 113 2^3 * 3 * 5
515028 320. sz 103 2^3 * 3^3 * 5 * 73[/QUOTE]

434700, 468360, 740736, and 947880 also show up blank.

In addition, there seem to be some errors in some of the existing sequences. For example, [URL="http://factordb.com/sequences.php?se=1&eff=2&aq=390992&action=last20&fr=0&to=100"]390992.744[/URL] shows up as:

[URL="http://factordb.com/index.php?id=2"][COLOR=#000000]2^3[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=7"][COLOR=#000000]7[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=1100000000296072720"][COLOR=#002099]1805225369...[/COLOR][/URL]<98>

Where the 98-digit cofactor is actually composite. The following terms of the sequence are still correct, but the factorizations are not.

Another power outage?

We should start a fund raiser and donate a decent UPS system to Syd..

The first numbers of Smallest probable primes are wrong with certificates:
2^1156-293<348> 2^1156-399<348> 2^1158-681<349> 2^1410-41<425> 2^1416-203<427> 2^1416-587<427> 2^1416-117<427> 2288091351...<445> 2^1668-453<503> 2^1668-23<503> 2^1820-663<548>

Maybe the sequence cache is not up to date anymore .. I'll delete it and let it rebuild. Hope that will fix it.

@mataje

whats wrong with these PRP's?

Hi Syd: The 445 digits is proven by certificate (Ignacio Santos) and for the others I have send certificates.

[QUOTE=Syd;254650]Maybe the sequence cache is not up to date anymore .. I'll delete it and let it rebuild. Hope that will fix it.[/QUOTE]That may have done it. I checked 282810 and the status looks OK. I'll download one of the problem sequences and check the integrity.

Fantastic work on the DB!

[QUOTE=schickel;254695]That may have done it. I checked 282810 and the status looks OK. I'll download one of the problem sequences and check the integrity.

Fantastic work on the DB![/QUOTE]

Yep, everything looks clean now. In addition, the error I reported in [URL="http://www.mersenneforum.org/showthread.php?p=238511#post238511"]this post[/URL] is also fixed (maybe a while ago).

Syd, let me add my thanks to the many others already posted here for all your work on creating and maintaining the DB. It's a fantastic resource and I've really enjoyed getting involved in the sequences -- it wouldn't be nearly as fun or interesting without your central repository for results.

Tha FactorDB seems to have problems with the HomePrime base 10 sequence:

For example for n=363 the FactorDB ends in a prime although the correct value is open ended (compare with mersennewiki for single indices).

I've informed Syd.
I've not yet checked other bases (2 or 6 on my page) with the FactorDB.
Furthermore it's not clear if other types of sequences affected, too (aliquot, etc.).

Thanks Mathew Steine for the hint.

Thanks you schickel and bchaffin and everyone else for helping!

I think I found & fixed the HP-bug. Sometimes small factors were not sorted correctly, causing a wrong next index. But we'll see ..

[QUOTE=Syd;255639]I think I found & fixed the HP-bug. Sometimes small factors were not sorted correctly, causing a wrong next index. But we'll see ..[/QUOTE]

The erroneous HP10-cases I found are correct now!

Thanks Markus.

What's this?

[QUOTE=lorgix;256173]What's this?[/QUOTE]

Thats a new function I'm implementing, but not done yet. Just forgot to remove it from the functiontest.

[QUOTE=Syd;256206]Thats a new function I'm implementing, but not done yet. Just forgot to remove it from the functiontest.[/QUOTE]

:smile:

Luigi

[QUOTE=cmd;256344]... update status table ...

[COLOR="Lime"]U[/COLOR]nit or [COLOR="Red"]U[/COLOR]ndefined

U >>> [url]http://factordb.com/index.php?id=1100000000295916578[/url]

[COLOR="LemonChiffon"](_|\/|_)[/COLOR][/QUOTE]

No problem, changed it

[QUOTE=cmd;256348]
would be possible to see last digit,
in this wonderful utility? ...[/QUOTE]

Sure. Just one or maybe some more?

[QUOTE=cmd;256465]( [url]http://factordb.com/index.php?id=1100000000304781066[/url] )

secondary (optional)

... Current state of progress bar ... ( tips )[/QUOTE]


It will end up eating more processing power that could otherwise be given to primality proving... :smile:

Luigi

[QUOTE=ET_;256491]It will end up eating more processing power that could otherwise be given to primality proving... :smile:

Luigi[/QUOTE]

Yes, thats the point. I moved the info about N+1 and N-1 into the box to avoid opening them on every page.

[QUOTE=cmd;256492]( it ) grazie Luigi per il chiarimento, quella non era una opzione indispensabile,
sarebbe invece più utile poter estendere la conversione base36 alla base64 [COLOR="LemonChiffon"]
p.s. pensiamo comunque che un tips non incida sui tempi di elaborazione e prova ...
è applicabile rilevando un valore dalla seconde schermata e visualizzando "una barra di avanzamento standard" questo eviterebbe di dover visualizzare una seconda pagina web
per i PRP ...[/COLOR][/QUOTE]

I use the gmp_strval function to display it, and within the installed version it only supports base 36. I'll change it when I install a new one.

[QUOTE=cmd;256561]why not ?[/QUOTE]

A lot of that info is in (show).

I'd like the "Report factors" box to be shown by default, just like before. It's inconvenient to click the arrow every time before entering the factors, especially if there are more than a few numbers to deal with.

Also, I'd like to be able to log in to the database from different computers simultaneously.

Thanks in advance.

[QUOTE=warut;257767]I'd like the "Report factors" box to be shown by default, just like before. It's inconvenient to click the arrow every time before entering the factors, especially if there are more than a few numbers to deal with.[/QUOTE]

I second this request.

The db has been unavailable for a few hours.

[CODE]Warning: mysql_connect() [[URL="http://factordb.com/function.mysql-connect"]function.mysql-connect[/URL]]: Can't connect to MySQL server on '192.168.0.2' (4) in /apache/htdocs/database.php on line 13
Could not connect to database
[/CODE]

[QUOTE=cmd;258839]be possible new option "hide / show" factored .. 5 (/ p5)[/QUOTE]
Perhaps I'm not understanding the request, but in case I am, wouldn't the capability of hiding certain individual factors lend to possible confusion? I do not see that as a good thing.

I would think for clarity, if a number is fully factored, it should show the [U]full set[/U] of factors[B].[/B] What purpose would be served by displaying:
[code]
30030 = 2 * 3 * 7 * 11 * 13
[/code]
It is not correct!

We have enough erroneous information on the Internet already. Let's not make it easier to misread.