https://bugs.documentfoundation.org/show_bug.cgi?id=44076

--- Comment #22 from b. <[email protected]> ---

(In reply to Jean-Baptiste Faure from comment #21)  

it's a little overstretching the OT, but as you ask and since many similar
questions are worrying me ...   

> Why did you implement mathematical inconsistency in Calc? Because MS did the
> same in Excel?

that could be discussed as one of multiple meaningful ideas - not necessarily
good or the best, but most decisions are two faced.   

IMHO there have been decisions to  
- use IEEE doubles - they are fast but not exact,  
- in Excel to - try to - cover some of the resulting issues by restricting to
15 sig. decimal digit precision ( alas different internally and for the GUI
inducing new issues ),  
- in Calc topping that by implementing an 'approximal' concept ( questionable
and not sufficient  attempt to cover issues resulting from the above ),
allowing 4 bit ( up to 30 ULP in some cases ) imprecision,  

and thus in LO Calc:  
'=0.333333333333334=0.333333333333333' -> 'TRUE' and  
'=0.333333333333334-0.333333333333333' -> '0' while  
'=RAWSUBTRACT(0.333333333333334,0.333333333333333)' -> '9.99200722162641E-16
'  
my gut feeling says that it is logically impossible to do consistent
mathematics on such a basis, nevertheless it is tried again and again with
pleasure.  

the effect of all these attempts for the OP problem is - in LO Calc:  

'1/3' = '0.333333333333333' = '0.333333333333334' = '6004799503160661/2^54'  

'approximate math' on a high level,  

> Now a^b != exp(b*ln(a))

there is one math which is consistent to high degree: school math, IMHO
implementing a variant with some deviations is basically difficult to build
fully consistent, thus expect fails here and there ...  

> You are confusing cubic root and the exponentiation function. a^b is not
> defined for a ≤ 0  

I vague remember that there is a valid concept to write roots as exponentiation
with fractions, but restricted to 'finally shortened fractions of exact
integers if you want to stay with rational results' or similar? with irrational
- complex - roots you can use all rationals as exponents?  

'accuracy' ... '2^54' is accurate only from a binary POV, from a decimal POV
it's beyond the limits where values can be represented to integer precision
with IEEE doubles, and thus the representative for a range, [ 18014398509481983
.. 18014398509481986 )? has the 'alternate' prime factorization of
'3*3*3*3*7*19*73*87211*262657' or can be divided by 6004799503160661 to a clean
3. a justified result in a math system where '= 3 * 6004799503160661' ->
'1801439850948198**4**'.  

accounting that and calculating with the shortened figure '1/3': '=(-8)^(1/3)'
-> '-2' is! a school mathematical meaningful result ... in the limits of how
accurate binary-FP-math can emulate decimal calculations.  

If you are looking for a spreadsheet with better precision and less - but not
yet none - inconsistencies and can live with a little reduced comfort: have a
look at gnumeric, IMHO calc could do good orienting more towards gnumeric and
less towards Excel, but a conversion would be an enormous piece of work.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to