Bug 44117 - : Wrong calculation function: MOD
Summary: : Wrong calculation function: MOD
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Reported: 2011-12-24 02:31 UTC by Konrad
Modified: 2020-10-16 13:55 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Konrad 2011-12-24 02:31:40 UTC
Problem description: 

Steps to reproduce:
1. =MOD(26^15;77)

Current behavior:

Expected behavior:

Platform (if different from the browser): 
Kubuntu 11.10
Browser: Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Comment 1 Markus Mohrhard 2011-12-25 01:52:11 UTC
This is a problem a floating point arithmetics. We will not fix this problem.
Comment 2 Konrad 2011-12-25 06:59:29 UTC
Hmm... Maybe some info about precision limitation?
Comment 3 Markus Mohrhard 2011-12-25 07:16:59 UTC
We are using IEEE754 double values internally (c++ double). This is the standard for floating point based calculations and is used by most modern programs and many programming languages.
Comment 4 Konrad 2011-12-25 08:16:02 UTC
Why =26^15

Calc gives 1,677259342285730000000e21
SpeedCrunch gives 1,67725934228572592537600000000000000000000000000000e21
Comment 5 b. 2020-10-16 13:55:50 UTC
calc 7.1 produces '0' as result, without notice of 'error' or 'overflow' ... critical ... 

is this substitution correct? 

MOD(26^15;77) = MOD((MOD(26^5;77)*MOD(26^5;77)*MOD(26^5;77));77)

if ... where is the problem for calc or devs to implement that ('split too big arguments') and deliver correct results? it's been nearly 9 years time for that ... 

and: ... 'better precision than ex$el' would be a great marketing gag ... 

@Markus Mohrhard: 'standard' and similar are good strong arguments, but not an excuse for 'everything', and not for wrong results ...