https://issues.apache.org/ooo/show_bug.cgi?id=114430
orcmid <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |[email protected] Resolution|WONTFIX |--- Ever confirmed|0 |1 --- Comment #6 from orcmid <[email protected]> --- Technically, the proper response for calculation of 0^0 is NaN. I suspect there is a setting somewhere in the FPU to make it 1 though. I remember arguing with Don Knuth about this once (since he found 1 nicer for certain things). I once published (in Dr. Dobbs) a Pascal implementation of x^n for integer n. I solved the problem for 0^0 by returning 0/0, which is expected to be mathematically equivalent if neither is NaN. If the floating point implementation determined that to be NaN, good. If it was set up to return something else, I had managed to side-step imposing my own notion of the correct answer. This doesn't solve the problem for Calc of course. OpenFormula specifies (in 6.4.6) that 0^0 is not permitted. But it also says a^b is implemented by POWER(a,b). In 6.16.46 POWER(0,0) is implementation-defined but must be one of 0, 1, or an Error. The smart thing is to do whatever Excel does in this case. I just got #NUM! for =POWER(0,0) using Excel 2013 Preview. The thing about #NUM! is that it can't be overlooked, whereas a result of 0 or 1 can end up being used in further calculations without awareness of what is happening. Someone who doesn't like #NUM! (or the Calc equivalent) can add logic to produce the result they prefer instead if 0^0 is possible in their particular spreadsheet. Since Pedro is going to look into this, I am changing the status of this issue to REOPENED. -- You are receiving this mail because: You are on the CC list for the bug.
