<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WORKSFORME - =(-8)^(1/3) should return -2" href="https://bugs.documentfoundation.org/show_bug.cgi?id=44076#c17">Comment # 17</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WORKSFORME - =(-8)^(1/3) should return -2" href="https://bugs.documentfoundation.org/show_bug.cgi?id=44076">bug 44076</a> from <a class="email" href="mailto:christopher.m.penalver@gmail.com" title="Christopher M. Penalver <christopher.m.penalver@gmail.com>"> Christopher M. Penalver</a> <pre>(In reply to b. from <a href="show_bug.cgi?id=44076#c16">comment #16</a>) > 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: > <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - Error taking Cube Root of Negative Number" href="show_bug.cgi?id=69293">https://bugs.documentfoundation.org/show_bug.cgi?id=69293</a> > > 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</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>