A handy reference to have: [url]http://www.mersenne.org/various/math.php[/url]

[QUOTE=Batalov;242864]P.S. Yes, it sure does. Tested:
[FONT=Courier New]Pminus1=1,2,53035711,-1,1700,21000[/FONT]
=>
[FONT=Courier New]P-1 found a factor in [I]stage #1, B1=1700[/I].[/FONT]
[FONT=Courier New]M53035711 has a factor: 61678157492310549218180505113[/FONT][/QUOTE]

How is this factor found in stage #1 with these bounds? I'm afraid I don't understand what you mean by "Does Prime95 preload with group order [I]p[/I]?" Of course, I knew it accounted for the exponent p in the factor's P-1, but how does 20719 also fall into a special category for your example?

[QUOTE=Mini-Geek;242874]How is this factor found in stage #1 with these bounds? I'm afraid I don't understand what you mean by "Does Prime95 preload with group order [I]p[/I]?" Of course, I knew it accounted for the exponent p in the factor's P-1, but how does 20719 also fall into a special category for your example?[/QUOTE]
Doesn't the handy link explain that? Oh my... I would think that it explains everything in the world!

For Q1, see GMP-ECM:
> ecm --help |grep order
-go val Preload with group order val

ECM-GMP is geared to any general numbers, and there, it is an option.
Prime95 does that without asking, naturally, because the query is an M-number.

However, for the second question, you will have to look in the source. My guess is that it increases small B1 values to some limit (and then the report is misleading: the real B1 may have not been 1700. Try it the test, though; the printout is genuine.) I ran not one similar test but three (one had B1=7000, B2=34000; it ran much faster than the result shown above and did find the factor in Stage 2, which leads me to believe that B1 was internally modified in the first case). Now, let's see the source...

[QUOTE=Batalov;242864]P.S. Yes, it sure does. Tested:
[FONT=Courier New]Pminus1=1,2,53035711,-1,1700,21000[/FONT]
=>
[FONT=Courier New]P-1 found a factor in [I]stage #1, B1=1700[/I].[/FONT]
[FONT=Courier New]M53035711 has a factor: 61678157492310549218180505113[/FONT][/QUOTE]Can you re-check that? What program and version is yours?

I just ran prime95 V25.8 with

[code]Pminus1=1,2,53035711,-1,1700,21000[/code]and got

[code][Tue Dec 21 16:21:19 2010]
P-1 found a factor in stage #2, B1=1700, B2=21000.
UID: RichBWoods/Puttputt, M53035711 has a factor: 61678157492310549218180505113
[/code]... finding it in stage 2, not stage 1.

[QUOTE=cheesehead;242938]I just ran prime95 V25.8
...
finding it in stage 2, not stage 1.[/QUOTE]

I just checked 24.14 and 26.4 as well. As you should expect, neither found the factor in the stage 1 GCD. 26.4 used the 2880K FFT in both stages, and 24.14 chose the 3072K FFT for both stages.
I'll repeat cheesehead's question: Batalov, what program/version/unusual settings were you using? Can you replicate your result?

[QUOTE=Batalov;242878]However, for the second question, you will have to look in the source. My guess is that it increases small B1 values to some limit (and then the report is misleading: the real B1 may have not been 1700. Try it the test, though; the printout is genuine.) I ran not one similar test but three (one had B1=7000, B2=34000; it ran much faster than the result shown above and did find the factor in Stage 2, which leads me to believe that B1 was internally modified in the first case). Now, let's see the source...[/QUOTE]I've just looked in the v25.11 source.

There is an adjustment of B1 that is below 30 (any lower B1 is adjusted to 30), but definitely not 1700. It's in module ecm.c (which handles both ECM and P-1). (Note: at this point variable B contains the B1 value. B2 value is in variable C.)

[code]/* Override silly bounds */

