On Sun, Feb 10, 2013 at 3:16 PM, Stuart <dertop...@web.de> wrote: > On Feb 9, 2013, Andrea Pescetti 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 > > > > On 02/10/13, Rob Weir wrote: >> >> 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. > > > +1. > > > On Feb 9, 2013, Andrea Pescetti wrote: >>> >>> - 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 > > > I would interpret this the following way: "0 ^ 0" may yield zero or null or > some error. Whichever value is yielded, it will stay the same. And not only > for all calls in a session (POWER could be implemented to return a different > value for 0 ^ 0 between invokations), but for all eternity. Even if the > software is upgraded. > > If you want to change the behaviour of a function over time, you should > explicitely tell so (unless we are talking about a bugfix). Whether the > changed implementation of the POWER function can be considered as a bugfix > is quite another issue since the documentation of the POWER function > explicitely mentions that POWER(0, 0) may return the value 1. So IMHO, this > cannot be considered a bugfix. > > We had some issues with a numerical badly behaved problem that converged on > one system and diverged on another. Same version of Matlab, same code. > Apparently it was down to the different FPU units on the processors (one > using 80bits for intermediate floating point values, one only using 64). > This is a PITA to debug. > > > On Feb 9, 2013, Andrea Pescetti wrote: >>> >>> 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 > > > On 02/10/13, Rob Weir wrote: >> >> 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. > > > Both of you have perfectly reasonable points. Why don't we simply make it > configurable whether POWER returns one, zero, or some error? For reasons of > backward compatibility we could return the value one as default, and if the > user wants better MS Office compatibilty, he could change the configuration > of POWER. >
An interesting option would be to enable a "strict" or "audit" mode of calculation where all error-prone expressions are reported to the user. This mode would be slower than a normal calculation, but would allow us to point out things like: 1) Use of implementation-defined formulas that might impact interoperability (0^0 is one example, but there are several others) 2) Dependency on automatic string to number conversion operations that might be interpreted differently in different locales. 3) Operations that involve exact comparisons of results to constant floating numbers, something that is very risky due to round-off errors and precision limitations. 4) String operations that silently returned reasonable values despite parameters that exceeded the bounds of the string. Regards, -Rob > Stuart >
