M919208341 trial factored to only 2^72?
 

I submitted the trial factoring results of M919208341 from 2^70-2^74, but out of bit-level order.

[CODE]
processing: TF no-factor for M919208341 (2[SUP]72[/SUP]-2[SUP]73[/SUP])
Result was not needed. TF on M919208341, sf: 72, ef: 73 CPU credit is 1.0406 GHz-days.
processing: TF no-factor for M919208341 (2[SUP]73[/SUP]-2[SUP]74[/SUP])
Error code: 40, error text: TF result for M919208341 was not needed
processing: TF no-factor for M919208341 (2[SUP]70[/SUP]-2[SUP]71[/SUP])
CPU credit is 0.2601 GHz-days.
processing: TF no-factor for M919208341 (2[SUP]71[/SUP]-2[SUP]72[/SUP])
CPU credit is 0.5203 GHz-days.
[/CODE]

After I finished the manual submission, I checked the exponent status and the display shows no factor to 2[SUP]72[/SUP]. Furthermore, the details show duplicate records for no factor from 2[SUP]72[/SUP] to 2[SUP]73[/SUP].

[url]https://www.mersenne.org/report_exponent/?exp_lo=919208341&full=1[/url]

Can anyone explain to me how that happened? Thanks in advance.

Sometimes Primenet shows the results out of order. If you look you will see that on one day the 70->71 was reported as were 71->72, 72->73, 73->74.

Aaron, George, or James needs to look at the code that reads these data and displays the right max level. The results were likely all submitted in a single lump but the processing got munged.

[QUOTE=Uncwilly;521209]Sometimes Primenet shows the results out of order. If you look you will see that on one day the 70->71 was reported as were 71->72, 72->73, 73->74.

Aaron, George, or James needs to look at the code that reads these data and displays the right max level. The results were likely all submitted in a single lump but the processing got munged.[/QUOTE]

Thanks for your help. But in my case, I submitted my results in this order:
72->73, 73->74, 70->71, 71->72. Same exponent. I believed that the order would not matter.

When I submitted my results in sequentially increasing bit levels, I faced no issues.

Maybe James can look at the parsing code and have it reorder things before ingesting them.

Try submitting the results over at Mersenne.ca and see if that reads them correctly.

For some dyslexic reason I initially read that your results from today were submitted 10 years ago. :redface:

[QUOTE=2M215856352p1;521210]I believed that the order would not matter.[/QUOTE]

It does. Primenet won't record the bit level correctly unless the results are submitted in order.

If you resubmit your results in order for the levels missed Primenet will correct the record.

[QUOTE=chalsall;521212]It does. Primenet won't record the bit level correctly unless the results are submitted in order.

If you resubmit your results in order for the levels missed Primenet will correct the record.[/QUOTE]

There was another recent discussion about this - I don't remember the details, but there was some reason for it doing what it does.

It had something to do wanting to show the TF bit level it has been *fully* factored to. Something like that. When results are submitted out of order (don't do that), then this is what happens. :smile:

[QUOTE=Madpoo;521242]When results are submitted out of order ([b]don't do that[/b]) ...[/QUOTE]Why not?

Storing, sorting and comparing are the strong points of computers. Maybe we can be using them for exactly that? Save the user's time and frustration.

[QUOTE=retina;521265]Why not?[/QUOTE]
It shows that something is (potentially) wrong. Preserving the integrity of the data is more important than user convenience -- a convenience which is not at all needed if the user would but do things "normally".

I would rather the server just outright reject any out-of-order TF submissions. Simple and unambiguous. The user most probably f'ed up in this case. They can correct their mistake and resubmit.

[QUOTE=Madpoo;521242]There was another recent discussion about this - I don't remember the details, but there was some reason for it doing what it does.

It had something to do wanting to show the TF bit level it has been *fully* factored to. Something like that. When results are submitted out of order (don't do that), then this is what happens. :smile:[/QUOTE]

But you can manually fix this exponent in the database right? or is it bugged forever?

[QUOTE=axn;521269]It shows that something is (potentially) wrong.[/QUOTE]But, if someone is launching an assault on an exponent and wants to get the factoring out of the way as fast as possible (wall clock time), this could happen. Throwing multiple machines at it with one/some doing lower levels, a GPU doing higher, and another machine doing the P-1 all at once. This could lead to the various machines turning in different bit levels and P-1 in different orders than expected. If you or several other forumites turned in work like this, I would not think twice about it. If someone did it on their first Primenet assignment, or no assignment, yes that is a concern.

[QUOTE=ATH;521282]But you can manually fix this exponent in the database right? or is it bugged forever?[/QUOTE]

For Primenet to be able to deal with TF levels out-of-order would either involve a bitmap for each level, or else a related table, instead of a simple integer recording the TF level.

Probably not worth the effort considering the rare edge-case.