On Sat, Feb 9, 2013 at 7:39 PM, Dennis E. Hamilton <orc...@apache.org> wrote:
> 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.
There is big difference between documenting the behavior ("nailing it
down") and changing the behavior.
Imagine the following scenario:
Someone has implemented a custom application based on an OpenOffice
spreadsheet document. It is a mixture of macros and spreadsheet
formulas. The user enters data into some cells, presses a button, and
a new results table and a nice chart pop up on another sheet in the
file.
The developer extensively tested this application, exercised the full
range of input values for his calculations, and verified that the
results were correct. For sake of argument, imagine that in some user
inputs, he does a calculation of 0^0, and it returns 1, and his model
is entirely happy to use that result. It works for him. It is
correct for his use.
The developer then distributes his app to end-users, who are now
happily using the application. They don't know that it uses POWER()
behind the scenes. In fact, the calculations might all be in hidden
sheets, with password protection enabled. There are no
user-serviceable parts here. The person who suffers because of the
change is not necessarily the person who can fix it.
This is the kind of thing we risk break by changing the behavior of
spreadsheet functions to introduce a new error where once the a
function returned a reasonable value.
We need to avoid the belief that the only thing to worry about is
someone who sat down and typed 0^0 into a cell. That is not the
point. The point is spreadsheets that work correct today, and may
break tomorrow because of this change.
> 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.
>