if (B < 30) {
OutputStr (thread_num, "Using minimum bound #1 of 30\n");
B = 30;[/code]Another find in module ecm.c is that prime95 won't [I]report, to the server,[/I] the result of an unsuccessful P-1 (or ECM) if B1 < 10000. George's comment is "Send P-1 completed message to the server. Although don't do it for puny values as this is just the user tinkering with P-1 factoring."

That wasn't in the version that was current a few years ago. One could find hundreds of recorded P-1 results with B1=30, hundreds more with B1=1000 or 2000 or 5000.

[QUOTE=Batalov;242878](and then the report is misleading: the real B1 may have not been 1700.[/QUOTE]In general, prime95 never misleads the user like that. In the particular case above, note that when B1 is adjusted to 30, there's a specific message displayed to the user.

I, too, [I]negatively[/I] reproduced it first on another computer, then negatively on the original. It is probably complicated, but the storyline did involve the computer with memory very full, a kill of the executable and a restart (and also an edit of the worktodo.txt before the restart; I added the other two tests and changed this test's task line; B1 was changed). I don't know which of the changes caused this.
I suspect that there may be a rare condition when prime95 picks up from the savefile and respects B1 from file and not from the worktodo.txt. The full tail from results.txt, verbatim:
[CODE]...
[Wed Dec 01 14:59:24 2010]
100010001*10^81776+1 is not prime. RES64: 1561541EE8179A9F. We1: 5F2EA482,00000000
100010001*10^81782+1 is not prime. RES64: 5493E4AC12858258. We1: 5F3AA48E,00000000
[Wed Dec 01 15:05:24 2010]
100010001*10^81785+1 is not prime. RES64: ADF84598C2ECF6E2. We1: 5F40A494,00000000
[Mon Dec 20 17:44:31 2010]
P-1 found a factor in stage #1, B1=1700.
M53035711 has a factor: 61678157492310549218180505113
[Mon Dec 20 19:05:03 2010]
P-1 found a factor in stage #2, B1=31000, B2=34000.
M53376457 has a factor: 22929204969316047666071720567
[Mon Dec 20 19:30:35 2010]
P-1 found a factor in stage #2, B1=7000, B2=34000.
M53470243 has a factor: 21377386912469750377694939071
[Tue Dec 21 01:09:21 2010]
P-1 found a factor in stage #2, B1=1700, B2=21000.
M53035711 has a factor: 61678157492310549218180505113
M53035711 already tested to B1=1700 and B2=21000.
M53035711 already tested to B1=1700 and B2=21000.
[Tue Dec 21 01:12:20 2010]
M53035711 already tested to B1=1700 and B2=21000.
[/CODE]
I am puzzled too (!!) and haven't been able to reproduce it as originally.

The version is 26.4 (Size: 26,705,920 bytes; Dated: Saturday, November 13, 2010, 2:46:00 PM)
The handpicked tests were these (got them from results in the M53M range with a filter on factor size, then factor and sort on exceptional smoothness sans p):
[CODE]Pminus1=1,2,53035711,-1,1700,21000
Pminus1=1,2,53376457,-1,31000,34000
Pminus1=1,2,53470243,-1,7000,34000
[/CODE]
I was planing to resume reconstruction of this feature (if not a bug) over the coming long weekend; I was too tired by 3am. It is unusual though. Too rare to be bothered.
______________________
[SIZE=1]Mods: branch this, maybe? Sorry for the twisted tangent, all my fault of course.[/SIZE]
[SIZE=1]It is not all too happy and not a meal. ;-)[/SIZE]
[SIZE=1][/SIZE]
[SIZE=1]______________________________[/SIZE]


[COLOR=green]P.S. There's kind of a bug/feature: Pminus1 leaves rather large savefiles in the directory after it is done. This is how P95 later 'knows' that "M53035711 already tested to B1=1700 and B2=21000." They have to be deleted to do it again. For most users, they will stay as a dead baggage for the HD (which I think is a bug).[/COLOR]

[QUOTE=Batalov;242948]I, too, [I]negatively[/I] reproduced it first on another computer, then negatively on the original. It is probably complicated, but the storyline did involve the computer with memory very full, a kill of the executable and a restart (and also an edit of the worktodo.txt before the restart; I added the other two tests and changed this test's task line; B1 was changed).[/QUOTE]Thank you for your efforts and this report! :-)

[quote]_____________________
[SIZE=1]Mods: branch this, maybe? Sorry for the twisted tangent, all my fault of course.[/SIZE]
[SIZE=1]It is not all too happy and not a meal. ;-)[/SIZE]

[SIZE=1]______________________________[/SIZE][/quote]I second this suggestion.

[quote][COLOR=green]P.S. There's kind of a bug/feature: Pminus1 leaves rather large savefiles in the directory after it is done. This is how P95 later 'knows' that "M53035711 already tested to B1=1700 and B2=21000." They have to be deleted to do it again. For most users, they will stay as a dead baggage for the HD (which I think is a bug).[/COLOR][/quote]I agree about the dead baggage, but of course, the difficulty is that leaving the savefile is necessary for the user to resume P-1 to higher limits later without repeating all previous computation.

Suggestion: Make prime95 erase P-1 save files by default, and add a worktodo parameter that cancels this.
Pro: Works for the majority of folks not interested in going to higher limits ... but ...
Con: Changing the default behavior is dangerous! Forget to add the new parameter, and there goes all your hard work!

Safer suggestion: At the end of a P-1, display a message reminding the user that the save file is being left there.
Pro: Unchanged default behavior.
Con: Doesn't do much to solve the problem for the majority of users, who'll probably resent being asked, in effect, to clean up the savefiles themselves, and will probably ask why the program "can't" do that itself.

Q: Does Windows or Linux provide a way to assign an expiration date to a file when it's created?

Now, I started thinking (there are thoughts to this end in the code) that George separates "Pminus1=..." tasks' behavior from a routine P-1 (viz. in the LL pipeline's context). So, leaving savefiles [I]is[/I] an intended behavior. I would limit removal to the .bu and .bu2 files at the clear exit from a finished Pminus1 test but keep the 'm' savefile for the increased-limits reruns. (At least, that'll be 1/3 of the lost luggage for some, and an intended save for others.)

For the puzzle, here's where I am digging now:
[CODE]:::ecm.c:::
/* Check for the rare case where we need to do even more stage 1 */
/* This happens when a save file was created with a smaller bound #1 */
/* than the bound #1 passed into this routine */
if (B > pm1data.B) {
more_B: pm1data.B = B;
stop_reason = start_sieve (&pm1data.si, thread_num, 2);
if (stop_reason) goto exit;
prime = sieve (&pm1data.si);
goto restart1;
}
[/CODE]
Could have inadvertently wandered into this section's execution by all the changes, but it still remains to be seen how the 1700 value survived for the final printout. Still some head-scratching in progress.


[COLOR=green]P.S. I am digging there because (and I mentioned it earlier --) that the mysterious test was almost as long as its later sibling (see above) with B1=31000 and definitely much longer than its third sibling with B1=7000. I do believe that in the execution, pm1data.B was upped to B2, but not in the variable that holds it for the final printout (B) - that's why the answer was found, that's why it was long. With some combination of environmental factors (the savefile, the contradicting worktodo.txt, a kill, a restart), the execution may have goto'd into that label more_B... (and hence digging how could it have happened).[/COLOR]

[QUOTE=Batalov;242948]I suspect that there may be a rare condition when prime95 picks up from the savefile and respects B1 from file and not from the worktodo.txt.
I am puzzled too (!!) and haven't been able to reproduce it as originally.

The version is 26.4 (Size: 26,705,920 bytes; Dated: Saturday, November 13, 2010, 2:46:00 PM)
The handpicked tests were these (got them from results in the M53M range with a filter on factor size, then factor and sort on exceptional smoothness sans p):
[CODE]Pminus1=1,2,53035711,-1,1700,21000
Pminus1=1,2,53376457,-1,31000,34000
Pminus1=1,2,53470243,-1,7000,34000
[/CODE]
I was planing to resume reconstruction of this feature (if not a bug) over the coming long weekend; I was too tired by 3am. It is unusual though. Too rare to be bothered.[/QUOTE]

I've reproduced the bug. It has to do, as you suspected, with a mismatch between the save file's B1 and the worktodo's B1. Note that I have the iterations between screen outputs set to 100, with B1=1700, that's ~4% of the progress, and with B1=21000, that's ~0.33% of the progress (between the two B1s, there aren't any other visible differences, except what B1 Prime95 should report: they both use 2880K FFT and report every ~5.6 seconds). Here's how I did it:
Put this line in worktodo.txt:
[CODE]Pminus1=1,2,53035711,-1,21000,21000[/CODE]
And start Prime95 then stop and close it so it creates a save file. As expected, it reports that B1=21000. Then change the line to:
[CODE]Pminus1=1,2,53035711,-1,1700,21000[/CODE]
(i.e. change the B1 to 1700) then start and continue Prime95. It says:
[CODE][Dec 22 06:46] Worker starting
[Dec 22 06:46] Setting affinity to run worker on any logical CPU.
[Dec 22 06:46] P-1 on M53035711 with B1=1700, B2=21000
[Dec 22 06:46] Using Core2 type-3 FFT length 2880K, Pass1=640, Pass2=4608
[Dec 22 06:46] M53035711 stage 1 is 2.317355% complete.
[Dec 22 06:46] M53035711 stage 1 is 2.647933% complete. Time: 5.579 sec.
[Dec 22 06:46] M53035711 stage 1 is 2.978512% complete. Time: 5.574 sec.
[Dec 22 06:46] M53035711 stage 1 is 3.309090% complete. Time: 5.602 sec.
[Dec 22 06:47] M53035711 stage 1 is 3.639669% complete. Time: 5.554 sec.
[Dec 22 06:47] M53035711 stage 1 is 3.970247% complete. Time: 5.551 sec.
...[/CODE]Note that the percentage for each line is ~0.33%, which corresponds to B1=21000, even though it reports B1=1700. This accounts for the time difference you saw, and explains the bug. And sure enough, it found it in stage 1, and thinks it was with B1=1700:
[code]P-1 found a factor in stage #1, B1=1700.
UID: x, M53035711 has a factor: 61678157492310549218180505113
[/code]

Great, thanks!

(I hate to report irreproducible results - they look made-up and create a Munchausen effect on the audience.) :rolleyes:

:never again: