[QUOTE=EdH;279421]@chris2be8: Your version produces an error:
[code]
syntax error at dbc.pl line 21, near ""./yafu \"factor($composite)\" |";"
Execution of dbc.pl aborted due to compilation errors.
[/code]I had to remove the first semicolon:
[code]
open(YAFU, "yafu \"factor($composite)\" |"[COLOR=Red];[/COLOR]) or die "Couldn't start yafu to factor $composite $!";
open(YAFU, "yafu \"factor($composite)\" |") or die "Couldn't start yafu to factor $composite $!";
[/code]Thanks everyone - sorry to not be able to fix these types of simple troubles on my own - maybe someday...[/QUOTE]

Sorry, that's what I get for posting untested code. The preview doesn't look exactly like the final post which tripped me up.

Chris K

PS. Look at what has happened to the code inside the quote above. I thought I had fixed it all but missed the extra ;

[QUOTE=chris2be8;279520]Sorry, that's what I get for posting untested code. The preview doesn't look exactly like the final post which tripped me up.

Chris K

PS. Look at what has happened to the code inside the quote above. I thought I had fixed it all but missed the extra ;[/QUOTE]
No real problem. At least I was able to figure that one out without help...

Your preview sounds odd, though. On all my machines, I've never noticed this behaviour. As far as I remember, all my previews are WYSIWYG...(or, maybe more precisely, WISIWIG...):smile:

Now there is more than 19000 numbers in the db for that 10 Miller-Rabin tests fails (with gmp-5.0.1), the previous count was approx. 1500. See [url]http://factordb.com/prooffailed.php[/url]

And a new world record (in this gmp version): for n=5376825678759197295101416291 I have found that 17 Miller Rabin tests fails! The previous (public) record was for n=76963568720428328358838771 and order=16, but that was not in the db.

Please allow me to make two small suggestions for a better exploitation of factorDB. I am already vaccinated for the fact that my suggestions are never implemented nor considered (see the story with Cullen numbers, and some other before), but considering that Syd and the other gods there have also a RL life and RL jobs to do, I would still make the suggestions:

1. The "Sequences" tab should have a longer radio-button list, to include "Show last 10 elements", "Show last 5 elements", and/or 3, 2 elements.
[B]Argument:[/B] there is no way to see last few terms of the sequence, beside of loading all sequence or loading the last 20 terms. To show only the last term is not good when you want to see how the "drivers/guides" changed, and the "20 terms" version is slow sometime. As the number of factors or the factors themselves are getting larger, this is also not fitting the screen, and you have to scroll up/down to see the last terms which interest you. Showing "from/to range" is also not useful, except to see parts of the sequence which you know their existence (beginning of the sequence, for example), but can't be used to see the end of the sequence as long as you don't know how long the sequence is.
[B]Benefits:[/B] If "10/5/3" terms version is implemented, the database searching engine would spent less time in looking/printing the terms. Speed gain. Most of the "leeches" (like me :P) are interested only in last few terms, 2-3 would be enough, to see the last term and to see how the driver changed. I don't need to see all last 20 terms, and first 17 of them would mean nothing for me when I work a sequence. If I need them I can make anytime a new request with "show range".

2. I would recommend changing the printing format for numbers bigger then 50 digits, to show last 2 (two) digits instead of last digit only.
[B]Argument:[/B] This is also related to aliquot sequences. They would gain/lose guides/drivers when some/all factors are in a certain class modulo 4. For example 2^x*3*bla*bla... can lose the 3 if x is even and each "bla" is 1 (mod 4), etc. That is why I am often interested to see the last TWO digits of the prime factors bigger then 50 digits, and also of the remaining composite cofactor (to see if it has any chances to split in two or more primes which are 1 mod 4, etc). For that, I always click on them to see them in full, this producing "overwork" for the data base. And I am sure that I am not the only one doing this.
[B]Benefits:[/B] Displaying one additional digit at the end of the number would avoid all the overload mentioned above, and would help us understand better the properties of drivers/guides, by looking how they get/lose powers of 2, 3, and 5 (they are all related to the classes of the factors modulo 4).

So, instead of "1023456789...1[SUB]<70>[/SUB]" it should be displayed as "102345678...71[SUB]<70>[/SUB]", using the same number of characters, or adding one additional character if there is no trouble with the space (i.e. keeping the "9" of the example). For the last one, I can see immediately that is 3 (mod 4), without clicking on it, and I know it has no chances to split into factors which are all 1 (mod 4).

