[QUOTE=Andi47;234182]sequence 10212 is currently at [B]size 147[/B], not 150. Index 2366 is correct. (currently GNFSing the c145 cofactor)[/QUOTE]Hmmm...well like I said, I saw some squirrelishness in there. I'll have to kick off a job tonight and see what things look like now.

[Edit] I was reluctant to hit it again too quickly.

I corrected several loss of data issues when the new database first went up. However, a bunch did require aliqueit to be run.


Basically, a term factored by aliqueit was treated as prime by the old database. Therefore the factorization wasn't even in the old db and if aliqueit was run again even on one term, the later sequence would be found.

I did submit earlier versions of the old db to the new to make sure work before the bug made it back in, and looked at a bunch of seq that looked like they might be wrong.

Chances are decent though that some were missed. If you know sequences should be longer, then it is possible even a short run or set of runs of aliqueit might refind them since most factorizations still exist.

It might be worth listing them and we can see if we can regenerate them.

[QUOTE=Greebley;234252]I corrected several loss of data issues when the new database first went up. However, a bunch did require aliqueit to be run.


Basically, a term factored by aliqueit was treated as prime by the old database. Therefore the factorization wasn't even in the old db and if aliqueit was run again even on one term, the later sequence would be found.

I did submit earlier versions of the old db to the new to make sure work before the bug made it back in, and looked at a bunch of seq that looked like they might be wrong.

Chances are decent though that some were missed. If you know sequences should be longer, then it is possible even a short run or set of runs of aliqueit might refind them since most factorizations still exist.

It might be worth listing them and we can see if we can regenerate them.[/QUOTE]Actually, I was just speaking of the current reservation list. There were a couple that didn't line up with the last time I pulled a list. I figure that those were probably a result of the power outage that Syd reported over in the factorDB thread....

86160, after bravely throwing off the 2*3 driver at line 1848, picked up the 2^2*7 driver at line 1866; have taken it to line 1911, fully-ECMed C126 ready for anyone else to pick up, but I'm done with this one.

Pulled and posted a complete update.....a couple of nice moves in there:[code]
75402 bchaffin 821 105 2^2 * 3^4 * 7
75402 bchaffin 3581 136 2^4 * 31[/code]and[code]392430 unconnected 5637 123 2
392430 unconnected 7206 116 2^2 * 7^2[/code]

[QUOTE=schickel;234901]Pulled and posted a complete update[/QUOTE]

[QUOTE=schickel;165249]
[code][B]Current reservations[/B]
10212 Andi47 2369 150 [COLOR="red"]2 * 3[/COLOR]
[/code]
[/quote]

What makes you always (i.e. at every update) think that sequence 10212 is at 150 digits?

[quote=factor database just a minute ago]
[code]Unchecked 2369 [B][COLOR="Red"]147[/COLOR][/B] (show) 3102789883...<147> = 2 · 3 · 58693 · 8810789145...<141>[/code][/quote]

[QUOTE=Andi47;234908]What makes you always (i.e. at every update) think that sequence 10212 is at 150 digits?[/QUOTE]Well now, that is a very good question. I'll have to see what my program is retieving. The raw output is this line:[code] 10212 2369. sz 150 2 * 3 * 58693[/code]What it does is pull the elf file and then check the size of the composite on the last line. Apparently something is being reported peculiarly just for 10212....

[Edit] Check that....it looks like something throwing off the size calulation on everything. I'll have to investigate further. Thanks for catching that.

[QUOTE=Andi47;234908]What makes you always (i.e. at every update) think that sequence 10212 is at 150 digits?[/QUOTE]'Cause I made a rookie mistake the last time I twiddled with the program. After Syd changed the interface, I moved some statements around. Net result: I was taking the position of the '.' in the last line, padding the line, then taking everything from the [B]unpadded[/B] position of the '.' to the '=' for the length of the compostite. So I had an 'off by x, x from 2-4' error, depending on the index of the sequence.....

Stupid, stupid, stupid. Sorry, I'll recompile and pull a correct update, but probably not until after work tomorrow.

Frank

392430 that shows a downdriver probably needs to be updated in the 1st posting here.

It has advanced nearly 1600 indexes since the last update! :smile:

Unreserving 67920 for Clifford.

Reserving 215778
 

Reserving 215778; continuing with 235416.