Bug 139095 - incorrect calculation result
Summary: incorrect calculation result
Status: RESOLVED DUPLICATE of bug 138920
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-20 14:47 UTC by Steffen Reinholz
Modified: 2021-02-18 15:54 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steffen Reinholz 2020-12-20 14:47:57 UTC
Description:
I have a ODS file where I weekly put the recent status of my accounts and investment portfolios. So I can check how they develop.
But when I calculate the difference of two weeks after I used the "sum" function it shows a very small difference. Calc does not calculate correctly.
For example this week it is: 24852,02 - 24427,97 = 424,0500000000003 instead of 424,05 but I don't actually type in the numbers I refer to the cell like = B167-B158 and within these cells I used =Summe(...:...)
As it is an overview of my bank accounts and investment portfolios I only use two digit numbers.
I don't know where this problem comes from.

Steps to Reproduce:
1. set up two different tables with various numbers like an overview of your accounts and you want to check how they develop
2. use the summerize function under both tables
3. calculate the difference of both sum ups

Actual Results:
424,0500000000003

Expected Results:
424,05


Reproducible: Always


User Profile Reset: No



Additional Info:
nothing
Comment 1 m_a_riosv 2020-12-20 15:28:10 UTC

*** This bug has been marked as a duplicate of bug 138920 ***
Comment 2 b. 2021-02-18 15:54:54 UTC
apart from the fact that the title of 138920 is misleading, 

in case of 'cancellation' when subtracting similarly large numbers, mathematically (decimal-mathematically!) wrong values are actually calculated, thus it requires no change in the 'display string' but a correction of the value itself on the basis of 'decimal expectations', 

so apart from that the classification as Duplicate is correct, if you look around you will probably find dozens of bugs that have the same cause ...