The Appallingly Blue Page

[LaurV]

Nice! Snap snap for Dubslow! hehe...

/offtopic:
for 747720, the error is at term 60, and it may be related to the 659^2 which appears on term 59. Somehow the "^2" part is missing for the next sigma. I attached here the right elf file, factors taken as shown in the DB, after searching the right numbers, verifying and combining them locally into a single elf file. Someone may notify Syd. I also added/reported the last 4 terms (cracked locally) to the DB. The C114 at the end is ecmd to 0.3, so there would be no factors under 35 digits or so. This sequence is driven by "D2 with 3" (2^2*3*7, or if you prefer, 2^2*7*3).

edit: forgot the attach

edit2: answer to your question: up to 70 digits max, if there are free workers/elves. Currently there are only 3 workers, only one is factoring, the others are proving primes/whatever, so the limit is 65 bits. You can see this if you access the status page of the DB.

[Dubslow]

Well if you look at the link on the page, it points to a post I made in the most recent sequence errors thread, remarking that it's a new error after the second DB flush... but hey. You should copy/paste the relevant parts of your post (and the attachment) to that thread.

WRT the small factor-all cutoff, the status page says "Workers will be back soon", while saying 65 digits (not bits). How often does that limit change? I could theoretically scan it with my script, but if it only changes like once a week or less I'd rather just hard code it. (Read: I don't particularly care to write the code to scan for the value.)

[OT (even more than above)]Edit: What's with the sudden spike of numbers at 2000 digits?[/OT]

Edit:

Originally Posted by Dubslow

How's that? 50th percentile is around 1156.

Since then, the 50th percentile has advanced to lines and is now around 1158. Nice!

[LaurV]

yes, 65 digits (not bits). Sorry! (time passed, I can't edit it).

Why you need this value related to aliquots? To check the minimum size, or why? All sequences should have more then 400 terms and more then 110 digits, as they were moved to that point by collective efforts, bchaffin elves, whatever. Anything below that is an error. People working them will usually not report them if they are under 100 digits, or if they got downdriver, etc, to avoid poaching. I try to let my sequences hanging at high (around C120) digits count, and deep ecm done, so any poacher have to work hard to add terms to them. And I only report if I accumulate too much local data, or hit a "hard point" again. I believe everybody does the same.

[Dubslow]

Originally Posted by LaurV

Why you need this value related to aliquots? To check the minimum size, or why? All sequences should have more then 400 terms and more then 110 digits, as they were moved to that point by collective efforts, bchaffin elves, whatever. Anything below that is an error. People working them will usually not report them if they are under 100 digits, or if they got downdriver, etc, to avoid poaching. I try to let my sequences hanging at high (around C120) digits count, and deep ecm done, so any poacher have to work hard to add terms to them. And I only report if I accumulate too much local data, or hit a "hard point" again. I believe everybody does the same.

When I first added the most recent table, there were two sequences with cofactor sizes in the 20s. There were around 5 total with cofactor sizes under 50, and a total of 17 sequences with cofactor sizes <= 77 (that's why, atm, the table's smallest is 78, because I manually updated those 17). I suspect it's mostly thanks to YAFU@Home attacking all the small composites. I had a note in the stats page that I'd try and manually update such sequences until I automated it; but, even before your post, I got it all fixed up so that if the composite cofactor is less than a certain size, sleep 1 second and re-query the sequence, on the assumption that the elves factor it in the mean time. The question I edited in of course was "less than what certain size"?

tl;dr: Turns out with YAFU@Home and the standard elves going at it, getting cofactor sizes < 50 is more common than you'd think, and it seemed to me that putting such a sequence in the table would be silly.

Edit:

Originally Posted by Dubslow

(And my sequence from last week is by far the leader for most extended in the last week. )

Record smashed!

[EdH]

Originally Posted by Dubslow

I think I'll interpret that to mean add more space below the table....

Actually, I prefer to place some sort of closing image at the bottom of pages. That way, it signals that you're at the bottom and that the page is fully loaded, like what's at the bottom of these pages. Sometimes, I put a closing statement or even a series of dashes.

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

[Dubslow]

Originally Posted by EdH

Actually, I prefer to place some sort of closing image at the bottom of pages. That way, it signals that you're at the bottom and that the page is fully loaded, like what's at the bottom of these pages. Sometimes, I put a closing statement or even a series of dashes.

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

Well... polite company might say I've taken a bit of "artistic license" in doing something like this.

In general, if you guys want me to do something, saying "Do B instead of A" is far more likely to get results instead of "Don't do A". In most cases of the latter, I won't do anything until an alternative is presented. (This particular case is an exception, though of course the first person to suggest something else will get their wish. )

Edit: I'm having some positioning problems with the stats page...

[EdH]

Originally Posted by Dubslow

Well... polite company might say I've taken a bit of "artistic license" in doing something like this.

In general, if you guys want me to do something, saying "Do B instead of A" is far more likely to get results instead of "Don't do A". In most cases of the latter, I won't do anything until an alternative is presented. (This particular case is an exception, though of course the first person to suggest something else will get their wish. )

The image looks fine, to me.

I am wondering if the table could use a border as well, though. It still seems to end abruptly...

Thanks for all your work.

Hmm... This is very minor, but I find it interesting - I'm seeing some strange header activity as I scroll down the table. The headers appear to dance somewhat and at certain points, "Recent Progress" swaps between one and two lines. I see no reason, but perhaps it is tied to the proportional sizing anomaly:

[LaurV]

as a side discussion, I just found out that the "misalignment of the header" problem (when you resize lateral, and the headers do not resize, the alignment with the columns is lost) can be simple solved by re-sorting (click on any column header). When resorting, the table is painted right, with all alignments reset to the right position/value.

[Dubslow]

Originally Posted by EdH

Hmm... This is very minor, but I find it interesting - I'm seeing some strange header activity as I scroll down the table. The headers appear to dance somewhat and at certain points, "Recent Progress" swaps between one and two lines. I see no reason, but perhaps it is tied to the proportional sizing anomaly:

That's a result of the JavaScript dynamically changing column widths as you scroll. I have yet to figure out how to stop that.

[LaurV]

hm... some supermods have really sick fantasies... (re: thread title)

[xilman]

Originally Posted by LaurV

hm... some supermods have really sick fantasies... (re: thread title)

Not me Guv.