[Libreoffice-bugs] [Bug 44076] =(-8)^(1/3) should return -2

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #17 from Christopher M. Penalver <christopher.m.penalver at gmail.com> ---
(In reply to b. from comment #16)
> here is still some air upward, while '=(-8)^(1/3)^(2)' results in 4, just
> like '=(-8)^(2)^(1/3)', '=(-8)^(2/3)' produces #NUM! error, at least in ver. 
> 
> Version: 7.1.0.0.alpha0+ (x64)
> Build ID: 0d45380c99c7200075d01860a2315d0ddb450f1c
> CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render:
> Skia/Raster; VCL: win
> Locale: de-DE (de_DE); UI: en-US
> Calc: 
> 
> reopen? new bug? leave for future generations? or am i barking up the wrong
> tree? 
> 
> btw. the workaroung from @Christopher M. Penalver doesn't hold for this
> case, at least not with above mentioned ver. 
> 
> @Mike Kaganski has worked out (some of) the logical limitations of such
> transformations there:
> https://bugs.documentfoundation.org/show_bug.cgi?id=69293
> 
> the annotation 'brackets specify the order' imho doesn't hold, my memories
> of school math say that there are! rules to deal with and legally change
> calculation ordering, that way the three terms from the first sentence are
> equivalent and should give identical results? i have to think about multiple
> or losing roots or getting additional ones, but at least one result would be
> nice ...  
> 
> @mwelinder: imho calc stops using exact representations at 2^53-1, already
> 2^53 isn't exact, and calc does 'more aggresive' rounding than neccessary
> (down to 14 instead of 15,95 *lol* significant digits), and at 2^54 it's in
> a range where it doesn't care about 34 less or 66 plus, thus all it's
> producing consists of approximations and assumptions which approximation
> best fits user expectations ... 
> 
> i'm in doubt if calc uses real integers anywhere - which could hold up to
> 2^64 as you pointed out - but uses floats as standard and integer precision
> is limited to the range where fragment and mantissa balance each other out, 
> 
> given that it would be as legal to calculate -2 for your sample as it's to
> calculate 2^54 minus 34 to the same 1,8014398509482E+016 representation as
> 2^54 plus 66, 
> 
> i'd read somewhere that internal values and calculations have better
> precision and the rounding is only for the final result shown in the sheet,
> couldn't yet test or prove that ...

This bug is confirmed resolved a long time ago, and in latest Calc below. If
you find you are experiencing a bug in LibreOffice, please file a new report
(not make comments in a confirmed resolved and closed report).

Version: 7.0.2.2 (x64)
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201017/a4100b30/attachment.htm>