[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.