Bug 44117 - : Wrong calculation function: MOD
Summary: : Wrong calculation function: MOD
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
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:

Attachments
Add an attachment (proposed patch, testcase, etc.)

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:
9

Expected behavior:
34

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 ...