I have a following problem. I am filing my annual income tax return and for which I am calculating my income. The following is the formula and its result in LibreOffice Calc and MS Excel :
(700000/3772)*344 = 63844.45
The same formula when I write in LibreOffice Writer using calculation function, gives me the following result :
(700000/3772)*344 = 63838.81
The value given by LibreOffice Writer is the correct one.
While I am not able to figure out why this error, my real issue is, even a small increase in my income, will put me in next slab of income tax.
Request for valuable input for achieving the correct value in LibreOffice Calc.
A general rule, when programming arithmetic expressions is to postpone divisions till last
So writing it as
700000*344/3772
is preferred.
The reason doing the divide last is preferred is that division often leads to loss of precision.
I tried my form in R and it leads to the correct result.
Regards
Neville
Python 3.10.4 (main, Apr 2 2022, 09:04:19) [GCC 11.2.0] on linux
Type “help”, “copyright”, “credits” or “license” for more information.
In a spreadsheet the formula is of the form =(700000/3772)*344
I tried it in both Libre Calc and Gnumeric; it works.
To round if off to cents use the currency format.
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!).
