<html>
    <head>
      <base href="https://bugs.documentfoundation.org/">
    </head>
    <body>
      <p>
        <div>
            <b><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 <span class="vcard"><a class="email" href="mailto:newbie-02@gmx.de" title="b. <newbie-02@gmx.de>"> <span class="fn">b.</span></a>
</span></b>
        <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>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>