The entire exponent range from 1000M to 2[sup]32[/sup] (~4294M) has now been TF'd to (at least) 2[sup]67[/sup] (in most cases stopping after first factor found). The [url=https://www.mersenne.ca/tf1G]tf1G[/url] page has been updated to show 68-77 columns.

[QUOTE=James Heinrich;531036]The entire exponent range from 1000M to 2[sup]32[/sup] (~4294M) has now been TF'd to (at least) 2[sup]67[/sup] (in most cases stopping after first factor found). The [URL="https://www.mersenne.ca/tf1G"]tf1G[/URL] page has been updated to show 68-77 columns.[/QUOTE]

I thought something was different.

Recently, I have been looking at the bottom of this page. It seems the effort has dropped off, (GHz days per day). This could also be an illusion as the time required to factor to higher bit levels would increase.

[QUOTE=storm5510;531042]It seems the effort has dropped off, (GHz days per day).[/QUOTE]The exact opposite in fact. Three months ago the daily average was about 12500GHd, now it's just over double that (25800).

More people are TF'ing to higher bit depths (70 or 71 instead of min+1) so the throughput of cleared exponents might be lower, but the expended effort is definitely up over time.

One thing we found a bit odd about those tables (from the beginning, not just now) is that there are a lot of assignments in ranges where either all the work was already done (and they are green) and either in the ranges that have no exponents available. May you explain please how those little red numbers work? Maybe our understanding is wrong..

[QUOTE=LaurV;531050]there are a lot of assignments in ranges where either all the work was already done (and they are green) and either in the ranges that have no exponents available. May you explain please how those little red numbers work?[/QUOTE]The big blue (clickable) numbers are the number of assignments available for assignment in that range. The small red numbers are the number of assignments already assigned. The sum of both numbers (not explicitly displayed) is the number of exponents in that range/bitlevel.

The green background color was buggy (it should not extend to any cell with available or assigned exponents). This has been fixed.

[QUOTE=James Heinrich;531054]This has been fixed.[/QUOTE]
Much better now, well done Sir!
If the 6000 assignments on "3730M to 68" are mine, then you can delete them (or they will expire anyhow in few days). I have no assignment at (or under) 68 right now, and they may be remnants from the past when I was trying to understand how your script works and most probably did few wrong rounds of "wget". I have no history nor backup and no way to restore them.

[QUOTE=LaurV;531055]If the 6000 assignments on "3730M to 68" are mine, then you can delete them
I have no history nor backup and no way to restore them.[/QUOTE]I can tell what the assignments are, but they're truly anonymous so I don't know if they're yours or not. Just let them expire if they're yours and your (or someone) will get them reassigned in a few days.

[QUOTE=LaurV;531055]Much better now, well done Sir!
If the 6000 assignments on "3730M to 68" are mine, then you can delete them (or they will expire anyhow in few days). I have no assignment at (or under) 68 right now, and they may be remnants from the past when I was trying to understand how your script works and most probably did few wrong rounds of "wget". I have no history nor backup and no way to restore them.[/QUOTE]

Ah, but the 6000 assignments in the 68 column aren't "to" 68, but "from" 68, to whatever was specified when reserving them. To 70, to 71, who knows. I think I saw the assignment expired and free to reserve again fairly recently, so I guess someone else wants to fill the gap now.

And whatever the mistake, it will expire in 10 days, which seems to be a good time for these short assignments. I know I've made my share of mistakes in the past... :blush: and it's sometimes a bit painful to wait for any sign of them to disappear from the table, but in the long term, luckily it doesn't matter.

TF verification
 

Hey James,

Not sure if this is the correct place, let me know if you think there's a better forum.

I wrote up and [URL="https://www.mersenneforum.org/showpost.php?p=520512&postcount=199"]coded a verifiable version of GPU trial factoring[/URL]. The idea is that you save k that minimize pow(2, candidate, k) as a proof of correct computation / work. The math is covered in the post. That conversation petered out when more manual methods of detecting cheating were deployed.

Obviously not all programs will support this and there will be some fun caveats (e.g. mfaktc with the larger kernel quits doesn't compute the final modulo so there will need to be multiple verification methods based on a kernel lookup). The value would be limited at first, but it feels like it's a good think to increase verification at a small(?) data cost.

I'm wondering what/who it would take for mersenne.ca / mersenne.org to parse and save an additional log line per TF-NF results. And if this is of interest to the community.

Thanks

[QUOTE=SethTro;531897]I'm wondering what/who it would take for mersenne.ca / mersenne.org to parse and save an additional log line per TF-NF results. And if this is of interest to the community.[/QUOTE]It is of interest to me. I can work on incorporating the parsing into mersenne.ca first, once that's working as intended I can port it to mersenne.org
I'm going to tell you to modify the output to JSON format, we can discuss the details in email.

Please email [email]james@mersenne.ca[/email] with the details, including a simple-language explanation of how to verify your checksum.

It remains curious to me that there is an apparent intention for .ca to remain distinct from .org, yet the icon that appears in web browser tabs is identical.
Would it not be reasonable that some distinction be made more clear by way of such icon?
Perhaps a different colour?
Or maple leaf background if you especially want!