[QUOTE=Cruelty;471639]Is this a standard output right now? :cool:[code]{"status":"C", "k":127, "b":2, "n":12000569, "c":-1, "worktype":"PRP-3", "res64":"700854A79E1515ED", "residue-type":1, "fft-length":786432, "error-code":"00000000", "security-code":"6DAF586E", "program":{"name":"Prime95", "version":"29.4", "build":4, "port":4}, "timestamp":"2017-11-12 11:32:16", "errors":{"gerbicz":0}}[/code]I haven't touched config files in a while, I guess from v28.9, and so far everything was OK.[/QUOTE]

Yes it look like :( - I hope that is way to revert in "old way"

PRP results in v29.4 are now output in JSON format. Other result types will also migrate to JSON over the next few versions when George has time to implement it. Using JSON as a result format makes it both more flexible and robust, and allows a common format between all result types and all software (e.g. Prime95, mfaktc, gpuowl, etc).

[QUOTE=James Heinrich;471644]PRP results in v29.4 are now output in JSON format. Other result types will also migrate to JSON over the next few versions when George has time to implement it. Using JSON as a result format makes it both more flexible and robust, and allows a common format between all result types and all software (e.g. Prime95, mfaktc, gpuowl, etc).[/QUOTE]
I hope that will also make "old results style" as one of option

[QUOTE=pepi37;471647]I hope that will also make "old results style" as one of option[/QUOTE]

It should be relatively easy to have code that can prettyprint the json format results. It might not look exactly the same but should be just as easy to read as the old style.

[QUOTE=Dubslow;471649]It should be relatively easy to have code that can prettyprint the json format results. It might not look exactly the same but should be just as easy to read as the old style.[/QUOTE]

I am nearly 100% sure that George will add switch ( like was in past) to have user choice: old or new style :)

Add this in prime.txt and result is revert to old way!

[QUOTE]OutputPrimes=1
OutputJSON=0
OutputComposites=1[/QUOTE]

[QUOTE]2*10^76345-1 is not prime. RES64: 210D1323F923FF54. Wg4: 34C07A14,00000000
2*10^21456-1 is not prime. RES64: B66A0B65630E740D. Wg4: 5D55A7A0,00000000
[Sun Nov 12 23:08:00 2017]
2*10^38232-1 is a probable prime! Wg4: 961ABD81,00000000[/QUOTE]

It may be what you're used to, but the non-JSON results are much harder to deal with when processing manual results. I'm personally in favour of deprecating all non-JSON results and eventually no longer them accepting them in the manual results forms. Don't worry, we're probably years away from that, but be prepared to see more JSON in the future.

BTW: George is less [url=https://en.wikipedia.org/wiki/Hobson%27s_choice]Hobsonian[/url] than I am so the option is already there. I however still strongly encourage you to embrace the JSON in your workflow. :smile:

[QUOTE=James Heinrich;471653]It may be what you're used to, but the non-JSON results are much harder to deal with when processing manual results. I'm personally in favour of deprecating all non-JSON results and eventually no longer them accepting them in the manual results forms. Don't worry, we're probably years away from that, but be prepared to see more JSON in the future.

BTW: George is less [URL="https://en.wikipedia.org/wiki/Hobson%27s_choice"]Hobsonian[/URL] than I am so the option is already there. I however still strongly encourage you to embrace the JSON in your workflow. :smile:[/QUOTE]

For me ,and my use of Prime 95 all I need is

[QUOTE]2*10^76345-1 is not prime. RES64: 210D1323F923FF54. Wg4: 34C07A14,00000000

2*10^38232-1 is a probable prime! Wg4: 961ABD81,00000000 [/QUOTE]

So I am back: and Prime95 is better in any way , any time :)
Thanks George :)

As long as you don't plan on submitting results to PrimeNet, have 'at it in the old format :smile:

[QUOTE=James Heinrich;471656]As long as you don't plan on submitting results to PrimeNet, have 'at it in the old format :smile:[/QUOTE]

Yes, I found it :) Upgrade Linux distro also :)
Error checking is always good thing!

[QUOTE=GP2;471635]PRP has better error correction, and should give very reliable results even on unreliable machines. It may eventually take over as the main form of testing. However, the Gerbicz error correction algorithm is very new, so adoption may be gradual and cautious. Meanwhile there are ten years' worth of old LL results that need double-checking.

PRP tests can prove a Mersenne number is composite, but can't mathematically prove that is prime (although there is a very high degree of confidence). LL tests do prove primality. This is a non-issue in practice, since Mersenne primes are extremely rare and credit will be given for any finds made with PRP testing even though a confirming LL test will be run subsequently.

The savefiles for PRP testing appear to be about three times larger than LL save files for equivalent exponents. Around 30MB vs. 10MB for exponents around the 80M range. Shouldn't be an issue unless you are extremely constrained for disk space or I/O throughput bandwidth (the latter may actually be an issue with the EFS filesystem on the AWS cloud if there is a low DiskWriteTime interval, low filesystem storage usage, and very frequent churning of spot instances).

The kinds of tests assigned by the default "whatever makes sense" setting will undoubtedly change over time. If that's what you use now, there's no need to change it.[/QUOTE]

Thank you for the reply, GP2. I understand the points that you have made. I'm sure this be addressed explicitly in future versions. Thank you!

When having invalid PRP-assignments, he will skip them, but he displays the wrong assignment as skipped:
[CODE][Worker #3 Nov 15 19:37] 5^100000-98 is not prime. RES64: 66F3AC8D2C121F65. Wg4: A3426CBC,00000000
[Worker #3 Nov 15 19:37] PRP test of 5^100000-98 aborted -- number is divisible by 3
[Worker #3 Nov 15 19:37] PRP test of 5^100000-98 aborted -- number is divisible by 3[/CODE]

worktodo.txt:
[CODE]PRP=N/A,1,5,100000,-98,99,0,3,1
PRP=N/A,1,5,100000,98,99,0,3,1
PRP=N/A,1,5,100000,-100,99,0,3,1[/CODE]