On 14/11/24 08:52, Roger Heflin wrote:
Hi,How different are the values? How many significant figures match? 0? 5? On Wed, Nov 13, 2024 at 12:33 PM Patrick Dupre via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote:Hello, I am not sure this issue is entirely relevant on this mailing list. Maybe you could redirect me. The same application (relatively heavy code), provides different values when it is run and compiled on 2 different machines. Both F40 (last update) gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) One Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz The other one Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz Actually, this happens when I use the gsl library. gsl-devel-2.7.1-8.fc40.x86_64 for integration (gsl_integration_cquad). Before integration, the values are strictly identical. The same Makefile is used. Now, if I copy the code generated by the machine A on machine B, I get the same results as it had been run on machine A. The size of both codes are slightly different. I conclude that the issue is due to the compiler. Indeed, the difference in the generated values seems pretty constant, i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference) i.e. a lot higher than the accuracy of the machine: < 1e-35. Which one is the good one? Why this behavior? Can I solve the issue?
Just my 2 cents worth. I develop at work in a language called SAS, which is interpretive like Python is. I see the sort of precision issues you are highlighting all the time, and the software vendor has written papers (which I can't lay my hands on atm) around the fact that they are expected because of the way computers work. There arguments are that when dealing with decimal numbers, because computers work in binary, there are certain numbers that cannot be accurately represented in binary, therefore you will get differences in the representation of those numbers. It may also have something to do with the fact that SAS stores numbers as double precision floating point. I've seen an upstream application supply us with a number to six decimal places and when we store that number in SAS the internal representation of that number does not match what we were supplied. One of the recommended solutions to this issue is to round numbers to the level of precision that you actually need.
regards,
Steve
Thank for any help. =========================================================================== Patrick DUPRÉ | | email: pdupre@xxxxxxx =========================================================================== -- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Attachment:
OpenPGP_0x1EBE7C07B0F7242C.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
