-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plfit fails some tests on the s390x, powerpc, and ppc64 architectures #38
Comments
Travis supports these. Could set up a Travis-based CI to debug. |
I have added a Edit: nevermind, got it, apparently I had to "migrate" the repo to travis-ci.com first. |
The build fails on s390x with Travis, but apparently only in release mode. |
When this issue was opened, I attempted to compile it for x87, but even with SSE disabled, I get an error that this is not possible. If that's easily fixable, it might be worth a try as it would make debugging simpler. |
I can't test this easily for x87 as I am on Apple Silicon and |
This was my mistake. It doesn't work with Clang on macOS, but it does work with GCC. Of course this is Intel-specific so it won't work on your M1 machine. The test suite passes. For reference, I used:
where |
The |
@jgmbenoit Something weird is going on with the
The output from the test log on
Note that the difference between the expected and the observed log-likelihood in the test is Do you have any ideas about what may be going on here? Or, alternatively, do you have a detailed test suite for |
I have indeed a test suite for the My first guess is that one of the used native C math functions does not work as expected on this architecture. If so, my fist move will be to check how this is managed in GSL (upstream and at packaging level). Note that, as Debian Developer, I have actually access to these architectures. I will try to have a look and submit a fix by the end of this week-end. This sounds as a good challenge. |
Thanks a lot for your help! Looking forward to the patched version. |
I have reverted |
The numerical tests for |
I would avoid relying on |
My understanding is that |
long double exists on every platform, but it's characteristics are all over the place. It might be the same as double, it might be Intel x87 80 bit extended precision, it might be powerpc "double double" or it might be IEEE quad precision. It may also be implemented in software even when regular floating point is implemented in hardware. So it really doesn't make sense to use in portable code. |
gcc on s390x has build flags -mlong-double-64 and -mlong-double-128. When building with -mlong-double-64 the unit tests are passed. With -mlong-double-128:
Either the unit test for log-likelihood should be removed or long double should not be used in the package. |
The second option is the one to choose: long double should not be used in the package . |
With the help of my favourite Computer Algebra System I could finally isolate and manage properly the faulty cancellations. I will now focus on the implementation of the analytical result. This is the easy part. |
Thanks, looking forward to this! |
see the Build status of the plfit Debian package for more details.
The text was updated successfully, but these errors were encountered: