LLR beta Version 3.8.13 (deprecated)

[Jean Penné]

Originally Posted by Prime95

The bug only affects zero-padded non-base-2 AVX FFTs larger than 6K. The FFT is fine, but the calculated roundoff error is garbage. I'll have a fix soon.

Good news, George, and thank you!
Jean

[pepi37]

Originally Posted by Jean Penné

Good news, George, and thank you!
Jean

Will you recompile binaries and GUI once fix is available?

[Jean Penné]

Originally Posted by pepi37

Will you recompile binaries and GUI once fix is available?

Yes, indeed, with the aid of Iain for Mac OS binaries, and of Rebirther for Win64 ones.
Jean

[Jean Penné]

Hi,

As gwnum beta V28.5 in now available, I have now rebuilt Win32 and all Linux applications linked with this new library. I made no other change, so, I replaced respectively the 3.8.12 binaries by the 3.8.13 ones. The source is also replaced, to allow the building of Win64 and Mac OS applications.

Regards,
Jean

[rebirther]

Done for 64bit, the result looks good. See upper link.

[Jean Penné]

Originally Posted by rebirther

Done for 64bit, the result looks good. See upper link.

Thank you Rebirther, the two files are now uploaded and replace the 3.8.12 ones.
Jean

[Jean Penné]

Hi,

Thanks to Iain Bethune who built the Mac OS binaries, the LLR 3.8.13 beta version is now complete and replaces the 3.8.12 one.

Regards,
Jean

[KEP]

Originally Posted by Prime95

The bug only affects zero-padded non-base-2 AVX FFTs larger than 6K. The FFT is fine, but the calculated roundoff error is garbage. I'll have a fix soon.

I noticed the debate at primegrid. It appears that my S16 and R16 results are fine, unquestionable. However, can I trust my S383 and R383 results or should those with zero-padded AVX FFT length be doublechecked?

In other words, if the tests run in LLR does produce a residue in the end, can I trust the non-base-2 result produced for the zero-padded AVX FFT length?

[henryzz]

Originally Posted by KEP

I noticed the debate at primegrid. It appears that my S16 and R16 results are fine, unquestionable. However, can I trust my S383 and R383 results or should those with zero-padded AVX FFT length be doublechecked?

In other words, if the tests run in LLR does produce a residue in the end, can I trust the non-base-2 result produced for the zero-padded AVX FFT length?

It should be fine. It is the error checking that is at fault.

[KEP]

Originally Posted by henryzz

It should be fine. It is the error checking that is at fault.

Okay, thanks Henry

Jean also told me the other day that I was not to be concerned regarding my tests. However the debate at primegrid confused me and thereby reinstated my uncertainty towards the safety of the new GWnum library

Anyway everything seems fine, so thanks for reensurring me that everything is just fine. Continuing to crunch for CRUS, happily

Take care

KEP

[AG5BPilot]

Originally Posted by KEP

Okay, thanks Henry

Jean also told me the other day that I was not to be concerned regarding my tests. However the debate at primegrid confused me and thereby reinstated my uncertainty towards the safety of the new GWnum library

Anyway everything seems fine, so thanks for reensurring me that everything is just fine. Continuing to crunch for CRUS, happily

Take care

KEP

Yes, you're confused about the debate at PrimeGrid. :)

We're not concerned about the validity of any of the BOINC jobs run with 3.8.12. The discussion I think you're referring to was about the qualification testing we're doing for 3.8.13, which must be done with 3.8.13. Someone essentially asked if he could use a test performed with 3.8.12 for the 3.8.13 qualification, and my answer was no. But BOINC tests performed with 3.8.12 are ok if they pass validation.