2

I am writing python code that involves a series of math calculations. One such is the following operation:

 result1 = float1 % float2 //modulo operation to find the remainder

where float1 = 6816605016955680000000 and float2 = 1577917828000

The result I get is 1573597498272 (reverse math shows that this is not accurate). I get the same result on Excel or Numbers as well.

However, when I try this on a quad-core system, Excel and Numbers give a very different result which is 1573597828000 (reverse math shows this is accurate). The python program continues to give the same old result even on the quad-core system. (Python version is 3.7.2 on my system and 3.9 on quad-core system).

What can I do to ensure python gives me the accurate result? Any guidance would be super valuable. Thanks in advance.

Nagendra Murti
  • 33
  • 1
  • 4
  • 1
    Can you give a complete, minimal program which produces the wrong answer on 3.7.2 and not on 3.9? I guess one or the other of the values is floating point rather than an integer. `6816605016955680000000 % 1577917828000` gives the right (integer) answer. `6816605016955680000000.0 % 1577917828000` gives the wrong (floating-point) answer. Results are the same in every version of python I believe. – Paul Hankin Mar 07 '21 at 07:13
  • floats are not precise by nature. If you do it with integers it gives you the correct answer. If you do it with floats it won't. That's just how it is. – matthias Mar 07 '21 at 08:00
  • See [this answer](https://stackoverflow.com/a/32143465/12299000). – kaya3 Mar 07 '21 at 09:11

1 Answers1

0

Python numbers are not accurate for large numbers, if you want more accurate precision, use the Decimal class:

from decimal import Decimal

Decimal(6816605016955680000000) % Decimal(1577917828000)

Output:
Decimal('1573597828000')

This should give you consistent results across different systems.

SeaBean
  • 22,547
  • 3
  • 13
  • 25
  • To be clear, although floating-point numbers are not precise enough for this calculation, the result in Python *should* be the same across different computer systems, otherwise they are not IEEE 754 compliant. The OP only says Excel gives different results on different systems (which it may well do), not Python. – kaya3 Mar 07 '21 at 09:08
  • @kaya3 Even though Python gives consistent results across systems, the results given are still wrong in this case. I don't see the suggested link in marking this post duplicate can gives any suggestion to OP regarding in Python context. It just discusss standards and cannot directly give a hint or solution to OP as to how to solve his/her problem. So, I would suggest not marking it duplicate base on the link attached. Please provide something that can help OP to get answer for his question `What can I do to ensure python gives me the accurate result? ` – SeaBean Mar 07 '21 at 09:45
  • Ok, I found the other link quoted in the comment does provide the answer in Python perspective. As it is quite long in the link. I would suggest the link provided at the top to pinpoint that specific answer instead. – SeaBean Mar 07 '21 at 09:48
  • There is no option to link to a specific answer as a duplicate, only a question. – kaya3 Mar 07 '21 at 10:18
  • 2
    @kaya3: Unlike some other languages, Python (at least CPython) makes no promise of IEEE 754 compliance: it just uses whatever C's `double` provides. With extremely high probability the actual `double` format _will_ be IEEE 754 binary64, but that doesn't prevent other factors from affecting reproducibility across systems. E.g., on some 32-bit Linux systems where `gcc` makes use of the x87 FPU, `1e16 + 2.9999` at a Python prompt will give `1.0000000000000004e+16` thanks to double-rounding with 64-bit intermediate precision. On most other machines it gives `1.0000000000000002e+16`. – Mark Dickinson Mar 07 '21 at 11:22