On Thu, 14 Nov 2024, Stephen Morris wrote:
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.
That really does not match OP's problem.
That conversion from floating decimal to floating binary and back
does not necessarily produce the same value has long been known.
OP's problem is more like the same sequence
produces different results on similar machines.
If OP's program has very long decimal strings,
a difference in compilers might make a difference.
Without such decimal strings, C requires round to nearest.
To ensure that rounding of decimal strings is not the issue,
OP could the a literal format that can be exactly
stored in a binary floating point variable.
E.g. 0x5.Fp-3 = (5 + 15./16)/8 .
A more likely issue is different algorithms in the libraries.
a*b + x*y + g*e might be evaluated in different orders in the libraries.
--
Michael hennebry@xxxxxxxxxxxxxxxxxxxxxx
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
--
_______________________________________________
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
