<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#c16">Comment # 16</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:newbie-02@gmx.de" title="b. <newbie-02@gmx.de>"> b.</a> <pre>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 ...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>