In C floating point numbers have about 7 digits of precision, and double precision floating point numbers have about 15 digits.
Your python case differs in the 16th digit, so python is using double precision floating point .
The example in the original post differs in the fourth digit… thats too much, there has to be some other problem like rounding or integer arithmetic. I dont understand what spreadsheets do with arithmetic but it seems precision is severely limited.
You do not even need the parenthesis, because multiplication and division are executed in sequence from left to right. Writing =700000/3772344 or =700000344/3772 (I tested it in LibreOffice Calc) gives the same result : 63838.8123011665,
I tested it on Excel (online version), and get the same result. wondering whith version did not give you the right result.
This is “double” precision (53 binary digits, which corresponds to (roughly speaking) 16 digits en decimal representation (15 digits are given by LO or Excel).
Internally, all calculations are in binary.
By the way, Excel does have a mistake in some calculations… the dates are wrong between 1.1.1900 and 28.2.1900, because Excel ignores the fact that 1900 was not a bessextile year…
I am tired and have not read through the replies, but an old friend reminded me once of the rule of PEMDAS (it’s an order of operations thing) and sometimes that has an impact on the bottom line. The question is are apps programmed to not just work the problem, but to do it properly in the right order of operations. This COULD be the issue you are experiencing (apologies if others said so and apologies if it is not!).