It is not clear that OpenOffice-lineage software has returned the same value for POWER(0,0) over the years. It seems that a third-party library has been relied upon for the implementation and there was apparently not much attention to edge cases. If that library changes or is different on different platforms, there is the prospect of unexpected differences. It is good that this is being nailed down.
In any case, in order to produce *any* reliable result for POWER(0,0), it is necessary to declare what that is as an implementation-defined (not -dependent) commitment. So Sayeth ODF 1.2 OpenFormula. The same goes for another implementation-defined case of POWER(a,b) although it seems that one is consistently implemented. (Java has a different idea, though. It appears capable of computing POWER(-27,1/3) = -3. Let's not do that.) - Dennis PS: I appreciate that the Release note should be succinct. For now, having an explanation for what is involved seemed useful for folks who wonder whether this is the right thing to do. A link to the BZ issue is helpful, once it is closed one way or the other. -----Original Message----- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, February 09, 2013 15:43 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 On Sat, Feb 9, 2013 at 6:11 PM, Andrea Pescetti <pesce...@apache.org> wrote: > A good practical example of backwards-incompatible changes in version 4.0 is > the behavior of Calc while computing 0 ^ 0. > > You can find a long issue, with different points of view, about this at: > https://issues.apache.org/ooo/show_bug.cgi?id=114430 > but in short: > - Obviously, 0 ^ 0 is an illegal operation in mathematics and the result is > undefined/invalid Spreadsheets are used by businessmen and not only mathematicians. Stability is important to them. Getting different results in different versions of OpenOffice would be a very scary thing. > - In 3.4.1, "=0 ^ 0" returns 1 > - In 4.0, as patched by Pedro (see issue), "=0 ^ 0" would return an error > - According to ODF, valid results are 0, 1, error In other words, the results we were giving before were entirely valid. > - We gain interoperability since Excel returns an error too Microsoft has gone decades with treating the year 1900 as a leap year. Should we? > - We lose backwards compatibility if someone was relying on the fact that > OpenOffice returns 1 as the result of "=0 ^ 0" > Correct. The fact is we have returned 1 for this calculation for over a decade. Whether mathematicians think it is right or wrong (and they do not all agree), that is what we did. So changing it now has the potential to break real user spreadsheets. So this is a serious change. > I'm OK with the proposed change, provided we advertise it in the release > notes. I'm not aware of any cases where someone is actively using the fact > that in Calc 0 ^ 0 evaluates to 1, and even if someone did, I would say that > his spreadsheets should not compute 0 ^ 0 at all. A side benefit would be For what advantage? Better Microsoft interop? OK. That is reasonable. But I would not support a similar change merely because it amuses the mathematically curious. > that school students quickly wanting to find out what is the result of 0 ^ 0 > would be told the truth (it's an error) instead of being presented with a > numeric result and no warnings. (Then the student would go on and write "= - > 2 ^ 2" and have a lot of fun, but this is out of scope here). > We need to take our responsibility as stewards of OpenOffice seriously. And that means dealing with the fact that we have millions of users and many millions of documents out there created with past versions of OpenOffice. We can't just change something because one person feels like it. Otherwise someone else can just change this function back at a later date because they feel like it. (ODF says 0 is also a permitted value. Maybe someone wants to change to that?) We need to discuss these kinds of changes. Changing the behavior of a Calc function, without prior discussion on the list, is entirely unacceptable. Maybe this was not clear before, but as I stated in my other note, I consider all changes that break backwards compatibility of public API's and interfaces, including spreadsheet formulas, to be controversial. They should require Review-then-Commit. Of course, having this discussion now, even after the code was checked in, and starting to add info the Release Notes, is good progress. But I want to make sure we're all on the same page as to why such changes are critical to have reviewed. > Is there consensus that this is a reasonable backwards-incompatible change, > or compelling reasons to revert it? > I already gave my concerns for accepting such changes: 1) We need Release notes. 2) We need Test cases Dennis contributed the first. It would be great to have a test document attached to the issue so we can verify that other aspects of the POWER() and associated ^ operator were not modified as well. I can come up with something and attach it to the BZ issue. Regards, -Rob > Regards, > Andrea.
