Description: (-1)^(1/3) --> -1 (-1)^(2/3) --> Error (-1)^(1/5) --> -1 (-1)^(3/5) --> Error (-1)^(6004799503160661/2^54) --> -1 From a purely mathematical (ie., using the mathematical concept of Reals) the correct results are -1, +1, -1, -1, and Error. From a floating-point view (i.e, using ieee-854 base-2 floating-point numbers, round-to-nearest and operations in the order dictated by parentheses) the correct results are Error, Error, Error, Error, and Error. In other words, the results are inconsistent with both mathematical and floating-point views. Looking at the code, this comes from a na\"ive attempt at identifying certain floating-point numbers as odd-denominator fractions. Suggestion: implement Gnumeric's 3-argument POWER, e.g. POWER(-1,1,3). That avoids trying to interpret floating-point numbers as fractions, a highly error-prone business. Steps to Reproduce: Enter this into A1:A5 =(-1)^(1/3) =(-1)^(2/3) =(-1)^(1/5) =(-1)^(3/5) =(-1)^(6004799503160661/2^54) Actual Results: Actual: -1, #NUM!, -1, #NUM!, and -1. Expected Results: Expected: 5 x #NUM! or Expected: -1, 1, -1, -1, #NUM! Reproducible: Always User Profile Reset: No Additional Info: The constants in (-1)^(6004799503160661/2^54) are carefully chosen such that there is no floating-point rounding errors at any point in the calculation. The exponent is what you get from 1/3 after rounding to nearest double. The code is at https://docs.libreoffice.org/sc/html/interpr5_8cxx_source.html near line 1588. As an aside, the static_cast<int> is undefined behaviour for cases like (-1)^(2^-64).
confirming with Version: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: de-DE (de_DE); Calc: but excel 2016 calculates same...
Created attachment 146601 [details] example excel 2016
*** This bug has been marked as a duplicate of bug 44076 ***
This is not a duplicate of bug 44076. The latter was the same as bug 69293, while this one is about inconsistent result of fixing them both.
Unmarking duplicate. 44076 was about odd roots only and was just closed based on evaluating (-8)^(1/3) as -2. That ignores the whole inconsistency raised here.
Hello, A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear mwelinder, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
for the bug hunting session: still behaviour as mentioned in OP with below ver., regardless which file format (ods, xls, xlsx), resistent against F9 and ctrl-shift-F9, indpendent on recalc on load or not, unaffected by threaded or CL ... just a math-error, sorry, inconsistency, not anything in handling, Version: 6.4.0.1 (x64) Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: CL
Expected should be 5 x #NUM! See https://bugs.documentfoundation.org/show_bug.cgi?id=44076#c21 and https://bugs.documentfoundation.org/show_bug.cgi?id=69293#c3 For me the correct solution is to restore initial behavior of a^b when a < 0. Best regards. JBF
I agree with a revision of code. Another bug is: =0^0 --> 1 but really must be an error. With the same formula Ecxel give an error.. I know many calc apps give 1 as result but not all!
(In reply to Roberto from comment #10) > [...] > =0^0 --> 1 > > but really must be an error. 0^0 = 1 by definition. So not a bug. > > With the same formula Ecxel give an error.. > I know many calc apps give 1 as result but not all! It is not necessary to mimic all MS-Excel's bugs! Best regards. JBF
*** This bug has been marked as a duplicate of bug 114929 ***
m.a.riosv: that must have been the wrong bug number. This bug (121398): semantics of evaluating powers 114929: parsing of power expressions in the absence of ()s. Clearly not a duplicate of that!
Back to NEW
Dear mwelinder, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The Operator ^ (6.4.6, part 4, ODF 1.3) is defined by reference to the POWER function. The POWER function (6.16.46, part4, ODF 1.3) allows some implementation-defined behavior: <quote> POWER(0,0) is implementation-defined, but shall be one of 0,1, or an Error. POWER(0,B), where B < 0, shall return an Error. POWER(A,B), where A ≤ 0 and INT(B) != B, is implementation-defined. </quote> Implementation-defined behavior has to be documented outside the code. For LibreOffice it is on page https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_implementation-defined_items For implementation-defined behavior in regard to operators and functions that page states, that it is defined in the online-help. The online help states " =POWER(0,0) returns 1." That is conform to ODF. But the online help says nothing about the case "POWER(A,B), where A ≤ 0 and INT(B) != B". So this is a missing documentation. Returning a value in same cases and an error in other cases is conform to ODF, but it must be documented. LibreOffice provides in addition detailed information for functions, in case of POWER it is page https://wiki.documentfoundation.org/Documentation/Calc_Functions/POWER There the description of the behavior of case "POWER(A,B), where A ≤ 0 and INT(B) != B" does not fit to the actual implementation. The current implementation is possible in ODF, but the documentation is wrong/missing. So I set Component to Documentation.
(In reply to Regina Henschel from comment #16) > Returning a value in same cases and an error in other cases is conform to > ODF, but it must be documented. I tried " may or may not ... " (https://gerrit.libreoffice.org/c/help/+/171350) but a bit of background explanation wouldn't hurt.
Pierre F committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/8b2a9c64b866c0978f37f8847ac46b527896268c POWER(). tdf#121398