Much further. Of course.

Re: PFGW: Yes, one can try smaller members simply to see that the FFT size tends to be ~3.75-4 times larger. For P74207281, after long initialization the process takes off:
[CODE]No factoring at all, not even trivial division
Generic modular reduction using generic reduction FMA3 FFT length 16000K, Pass1=640, Pass2=25K on A 148414563-bit number
PRP: 2^148414561-2^74207280+1 35000/148414560[/CODE]

[QUOTE=Batalov;424320]Much further. Of course.

Re: PFGW: Yes, one can try smaller members simply to see that the FFT size tends to be ~3.75-4 times larger. For P74207281, after long initialization the process takes off:
[CODE]No factoring at all, not even trivial division
Generic modular reduction using generic reduction FMA3 FFT length 16000K, Pass1=640, Pass2=25K on A 148414563-bit number
PRP: 2^148414561-2^74207280+1 35000/148414560[/CODE][/QUOTE]

What command line did you use? :smile:

[QUOTE=Batalov;424320]Much further. Of course.

Re: PFGW: Yes, one can try smaller members simply to see that the FFT size tends to be ~3.75-4 times larger. For P74207281, after long initialization the process takes off:
[CODE]No factoring at all, not even trivial division
Generic modular reduction using generic reduction FMA3 FFT length 16000K, Pass1=640, Pass2=25K on A 148414563-bit number
PRP: 2^148414561-2^74207280+1 35000/148414560[/CODE][/QUOTE]

Interesting. PFGW crashes for me trying to run that same expression. Tried both 3.7.7 and 3.7.10.

You'd need quite a bit of free memory (perhaps for the first, "giants", step; it can also be the reason for a very low start; "giants" object is created first and then converted to a gwnum object and may be used for the mod step; for a faster implementation, this needs to be custom written inside the code), maybe this is why it is crashes for you guys.

I've used three ways, and all worked (all on linux, can't vouch for W!ndows).
One (common with trying LLR*):
File a.abc
[CODE]ABC $a^$b-$a^$c+1
2 148414561 74207280[/CODE]And then ./pfgw -f0 -V -N -l a.abc and/or ./sllr -d a.abc.
Another, ./pfgw -f0 -V -N -q"2^148414561-2^74207280+1" (works, too).
Third one, ./pfgw -f0 -V -N -t -hhelper -q"2^148414561-2^74207280+1" (where helper file has 2^74207281-1 in it)

________________
*LLR turns out to be not immediately helpful for the purpose of the N-1 proof because it implements a >50% proof only (a k*2^n+1 approach with desired k < 2^n).

I'll try those. I tried "pfgw64.exe -f0 -q"2^148414561-2^74207280+1" on Windows 7 boxes with 32GB and 16GB respectively. Watching Task Manager, the process never pulled more than about 1 GB of RAM for use.

It's not a big deal, obviously, but now I'm just curious. :smile:

Edit: Yeah, none of those worked for me (pfgw or llr). I guess I'll stick to slightly lower numbers then. :smile:

It [B]does[/B] segfault on Windows. What a [URL="http://mersenneforum.org/showthread.php?p=424098#post424098"]terribly written program[/URL]!! :tantrum:
[QUOTE]...unfortunate, but I suppose state of the art [STRIKE]factoring [/STRIKE]primality software is unlikely to win any awards for user friendliness.[/QUOTE]:kracker:

It's all good. This is the first issue I've run into with it after a good amount of use, so I'd say it's doing alright. :tu:

Of course! Mark is also very helpful,; the only wrinkle I thought of was that he doesn't read every thread (not that I blame him), so I PM'd him with a link, too. Undoubtedly this will get fixed.

I finally read Batalov's PM. I'll see what I can do.

As for pfgw being "terribly written", I would agree. The code base is very convoluted. I have considered rewriting the program, but that would probably take months.

[QUOTE=rogue;424393]I finally read Batalov's PM. I'll see what I can do.

As for pfgw being "terribly written", I would agree. The code base is very convoluted. I have considered rewriting the program, but that would probably take months.[/QUOTE]

What would it take to add gwnum multithreading for prp testing? Is it a case of using different gwnum functions?

[QUOTE=henryzz;424400]What would it take to add gwnum multithreading for prp testing? Is it a case of using different gwnum functions?[/QUOTE]

I'm not familiar with that feature of gwnum.

I have good news and bad news. The good news is that I have been able to reproduce the problem on Windows. The bad news is that the bug is causing memory to be overwritten so the call stack is lost. It says the memcpy is to blame, but it is not one of the many calls to memcpy in the application. I suspect that an assignment is calling memcpy under the covers. This will take a lot more work to debug. Ugh!