[QUOTE=LaurV;280505]1. The "Sequences" tab should have a longer radio-button list, to include "Show last 10 elements", "Show last 5 elements", and/or 3, 2 elements. [/QUOTE]
Maybe it would be simpler in the interface, and allow more flexibility, to replace "Show last 20 elements" with "Show last __ elements" (i.e. a text box), so you can enter however many you want to see, with the text box defaulting to 20.
[QUOTE=LaurV;280505]2. I would recommend changing the printing format for numbers bigger then 50 digits, to show last 2 (two) digits instead of last digit only. [/QUOTE]

I second this suggestion. :tu:

[QUOTE=Mini-Geek;280523]Maybe it would be simpler in the interface, and allow more flexibility, to replace "Show last 20 elements" with "Show last __ elements" (i.e. a text box), so you can enter however many you want to see, with the text box defaulting to 20.[/QUOTE]


I was thinking something like show last, then in the boxes #last-2 and #last you've got the three he wanted.

Running yoyo's script, one of my machines turned up a peculiar c94. It looks manufactured! My machine must have grabbed it before the db even looked at it. I can't see how the db didn't factor it upon receipt. My weak P4 didn't take much more than half a second:
[code]
get composites
Factoring 94 digits: 1742241304552027448375075733065825595744067342821037447030890602479325108309893651343842781129

factoring 1742241304552027448375075733065825595744067342821037447030890602479325108309893651343842781129

div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 1, starting 1000 iterations on C37
rho: x^2 + 1, starting 1000 iterations on C32
rho: x^2 + 1, starting 1000 iterations on C27
rho: x^2 + 1, starting 1000 iterations on C22
rho: x^2 + 1, starting 1000 iterations on C18
rho: x^2 + 1, starting 1000 iterations on C12
Total factoring time = 0.5593 seconds


***factors found***

P2 = 17
*****
P2 = 29
*****
P2 = 73
*****
P3 = 113
*****
P3 = 193
*****
P3 = 337
*****
P3 = 409
*****
P3 = 449
*****
P3 = 673
*****
P3 = 911
*****
P4 = 1087
*****
P4 = 1201
*****
P4 = 1811
*****
P4 = 2129
*****
P4 = 2897
*****
P4 = 3259
*****
P4 = 3361
*****
P4 = 4733
*****
P4 = 7603
*****
P4 = 8689
*****
PRP5 = 38011
*****
PRP5 = 43441
*****
PRP6 = 121633
*****
PRP5 = 51031
*****
PRP6 = 172313
*****
PRP6 = 681647
*****
PRP6 = 973057
*****

ans = 1

===========================================================================
report factors
New factors added: 0
Factors already known: 0
Small factors: 27
Errors (does not divide): 0
===========================================================================
[/code]

[QUOTE=EdH;281134]Running yoyo's script, one of my machines turned up a peculiar [URL="http://factorization.ath.cx/index.php?id=1100000000466670317"]c94[/URL]. It looks manufactured![/QUOTE]

More Information shows that it is a cofactor of 7^60816-1. It was probably found by p-1 or small ecm, and contains the small primes from many of the algebraic factors.

[QUOTE=wblipp;281187]More Information shows that it is a cofactor of 7^60816-1. It was probably found by p-1 or small ecm, and contains the small primes from many of the algebraic factors.[/QUOTE]
OK, that makes more sense.

What is odd is that it sat there undisturbed until Dec 4/5 and then was fully factored when my machine reported back a few seconds later. I guess this means that composites are dormant until queried, similar to aliquot sequences. It would be nice if there were some way to find out if the db has factored a queried number before spending time on it, even though the ones factored like this one, take little time.
[code]
[B] Create time
[/B]Between November 29, 2011, 8:12 am and November 29, 2011, 8:16 am
[/code]

[QUOTE=wblipp;281187]More Information shows that it is a cofactor of 7^60816-1. It was probably found by p-1 or small ecm, and contains the small primes from many of the algebraic factors.[/QUOTE]

I think the DB clearly needs a "0[SUP]th[/SUP]" stage for the scan button, which does trial factoring up to a certain limit (e.g. 1e6 or so) - and which should be also available for huge numbers:
When I was searching the DB for PRPs in order to do some P-1 and primo prime proving a week ago, I encountered a PRP derived from factorials (I don't remember exactly which one), where N-1 had *boatloads* of tiny factors, but hence it was a quite huge number, I had to add them manually.

What's with the "User" link at the top of the db page? I click on it and it says "Not yet done". It's been there for a month or more. Is that an unfinished profile options page or something? Why has it been left unfinished for 1 month?