Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

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
- 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
- We gain interoperability since Excel returns an error too
- We lose backwards compatibility if someone was relying on the fact 
that OpenOffice returns 1 as the result of "=0 ^ 0"

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 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).

Is there consensus that this is a reasonable backwards-incompatible 
change, or compelling reasons to revert it?

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

["Marcus (OOo)" <ma...@wtnet.de>]

Am 02/12/2013 11:22 PM, schrieb Rob Weir:
> On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo)<ma...@wtnet.de>  wrote:
>> Am 02/12/2013 10:39 PM, schrieb Rob Weir:
>>
>>> On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>>
>>>> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>>>>
>>>>> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni<pf...@apache.org>    wrote:
>>>>>>
>>>>>>
>>>>>> Hello;
>>>>>>
>>>>>> I don't understand,
>>>>>>
>>>>>> I saw a bug (erroneous result returned by a function) and I fixed
>>>>>> it respecting the standards, thereby enhancing interperability
>>>>>> with the market leader.
>>>>>>
>>>>>> I am aware that Rob has a different point of view here but so
>>>>>
>>>>>
>>>>>
>>>>> By my count, those who expressed concern about your patch are;
>>>>>
>>>>> - Me
>>>>> - Regina
>>>>> - Andre
>>>>> - Stuart
>>>>> - Günter
>>>>>
>>>>> I think this is a non-trivial amount opposition, including from some
>>>>> whose opinions you might respect more than mine.
>>>>>
>>>>>> far neither him nor Stephen Hawking has explained how the change
>>>>>> would be incorrect and no example where someone has been affected
>>>>>> by this change has been provided.
>>>>>>
>>>>>
>>>>> You can't have it both ways. Your claimed benefit is intrinsically
>>>>> tied to breaking compatibility with earlier versions of OpenOffice.
>>>>> You cannot both claim that it has a significant interop benefit and
>>>>> also claim that it has a negligible backwards compatibility impact.
>>>>
>>>>
>>>>
>>>> IMHO nobody wrote that there is a significant improvement in direction of
>>>> better compatibility. Of course it's just a step of 1 per mill.
>>>>
>>>> Some facts from the issue itself:
>>>>
>>>> - open since 2010-09-09
>>>> - only 2 votes (from author of comment #2)
>>>> - only 4 mail addresses on CC (all from apache)
>>>> - only 3 comments (before our discussion started)
>>>>
>>>>   From my point of view this issue is of very low interest for others -
>>>> compared with other issues.
>>>>
>>>> But as nobody has delievered a valid use case, we're talking about a
>>>> theoretically possibility of broken spreadsheets and therefore spent
>>>> already
>>>> too much of our time for this discussion.
>>>>
>>>
>>> Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
>>> right now that would be break if we changed the behavior of 0^0.
>>
>>
>> And what is your *serious* use case for this spreadsheet? Beside to use it
>> as a test document? And you have it created before the discussion has
>> started?
>>
>
> The spreadsheet I am thinking about is over 4 years old, has been
> published and is used by others as well.

Maybe, but what we still don't know is the use case. Why don't you come 
up with more details?

> I'd also point out that asking your question on this list is not
> really telling you anything.  We've had 37 million downloads of AOO
> 3.4.  Only 400 people subscribe to this list.  So I don't think this
> is great evidence for saying it has zero impact.
>
> But again, if you think that situation never comes up in real use,
> then let's not make the change, since it would have no benefit.

Sorry, I don't understand why the change should not been made? Just to 
keep the implementation forever? Honestly, your sentence makes no sense 
to me.

OK, to make it clear:
Do what you want, discuss on and on. My standpoint is that this is a 
ridicolous discussion and the change non-serious.

For me this is EOD.

Good night.

Marcus



>> I'll ask my question again:
>> Is there more than one who can deliever a *serious and valid use case*?
>>
>> Thanks
>>
>> Marcus
>>
>>
>>
>>
>>>> I propose to keep the change as it is now.
>>>>
>>>> My 2 ct.
>>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> Has the patch been vetoed, and if so on what basis?
>>>>>>
>>>>>> Pedro.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ________________________________
>>>>>>> Da: Dennis E. Hamilton<de...@acm.org>
>>>>>>> A: dev@openoffice.apache.org
>>>>>>> Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro
>>>>>>> Giffuni'<pf...@apache.org>
>>>>>>> Inviato: Martedì 12 Febbraio 2013 13:11
>>>>>>> Oggetto: RE: Calc behavior: result of 0 ^ 0
>>>>>>>
>>>>>>> RESOLUTION OF THE PROPOSAL
>>>>>>>
>>>>>>> The proposed change was made under CTR (Commit then Review). There has
>>>>>>> been
>>>>>>> a subsequent review and, as Don points out, the discussion has been
>>>>>>> lengthy
>>>>>>> and vocal.
>>>>>>>
>>>>>>> The objective is to achieve consensus.  I believe it is clear that
>>>>>>> there
>>>>>>> is
>>>>>>> no consensus on the proposed change and the proposal fails.
>>>>>>>
>>>>>>> I can't speak for the AOO PMC.  It would be useful if Andreas helped
>>>>>>> wrap
>>>>>>> this up.  If the lack of consensus is affirmed, Pedro can revert the
>>>>>>> change
>>>>>>> and adjust the Bugzilla issue.
>>>>>>>
>>>>>>> THE ESSENCE OF THE PROPOSAL
>>>>>>>
>>>>>>> The proposal is to enact the breaking change as described on
>>>>>>> the Community Wiki at
>>>>>>>
>>>>>>>
>>>>>>> <https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
>>>>>>> .
>>>>>>>
>>>>>>> It is under Changes that Impact Backward Compatibility, Calc and
>>>>>>> OpenFormula
>>>>>>> Support.
>>>>>>>
>>>>>>> "Exponentiation
>>>>>>>
>>>>>>> "The current version of Calc produces 1 for POWER(0,0).  This is one
>>>>>>> of
>>>>>>> the
>>>>>>> implementation-defined results that is permitted by ODF 1.2
>>>>>>> OpenFormula.
>>>>>>>
>>>>>>> "It is proposed to change POWER(0,0) to result in #VALUE!.  This is
>>>>>>> also
>>>>>>> permitted as the implementation-defined result.  This is also
>>>>>>> compatible
>>>>>>> with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>>>>>>> Spreadsheets. ..."
>>>>>>>
>>>>>>> OUTCOME
>>>>>>>
>>>>>>> The proposed change is tracked in Bugzilla Issue #114430,
>>>>>>> <    https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>>>>>>>
>>>>>>> A patch to implement this proposal is already included in the SVN.
>>>>>>> If the proposal is not accepted as the result of CTR review, the
>>>>>>> Issue will be closed and the patch reverted.
>>>>>>>
>>>>>>> - Dennis
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Donald Whytock [mailto:dwhytock@gmail.com]
>>>>>>> Sent: Tuesday, February 12, 2013 09:20
>>>>>>> To: dev@openoffice.apache.org
>>>>>>> Subject: Re: Calc behavior: result of 0 ^ 0
>>>>>>>
>>>>>>> ...So I got curious, and I paged back in my email archive, and it
>>>>>>> seems this is the biggest AOO dev thread since the graduation vote
>>>>>>> back in early September.
>>>>>>>
>>>>>>> At this point, does anyone care enough about changing the status quo
>>>>>>> as to put up a coherent proposal to be voted on?
>>>>>>>
>>>>>>> Don

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

On 02/12/2013 05:45 PM, Rob Weir wrote:
> On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest <ha...@laposte.net> wrote:
>> Le 12/02/2013 23:22, Rob Weir a écrit :
>>
>>> But again, if you think that situation never comes up in real use,
>>> then let's not make the change, since it would have no benefit.
>>
>> You don't seem to see the benefit of the change: warn the user that there is
>> something weird in the formula that requires his attention.
>> Perhaps that there are users getting wrong results because a value is
>> returned and therefore hides the problem.
>>
> And your solution is to give users error messages where they do not
> have a problem ?!  What if they the examine the formula and find out
> that it is exactly what they wanted?  Your solution would force them
> to rewrite their formulas for no good reason.
>
> Again this is like giving an spelling error for "their" because some
> users might confuse it with "there".
>
> -Rob

I am torn as to which is worse..... because loading the document in any 
other program able to read ODF might exhibit completely different 
behavior; and still be valid to the spec.

Although I would prefer returning an error, if it does not, then it 
should stay as it is (as opposed to changing to one of the other 
supported values)

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 12/02/2013 23:22, Rob Weir a écrit :
>
>> But again, if you think that situation never comes up in real use,
>> then let's not make the change, since it would have no benefit.
>
>
> You don't seem to see the benefit of the change: warn the user that there is
> something weird in the formula that requires his attention.
> Perhaps that there are users getting wrong results because a value is
> returned and therefore hides the problem.
>

And your solution is to give users error messages where they do not
have a problem ?!  What if they the examine the formula and find out
that it is exactly what they wanted?  Your solution would force them
to rewrite their formulas for no good reason.

Again this is like giving an spelling error for "their" because some
users might confuse it with "there".

-Rob


> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 12/02/2013 23:22, Rob Weir a écrit :
> But again, if you think that situation never comes up in real use,
> then let's not make the change, since it would have no benefit.

You don't seem to see the benefit of the change: warn the user that there is something weird in the formula that requires his attention.
Perhaps that there are users getting wrong results because a value is returned and therefore hides the problem.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 02/12/2013 10:39 PM, schrieb Rob Weir:
>
>> On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)<ma...@wtnet.de>
>> wrote:
>>>
>>> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>>>
>>>> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni<pf...@apache.org>   wrote:
>>>>>
>>>>>
>>>>> Hello;
>>>>>
>>>>> I don't understand,
>>>>>
>>>>> I saw a bug (erroneous result returned by a function) and I fixed
>>>>> it respecting the standards, thereby enhancing interperability
>>>>> with the market leader.
>>>>>
>>>>> I am aware that Rob has a different point of view here but so
>>>>
>>>>
>>>>
>>>> By my count, those who expressed concern about your patch are;
>>>>
>>>> - Me
>>>> - Regina
>>>> - Andre
>>>> - Stuart
>>>> - Günter
>>>>
>>>> I think this is a non-trivial amount opposition, including from some
>>>> whose opinions you might respect more than mine.
>>>>
>>>>> far neither him nor Stephen Hawking has explained how the change
>>>>> would be incorrect and no example where someone has been affected
>>>>> by this change has been provided.
>>>>>
>>>>
>>>> You can't have it both ways. Your claimed benefit is intrinsically
>>>> tied to breaking compatibility with earlier versions of OpenOffice.
>>>> You cannot both claim that it has a significant interop benefit and
>>>> also claim that it has a negligible backwards compatibility impact.
>>>
>>>
>>>
>>> IMHO nobody wrote that there is a significant improvement in direction of
>>> better compatibility. Of course it's just a step of 1 per mill.
>>>
>>> Some facts from the issue itself:
>>>
>>> - open since 2010-09-09
>>> - only 2 votes (from author of comment #2)
>>> - only 4 mail addresses on CC (all from apache)
>>> - only 3 comments (before our discussion started)
>>>
>>>  From my point of view this issue is of very low interest for others -
>>> compared with other issues.
>>>
>>> But as nobody has delievered a valid use case, we're talking about a
>>> theoretically possibility of broken spreadsheets and therefore spent
>>> already
>>> too much of our time for this discussion.
>>>
>>
>> Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
>> right now that would be break if we changed the behavior of 0^0.
>
>
> And what is your *serious* use case for this spreadsheet? Beside to use it
> as a test document? And you have it created before the discussion has
> started?
>

The spreadsheet I am thinking about is over 4 years old, has been
published and is used by others as well.

I'd also point out that asking your question on this list is not
really telling you anything.  We've had 37 million downloads of AOO
3.4.  Only 400 people subscribe to this list.  So I don't think this
is great evidence for saying it has zero impact.

But again, if you think that situation never comes up in real use,
then let's not make the change, since it would have no benefit.

-Rob

> I'll ask my question again:
> Is there more than one who can deliever a *serious and valid use case*?
>
> Thanks
>
> Marcus
>
>
>
>
>>> I propose to keep the change as it is now.
>>>
>>> My 2 ct.
>>>
>>> Marcus
>>>
>>>
>>>
>>>
>>>
>>>>> Has the patch been vetoed, and if so on what basis?
>>>>>
>>>>> Pedro.
>>>>>
>>>>>
>>>>>
>>>>>> ________________________________
>>>>>> Da: Dennis E. Hamilton<de...@acm.org>
>>>>>> A: dev@openoffice.apache.org
>>>>>> Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro
>>>>>> Giffuni'<pf...@apache.org>
>>>>>> Inviato: Martedì 12 Febbraio 2013 13:11
>>>>>> Oggetto: RE: Calc behavior: result of 0 ^ 0
>>>>>>
>>>>>> RESOLUTION OF THE PROPOSAL
>>>>>>
>>>>>> The proposed change was made under CTR (Commit then Review). There has
>>>>>> been
>>>>>> a subsequent review and, as Don points out, the discussion has been
>>>>>> lengthy
>>>>>> and vocal.
>>>>>>
>>>>>> The objective is to achieve consensus.  I believe it is clear that
>>>>>> there
>>>>>> is
>>>>>> no consensus on the proposed change and the proposal fails.
>>>>>>
>>>>>> I can't speak for the AOO PMC.  It would be useful if Andreas helped
>>>>>> wrap
>>>>>> this up.  If the lack of consensus is affirmed, Pedro can revert the
>>>>>> change
>>>>>> and adjust the Bugzilla issue.
>>>>>>
>>>>>> THE ESSENCE OF THE PROPOSAL
>>>>>>
>>>>>> The proposal is to enact the breaking change as described on
>>>>>> the Community Wiki at
>>>>>>
>>>>>>
>>>>>> <https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
>>>>>> .
>>>>>>
>>>>>> It is under Changes that Impact Backward Compatibility, Calc and
>>>>>> OpenFormula
>>>>>> Support.
>>>>>>
>>>>>> "Exponentiation
>>>>>>
>>>>>> "The current version of Calc produces 1 for POWER(0,0).  This is one
>>>>>> of
>>>>>> the
>>>>>> implementation-defined results that is permitted by ODF 1.2
>>>>>> OpenFormula.
>>>>>>
>>>>>> "It is proposed to change POWER(0,0) to result in #VALUE!.  This is
>>>>>> also
>>>>>> permitted as the implementation-defined result.  This is also
>>>>>> compatible
>>>>>> with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>>>>>> Spreadsheets. ..."
>>>>>>
>>>>>> OUTCOME
>>>>>>
>>>>>> The proposed change is tracked in Bugzilla Issue #114430,
>>>>>> <   https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>>>>>>
>>>>>> A patch to implement this proposal is already included in the SVN.
>>>>>> If the proposal is not accepted as the result of CTR review, the
>>>>>> Issue will be closed and the patch reverted.
>>>>>>
>>>>>> - Dennis
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Donald Whytock [mailto:dwhytock@gmail.com]
>>>>>> Sent: Tuesday, February 12, 2013 09:20
>>>>>> To: dev@openoffice.apache.org
>>>>>> Subject: Re: Calc behavior: result of 0 ^ 0
>>>>>>
>>>>>> ...So I got curious, and I paged back in my email archive, and it
>>>>>> seems this is the biggest AOO dev thread since the graduation vote
>>>>>> back in early September.
>>>>>>
>>>>>> At this point, does anyone care enough about changing the status quo
>>>>>> as to put up a coherent proposal to be voted on?
>>>>>>
>>>>>> Don

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

On 02/12/2013 05:07 PM, Marcus (OOo) wrote:
> Am 02/12/2013 10:39 PM, schrieb Rob Weir:
>> Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
>> right now that would be break if we changed the behavior of 0^0.
>
> And what is your *serious* use case for this spreadsheet? Beside to 
> use it as a test document? And you have it created before the 
> discussion has started?
>
> I'll ask my question again:
> Is there more than one who can deliever a *serious and valid use case*?

I assume that the valid use case is that existing spreadsheets start 
returning different values than they do with the current release.

It is always annoying when you have existing things that stop working 
when there is a new release. Admittedly, it may fail on any other 
program since the behavior is not well defined by the standard in this 
case.

AOO is ODF compliant regardless, because the standard allows for the 
different values.

On the other hand, if a sheet is designed to function with an error 
value returned for 0^0, I expect that it will then work the same on all 
implementations. Yeah, I prefer that we break the existing sheets, but I 
feel bad about it.

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

["Marcus (OOo)" <ma...@wtnet.de>]

Am 02/12/2013 10:39 PM, schrieb Rob Weir:
> On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)<ma...@wtnet.de>  wrote:
>> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>>
>>> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni<pf...@apache.org>   wrote:
>>>>
>>>> Hello;
>>>>
>>>> I don't understand,
>>>>
>>>> I saw a bug (erroneous result returned by a function) and I fixed
>>>> it respecting the standards, thereby enhancing interperability
>>>> with the market leader.
>>>>
>>>> I am aware that Rob has a different point of view here but so
>>>
>>>
>>> By my count, those who expressed concern about your patch are;
>>>
>>> - Me
>>> - Regina
>>> - Andre
>>> - Stuart
>>> - Günter
>>>
>>> I think this is a non-trivial amount opposition, including from some
>>> whose opinions you might respect more than mine.
>>>
>>>> far neither him nor Stephen Hawking has explained how the change
>>>> would be incorrect and no example where someone has been affected
>>>> by this change has been provided.
>>>>
>>>
>>> You can't have it both ways. Your claimed benefit is intrinsically
>>> tied to breaking compatibility with earlier versions of OpenOffice.
>>> You cannot both claim that it has a significant interop benefit and
>>> also claim that it has a negligible backwards compatibility impact.
>>
>>
>> IMHO nobody wrote that there is a significant improvement in direction of
>> better compatibility. Of course it's just a step of 1 per mill.
>>
>> Some facts from the issue itself:
>>
>> - open since 2010-09-09
>> - only 2 votes (from author of comment #2)
>> - only 4 mail addresses on CC (all from apache)
>> - only 3 comments (before our discussion started)
>>
>>  From my point of view this issue is of very low interest for others -
>> compared with other issues.
>>
>> But as nobody has delievered a valid use case, we're talking about a
>> theoretically possibility of broken spreadsheets and therefore spent already
>> too much of our time for this discussion.
>>
>
> Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
> right now that would be break if we changed the behavior of 0^0.

And what is your *serious* use case for this spreadsheet? Beside to use 
it as a test document? And you have it created before the discussion has 
started?

I'll ask my question again:
Is there more than one who can deliever a *serious and valid use case*?

Thanks

Marcus



>> I propose to keep the change as it is now.
>>
>> My 2 ct.
>>
>> Marcus
>>
>>
>>
>>
>>
>>>> Has the patch been vetoed, and if so on what basis?
>>>>
>>>> Pedro.
>>>>
>>>>
>>>>
>>>>> ________________________________
>>>>> Da: Dennis E. Hamilton<de...@acm.org>
>>>>> A: dev@openoffice.apache.org
>>>>> Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro
>>>>> Giffuni'<pf...@apache.org>
>>>>> Inviato: Martedì 12 Febbraio 2013 13:11
>>>>> Oggetto: RE: Calc behavior: result of 0 ^ 0
>>>>>
>>>>> RESOLUTION OF THE PROPOSAL
>>>>>
>>>>> The proposed change was made under CTR (Commit then Review). There has
>>>>> been
>>>>> a subsequent review and, as Don points out, the discussion has been
>>>>> lengthy
>>>>> and vocal.
>>>>>
>>>>> The objective is to achieve consensus.  I believe it is clear that there
>>>>> is
>>>>> no consensus on the proposed change and the proposal fails.
>>>>>
>>>>> I can't speak for the AOO PMC.  It would be useful if Andreas helped
>>>>> wrap
>>>>> this up.  If the lack of consensus is affirmed, Pedro can revert the
>>>>> change
>>>>> and adjust the Bugzilla issue.
>>>>>
>>>>> THE ESSENCE OF THE PROPOSAL
>>>>>
>>>>> The proposal is to enact the breaking change as described on
>>>>> the Community Wiki at
>>>>>
>>>>> <https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
>>>>> .
>>>>>
>>>>> It is under Changes that Impact Backward Compatibility, Calc and
>>>>> OpenFormula
>>>>> Support.
>>>>>
>>>>> "Exponentiation
>>>>>
>>>>> "The current version of Calc produces 1 for POWER(0,0).  This is one of
>>>>> the
>>>>> implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>>>>>
>>>>> "It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>>>>> permitted as the implementation-defined result.  This is also compatible
>>>>> with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>>>>> Spreadsheets. ..."
>>>>>
>>>>> OUTCOME
>>>>>
>>>>> The proposed change is tracked in Bugzilla Issue #114430,
>>>>> <   https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>>>>>
>>>>> A patch to implement this proposal is already included in the SVN.
>>>>> If the proposal is not accepted as the result of CTR review, the
>>>>> Issue will be closed and the patch reverted.
>>>>>
>>>>> - Dennis
>>>>>
>>>>> -----Original Message-----
>>>>> From: Donald Whytock [mailto:dwhytock@gmail.com]
>>>>> Sent: Tuesday, February 12, 2013 09:20
>>>>> To: dev@openoffice.apache.org
>>>>> Subject: Re: Calc behavior: result of 0 ^ 0
>>>>>
>>>>> ...So I got curious, and I paged back in my email archive, and it
>>>>> seems this is the biggest AOO dev thread since the graduation vote
>>>>> back in early September.
>>>>>
>>>>> At this point, does anyone care enough about changing the status quo
>>>>> as to put up a coherent proposal to be voted on?
>>>>>
>>>>> Don

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>
>> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni<pf...@apache.org>  wrote:
>>>
>>> Hello;
>>>
>>> I don't understand,
>>>
>>> I saw a bug (erroneous result returned by a function) and I fixed
>>> it respecting the standards, thereby enhancing interperability
>>> with the market leader.
>>>
>>> I am aware that Rob has a different point of view here but so
>>
>>
>> By my count, those who expressed concern about your patch are;
>>
>> - Me
>> - Regina
>> - Andre
>> - Stuart
>> - Günter
>>
>> I think this is a non-trivial amount opposition, including from some
>> whose opinions you might respect more than mine.
>>
>>> far neither him nor Stephen Hawking has explained how the change
>>> would be incorrect and no example where someone has been affected
>>> by this change has been provided.
>>>
>>
>> You can't have it both ways. Your claimed benefit is intrinsically
>> tied to breaking compatibility with earlier versions of OpenOffice.
>> You cannot both claim that it has a significant interop benefit and
>> also claim that it has a negligible backwards compatibility impact.
>
>
> IMHO nobody wrote that there is a significant improvement in direction of
> better compatibility. Of course it's just a step of 1 per mill.
>
> Some facts from the issue itself:
>
> - open since 2010-09-09
> - only 2 votes (from author of comment #2)
> - only 4 mail addresses on CC (all from apache)
> - only 3 comments (before our discussion started)
>
> From my point of view this issue is of very low interest for others -
> compared with other issues.
>
> But as nobody has delievered a valid use case, we're talking about a
> theoretically possibility of broken spreadsheets and therefore spent already
> too much of our time for this discussion.
>

Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
right now that would be break if we changed the behavior of 0^0.

Regards,

-Rob

> I propose to keep the change as it is now.
>
> My 2 ct.
>
> Marcus
>
>
>
>
>
>>> Has the patch been vetoed, and if so on what basis?
>>>
>>> Pedro.
>>>
>>>
>>>
>>>> ________________________________
>>>> Da: Dennis E. Hamilton<de...@acm.org>
>>>> A: dev@openoffice.apache.org
>>>> Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro
>>>> Giffuni'<pf...@apache.org>
>>>> Inviato: Martedì 12 Febbraio 2013 13:11
>>>> Oggetto: RE: Calc behavior: result of 0 ^ 0
>>>>
>>>> RESOLUTION OF THE PROPOSAL
>>>>
>>>> The proposed change was made under CTR (Commit then Review). There has
>>>> been
>>>> a subsequent review and, as Don points out, the discussion has been
>>>> lengthy
>>>> and vocal.
>>>>
>>>> The objective is to achieve consensus.  I believe it is clear that there
>>>> is
>>>> no consensus on the proposed change and the proposal fails.
>>>>
>>>> I can't speak for the AOO PMC.  It would be useful if Andreas helped
>>>> wrap
>>>> this up.  If the lack of consensus is affirmed, Pedro can revert the
>>>> change
>>>> and adjust the Bugzilla issue.
>>>>
>>>> THE ESSENCE OF THE PROPOSAL
>>>>
>>>> The proposal is to enact the breaking change as described on
>>>> the Community Wiki at
>>>>
>>>> <https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
>>>> .
>>>>
>>>> It is under Changes that Impact Backward Compatibility, Calc and
>>>> OpenFormula
>>>> Support.
>>>>
>>>> "Exponentiation
>>>>
>>>> "The current version of Calc produces 1 for POWER(0,0).  This is one of
>>>> the
>>>> implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>>>>
>>>> "It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>>>> permitted as the implementation-defined result.  This is also compatible
>>>> with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>>>> Spreadsheets. ..."
>>>>
>>>> OUTCOME
>>>>
>>>> The proposed change is tracked in Bugzilla Issue #114430,
>>>> <  https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>>>>
>>>> A patch to implement this proposal is already included in the SVN.
>>>> If the proposal is not accepted as the result of CTR review, the
>>>> Issue will be closed and the patch reverted.
>>>>
>>>> - Dennis
>>>>
>>>> -----Original Message-----
>>>> From: Donald Whytock [mailto:dwhytock@gmail.com]
>>>> Sent: Tuesday, February 12, 2013 09:20
>>>> To: dev@openoffice.apache.org
>>>> Subject: Re: Calc behavior: result of 0 ^ 0
>>>>
>>>> ...So I got curious, and I paged back in my email archive, and it
>>>> seems this is the biggest AOO dev thread since the graduation vote
>>>> back in early September.
>>>>
>>>> At this point, does anyone care enough about changing the status quo
>>>> as to put up a coherent proposal to be voted on?
>>>>
>>>> Don

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 12/02/2013 22:31, Marcus (OOo) a écrit :
> Some facts from the issue itself:
>
> - open since 2010-09-09
> - only 2 votes (from author of comment #2)

Now 4 with mines.

Hagar

Re: Calc behavior: result of 0 ^ 0

["Marcus (OOo)" <ma...@wtnet.de>]

Am 02/12/2013 08:46 PM, schrieb Rob Weir:
> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni<pf...@apache.org>  wrote:
>> Hello;
>>
>> I don't understand,
>>
>> I saw a bug (erroneous result returned by a function) and I fixed
>> it respecting the standards, thereby enhancing interperability
>> with the market leader.
>>
>> I am aware that Rob has a different point of view here but so
>
> By my count, those who expressed concern about your patch are;
>
> - Me
> - Regina
> - Andre
> - Stuart
> - Günter
>
> I think this is a non-trivial amount opposition, including from some
> whose opinions you might respect more than mine.
>
>> far neither him nor Stephen Hawking has explained how the change
>> would be incorrect and no example where someone has been affected
>> by this change has been provided.
>>
>
> You can't have it both ways. Your claimed benefit is intrinsically
> tied to breaking compatibility with earlier versions of OpenOffice.
> You cannot both claim that it has a significant interop benefit and
> also claim that it has a negligible backwards compatibility impact.

IMHO nobody wrote that there is a significant improvement in direction 
of better compatibility. Of course it's just a step of 1 per mill.

Some facts from the issue itself:

- open since 2010-09-09
- only 2 votes (from author of comment #2)
- only 4 mail addresses on CC (all from apache)
- only 3 comments (before our discussion started)

 From my point of view this issue is of very low interest for others - 
compared with other issues.

But as nobody has delievered a valid use case, we're talking about a 
theoretically possibility of broken spreadsheets and therefore spent 
already too much of our time for this discussion.

I propose to keep the change as it is now.

My 2 ct.

Marcus




>> Has the patch been vetoed, and if so on what basis?
>>
>> Pedro.
>>
>>
>>
>>> ________________________________
>>> Da: Dennis E. Hamilton<de...@acm.org>
>>> A: dev@openoffice.apache.org
>>> Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro Giffuni'<pf...@apache.org>
>>> Inviato: Martedì 12 Febbraio 2013 13:11
>>> Oggetto: RE: Calc behavior: result of 0 ^ 0
>>>
>>> RESOLUTION OF THE PROPOSAL
>>>
>>> The proposed change was made under CTR (Commit then Review). There has been
>>> a subsequent review and, as Don points out, the discussion has been lengthy
>>> and vocal.
>>>
>>> The objective is to achieve consensus.  I believe it is clear that there is
>>> no consensus on the proposed change and the proposal fails.
>>>
>>> I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
>>> this up.  If the lack of consensus is affirmed, Pedro can revert the change
>>> and adjust the Bugzilla issue.
>>>
>>> THE ESSENCE OF THE PROPOSAL
>>>
>>> The proposal is to enact the breaking change as described on
>>> the Community Wiki at
>>> <https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
>>> .
>>>
>>> It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
>>> Support.
>>>
>>> "Exponentiation
>>>
>>> "The current version of Calc produces 1 for POWER(0,0).  This is one of the
>>> implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>>>
>>> "It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>>> permitted as the implementation-defined result.  This is also compatible
>>> with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>>> Spreadsheets. ..."
>>>
>>> OUTCOME
>>>
>>> The proposed change is tracked in Bugzilla Issue #114430,
>>> <  https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>>>
>>> A patch to implement this proposal is already included in the SVN.
>>> If the proposal is not accepted as the result of CTR review, the
>>> Issue will be closed and the patch reverted.
>>>
>>> - Dennis
>>>
>>> -----Original Message-----
>>> From: Donald Whytock [mailto:dwhytock@gmail.com]
>>> Sent: Tuesday, February 12, 2013 09:20
>>> To: dev@openoffice.apache.org
>>> Subject: Re: Calc behavior: result of 0 ^ 0
>>>
>>> ...So I got curious, and I paged back in my email archive, and it
>>> seems this is the biggest AOO dev thread since the graduation vote
>>> back in early September.
>>>
>>> At this point, does anyone care enough about changing the status quo
>>> as to put up a coherent proposal to be voted on?
>>>
>>> Don

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hello;
>
> I don't understand,
>
> I saw a bug (erroneous result returned by a function) and I fixed
> it respecting the standards, thereby enhancing interperability
> with the market leader.
>
> I am aware that Rob has a different point of view here but so

By my count, those who expressed concern about your patch are;

- Me
- Regina
- Andre
- Stuart
- Günter

I think this is a non-trivial amount opposition, including from some
whose opinions you might respect more than mine.

> far neither him nor Stephen Hawking has explained how the change
> would be incorrect and no example where someone has been affected
> by this change has been provided.
>

You can't have it both ways. Your claimed benefit is intrinsically
tied to breaking compatibility with earlier versions of OpenOffice.
You cannot both claim that it has a significant interop benefit and
also claim that it has a negligible backwards compatibility impact.

Regards,

-Rob



> Has the patch been vetoed, and if so on what basis?
>
> Pedro.
>
>
>
>>________________________________
>> Da: Dennis E. Hamilton <de...@acm.org>
>>A: dev@openoffice.apache.org
>>Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro Giffuni' <pf...@apache.org>
>>Inviato: Martedì 12 Febbraio 2013 13:11
>>Oggetto: RE: Calc behavior: result of 0 ^ 0
>>
>>RESOLUTION OF THE PROPOSAL
>>
>>The proposed change was made under CTR (Commit then Review). There has been
>>a subsequent review and, as Don points out, the discussion has been lengthy
>>and vocal.
>>
>>The objective is to achieve consensus.  I believe it is clear that there is
>>no consensus on the proposed change and the proposal fails.
>>
>>I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
>>this up.  If the lack of consensus is affirmed, Pedro can revert the change
>>and adjust the Bugzilla issue.
>>
>>THE ESSENCE OF THE PROPOSAL
>>
>>The proposal is to enact the breaking change as described on
>>the Community Wiki at
>><https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
>>.
>>
>>It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
>>Support.
>>
>>"Exponentiation
>>
>>"The current version of Calc produces 1 for POWER(0,0).  This is one of the
>>implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>>
>>"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>>permitted as the implementation-defined result.  This is also compatible
>>with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>>Spreadsheets. ..."
>>
>>OUTCOME
>>
>>The proposed change is tracked in Bugzilla Issue #114430,
>>< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>>
>>A patch to implement this proposal is already included in the SVN.
>>If the proposal is not accepted as the result of CTR review, the
>>Issue will be closed and the patch reverted.
>>
>>- Dennis
>>
>>-----Original Message-----
>>From: Donald Whytock [mailto:dwhytock@gmail.com]
>>Sent: Tuesday, February 12, 2013 09:20
>>To: dev@openoffice.apache.org
>>Subject: Re: Calc behavior: result of 0 ^ 0
>>
>>...So I got curious, and I paged back in my email archive, and it
>>seems this is the biggest AOO dev thread since the graduation vote
>>back in early September.
>>
>>At this point, does anyone care enough about changing the status quo
>>as to put up a coherent proposal to be voted on?
>>
>>Don
>>
>>
>>
>>

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <or...@apache.org>]

The current behavior is in compliance with the ODF 1.2 OpenFormula
specification.  In that context, the current result for POWER(0,0) is not a
bug.

The fact that 0^0 is not defined (nor are 0^-n values) in mathematics
(although some define them for various conveniences) does not mean it can't
be defined in a computational procedure, which is what POWER(x,y) specifies
characteristics of.  The discrepancy with respect to mathematics is
troublesome, but only if the computational procedure's definition is relied
upon as a mathematical fact (e.g., in proving theorems, such as 0/0 = 1).

I prefer Pedro's solution, which is to produce an error value for POWER(0,0)
and also have greater interoperability with another important
implementation.  That is also in compliance with the ODF 1.2 OpenFormula
specification.  It also prevents the inference of unsupportable mathematical
facts by computational definition.

There is clearly no consensus to making that change.  This is what CTR is
about.  It would have been what RTC were about, had the proposal been made
before the patch.  This thread is the R part either way.

I don't recommend having a ballot on the proposed change, and I don't know
what (non-binding) vote I would cast were one held.  

 - Dennis

-----Original Message-----
From: Pedro Giffuni [mailto:pfg@apache.org] 
Sent: Tuesday, February 12, 2013 11:12
To: dennis.hamilton@acm.org; dev@openoffice.apache.org
Cc: dwhytock@gmail.com; pescetti@apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

Hello;

I don't understand,

I saw a bug (erroneous result returned by a function) and I fixed
it respecting the standards, thereby enhancing interperability
with the market leader.

I am aware that Rob has a different point of view here but so
far neither him nor Stephen Hawking has explained how the change
would be incorrect and no example where someone has been affected
by this change has been provided.

Has the patch been vetoed, and if so on what basis?

Pedro.



>________________________________
> Da: Dennis E. Hamilton <de...@acm.org>
>A: dev@openoffice.apache.org 
>Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro Giffuni'
<pf...@apache.org> 
>Inviato: Martedì 12 Febbraio 2013 13:11
>Oggetto: RE: Calc behavior: result of 0 ^ 0
> 
>RESOLUTION OF THE PROPOSAL
>
>The proposed change was made under CTR (Commit then Review). There has been
>a subsequent review and, as Don points out, the discussion has been lengthy
>and vocal. 
>
>The objective is to achieve consensus.  I believe it is clear that there is
>no consensus on the proposed change and the proposal fails.
>
>I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
>this up.  If the lack of consensus is affirmed, Pedro can revert the change
>and adjust the Bugzilla issue.
>
>THE ESSENCE OF THE PROPOSAL
>
>The proposal is to enact the breaking change as described on 
>the Community Wiki at 
><https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
>
>.
>
>It is under Changes that Impact Backward Compatibility, Calc and
OpenFormula
>Support.
>
>"Exponentiation
>
>"The current version of Calc produces 1 for POWER(0,0).  This is one of the

>implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>
>"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>permitted as the implementation-defined result.  This is also compatible
>with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>Spreadsheets. ..."
>
>OUTCOME
>
>The proposed change is tracked in Bugzilla Issue #114430,
>< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>
>A patch to implement this proposal is already included in the SVN.  
>If the proposal is not accepted as the result of CTR review, the 
>Issue will be closed and the patch reverted.
>
>- Dennis
>
>-----Original Message-----
>From: Donald Whytock [mailto:dwhytock@gmail.com] 
>Sent: Tuesday, February 12, 2013 09:20
>To: dev@openoffice.apache.org
>Subject: Re: Calc behavior: result of 0 ^ 0
>
>...So I got curious, and I paged back in my email archive, and it
>seems this is the biggest AOO dev thread since the graduation vote
>back in early September.
>
>At this point, does anyone care enough about changing the status quo
>as to put up a coherent proposal to be voted on?
>
>Don
>
>
>
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Hello;

I don't understand,

I saw a bug (erroneous result returned by a function) and I fixed
it respecting the standards, thereby enhancing interperability
with the market leader.

I am aware that Rob has a different point of view here but so
far neither him nor Stephen Hawking has explained how the change
would be incorrect and no example where someone has been affected
by this change has been provided.

Has the patch been vetoed, and if so on what basis?

Pedro.



>________________________________
> Da: Dennis E. Hamilton <de...@acm.org>
>A: dev@openoffice.apache.org 
>Cc: dwhytock@gmail.com; pescetti@apache.org; 'Pedro Giffuni' <pf...@apache.org> 
>Inviato: Martedì 12 Febbraio 2013 13:11
>Oggetto: RE: Calc behavior: result of 0 ^ 0
> 
>RESOLUTION OF THE PROPOSAL
>
>The proposed change was made under CTR (Commit then Review). There has been
>a subsequent review and, as Don points out, the discussion has been lengthy
>and vocal. 
>
>The objective is to achieve consensus.  I believe it is clear that there is
>no consensus on the proposed change and the proposal fails.
>
>I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
>this up.  If the lack of consensus is affirmed, Pedro can revert the change
>and adjust the Bugzilla issue.
>
>THE ESSENCE OF THE PROPOSAL
>
>The proposal is to enact the breaking change as described on 
>the Community Wiki at 
><https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
>.
>
>It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
>Support.
>
>"Exponentiation
>
>"The current version of Calc produces 1 for POWER(0,0).  This is one of the 
>implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>
>"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>permitted as the implementation-defined result.  This is also compatible
>with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>Spreadsheets. ..."
>
>OUTCOME
>
>The proposed change is tracked in Bugzilla Issue #114430,
>< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>
>A patch to implement this proposal is already included in the SVN.  
>If the proposal is not accepted as the result of CTR review, the 
>Issue will be closed and the patch reverted.
>
>- Dennis
>
>-----Original Message-----
>From: Donald Whytock [mailto:dwhytock@gmail.com] 
>Sent: Tuesday, February 12, 2013 09:20
>To: dev@openoffice.apache.org
>Subject: Re: Calc behavior: result of 0 ^ 0
>
>...So I got curious, and I paged back in my email archive, and it
>seems this is the biggest AOO dev thread since the graduation vote
>back in early September.
>
>At this point, does anyone care enough about changing the status quo
>as to put up a coherent proposal to be voted on?
>
>Don
>
>
>
>

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Tue, Feb 12, 2013 at 4:17 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Ugh..
>
> I haven't been following this thread at all ...
>

I recommend reading the archives then, since every argument that could
be made, has been made already.

-Rob

> I unsubscribed from the -dev list because I always ended up in absurd discussions
> and there was not much technical content either.
>
> I suspected it would be bikeshed.org material but in any case let me make things clear.
>
> - 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 is 1,
> however when you consider the limit when x tends to -0, the limit is infinite. This
> is called Indeterminate Form.
>     http://en.wikipedia.org/wiki/Indeterminate_form
>
>
> If you wonder, I failed a math quiz in the University for blindly using the value my
> HP Calculator gave (1), so I am sort of glad that this has been a free educational
> experience for some of you.
>
> The implementation in OOo doesn't return explicitly a 1 value but instead relies on
> what the libc pow() function does. The standard libc lets you do 0^0 but it also lets
> you divide by zero without aborting . Modern IEEE 754 2008 implements three
> power functions pow(), pown() and powr(), powr() being the most similar to the real
> mathematical function.
>
> The implementation is non intrusive: I added a wrapper in SAL that behaves like
> powr() so that we don't affect other formulas that use pow() internally. So far
> no one has given an example where shooting yourself in the foot by expecting
> pow(0,0) to be 1 is a good thing.
>
> I am gladly surprised that Excel does the same, but the real reason why I went
> ahead and implemented a solution is to do the right thing, mathematically
> speaking. Mathematical correctness is not something that IMHO pertains to
> democracy.
>
> Sure it would be nice to have an option to adjust your results for
> mathematically undetermined cases like 0^0 or 0/0 but unless you are planning
> to implement it don't expected such features to appear magically either.
>
> I would be extremely disappointed to have to revert a correct fix for non-technical
> reasons. I think I would lose any motivation to improve other functions in Calc.
>
> Pedro.

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Ugh..

I haven't been following this thread at all ...

I unsubscribed from the -dev list because I always ended up in absurd discussions
and there was not much technical content either.

I suspected it would be bikeshed.org material but in any case let me make things clear.

- 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 is 1,
however when you consider the limit when x tends to -0, the limit is infinite. This
is called Indeterminate Form.
    http://en.wikipedia.org/wiki/Indeterminate_form


If you wonder, I failed a math quiz in the University for blindly using the value my
HP Calculator gave (1), so I am sort of glad that this has been a free educational
experience for some of you.

The implementation in OOo doesn't return explicitly a 1 value but instead relies on
what the libc pow() function does. The standard libc lets you do 0^0 but it also lets
you divide by zero without aborting . Modern IEEE 754 2008 implements three
power functions pow(), pown() and powr(), powr() being the most similar to the real
mathematical function.

The implementation is non intrusive: I added a wrapper in SAL that behaves like
powr() so that we don't affect other formulas that use pow() internally. So far
no one has given an example where shooting yourself in the foot by expecting
pow(0,0) to be 1 is a good thing.

I am gladly surprised that Excel does the same, but the real reason why I went
ahead and implemented a solution is to do the right thing, mathematically
speaking. Mathematical correctness is not something that IMHO pertains to
democracy.

Sure it would be nice to have an option to adjust your results for
mathematically undetermined cases like 0^0 or 0/0 but unless you are planning
to implement it don't expected such features to appear magically either.

I would be extremely disappointed to have to revert a correct fix for non-technical
reasons. I think I would lose any motivation to improve other functions in Calc.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

My preference is to leave the patch and return #Value

On 02/12/2013 01:11 PM, Dennis E. Hamilton wrote:
> RESOLUTION OF THE PROPOSAL
>
> The proposed change was made under CTR (Commit then Review). There has been
> a subsequent review and, as Don points out, the discussion has been lengthy
> and vocal.
>
> The objective is to achieve consensus.  I believe it is clear that there is
> no consensus on the proposed change and the proposal fails.
>
> I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
> this up.  If the lack of consensus is affirmed, Pedro can revert the change
> and adjust the Bugzilla issue.
>
> THE ESSENCE OF THE PROPOSAL
>
> The proposal is to enact the breaking change as described on
> the Community Wiki at
> <https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
> .
>
> It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
> Support.
>
> "Exponentiation
>
> "The current version of Calc produces 1 for POWER(0,0).  This is one of the
> implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>
> "It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
> permitted as the implementation-defined result.  This is also compatible
> with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
> Spreadsheets. ..."
>
> OUTCOME
>
> The proposed change is tracked in Bugzilla Issue #114430,
> < https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>
> A patch to implement this proposal is already included in the SVN.
> If the proposal is not accepted as the result of CTR review, the
> Issue will be closed and the patch reverted.
>   
>   - Dennis
>
> -----Original Message-----
> From: Donald Whytock [mailto:dwhytock@gmail.com]
> Sent: Tuesday, February 12, 2013 09:20
> To: dev@openoffice.apache.org
> Subject: Re: Calc behavior: result of 0 ^ 0
>
> ...So I got curious, and I paged back in my email archive, and it
> seems this is the biggest AOO dev thread since the graduation vote
> back in early September.
>
> At this point, does anyone care enough about changing the status quo
> as to put up a coherent proposal to be voted on?
>
> Don
>

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Guenter Marxen <gu...@googlemail.com>]

Hi,

I reply to this mail, because I have some remarks to Andrea's statements 
(see below). But please excuse, if I (as german) perhaps use not always 
the right english words/expressions/definitions.)

But first:

Norbert Thibaud has cleared the mathematical questions and shown, that 
statements like Petros "0^0 = 1 is NOT mathematically correct." are 
meaningless.

0^0 is a "shortcut" or "symbol" for something meaningfull in special 
cases or models.

Mathematic is a set of theories that has (at least) 2 great sectors: 
Theoretical/pure mathematics and applied mathematics which are different 
in methodology.

"Pure" models or theories are based on axioms and definitions. Axioms 
must be "complete" and not "contradictory" but are otherwise "free". 
Definitions have to be reasonable (and helpfull). Statements/proofs (if 
derived correctly out of the axioms) are "true" only in the respective 
model. In other models they make no sense.

As the definition of 0^0 = 1 is _not_ wrong and not unreasonable (false 
is a wrong category in this case), for me the problems reduces to:

Are there more (and "heavier") advantages than disadvantages when 
changing the behaviour in Calc?

The whole line of OOo-versions (I have tested also with StarOffice 7 and 
8, if necessary I can also test with V5.2 but I think it's not worth the 
time to install etc.) defines 0^0=1. So generations of Calc-Spreadsheets 
rely on this even if only a very few may explicitly use this features.

On the other side only one advantage was cited: The compatibilty with 
Excel. For me, the backward-compatibility is worth more. (See also my 
comment to 5) below.)

Am 13.02.2013 01:00, schrieb Andrea Pescetti:
> Dennis E. Hamilton wrote:
>> The objective is to achieve consensus.  I believe it is clear that
>> there is
>> no consensus on the proposed change and the proposal fails.
>
> I still have to see some credible arguments here, since most of the
> feedback was misplaced. What we learned so far is:
>
> 1) Nobody so far exhibited a spreadsheet that would be broken by the new
> behavior. Rob has one, which was even published, so I'm sure he can

and Norbert has given another Example where the old definition allows to 
model the correct mathematical behaviour for x^y. And you forget the 
many generations of older spreadsheets.

> share it for everybody to have a look. Even better, we have a fantastic
> collection of Calc templates at
> http://templates.openoffice.org/en/taxonomy/term/3923 ; seeing one of
> those templates break would help.
>
> 2) Everybody feels the need to say something about 0 ^ 0, but threads
> like this one are not pleasant to read. If you have nothing to say,
> please don't say anything. And if you have a lot to say, please limit
> yourself to what's strictly needed. Especially, undoing a volunteer's
> work without some concrete (in ODF format, in this case!) reasons is
> something the project must avoid.

Generally I agree with "must avoid". But I did not see a discussion, if 
this change shouldt be done.

> 3) Mathematics and the standards are two different worlds. If a standard
> is mathematically wrong, change the standard and come back.

That is false: The standard is mathematically correct.

> 4) We implement a standard, ODF. There 0 ^ 0 can legitimately be
> evaluated to 0, 1 or an error.
>
> 5) We read another standard, OOXML. There 0 ^ 0 can only be evaluated as
> an error; the fact that OpenOffice will evaluate 0 ^ 0 from a XLSX file
> to 1 is a bug.

This is false: It is no bug!
If Excel were the standard it would be true. And if, then calc must also 
implement the leap-year bug. (And I think nobody would want to implement 
such an error.)

But true is, that Calc now is not Excel-compatibel in this case which 
leads to the core-question "backwards-comp. vs. Excel comp.".

> 6) Anyone whose spreadsheets depend on 0 ^ 0 being evaluated to 1 (or to
> zero, or to an error for that matter) has entered the dangerous world of
> "implementation-defined" behavior: even if you save in a standard format

I'm a little bit confused. Everthing in applications is 
"implementation-defined" what else?

> like ODF, your spreadsheet depends on a particular ODF implementation
> (e.g., on the specific version of OpenOffice you used).

Also the change would be "implementation-defined" and the behaviour 
would shurely depend on the OOo-Version used.

> Based on 5 and 6 I would actually still believe that it's good to
> evaluate 0 ^ 0 to error (so that we fix the bug in 5 and we choose the
> most strict behavior in 6). But I fully agree with Marcus in saying this
> issue is much smaller than the discussion around it, so I can surely
> change my opinion if I finally see some real-world spreadsheets impacted
> by the change. When we have those, also Pedro will likely see reasons
> for reverting the change. In short: provide concrete examples and
> everybody will be happy.

Making controverse changes against many good reasons if not somebody 
else proves that it is negative, is no good collaboration.

I understand, that Pedro will be frustrated, if his patch is reverted, 
especially if it was much work. But perhaps he can understand, that his 
math-argument was not valid and that other reasons speak for backw.-comp.

And perhaps in the future it would be better to discuss incompatibility 
issues before anybody begins to code.

>
> Regards,
>    Andrea.

-- 
Grüße

Günter Marxen

Re: Calc behavior: result of 0 ^ 0

[Andre Fischer <aw...@gmail.com>]

On 13.02.2013 08:28, Norbert Thiebaud wrote:
> On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>>> (OK, I guess it's better to re-subscribe to the list).
>>>
>>> In reply to Norbert Thiebaud*:
>>>
>>> In the Power rule, which *is* commonly used for differentiation, we take a series
>>> of polinomials where n !=0. n is not only different than zero, most importantly,
>>> it is a constant.
[...]
>
> For those interested in the actual Math... in Math words have meaning
> and that meaning have often context. let me develop a bit the notion
> of 'form' mentioned earlier:
> for instance in the expression 'in an indeterminate form', there is
> 'form' and it matter because in the context of determining extension
> by continuity of a function, there are certain case where you can
> transform you equation into another 'form' but if these transformation
> lead you to an 'indeterminate form', you have to find another
> transformation to continue...
> hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
> is establish that h actually converge in the operating set, and that
> is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
> passing 'to the limit' in each term would yield 0^0 with is a
> indeterminable 'form' (not a value, not a number, not claimed to be
> the result of a calculation of power(0,0), but a 'form' of the
> equation that is indeterminate...) at which point you cannot conclude,
> what the limit is. What a mathematician is to do is to 'trans-form'
> the original h in such a way that it lead him to a path to an actual
> value.
>
> in other words that is a very specific meaning for a very specific
> subset of mathematics, that does not conflict with defining power(0,0)
> = 1.
>
>
> wrt to the 'context' of the quote I gave earlier:
>
> "Proposition 9: : Let X and Y be two sets, a and b their respective
> cardinals, then the set X{superscript Y} has cardinal a {superscript
> b}. "
>
> ( I will use x^y here from now on to note x {superscript y} for readability )
>
> "Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
> and 0^a = 0 if a != 0
>
> For there exist a unique mapping of 'empty-set' into any given set
> (namely, the mapping whose graph is the empty set); the set of
> mappings of a set consisting of a single element into an arbitrary set
> X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
> mapping of an arbitrary set into a set consisting of a single element;
> and finally there is not mapping of a non-empty set into the
> empty-set;
> * Note in particular that 0^0 = 1
> "
>
> Here is the full context of the quote. And if you think you have a
> proof that there is a mathematical error there, by all means, rush to
> your local university, as surely proving that half-way to the first
> volume, on set theory, of a body of work that is acclaimed for it's
> rigor and aim at grounding the entire field of mathematics soundly in
> the rigor of set theory, there is an 'error', will surely promptly get
> you a PhD in math... since that has escaped the attentive scrutiny and
> peer review of the entire world of mathematicians for decades...

Thanks for providing some real math into this thread.   I don't claim to 
have understood everything you write, but still, I learned something new.
And I would never have expected to hear the name of Bourbaki on the dev 
list.  Thanks for that, too.

-Andre

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Thank you Ricardo;

My suggestion would be to leave things as they are and give the matter a rest.
I personally prefer to focus on other (more necessary) developments like
updating python to version 2.7.4 which will be released this weekend.

We have ample time for testing and if there is new information we can
revise the issue before 4.0 is released.

Pedro.



>________________________________
> Da: RGB ES <rg...@gmail.com>
>A: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org> 
>Inviato: Mercoledì 13 Febbraio 2013 10:43
>Oggetto: Re: Calc behavior: result of 0 ^ 0
> 
>
>Not answering any particular message, so top posting.
>
>
>Two points:
>
>
>a) Of course you can always redefine a function to "fill holes" on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit), then there is NO way to make that function continuous on (0,0), let alone what happens when x < 0... so the real question is: does it make sense to "fill the hole" on x^y? *My* answer (and that leads to the second point) is no because it do not give any added value.
>
>
>b) Considering that we are near to 90 messages on this thread it is quite clear that an agreement is not possible. On this situation it is also clear that choosing an error instead of a fixed value is the best bet. 
>
>
>Just my 2¢
>
>
>Regards
>Ricardo
>
>
>
>2013/2/13 Pedro Giffuni <pf...@apache.org>
>
>Hello;
>>
>>>
>>> Da: Norbert Thiebaud
>>...
>>
>>>On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>>>> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>>>
>>>>> (OK, I guess it's better to re-subscribe to the list).
>>>>>
>>>>> In reply to Norbert Thiebaud*:
>>>>>
>>>>> In the Power rule, which *is* commonly used for differentiation, we take a series
>>>>> of polinomials where n !=0. n is not only different than zero, most importantly,
>>>>> it is a constant.
>>>
>>>Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
>>>so for n=1  (which _is_ different of 0 !)
>>>d/dx X = 1.x^0
>>>for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
>>>
>>>I know math can be challenging... but you don't get to invent
>>>restriction on the Power Rule just to fit you argument.
>>>
>>
>>I will put it in simple terms. You are saying that you can't calculate the
>>slope of the equation:
>>
>>y =a*x + b
>>
>>because in the process you need to calculate the value of x^0.
>>
>>
>>
>>>>>
>>
>>>>> In the case of the set theory book, do note that the author is constructing
>>>>> his own algebra,
>>>
>>>The fact that you call 'Nicola Bourbaki' 'the author', is in itself
>>>very telling about your expertise in Math.
>>>I nicely put a link to the wikipedia page, since laymen are indeed
>>>unlikely to know 'who' Borbaki is.
>>>
>>
>>Do I really care if the name of the author is fictitious or real?
>>
>>
>>>>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>>>>> a demonstration, it is simply a statement taken out of context.
>>>
>>>You ask for a practical spreadsheet example, when one is given you
>>>invent new 'rules' to ignore' it.
>>
>>You haven't provided so far that practical spreadsheet.
>>
>>
>>>You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
>>>And when I gave you the page and line from one of the most rigorous
>>>mathematical body of work of the 20th century (yep Bourbaki... look it
>>>up)
>>>you and hand-wave, pretending the author did not mean it.. or even
>>>better " if this author(sic) *is* using mathematics correctly."
>>>
>>
>>The thing is that you are taking statements out of context. I don't
>>claim being a mathematithian. I took a few courses from the career for fun. 
>>
>>In the case of set theory you can define, for your own purposes, a special
>>algebra where:
>>
>>- You redefine your own multiplication operator (x).
>>- You don't define division.
>>- You make yor algebra system fit into a set of properties that
>>is useful for your own properties.
>>
>>Once you define your own multiplication (which is not the same
>>multiplication supported in a spreadsheet) You work around the
>>issue in the power operator by defining the undefined case.
>>
>>These are all nice mathematical models that don't apply to a spreadsheet.
>>
>>
>>>>>
>>>>> I guess looking hard it may be possible to find an elaborated case where
>>>>> someone manages to shoot himself in the foot
>>>
>>>Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
>>>for shooting himself in the foot when doing math...
>>>
>>>For those interested in the actual Math... in Math words have meaning
>>>and that meaning have often context. let me develop a bit the notion
>>>of 'form' mentioned earlier:
>>>for instance in the expression 'in an indeterminate form', there is
>>>'form' and it matter because in the context of determining extension
>>>by continuity of a function, there are certain case where you can
>>>transform you equation into another 'form' but if these transformation
>>>lead you to an 'indeterminate form', you have to find another
>>>transformation to continue...
>>>hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
>>>is establish that h actually converge in the operating set, and that
>>>is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
>>>passing 'to the limit' in each term would yield 0^0 with is a
>>>indeterminable 'form' (not a value, not a number, not claimed to be
>>>the result of a calculation of power(0,0), but a 'form' of the
>>>equation that is indeterminate...) at which point you cannot conclude,
>>>what the limit is. What a mathematician is to do is to 'trans-form'
>>>the original h in such a way that it lead him to a path to an actual
>>>value.
>>>
>>>in other words that is a very specific meaning for a very specific
>>>subset of mathematics, that does not conflict with defining power(0,0)
>>>= 1.
>>>
>>>
>>>wrt to the 'context' of the quote I gave earlier:
>>>
>>>"Proposition 9: : Let X and Y be two sets, a and b their respective
>>>cardinals, then the set X{superscript Y} has cardinal a {superscript
>>>b}. "
>>>
>>>( I will use x^y here from now on to note x {superscript y} for readability )
>>>
>>>"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
>>>and 0^a = 0 if a != 0
>>>
>>>For there exist a unique mapping of 'empty-set' into any given set
>>>(namely, the mapping whose graph is the empty set); the set of
>>>mappings of a set consisting of a single element into an arbitrary set
>>>X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
>>>mapping of an arbitrary set into a set consisting of a single element;
>>>and finally there is not mapping of a non-empty set into the
>>>empty-set;
>>>* Note in particular that 0^0 = 1
>>>"
>>
>>Again, I will stand to what I said: this statement is not a demonstration
>>and is taken out of context. The definition is given to conform with this
>>"unique mapping" which unfortunately doesn't exist in the real world.
>>
>>
>>
>>>
>>>Here is the full context of the quote. And if you think you have a
>>>proof that there is a mathematical error there, by all means, rush to
>>>your local university, as surely proving that half-way to the first
>>>volume, on set theory, of a body of work that is acclaimed for it's
>>>rigor and aim at grounding the entire field of mathematics soundly in
>>>the rigor of set theory, there is an 'error', will surely promptly get
>>>you a PhD in math... since that has escaped the attentive scrutiny and
>>>peer review of the entire world of mathematicians for decades...
>>>
>>
>>I lost contact with my teacher, indeed quite an authority, but for some
>>reason he disliked computer math to the extreme anyways.
>>
>>Pedro.
>>
>
>
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

----- Messaggio originale -----
> Da: Joe Schaefer
 
> FWIW I refreshed my memory about how
> to compute polynomials numerically by
> looking back at my old copy of Numerical
> Recipes in C and it's always considered
> bad form to evaluate the terms individually,
> especially not by using the POWER function to
> do it.  Most of the time you want to
> compute p = c[0] x^0 + ... + c[n] x^n by doing
> 
> p = c[j=n];
> while (j > 0)
>     p = p*x + c[--j];
> 
> 
> which does the right thing and pulls out
> c[0] when x=0.  Obviously there are overflow
> issues to deal with for large degree polynomials
> and large values of x, but you get the idea.
>

Ah yes, that's an old numerical trick when n
is an integer. The non-integer case is, of
course, more interesting ;).

What I was noting in a previous reply (to Norbert) is that
you actually never even write x^0, you just write:

 p = c[0] + c[1] x^1 + ... + c[n] x^n 

so when calculating the derivative (using the power
rule) you completely ignore the first term as it's a
waste of time (the derivate of a constant is 0).

It somewhat silly (and a waste of time) to write
POWER($A1, 0) in a spreadsheet where 0 ^ 0 is 1.

My HP Calculator does have a valid reason for
setting 0 ^ 0 =1, but it doesn't apply to a spreadsheet
so I will leave at that :-P. 


Pedro.

Re: Calc behavior: result of 0 ^ 0

[Joe Schaefer <jo...@yahoo.com>]

FWIW I refreshed my memory about how
to compute polynomials numerically by
looking back at my old copy of Numerical
Recipes in C and it's always considered
bad form to evaluate the terms individually,
especially not by using the POWER function to
do it.  Most of the time you want to
compute p = c[0] x^0 + ... + c[n] x^n by doing

p = c[j=n];
while (j > 0)
    p = p*x + c[--j];


which does the right thing and pulls out
c[0] when x=0.  Obviously there are overflow
issues to deal with for large degree polynomials
and large values of x, but you get the idea.


The book also contains methods for dealing
with infinite power series as well, but I
think the key observation is that you want
polynomials with integer coefficients to
evaluate to an exact integer when dealing
with integer values of x.  If POWER(n,m) is
always guaranteed to do that, then I can
see why you'd use that in your spreadsheet
app, even if it isn't what a numerical analyst
would recommend off the top of her head.


IOW what I'm saying is that the choice to
use POWER() in evaluating polynomials and
infinite series in spreadsheets is a CHOICE,
the fact that x^0 = 1 for all values of x
doesn't have to weigh in to your deliberations
about what the right value is for POWER(0,0)
unless you insist in supporting the evaluation
of polynomialexpressions using the POWER
function.





>________________________________
> From: Joe Schaefer <jo...@yahoo.com>
>To: "dev@openoffice.apache.org" <de...@openoffice.apache.org> 
>Sent: Wednesday, February 13, 2013 12:43 PM
>Subject: Re: Calc behavior: result of 0 ^ 0
> 
>
>I think the days of fruitful debate
>about this topic are well past us now.
>What this issue needs at this point
>is a decision one way or the other.
>There are several ways of doing that
>according to the general voting policies
>at Apache: exercising those procedures
>should not be viewed as "blunt instruments"
>but rather time-honored methods of obtaining
>clarity on what amounts to a perfect bikeshed
>issue where the spec provides no clear guidance
>one way or the other.
>
>
>
>
>
>
>>________________________________
>> From: Rob Weir <ro...@apache.org>
>>To: dev@openoffice.apache.org 
>>Sent: Wednesday, February 13, 2013 12:30 PM
>>Subject: Re: Calc behavior: result of 0 ^ 0
>> 
>>On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>>> OTOH I haven't seen anyone issue a technical
>>> veto on this change, which is really what's
>>> required before Pedro actually needs to revert
>>> anything.
>>>
>>
>>I was waiting to see if there were any persuasive arguments in favor
>>of breaking backwards compatibility before deciding whether to do
>>that.  I think things are getting a little clearer now with Norbert's
>>contribution to the discussion.  But if (as it seems now) that
>>"mathematical correctness" does not justify the change, then my
>>position would be that we don't break backwards compatibility.
>>
>>Also, a veto would be a blunt instrument and I'd rather avoid it if
>>further discussion leads to a
 consensus.
>>
>>-Rob
>>
>>>
>>>
>>>
>>>
>>>>________________________________
>>>> From: Joe Schaefer <jo...@yahoo.com>
>>>>To: "dev@openoffice.apache.org" <de...@openoffice.apache.org>; Pedro Giffuni <pf...@apache.org>
>>>>Sent: Wednesday, February 13, 2013 10:53 AM
>>>>Subject: Re: Calc behavior: result of 0 ^ 0
>>>>
>>>>
>>>>Honestly I'd say that if anything is clear,
>>>>it's that changing away from the status quo
>>>>currently enjoys zero consensus.
>>>>
>>>>As a Ph.D. mathematician who knows about
 Bourbaki,
>>>>all I can say is that line of argument is curious
>>>>here.  There are no authorities other than the spec
>>>>to turn to about how you want POWER(0,0) to behave-
>>>>as a function of 2 variables returning an error is
>>>>probably best mathematically because the POWER
>>>>function isn't remotely continuous at (0,0), but as
>>>>part of an implementation of power series
>>>>representations of sums involving 0^0, returning 1
>>>>is better.
>>>>
>>>>
>>>>
>>>>In any case, the idea for how issues like this should
>>>>be resolved at Apache is always in favor of stability;
>>>>that's why the impetus for consensus away from the current
>>>>behavior is required, not a general discussion about
>>>>which behavior is better given two equal choices
>>>>in the abstract.  A prior decision has already been
 made
>>>>about the code, and those that wish to change it need
>>>>to demonstrate consensus for the change, not the other
>>>>way around.
>>>>
>>>>
>>>>
>>>>HTH
>>>>
>>>>
>>>>
>>>>
>>>>>________________________________
>>>>> From: RGB ES <rg...@gmail.com>
>>>>>To: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org>
>>>>>Sent: Wednesday, February 13, 2013 10:43 AM
>>>>>Subject: Re: Calc behavior: result of 0 ^ 0
>>>>>
>>>>>Not answering any particular message, so top posting.
>>>>>
>>>>>Two points:
>>>>>
>>>>>a) Of
 course you can always redefine a function to "fill holes" on non
>>>>>defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0
>>>>>makes sense because you obtain a continuous function... but that's on 1
>>>>>variable: when you go to two variables things become more difficult. In
>>>>>fact, the limit for x^y with x *and* y tending to zero do NOT exists
>>>>>(choose a different path and you'll get a different limit), then there is
>>>>>NO way to make that function continuous on (0,0), let alone what happens
>>>>>when x < 0... so the real question is: does it make sense to "fill the
>>>>>hole" on x^y? *My* answer (and that leads to the second point) is no
>>>>>because it do not give any added value.
>>>>>
>>>>>b) Considering that we are near to 90 messages on this thread it is quite
>>>>>clear that an agreement is not
 possible. On this situation it is also clear
>>>>>that
>>>  choosing an error instead of a fixed value is the best bet.
>>>>>
>>>>>Just my 2¢
>>>>>
>>>>>Regards
>>>>>Ricardo
>>>>>
>>>>>
>>>>>2013/2/13 Pedro Giffuni <pf...@apache.org>
>>>>>
>>>>>> Hello;
>>>>>>
>>>>>> >
>>>>>> > Da: Norbert Thiebaud
>>>>>> ...
>>>>>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>>>>>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>>>>> >>
>>>>>>
 >>> (OK, I guess it's better to re-subscribe to the list).
>>>>>> >>>
>>>>>> >>> In reply to Norbert Thiebaud*:
>>>>>> >>>
>>>>>> >>> In the Power rule, which *is* commonly used for differentiation, we
>>>>>> take a series
>>>>>> >>> of
>>>  polinomials where n !=0. n is not only different than zero, most
>>>>>> importantly,
>>>>>> >>> it is a constant.
>>>>>> >
>>>>>> >Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
>>>>>> >so for n=1  (which _is_ different of 0 !)
>>>>>> >d/dx X = 1.x^0
>>>>>> >for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
>>>>>> >
>>>>>> >I know math can be challenging... but you don't get to
 invent
>>>>>> >restriction on the Power Rule just to fit you argument.
>>>>>> >
>>>>>>
>>>>>> I will put it in simple terms. You are saying that you can't calculate the
>>>>>> slope of the equation:
>>>>>>
>>>>>> y =a*x + b
>>>>>>
>>>>>> because in the process you need to calculate the value of x^0.
>>>>>>
>>>>>>
>>>>>> >>>
>>>>>>
>>>>>> >>> In the case of the set theory book, do note that the author is
>>>>>> constructing
>>>>>> >>> his own
>>>  algebra,
>>>>>> >
>>>>>> >The fact that you call 'Nicola Bourbaki' 'the author', is in itself
>>>>>> >very telling about your expertise in Math.
>>>>>> >I nicely put a link to the wikipedia page, since
 laymen are indeed
>>>>>> >unlikely to know 'who' Borbaki is.
>>>>>> >
>>>>>>
>>>>>> Do I really care if the name of the author is fictitious or real?
>>>>>>
>>>>>> >>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>>>>>> >>> a demonstration, it is simply a statement taken out of context.
>>>>>> >
>>>>>> >You ask for a practical spreadsheet example, when one is given you
>>>>>> >invent new 'rules' to ignore' it.
>>>>>>
>>>>>> You haven't provided so far that practical spreadsheet.
>>>>>>
>>>>>> >You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
>>>>>> >And when I gave you the page and line from one of the most rigorous
>>>>>> >mathematical
>>>  body of work of
 the 20th century (yep Bourbaki... look it
>>>>>> >up)
>>>>>> >you and hand-wave, pretending the author did not mean it.. or even
>>>>>> >better " if this author(sic) *is* using mathematics correctly."
>>>>>> >
>>>>>>
>>>>>> The thing is that you are taking statements out of context. I don't
>>>>>> claim being a mathematithian. I took a few courses from the career for
>>>>>> fun.
>>>>>>
>>>>>> In the case of set theory you can define, for your own purposes, a special
>>>>>> algebra where:
>>>>>>
>>>>>> - You redefine your own multiplication operator (x).
>>>>>> - You don't define division.
>>>>>> - You make yor algebra system fit into a set of properties that
>>>>>> is useful for your own
 properties.
>>>>>>
>>>>>> Once you define your own multiplication (which is not the same
>>>>>> multiplication supported in a spreadsheet) You work around the
>>>>>> issue in the power operator by defining the undefined
>>>  case.
>>>>>>
>>>>>> These are all nice mathematical models that don't apply to a spreadsheet.
>>>>>>
>>>>>> >>>
>>>>>> >>> I guess looking hard it may be possible to find an elaborated case
>>>>>> where
>>>>>> >>> someone manages to shoot himself in the foot
>>>>>> >
>>>>>> >Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
>>>>>> >for shooting himself in the foot when doing math...
>>>>>> >
>>>>>> >For those interested in the actual Math... in Math words
 have meaning
>>>>>> >and that meaning have often context. let me develop a bit the notion
>>>>>> >of 'form' mentioned earlier:
>>>>>> >for instance in the expression 'in an indeterminate form', there is
>>>>>> >'form' and it matter because in the context of determining extension
>>>>>> >by continuity of a function, there are certain case where you can
>>>>>> >transform you equation into another 'form' but
>>>  if these transformation
>>>>>> >lead you to an 'indeterminate form', you have to find another
>>>>>> >transformation to continue...
>>>>>> >hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
>>>>>> >is establish that h actually converge in the operating set, and that
>>>>>> >is another topic altogether -- lim h(x) x->0 =
 (lim f)^(lim g).
>>>>>> >passing 'to the limit' in each term would yield 0^0 with is a
>>>>>> >indeterminable 'form' (not a value, not a number, not claimed to be
>>>>>> >the result of a calculation of power(0,0), but a 'form' of the
>>>>>> >equation that is indeterminate...) at which point you cannot conclude,
>>>>>> >what the limit is. What a mathematician is to do is to 'trans-form'
>>>>>> >the original h in such a way that it lead him to a path to an actual
>>>>>> >value.
>>>>>> >
>>>>>> >in other words that is a very specific
>>>  meaning for a very specific
>>>>>> >subset of mathematics, that does not conflict with defining power(0,0)
>>>>>> >= 1.
>>>>>> >
>>>>>> >
>>>>>> >wrt to the 'context' of the quote I gave
 earlier:
>>>>>> >
>>>>>> >"Proposition 9: : Let X and Y be two sets, a and b their respective
>>>>>> >cardinals, then the set X{superscript Y} has cardinal a {superscript
>>>>>> >b}. "
>>>>>> >
>>>>>> >( I will use x^y here from now on to note x {superscript y} for
>>>>>> readability )
>>>>>> >
>>>>>> >"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
>>>>>> >and 0^a = 0 if a != 0
>>>>>> >
>>>>>> >For there exist a unique mapping of 'empty-set' into any given set
>>>>>> >(namely, the mapping whose graph is the empty set); the set of
>>>>>> >mappings of a set consisting of a single element into an arbitrary set
>>>>>> >X is equipotent to X (Chapter II, pragraph 5.3); there
>>>  exist a
 unique
>>>>>> >mapping of an arbitrary set into a set consisting of a single element;
>>>>>> >and finally there is not mapping of a non-empty set into the
>>>>>> >empty-set;
>>>>>> >* Note in particular that 0^0 = 1
>>>>>> >"
>>>>>>
>>>>>> Again, I will stand to what I said: this statement is not a demonstration
>>>>>> and is taken out of context. The definition is given to conform with this
>>>>>> "unique mapping" which unfortunately doesn't exist in the real world.
>>>>>>
>>>>>>
>>>>>> >
>>>>>> >Here is the full context of the quote. And if you think you have a
>>>>>> >proof that there is a mathematical error there, by all means, rush to
>>>>>> >your local university, as surely proving that half-way to the first
>>>>>>
 >volume, on set theory, of a body of work that is acclaimed for it's
>>>>>> >rigor and aim at grounding the entire field of mathematics soundly in
>>>>>> >the rigor of set
>>>  theory, there is an 'error', will surely promptly get
>>>>>> >you a PhD in math... since that has escaped the attentive scrutiny and
>>>>>> >peer review of the entire world of mathematicians for decades...
>>>>>> >
>>>>>>
>>>>>> I lost contact with my teacher, indeed quite an authority, but for some
>>>>>> reason he disliked computer math to the extreme anyways.
>>>>>>
>>>>>> Pedro.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>
>

Re: Calc behavior: result of 0 ^ 0

[Joe Schaefer <jo...@yahoo.com>]

I think the days of fruitful debate
about this topic are well past us now.
What this issue needs at this point
is a decision one way or the other.
There are several ways of doing that
according to the general voting policies
at Apache: exercising those procedures
should not be viewed as "blunt instruments"
but rather time-honored methods of obtaining
clarity on what amounts to a perfect bikeshed
issue where the spec provides no clear guidance
one way or the other.





>________________________________
> From: Rob Weir <ro...@apache.org>
>To: dev@openoffice.apache.org 
>Sent: Wednesday, February 13, 2013 12:30 PM
>Subject: Re: Calc behavior: result of 0 ^ 0
> 
>On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>> OTOH I haven't seen anyone issue a technical
>> veto on this change, which is really what's
>> required before Pedro actually needs to revert
>> anything.
>>
>
>I was waiting to see if there were any persuasive arguments in favor
>of breaking backwards compatibility before deciding whether to do
>that.  I think things are getting a little clearer now with Norbert's
>contribution to the discussion.  But if (as it seems now) that
>"mathematical correctness" does not justify the change, then my
>position would be that we don't break backwards compatibility.
>
>Also, a veto would be a blunt instrument and I'd rather avoid it if
>further discussion leads to a consensus.
>
>-Rob
>
>>
>>
>>
>>
>>>________________________________
>>> From: Joe Schaefer <jo...@yahoo.com>
>>>To: "dev@openoffice.apache.org" <de...@openoffice.apache.org>; Pedro Giffuni <pf...@apache.org>
>>>Sent: Wednesday, February 13, 2013 10:53 AM
>>>Subject: Re: Calc behavior: result of 0 ^ 0
>>>
>>>
>>>Honestly I'd say that if anything is clear,
>>>it's that changing away from the status quo
>>>currently enjoys zero consensus.
>>>
>>>As a Ph.D. mathematician who knows about Bourbaki,
>>>all I can say is that line of argument is curious
>>>here.  There are no authorities other than the spec
>>>to turn to about how you want POWER(0,0) to behave-
>>>as a function of 2 variables returning an error is
>>>probably best mathematically because the POWER
>>>function isn't remotely continuous at (0,0), but as
>>>part of an implementation of power series
>>>representations of sums involving 0^0, returning 1
>>>is better.
>>>
>>>
>>>
>>>In any case, the idea for how issues like this should
>>>be resolved at Apache is always in favor of stability;
>>>that's why the impetus for consensus away from the current
>>>behavior is required, not a general discussion about
>>>which behavior is better given two equal choices
>>>in the abstract.  A prior decision has already been made
>>>about the code, and those that wish to change it need
>>>to demonstrate consensus for the change, not the other
>>>way around.
>>>
>>>
>>>
>>>HTH
>>>
>>>
>>>
>>>
>>>>________________________________
>>>> From: RGB ES <rg...@gmail.com>
>>>>To: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org>
>>>>Sent: Wednesday, February 13, 2013 10:43 AM
>>>>Subject: Re: Calc behavior: result of 0 ^ 0
>>>>
>>>>Not answering any particular message, so top posting.
>>>>
>>>>Two points:
>>>>
>>>>a) Of course you can always redefine a function to "fill holes" on non
>>>>defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0
>>>>makes sense because you obtain a continuous function... but that's on 1
>>>>variable: when you go to two variables things become more difficult. In
>>>>fact, the limit for x^y with x *and* y tending to zero do NOT exists
>>>>(choose a different path and you'll get a different limit), then there is
>>>>NO way to make that function continuous on (0,0), let alone what happens
>>>>when x < 0... so the real question is: does it make sense to "fill the
>>>>hole" on x^y? *My* answer (and that leads to the second point) is no
>>>>because it do not give any added value.
>>>>
>>>>b) Considering that we are near to 90 messages on this thread it is quite
>>>>clear that an agreement is not possible. On this situation it is also clear
>>>>that
>>  choosing an error instead of a fixed value is the best bet.
>>>>
>>>>Just my 2¢
>>>>
>>>>Regards
>>>>Ricardo
>>>>
>>>>
>>>>2013/2/13 Pedro Giffuni <pf...@apache.org>
>>>>
>>>>> Hello;
>>>>>
>>>>> >
>>>>> > Da: Norbert Thiebaud
>>>>> ...
>>>>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>>>>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>>>> >>
>>>>> >>> (OK, I guess it's better to re-subscribe to the list).
>>>>> >>>
>>>>> >>> In reply to Norbert Thiebaud*:
>>>>> >>>
>>>>> >>> In the Power rule, which *is* commonly used for differentiation, we
>>>>> take a series
>>>>> >>> of
>>  polinomials where n !=0. n is not only different than zero, most
>>>>> importantly,
>>>>> >>> it is a constant.
>>>>> >
>>>>> >Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
>>>>> >so for n=1  (which _is_ different of 0 !)
>>>>> >d/dx X = 1.x^0
>>>>> >for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
>>>>> >
>>>>> >I know math can be challenging... but you don't get to invent
>>>>> >restriction on the Power Rule just to fit you argument.
>>>>> >
>>>>>
>>>>> I will put it in simple terms. You are saying that you can't calculate the
>>>>> slope of the equation:
>>>>>
>>>>> y =a*x + b
>>>>>
>>>>> because in the process you need to calculate the value of x^0.
>>>>>
>>>>>
>>>>> >>>
>>>>>
>>>>> >>> In the case of the set theory book, do note that the author is
>>>>> constructing
>>>>> >>> his own
>>  algebra,
>>>>> >
>>>>> >The fact that you call 'Nicola Bourbaki' 'the author', is in itself
>>>>> >very telling about your expertise in Math.
>>>>> >I nicely put a link to the wikipedia page, since laymen are indeed
>>>>> >unlikely to know 'who' Borbaki is.
>>>>> >
>>>>>
>>>>> Do I really care if the name of the author is fictitious or real?
>>>>>
>>>>> >>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>>>>> >>> a demonstration, it is simply a statement taken out of context.
>>>>> >
>>>>> >You ask for a practical spreadsheet example, when one is given you
>>>>> >invent new 'rules' to ignore' it.
>>>>>
>>>>> You haven't provided so far that practical spreadsheet.
>>>>>
>>>>> >You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
>>>>> >And when I gave you the page and line from one of the most rigorous
>>>>> >mathematical
>>  body of work of the 20th century (yep Bourbaki... look it
>>>>> >up)
>>>>> >you and hand-wave, pretending the author did not mean it.. or even
>>>>> >better " if this author(sic) *is* using mathematics correctly."
>>>>> >
>>>>>
>>>>> The thing is that you are taking statements out of context. I don't
>>>>> claim being a mathematithian. I took a few courses from the career for
>>>>> fun.
>>>>>
>>>>> In the case of set theory you can define, for your own purposes, a special
>>>>> algebra where:
>>>>>
>>>>> - You redefine your own multiplication operator (x).
>>>>> - You don't define division.
>>>>> - You make yor algebra system fit into a set of properties that
>>>>> is useful for your own properties.
>>>>>
>>>>> Once you define your own multiplication (which is not the same
>>>>> multiplication supported in a spreadsheet) You work around the
>>>>> issue in the power operator by defining the undefined
>>  case.
>>>>>
>>>>> These are all nice mathematical models that don't apply to a spreadsheet.
>>>>>
>>>>> >>>
>>>>> >>> I guess looking hard it may be possible to find an elaborated case
>>>>> where
>>>>> >>> someone manages to shoot himself in the foot
>>>>> >
>>>>> >Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
>>>>> >for shooting himself in the foot when doing math...
>>>>> >
>>>>> >For those interested in the actual Math... in Math words have meaning
>>>>> >and that meaning have often context. let me develop a bit the notion
>>>>> >of 'form' mentioned earlier:
>>>>> >for instance in the expression 'in an indeterminate form', there is
>>>>> >'form' and it matter because in the context of determining extension
>>>>> >by continuity of a function, there are certain case where you can
>>>>> >transform you equation into another 'form' but
>>  if these transformation
>>>>> >lead you to an 'indeterminate form', you have to find another
>>>>> >transformation to continue...
>>>>> >hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
>>>>> >is establish that h actually converge in the operating set, and that
>>>>> >is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
>>>>> >passing 'to the limit' in each term would yield 0^0 with is a
>>>>> >indeterminable 'form' (not a value, not a number, not claimed to be
>>>>> >the result of a calculation of power(0,0), but a 'form' of the
>>>>> >equation that is indeterminate...) at which point you cannot conclude,
>>>>> >what the limit is. What a mathematician is to do is to 'trans-form'
>>>>> >the original h in such a way that it lead him to a path to an actual
>>>>> >value.
>>>>> >
>>>>> >in other words that is a very specific
>>  meaning for a very specific
>>>>> >subset of mathematics, that does not conflict with defining power(0,0)
>>>>> >= 1.
>>>>> >
>>>>> >
>>>>> >wrt to the 'context' of the quote I gave earlier:
>>>>> >
>>>>> >"Proposition 9: : Let X and Y be two sets, a and b their respective
>>>>> >cardinals, then the set X{superscript Y} has cardinal a {superscript
>>>>> >b}. "
>>>>> >
>>>>> >( I will use x^y here from now on to note x {superscript y} for
>>>>> readability )
>>>>> >
>>>>> >"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
>>>>> >and 0^a = 0 if a != 0
>>>>> >
>>>>> >For there exist a unique mapping of 'empty-set' into any given set
>>>>> >(namely, the mapping whose graph is the empty set); the set of
>>>>> >mappings of a set consisting of a single element into an arbitrary set
>>>>> >X is equipotent to X (Chapter II, pragraph 5.3); there
>>  exist a unique
>>>>> >mapping of an arbitrary set into a set consisting of a single element;
>>>>> >and finally there is not mapping of a non-empty set into the
>>>>> >empty-set;
>>>>> >* Note in particular that 0^0 = 1
>>>>> >"
>>>>>
>>>>> Again, I will stand to what I said: this statement is not a demonstration
>>>>> and is taken out of context. The definition is given to conform with this
>>>>> "unique mapping" which unfortunately doesn't exist in the real world.
>>>>>
>>>>>
>>>>> >
>>>>> >Here is the full context of the quote. And if you think you have a
>>>>> >proof that there is a mathematical error there, by all means, rush to
>>>>> >your local university, as surely proving that half-way to the first
>>>>> >volume, on set theory, of a body of work that is acclaimed for it's
>>>>> >rigor and aim at grounding the entire field of mathematics soundly in
>>>>> >the rigor of set
>>  theory, there is an 'error', will surely promptly get
>>>>> >you a PhD in math... since that has escaped the attentive scrutiny and
>>>>> >peer review of the entire world of mathematicians for decades...
>>>>> >
>>>>>
>>>>> I lost contact with my teacher, indeed quite an authority, but for some
>>>>> reason he disliked computer math to the extreme anyways.
>>>>>
>>>>> Pedro.
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Hi Andrea;


----- Messaggio originale -----
> Da: Andrea Pescetti

> 
> Rob Weir wrote:
>>  On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote:
>>>  Fine. I would have started the vote earlier, but it's your code so 
> I'll
>>>  respect your choice. And it's good to give people more time to 
> think (not to
>>  We had a committer veto.  Why are having a vote?  A -1 from a
>>  commmitter is not something we vote on.
> 
> Vetos must be based on technical grounds and can be withdrawn, see
> http://www.apache.org/foundation/voting.html#Veto
> (no, I haven't seen a clearly stated "technical ground" in 
> Kay's mail). Due to the exceptional amount of posts in this thread, a proper 
> vote is now the clearest way out, and in case of opposition it will allow to 
> record clearly what the technical reason was.
> 

The reason why I am asking for a two weeks break from the issue is
that the list is in "bikeshed mode".

As far as I can tell:

- No one involved in thread has a spreadsheet depending on POWER(0, 0)
and are only now aware that the value is somehow dubious.

- With the notable exception of Regina, no one in this thread is doing
Calc development and this change doesn't interfere with anyone else's
work.

- No one has complained about the technical merits of the patch. Was
there a cleaer way to do it .. patches welcome!!

AFAICT, just because this issue is easy to understand and somewhat
controversial everyone think they should take a part of it. This called
bikeshedding.

I will not be bringing again this patch everytime there is a major release:
if it doesn't make it in 4.0 it will be a sign that the fundamental Calc
functionality is untouchable.

I would prefer if people have time to evaluate the pros and cons of the
patch before taking a vote. I honestly think the change is innocuous.


>>  The patch needs to be reverted, now.
> 
> Please do not go on and revert it now, and please do not escalate the problem 
> again (this friendly advice applies to Pedro too). It is a trivial issue, with 
> no side effects on the rest of the code, and it will be quickly solved by voting 
> (where a -1 from a committer with a clearly stated "technical ground" 
> counts as veto) well before a release, or even a beta version, containing it is 
> distributed.
>

So far Regina's response has been the best structured opposition to the
patch and without bikeshedding.

I do have the patch ready to revert if if required but TBH I don't see valid
reasons as of yet.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Regina Henschel <rb...@t-online.de>]

Hi all,

please have a break. Keep in mind, that our community members from China 
have their Chinese New Year holidays and might not be back yet. Give 
them a change to notice the discussion.

Kind regards
Regina

Andrea Pescetti schrieb:
> Rob Weir wrote:
>> On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote:
>>> Fine. I would have started the vote earlier, but it's your code so I'll
>>> respect your choice. And it's good to give people more time to think
>>> (not to
>> We had a committer veto.  Why are having a vote?  A -1 from a
>> commmitter is not something we vote on.
>
> Vetos must be based on technical grounds and can be withdrawn, see
> http://www.apache.org/foundation/voting.html#Veto
> (no, I haven't seen a clearly stated "technical ground" in Kay's mail).
> Due to the exceptional amount of posts in this thread, a proper vote is
> now the clearest way out, and in case of opposition it will allow to
> record clearly what the technical reason was.
>
>> The patch needs to be reverted, now.
>
> Please do not go on and revert it now, and please do not escalate the
> problem again (this friendly advice applies to Pedro too). It is a
> trivial issue, with no side effects on the rest of the code, and it will
> be quickly solved by voting (where a -1 from a committer with a clearly
> stated "technical ground" counts as veto) well before a release, or even
> a beta version, containing it is distributed.
>
> Overstating the problem or insisting on this, no longer fruitful,
> discussion would only drain resources from more important topics. I
> recommend that we put community over code, suspend this discussion, take
> a final vote when Pedro calls it and respect its outcome, whatever it is.

Re: Calc behavior: result of 0 ^ 0

[Kay Schenk <ka...@gmail.com>]

On Thu, Feb 14, 2013 at 11:17 AM, Pedro Giffuni <pf...@apache.org> wrote:

> Hello Kay;
>
>
> ----- Messaggio originale -----
> > Da: Kay Schenk
>
> >
> > I readily admit this is true. I would like my veto to stand and here I
> will
> > elaborate and hopefully provide my technical justification.
> >
> > In my mind, current mathematical information aside, we have implemented
> an
> > acceptable solution based on the ODF specification. If, at some point,
> some
> > universal mathematical body says without doubt that 0^0 should never ever
> > be considered 1, then I am assuming the ODF standards body would change
> the
> > standard for that function, and we would then change the current
> > calculation.
> >
> > I have seen many references to this "issue" on the web, some which
> > support
> > the current implementation, some of which do not. In my mind, this needs
> to
> > go back to OASIS.
> >
> > So for what it's worth, this is my technical justification. We are not a
> > mathematical body, we are implementing code that complies to the ODF
> > standard.
> >
>
> Can you please point me to the specific point of the ODF standard where
> this change has brought us out of compliance?
>

It has not brought us out of compliance but well, let me put it better, out
of a long-standing desire of OpenOffice to implement this particular
function with this result.

As Dennis pointed out early in this thread, this is one of several possible
outcomes for this function:

Section 6.16.46

of:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#__RefHeading__1018122_715980110

I would think changes with more far reaching implications such as this one
would first be introduced via a PROPOSAL rather than an immediate change.




>
>
> > If "we" have a problem with that standard, "we" need to
> > discuss it with the standards body, not change existing code because
> > of a personal viewpoint.
> >
>
> We have no problems with the standards body.
>
> I don't like having to revert my work, of course, but this is not
> a matter of personal viewpoint.
>
> Please,, *please* do understand this issue has little to view with
> my personal point of view: I didn't create the BZ issue, I don't work
> for Microsoft, I didn't patch Excel to change results.
>
> Pedro.
>
>


-- 
----------------------------------------------------------------------------------------
MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 17, 2013 at 6:40 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Ugh.. I am really tired of this.
>
> I even declare myself agnostic.
>

Pedro, this is not about you.  It is about the code.  You are welcome
to believe deeply that 0^0 should be NaN.  You don't need to be
agnostic.  But the code should not be agnostic.  It should preserve
backwards compatibility by default, and not require special build
flags in order to do so.

-Rob

> I have a new way to address this issue and hopefully put an end to it
> and I will post it RSN, OK?
>
> Pedro.
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Ugh.. I am really tired of this.

I even declare myself agnostic.

I have a new way to address this issue and hopefully put an end to it
and I will post it RSN, OK?

Pedro.

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <de...@acm.org>]

I've been sitting on this in draft since Thursday because the two vetoes
from Kay and Rob seemed to have been sufficient and I didn't want to pile
onto Pedro.  Pedro, it seems to me you are not paying attention.  I agree
that the veto should have left the patch to be reverted yourself, and the
addition of veto as a tag is also very handy now.

And here's mine now:

-1 on the change from returning 1.0 for Calc OpenFormula function POWER(0,0)
to returning an error value (as that term is used specifically for
OpenFormula) instead.

Furthermore, I am prepared to object to *any* patches to Calc functions at
some level that does not explain exactly what the *Calc* impact is.  What is
correct for a C/C++ library result for pow[r] is not relevant.  What matters
is what is correct for *Calc*, and backward compatibility is an important
technical factor that is applicable to this particular case.  

This has become tantamount to a Wikipedia edit war.  It must stop.  This
business about turning in untested (in Calc) code and claiming that all
issues (whatever they include) are resolved is not working.  While that is
presumably more-or-less all right on SVN trunk, I suggest that it is
incumbent on the contributor to take a developer build and demonstrate that
the result is as specified, after claiming what it is that is specified.
And if that fails or the modified behavior is disputed, I prefer that the
trunk not be left dirty.

 - Dennis

TECHNICAL JUSTIFICATION

It is agreed that there are three values any of which may be
implementation-defined as the value produced by an implementation and that
satisfies the ODF 1.2 OpenFormula specification (an OASIS Standard).

AOO Calc produces one of those values and is in accord with ODF 1.2 in that
respect.  (There are no spreadsheet functions defined in earlier versions of
the ODF specification.)

The technical objection is around breaking backward compatibility with the
body of existing OpenOffice.org, Apache OpenOffice, IBM Lotus Symphony and
LibreOffice ODF documents.  (They are all *already* incompatible with what
Excel does, either in its recent ODF 1.2 support, its original native
implementation, or in its support for OOXML.)

The veto is appropriate on those grounds.  A controversial breaking change
is as valid a technical justification as is a performance issue.

PS: I assume that there can continue to be a ballot or whatever other
consensus directed determination following this, but the change should not
be made until it survives such a determination.

PPS: I agree with Rob to the extent that this is not about repair of a
defect.  I understand that some believe otherwise.  I agree that it is about
handling of an edge case in an interoperable manner.  It comes down to
interoperable with whom, because either choice is incompatible with someone.

PPPS: I continue to prefer that POWER(0,0) be the Calc equivalent of NaN.  I
don't believe that gives me the right to impose it.  As a progression of
previous posts from me reveals, I believe that the issue is about defined
functional behavior of a computational procedure, it is not about the
mathematics of exponentiation beyond the desire to approach the far more
significant uncontroversial features of exponentiation sufficient to count
as practical success.  POWER(0,0) is not critical to that endeavor.

-----Original Message-----
From: Pedro Giffuni [mailto:pfg@apache.org] 
Sent: Thursday, February 14, 2013 11:18
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

Hello Kay;


----- Messaggio originale -----
> Da: Kay Schenk 

> 
> I readily admit this is true. I would like my veto to stand and here I
will
> elaborate and hopefully provide my technical justification.
> 
> In my mind, current mathematical information aside, we have implemented an
> acceptable solution based on the ODF specification. If, at some point,
some
> universal mathematical body says without doubt that 0^0 should never ever
> be considered 1, then I am assuming the ODF standards body would change
the
> standard for that function, and we would then change the current
> calculation.
> 
> I have seen many references to this "issue" on the web, some which 
> support
> the current implementation, some of which do not. In my mind, this needs
to
> go back to OASIS.
> 
> So for what it's worth, this is my technical justification. We are not a
> mathematical body, we are implementing code that complies to the ODF
> standard.
> 

Can you please point me to the specific point of the ODF standard where
this change has brought us out of compliance?



> If "we" have a problem with that standard, "we" need to 
> discuss it with the standards body, not change existing code because
> of a personal viewpoint.
>

We have no problems with the standards body.

I don't like having to revert my work, of course, but this is not
a matter of personal viewpoint.

Please,, *please* do understand this issue has little to view with
my personal point of view: I didn't create the BZ issue, I don't work
for Microsoft, I didn't patch Excel to change results.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Hello Kay;


----- Messaggio originale -----
> Da: Kay Schenk 

> 
> I readily admit this is true. I would like my veto to stand and here I will
> elaborate and hopefully provide my technical justification.
> 
> In my mind, current mathematical information aside, we have implemented an
> acceptable solution based on the ODF specification. If, at some point, some
> universal mathematical body says without doubt that 0^0 should never ever
> be considered 1, then I am assuming the ODF standards body would change the
> standard for that function, and we would then change the current
> calculation.
> 
> I have seen many references to this "issue" on the web, some which 
> support
> the current implementation, some of which do not. In my mind, this needs to
> go back to OASIS.
> 
> So for what it's worth, this is my technical justification. We are not a
> mathematical body, we are implementing code that complies to the ODF
> standard.
> 

Can you please point me to the specific point of the ODF standard where
this change has brought us out of compliance?



> If "we" have a problem with that standard, "we" need to 
> discuss it with the standards body, not change existing code because
> of a personal viewpoint.
>

We have no problems with the standards body.

I don't like having to revert my work, of course, but this is not
a matter of personal viewpoint.

Please,, *please* do understand this issue has little to view with
my personal point of view: I didn't create the BZ issue, I don't work
for Microsoft, I didn't patch Excel to change results.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ra...@gmail.com>]

On Feb 14, 2013, at 8:51 PM, Pedro Giffuni <pf...@apache.org> wrote:

> Rob;
>
> Can you confirm the platform where you got those results?
>

I believe this was WinXP SP3 (32-bit), but I can confirm in the morning.

-Rob


> Thanks,
>
> Pedro.
>
>
> ----- Messaggio originale -----
>> Da: Rob Weir <ro...@apache.org>
>> A: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org>
>> Cc:
>> Inviato: Giovedì 14 Febbraio 2013 16:47
>> Oggetto: Re: Calc behavior: result of 0 ^ 0
>>
>> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni <pf...@apache.org> wrote
>>>
>>>
>>> ----- Messaggio originale -----
>>>> Da: Rob Weir
>>>
>>>>
>>>> And I should say that I'm happy to help if you or anyone else
>> wishes
>>>> to introduce a "warning mode" or "formula lint" or
>> similar  feature
>>>> that can be optionally enabled to check for possible inadvertent user
>>>> errors.
>>>
>>> As the guys from the poisonous people video[1] said:
>>>
>>> "Patches Welcome"
>>
>> Pedro, I reverted your patch.  It was broken in many ways.  It is sad
>> that with the length of this thread that no one, apparently even you,
>> tried to test it.  But I did and found:
>>
>> 0^0 now returns a #VALUE! error in Calc, breaking compatibility.
>>
>> 2^(1/3) which should be the cube root of 2 now returns 1.  This is
>> mathematically incorrect and breaks compatibility.
>>
>> 2^(-1/3) which should be the reciprocal of the cube root of 3 returns
>> 1 with Pedro's changes.  This is mathematically incorrect and breaks
>> compatibility.
>>
>> -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
>> returns 1 with Pedro's changes.  This is mathematically incorrect and
>> breaks compatibility.
>>
>> -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
>> returns 1 with Pedro's changes.  This is mathematically incorrect and
>> breaks compatibility.
>>
>> -Rob
>>
>>> Pedro.
>>>
>>> [1]  http://www.youtube.com/watch?v=Q52kFL8zVoM
>>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Rob;

Can you confirm the platform where you got those results?

Thanks,

Pedro.


----- Messaggio originale -----
> Da: Rob Weir <ro...@apache.org>
> A: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org>
> Cc: 
> Inviato: Giovedì 14 Febbraio 2013 16:47
> Oggetto: Re: Calc behavior: result of 0 ^ 0
> 
> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni <pf...@apache.org> wrote:
>> 
>> 
>>  ----- Messaggio originale -----
>>>  Da: Rob Weir
>> 
>>> 
>>>  And I should say that I'm happy to help if you or anyone else 
> wishes
>>>  to introduce a "warning mode" or "formula lint" or 
> similar  feature
>>>  that can be optionally enabled to check for possible inadvertent user
>>>  errors.
>>> 
>> 
>>  As the guys from the poisonous people video[1] said:
>> 
>>  "Patches Welcome"
>> 
> 
> Pedro, I reverted your patch.  It was broken in many ways.  It is sad
> that with the length of this thread that no one, apparently even you,
> tried to test it.  But I did and found:
> 
> 0^0 now returns a #VALUE! error in Calc, breaking compatibility.
> 
> 2^(1/3) which should be the cube root of 2 now returns 1.  This is
> mathematically incorrect and breaks compatibility.
> 
> 2^(-1/3) which should be the reciprocal of the cube root of 3 returns
> 1 with Pedro's changes.  This is mathematically incorrect and breaks
> compatibility.
> 
> -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
> returns 1 with Pedro's changes.  This is mathematically incorrect and
> breaks compatibility.
> 
> -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
> returns 1 with Pedro's changes.  This is mathematically incorrect and
> breaks compatibility.
> 
> -Rob
> 
>>  Pedro.
>> 
>>  [1]  http://www.youtube.com/watch?v=Q52kFL8zVoM
> 

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 4:47 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>>
>> ----- Messaggio originale -----
>>> Da: Rob Weir
>>
>>>
>>> And I should say that I'm happy to help if you or anyone else wishes
>>> to introduce a "warning mode" or "formula lint" or similar  feature
>>> that can be optionally enabled to check for possible inadvertent user
>>> errors.
>>>
>>
>> As the guys from the poisonous people video[1] said:
>>
>> "Patches Welcome"
>>
>
> Pedro, I reverted your patch.  It was broken in many ways.  It is sad
> that with the length of this thread that no one, apparently even you,
> tried to test it.  But I did and found:
>
> 0^0 now returns a #VALUE! error in Calc, breaking compatibility.
>

And I should mention that this would come up quite frequently, due to
the way Calc treats empty cells.  So if a user had a spreadsheet for
users to fill out and did: =a1^a2 and used that return in a
calculation, and initially had A1 and A2 blank for the user to fill
in, then before there was no error before the user entered data, but
now there is.  So it is essentially changing the UI of template
spreadsheets.

-Rob


> 2^(1/3) which should be the cube root of 2 now returns 1.  This is
> mathematically incorrect and breaks compatibility.
>
> 2^(-1/3) which should be the reciprocal of the cube root of 3 returns
> 1 with Pedro's changes.  This is mathematically incorrect and breaks
> compatibility.
>
> -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
> returns 1 with Pedro's changes.  This is mathematically incorrect and
> breaks compatibility.
>
> -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
> returns 1 with Pedro's changes.  This is mathematically incorrect and
> breaks compatibility.
>
> -Rob
>
>> Pedro.
>>
>> [1]  http://www.youtube.com/watch?v=Q52kFL8zVoM

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

On 16/02/2013 Hagar Delest wrote:
> I'm rather disappointed by the way it has been handled.

I agree it could have been better. There were also some unprecedented 
events, like a veto, and the discussion mixed in procedural elements, 
technical elements, folkloristic elements... And the tone of some 
messages should have been better. There are other threads open to 
discuss the generic handling, and I'm confident we will improve in future.

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sat, Feb 16, 2013 at 5:19 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 14/02/2013 23:34, Rob Weir a écrit :
>
>> In any case, I don't think anyone should care who reverts.  Once a
>> veto has been stated, the code needs to be reverted.  Who does it is a
>> matter of convenience.  Please don't be offended if someone else does
>> it.
>
>
> The vetoes were very poorly documented.
>
> Nobody has commented about Pedro's remark about the context of Bourbaki's
> work (this point being the most technical point of this whole topic).
> I've not taken the care to look at it (my maths lessons are rather old now).
> The question is: was the work presented applicable to real world or was it a
> custom maths space with a custom set of laws that would not fit the reality
> of a spreadsheet for real work?
>
> Even if the patch case is now closed, I'm rather disappointed by the way it
> has been handled. I can't see how this kind of behavior could attract new
> developers.
>
> Side question: we have see that the backward compatibility was the most
> important point here. What about a future improvement that would break the
> backward compatibility? Does it mean that it would be vetoed as well?
>

I don't think anyone can respond to a vague hypothetical.  But I would
recommend that anyone who wants to make "a future improvement that
would break the backward compatibility" propose it on the list first
and have the discussion first.  We might find out that it is not an
either/or situation, but that it is possible to both preserve
compatibility and improve.

-Rob

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 14/02/2013 23:34, Rob Weir a écrit :
> In any case, I don't think anyone should care who reverts.  Once a
> veto has been stated, the code needs to be reverted.  Who does it is a
> matter of convenience.  Please don't be offended if someone else does
> it.

The vetoes were very poorly documented.

Nobody has commented about Pedro's remark about the context of Bourbaki's work (this point being the most technical point of this whole topic).
I've not taken the care to look at it (my maths lessons are rather old now). The question is: was the work presented applicable to real world or was it a custom maths space with a custom set of laws that would not fit the reality of a spreadsheet for real work?

Even if the patch case is now closed, I'm rather disappointed by the way it has been handled. I can't see how this kind of behavior could attract new developers.

Side question: we have see that the backward compatibility was the most important point here. What about a future improvement that would break the backward compatibility? Does it mean that it would be vetoed as well?

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 5:18 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
>
>
> ----- Messaggio originale -----
>> Da: Rob Weir
>
>>
>> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>>
>>>
>>>  ----- Messaggio originale -----
>>>>  Da: Rob Weir
>>>
>>>>
>>>>  And I should say that I'm happy to help if you or anyone else
>> wishes
>>>>  to introduce a "warning mode" or "formula lint" or
>> similar  feature
>>>>  that can be optionally enabled to check for possible inadvertent user
>>>>  errors.
>>>>
>>>
>>>  As the guys from the poisonous people video[1] said:
>>>
>>>  "Patches Welcome"
>>>
>>
>> Pedro, I reverted your patch.  It was broken in many ways.  It is sad
>> that with the length of this thread that no one, apparently even you,
>> tried to test it.  But I did and found:
>>
>
> Now that I recall, I did indeed test that and had noticed some
> strange errors but I thought it may be related with my systems'
> libc (I am also an OS developer in my spare time).
>
>
>
>> 0^0 now returns a #VALUE! error in Calc, breaking compatibility.
>>
>> 2^(1/3) which should be the cube root of 2 now returns 1.  This is
>> mathematically incorrect and breaks compatibility.
>>
>> 2^(-1/3) which should be the reciprocal of the cube root of 3 returns
>> 1 with Pedro's changes.  This is mathematically incorrect and breaks
>> compatibility.
>>
>> -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
>> returns 1 with Pedro's changes.  This is mathematically incorrect and
>> breaks compatibility.
>>
>> -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
>> returns 1 with Pedro's changes.  This is mathematically incorrect and
>> breaks compatibility.
>>
>
> The last 4 values would've been sufficiently technical to cause the revert
> but I should be given the chance to revert it my self. in particular since
> the change in
>

Sorry, but I believed you when you stated emphatically that you would
not revert this patch:

https://issues.apache.org/ooo/show_bug.cgi?id=114430#c28

In any case, I don't think anyone should care who reverts.  Once a
veto has been stated, the code needs to be reverted.  Who does it is a
matter of convenience.  Please don't be offended if someone else does
it.

-Rob


> main/sc/source/core/inc/interpre.hxx
>
> were correct cleanups.
>
> Pedro.

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

----- Messaggio originale -----
> Da: Rob Weir 

> 
> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni <pf...@apache.org> wrote:
>> 
>> 
>>  ----- Messaggio originale -----
>>>  Da: Rob Weir
>> 
>>> 
>>>  And I should say that I'm happy to help if you or anyone else 
> wishes
>>>  to introduce a "warning mode" or "formula lint" or 
> similar  feature
>>>  that can be optionally enabled to check for possible inadvertent user
>>>  errors.
>>> 
>> 
>>  As the guys from the poisonous people video[1] said:
>> 
>>  "Patches Welcome"
>> 
> 
> Pedro, I reverted your patch.  It was broken in many ways.  It is sad
> that with the length of this thread that no one, apparently even you,
> tried to test it.  But I did and found:
> 

Now that I recall, I did indeed test that and had noticed some
strange errors but I thought it may be related with my systems'
libc (I am also an OS developer in my spare time).



> 0^0 now returns a #VALUE! error in Calc, breaking compatibility.
> 
> 2^(1/3) which should be the cube root of 2 now returns 1.  This is
> mathematically incorrect and breaks compatibility.
> 
> 2^(-1/3) which should be the reciprocal of the cube root of 3 returns
> 1 with Pedro's changes.  This is mathematically incorrect and breaks
> compatibility.
> 
> -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
> returns 1 with Pedro's changes.  This is mathematically incorrect and
> breaks compatibility.
> 
> -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
> returns 1 with Pedro's changes.  This is mathematically incorrect and
> breaks compatibility.
> 

The last 4 values would've been sufficiently technical to cause the revert
but I should be given the chance to revert it my self. in particular since
the change in

main/sc/source/core/inc/interpre.hxx 
 
were correct cleanups.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
> ----- Messaggio originale -----
>> Da: Rob Weir
>
>>
>> And I should say that I'm happy to help if you or anyone else wishes
>> to introduce a "warning mode" or "formula lint" or similar  feature
>> that can be optionally enabled to check for possible inadvertent user
>> errors.
>>
>
> As the guys from the poisonous people video[1] said:
>
> "Patches Welcome"
>

Pedro, I reverted your patch.  It was broken in many ways.  It is sad
that with the length of this thread that no one, apparently even you,
tried to test it.  But I did and found:

0^0 now returns a #VALUE! error in Calc, breaking compatibility.

2^(1/3) which should be the cube root of 2 now returns 1.  This is
mathematically incorrect and breaks compatibility.

2^(-1/3) which should be the reciprocal of the cube root of 3 returns
1 with Pedro's changes.  This is mathematically incorrect and breaks
compatibility.

-2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
returns 1 with Pedro's changes.  This is mathematically incorrect and
breaks compatibility.

-2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now
returns 1 with Pedro's changes.  This is mathematically incorrect and
breaks compatibility.

-Rob

> Pedro.
>
> [1]  http://www.youtube.com/watch?v=Q52kFL8zVoM

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

----- Messaggio originale -----
> Da: Rob Weir 

> 
> And I should say that I'm happy to help if you or anyone else wishes
> to introduce a "warning mode" or "formula lint" or similar  feature
> that can be optionally enabled to check for possible inadvertent user
> errors.
> 

As the guys from the poisonous people video[1] said:

"Patches Welcome"

Pedro.

[1]  http://www.youtube.com/watch?v=Q52kFL8zVoM

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 3:42 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>>
>> ----- Messaggio originale -----
>>> Da: Rob Weir
>> ...
>>>>
>>>>  OOo already has plenty of functions that give backwards
>>>>  incompatible results with previous versions of OOo and
>>>>  Symphony (which is rather crappy). atanh, asinh, erf,
>>>>  everything in SAL has needed continued revisions.
>>>>
>>>
>>> I have not seen anything that took a legitimate formula and changed it
>>> to an error.  I'm not ab absolutist.  I'm willing to consider changes
>>> at the 8th decimal points.  But not gross level breaks in
>>> compatibility.
>>>
>>
>> Please note that we don't return an error: this is not something that will cause
>> core dumps or affect stability: we return Not a Number (NaN), which is more
>> in line with the mathematical behavior of the real function and signals
>> the end user that he likely made has to revisit his formulation (all very good
>> IMHO).
>>
>> The distinction is important. I surely didn't introduce a bug.
>>
>>
>>>>>  Finally, treating 0^0 == 1 is very common in programming languages and
>>>>>  spreadsheets, being the value returned by OpenOffice since 1.0, as
>>>>>  well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java,
>>>>>  C, and .NET.  Anyone arguing that the value is incorrect faces a
>>>>>  mountain of contrary opinion and practice.
>>>>>
>>>>
>>>>  So far you have failed to produce an example of reasonable use where
>>>>  such incompatibility is evident.
>>>>
>>>
>>> For purposes of a veto I only need to show that I have a technical objection.
>>>
>>
>> And I don't see a valid technical objection, just different criteria.
>>
>> Now, it is probably not fair for me to judge if your technical objection
>> is valid or not. It surely doesn't fall within the common examples (
>> does not open a security exposure, negatively affects performance,
>> etc)
>>
>
> You have two vetos.  Are you going to revert or shall I do it for you?
>
> You are welcome to continue the discussion all you want, but that
> should be done with the change reverted first.
>

And I should say that I'm happy to help if you or anyone else wishes
to introduce a "warning mode" or "formula lint" or similar feature
that can be optionally enabled to check for possible inadvertent user
errors.

-Rob


> -Rob
>
>> There should probably be an objective judge for these things (the PMC?)
>> but it is not defined within the Apache procedures.
>>
>> Pedro.
>>

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
> ----- Messaggio originale -----
>> Da: Rob Weir
> ...
>>>
>>>  OOo already has plenty of functions that give backwards
>>>  incompatible results with previous versions of OOo and
>>>  Symphony (which is rather crappy). atanh, asinh, erf,
>>>  everything in SAL has needed continued revisions.
>>>
>>
>> I have not seen anything that took a legitimate formula and changed it
>> to an error.  I'm not ab absolutist.  I'm willing to consider changes
>> at the 8th decimal points.  But not gross level breaks in
>> compatibility.
>>
>
> Please note that we don't return an error: this is not something that will cause
> core dumps or affect stability: we return Not a Number (NaN), which is more
> in line with the mathematical behavior of the real function and signals
> the end user that he likely made has to revisit his formulation (all very good
> IMHO).
>
> The distinction is important. I surely didn't introduce a bug.
>
>
>>>>  Finally, treating 0^0 == 1 is very common in programming languages and
>>>>  spreadsheets, being the value returned by OpenOffice since 1.0, as
>>>>  well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java,
>>>>  C, and .NET.  Anyone arguing that the value is incorrect faces a
>>>>  mountain of contrary opinion and practice.
>>>>
>>>
>>>  So far you have failed to produce an example of reasonable use where
>>>  such incompatibility is evident.
>>>
>>
>> For purposes of a veto I only need to show that I have a technical objection.
>>
>
> And I don't see a valid technical objection, just different criteria.
>
> Now, it is probably not fair for me to judge if your technical objection
> is valid or not. It surely doesn't fall within the common examples (
> does not open a security exposure, negatively affects performance,
> etc)
>

You have two vetos.  Are you going to revert or shall I do it for you?

You are welcome to continue the discussion all you want, but that
should be done with the change reverted first.

-Rob

> There should probably be an objective judge for these things (the PMC?)
> but it is not defined within the Apache procedures.
>
> Pedro.
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

----- Messaggio originale -----
> Da: Rob Weir 
...
>> 
>>  OOo already has plenty of functions that give backwards
>>  incompatible results with previous versions of OOo and
>>  Symphony (which is rather crappy). atanh, asinh, erf,
>>  everything in SAL has needed continued revisions.
>> 
> 
> I have not seen anything that took a legitimate formula and changed it
> to an error.  I'm not ab absolutist.  I'm willing to consider changes
> at the 8th decimal points.  But not gross level breaks in
> compatibility.
>

Please note that we don't return an error: this is not something that will cause
core dumps or affect stability: we return Not a Number (NaN), which is more
in line with the mathematical behavior of the real function and signals
the end user that he likely made has to revisit his formulation (all very good
IMHO).

The distinction is important. I surely didn't introduce a bug.

  
>>>  Finally, treating 0^0 == 1 is very common in programming languages and
>>>  spreadsheets, being the value returned by OpenOffice since 1.0, as
>>>  well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java,
>>>  C, and .NET.  Anyone arguing that the value is incorrect faces a
>>>  mountain of contrary opinion and practice.
>>> 
>> 
>>  So far you have failed to produce an example of reasonable use where
>>  such incompatibility is evident.
>> 
> 
> For purposes of a veto I only need to show that I have a technical objection.
> 

And I don't see a valid technical objection, just different criteria.

Now, it is probably not fair for me to judge if your technical objection
is valid or not. It surely doesn't fall within the common examples (
does not open a security exposure, negatively affects performance,
etc)

There should probably be an objective judge for these things (the PMC?)
but it is not defined within the Apache procedures.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 2:58 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Man.. do I have to repeat everything again?
>
>
> ----- Messaggio originale -----
>> Da: Rob Weir <>
>> And so it is clear, my technical objection is:
>>
>> Backwards compatibility of spreadsheet documents, and calculations
>> specifically, is critical.  If AOO 4.0 returns results that are even a
>> penny different than earlier versions than this would be a severe
>> defect.  If we found such a defect even the day before a major release
>> we would probably treat it as a "stop ship" blocking issue.  Any
>> change that breaks backwards compatibility is a technical issue.
>>
>
> Breaking backwards compatibility is acceptable for 4.0 Release given
> that we are attempting to comply with a stricter standard. If it were
> prohibited to do such changes then other Apache Projects would be in
> big trouble: look at Apache Lucene:
>

I am not talking about backwards compatibility in general.  I am
talking specifically about spreadsheet formulas.  We have never had a
discussion, and certainly not consensus, about breaking spreadsheet
formula backwards compatibility for AOO 4.0.  If I am in error in
this, please point me to the thread.

> http://lucene.apache.org/core/4_1_0/changes/Changes.html
>

We are talking about spreadsheet formula evaluation in AOO 4,0.  I'm
not talking about Lucerne.

>
> The same number of compatibility-related changes than optimizations!
>
>
>> Fact:  Pedro's patch changes the results of spreadsheet calculations
>> in OpenOffice, introducing an error where there was not one before.
>>
>
> OOo already has plenty of functions that give backwards
> incompatible results with previous versions of OOo and
> Symphony (which is rather crappy). atanh, asinh, erf,
> everything in SAL has needed continued revisions.
>

I have not seen anything that took a legitimate formula and changed it
to an error.  I'm not ab absolutist.  I'm willing to consider changes
at the 8th decimal points.  But not gross level breaks in
compatibility.

>> Finally, treating 0^0 == 1 is very common in programming languages and
>> spreadsheets, being the value returned by OpenOffice since 1.0, as
>> well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java,
>> C, and .NET.  Anyone arguing that the value is incorrect faces a
>> mountain of contrary opinion and practice.
>>
>
> So far you have failed to produce an example of reasonable use where
> such incompatibility is evident.
>

For purposes of a veto I only need to show that I have a technical objection.

-Rob

> Oh, and Microsoft Excel, which holds a bigger market share than all the above
> mentioned alternatives is evidently buried within such mountain. :).
>
> Is this really the best you got? Why not take my offer and give it a two
> weeks thought? You may come up with something more elaborate.
>
> Pedro.

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Man.. do I have to repeat everything again?


----- Messaggio originale -----
> Da: Rob Weir <> 
> And so it is clear, my technical objection is:
> 
> Backwards compatibility of spreadsheet documents, and calculations
> specifically, is critical.  If AOO 4.0 returns results that are even a
> penny different than earlier versions than this would be a severe
> defect.  If we found such a defect even the day before a major release
> we would probably treat it as a "stop ship" blocking issue.  Any
> change that breaks backwards compatibility is a technical issue.
> 

Breaking backwards compatibility is acceptable for 4.0 Release given
that we are attempting to comply with a stricter standard. If it were
prohibited to do such changes then other Apache Projects would be in
big trouble: look at Apache Lucene:

http://lucene.apache.org/core/4_1_0/changes/Changes.html


The same number of compatibility-related changes than optimizations!


> Fact:  Pedro's patch changes the results of spreadsheet calculations
> in OpenOffice, introducing an error where there was not one before.
> 

OOo already has plenty of functions that give backwards
incompatible results with previous versions of OOo and
Symphony (which is rather crappy). atanh, asinh, erf,
everything in SAL has needed continued revisions.

> Finally, treating 0^0 == 1 is very common in programming languages and
> spreadsheets, being the value returned by OpenOffice since 1.0, as
> well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java,
> C, and .NET.  Anyone arguing that the value is incorrect faces a
> mountain of contrary opinion and practice.
> 

So far you have failed to produce an example of reasonable use where
such incompatibility is evident.

Oh, and Microsoft Excel, which holds a bigger market share than all the above
mentioned alternatives is evidently buried within such mountain. :).

Is this really the best you got? Why not take my offer and give it a two
weeks thought? You may come up with something more elaborate.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 1:58 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Thu, Feb 14, 2013 at 5:49 AM, Andrea Pescetti <pe...@apache.org>wrote:
>
>> Rob Weir wrote:
>>
>>  On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote:
>>>
>>>> Fine. I would have started the vote earlier, but it's your code so I'll
>>>> respect your choice. And it's good to give people more time to think
>>>> (not to
>>>>
>>> We had a committer veto.  Why are having a vote?  A -1 from a
>>> commmitter is not something we vote on.
>>>
>>
>> Vetos must be based on technical grounds and can be withdrawn, see
>> http://www.apache.org/**foundation/voting.html#Veto<http://www.apache.org/foundation/voting.html#Veto>
>> (no, I haven't seen a clearly stated "technical ground" in Kay's mail).
>> Due to the exceptional amount of posts in this thread, a proper vote is now
>> the clearest way out, and in case of opposition it will allow to record
>> clearly what the technical reason was.
>
>
> I readily admit this is true. I would like my veto to stand and here I will
> elaborate and hopefully provide my technical justification.
>
> In my mind, current mathematical information aside, we have implemented an
> acceptable solution based on the ODF specification. If, at some point, some
> universal mathematical body says without doubt that 0^0 should never ever
> be considered 1, then I am assuming the ODF standards body would change the
> standard for that function, and we would then change the current
> calculation.
>
> I have seen many references to this "issue" on the web, some which support
> the current implementation, some of which do not. In my mind, this needs to
> go back to OASIS.
>
> So for what it's worth, this is my technical justification. We are not a
> mathematical body, we are implementing code that complies to the ODF
> standard.
>
> If "we" have a problem with that standard, "we" need to discuss it with the
> standards body, not change existing code because of a personal viewpoint.
>

And so it is clear, my technical objection is:

Backwards compatibility of spreadsheet documents, and calculations
specifically, is critical.  If AOO 4.0 returns results that are even a
penny different than earlier versions than this would be a severe
defect.  If we found such a defect even the day before a major release
we would probably treat it as a "stop ship" blocking issue.  Any
change that breaks backwards compatibility is a technical issue.

Fact:  Pedro's patch changes the results of spreadsheet calculations
in OpenOffice, introducing an error where there was not one before.

Finally, treating 0^0 == 1 is very common in programming languages and
spreadsheets, being the value returned by OpenOffice since 1.0, as
well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java,
C, and .NET.  Anyone arguing that the value is incorrect faces a
mountain of contrary opinion and practice.

Regards,

-Rob

>
>>
>>  The patch needs to be reverted, now.
>>>
>>
>> Please do not go on and revert it now, and please do not escalate the
>> problem again (this friendly advice applies to Pedro too). It is a trivial
>> issue, with no side effects on the rest of the code, and it will be quickly
>> solved by voting (where a -1 from a committer with a clearly stated
>> "technical ground" counts as veto) well before a release, or even a beta
>> version, containing it is distributed.
>>
>> Overstating the problem or insisting on this, no longer fruitful,
>> discussion would only drain resources from more important topics. I
>> recommend that we put community over code, suspend this discussion, take a
>> final vote when Pedro calls it and respect its outcome, whatever it is.
>>
>> Regards,
>>   Andrea.
>>
>
>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> "A great deal of talent is lost to the world
>       for want of a little courage."
>                              -- Sydney Smith

Re: Calc behavior: result of 0 ^ 0

[Kay Schenk <ka...@gmail.com>]

On Thu, Feb 14, 2013 at 5:49 AM, Andrea Pescetti <pe...@apache.org>wrote:

> Rob Weir wrote:
>
>  On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote:
>>
>>> Fine. I would have started the vote earlier, but it's your code so I'll
>>> respect your choice. And it's good to give people more time to think
>>> (not to
>>>
>> We had a committer veto.  Why are having a vote?  A -1 from a
>> commmitter is not something we vote on.
>>
>
> Vetos must be based on technical grounds and can be withdrawn, see
> http://www.apache.org/**foundation/voting.html#Veto<http://www.apache.org/foundation/voting.html#Veto>
> (no, I haven't seen a clearly stated "technical ground" in Kay's mail).
> Due to the exceptional amount of posts in this thread, a proper vote is now
> the clearest way out, and in case of opposition it will allow to record
> clearly what the technical reason was.


I readily admit this is true. I would like my veto to stand and here I will
elaborate and hopefully provide my technical justification.

In my mind, current mathematical information aside, we have implemented an
acceptable solution based on the ODF specification. If, at some point, some
universal mathematical body says without doubt that 0^0 should never ever
be considered 1, then I am assuming the ODF standards body would change the
standard for that function, and we would then change the current
calculation.

I have seen many references to this "issue" on the web, some which support
the current implementation, some of which do not. In my mind, this needs to
go back to OASIS.

So for what it's worth, this is my technical justification. We are not a
mathematical body, we are implementing code that complies to the ODF
standard.

If "we" have a problem with that standard, "we" need to discuss it with the
standards body, not change existing code because of a personal viewpoint.


>
>  The patch needs to be reverted, now.
>>
>
> Please do not go on and revert it now, and please do not escalate the
> problem again (this friendly advice applies to Pedro too). It is a trivial
> issue, with no side effects on the rest of the code, and it will be quickly
> solved by voting (where a -1 from a committer with a clearly stated
> "technical ground" counts as veto) well before a release, or even a beta
> version, containing it is distributed.
>
> Overstating the problem or insisting on this, no longer fruitful,
> discussion would only drain resources from more important topics. I
> recommend that we put community over code, suspend this discussion, take a
> final vote when Pedro calls it and respect its outcome, whatever it is.
>
> Regards,
>   Andrea.
>



-- 
----------------------------------------------------------------------------------------
MzK

"A great deal of talent is lost to the world
      for want of a little courage."
                             -- Sydney Smith

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Hi Juergen;


----- Messaggio originale -----
> Da: Jürgen Schmidt
...
>> 
> And to be honest the technical ground for the veto is in this thread,
> especially Norbert's mail.
> 

As I replied to Norbert's email: the quote was taken out of context:
the definition applies to some special purpose algebra in an invented
set that has no connection to the regular math in a spreadsheet.

In all honesty, the discussion about the correct value that should
be assigned to 0 ^ 0 is in discussion since at least 1834 and is
apparently not going to be solved in this list :).

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

On 02/14/2013 09:29 AM, Jürgen Schmidt wrote:
> On 2/14/13 2:49 PM, Andrea Pescetti wrote:
>> Rob Weir wrote:
>>> On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote:
>>>> Fine. I would have started the vote earlier, but it's your code so I'll
>>>> respect your choice. And it's good to give people more time to think
>>>> (not to
>>> We had a committer veto.  Why are having a vote?  A -1 from a
>>> commmitter is not something we vote on.
>> Vetos must be based on technical grounds and can be withdrawn, see
>> http://www.apache.org/foundation/voting.html#Veto
>> (no, I haven't seen a clearly stated "technical ground" in Kay's mail).
>> Due to the exceptional amount of posts in this thread, a proper vote is
>> now the clearest way out, and in case of opposition it will allow to
>> record clearly what the technical reason was.
>>
>>> The patch needs to be reverted, now.
>> Please do not go on and revert it now, and please do not escalate the
>> problem again (this friendly advice applies to Pedro too). It is a
>> trivial issue, with no side effects on the rest of the code, and it will
>> be quickly solved by voting (where a -1 from a committer with a clearly
>> stated "technical ground" counts as veto) well before a release, or even
>> a beta version, containing it is distributed.
>>
>> Overstating the problem or insisting on this, no longer fruitful,
>> discussion would only drain resources from more important topics. I
>> recommend that we put community over code, suspend this discussion, take
>> a final vote when Pedro calls it and respect its outcome, whatever it is.
>>
> independent of this thread and just for completeness
>
> see http://www.apache.org/foundation/glossary.html#Veto
>
> "According to the Apache methodology, a change which has been made or
> proposed may be made moot through the exercise of a veto by a committer
> to the codebase in question. If the R-T-C commit policy is in effect, a
> veto prevents the change from being made. In either the R-T-C or C-T-R
> environments, a veto applied to a change that has already been made
> forces it to be reverted. Vetos may not be overridden nor voted down,
> and only cease to apply when the committer who issued the veto withdraws
> it. All vetos must be accompanied by a valid technical justification; a
> veto without such a justification is invalid. Vetos only apply to code
> changes; they do not apply to procedural issues such as software releases."
>
> And to be honest the technical ground for the veto is in this thread,
> especially Norbert's mail.
>
> Juergen
Thanks, this is very instructive for me!

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Jürgen Schmidt <jo...@gmail.com>]

On 2/14/13 2:49 PM, Andrea Pescetti wrote:
> Rob Weir wrote:
>> On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote:
>>> Fine. I would have started the vote earlier, but it's your code so I'll
>>> respect your choice. And it's good to give people more time to think
>>> (not to
>> We had a committer veto.  Why are having a vote?  A -1 from a
>> commmitter is not something we vote on.
> 
> Vetos must be based on technical grounds and can be withdrawn, see
> http://www.apache.org/foundation/voting.html#Veto
> (no, I haven't seen a clearly stated "technical ground" in Kay's mail).
> Due to the exceptional amount of posts in this thread, a proper vote is
> now the clearest way out, and in case of opposition it will allow to
> record clearly what the technical reason was.
> 
>> The patch needs to be reverted, now.
> 
> Please do not go on and revert it now, and please do not escalate the
> problem again (this friendly advice applies to Pedro too). It is a
> trivial issue, with no side effects on the rest of the code, and it will
> be quickly solved by voting (where a -1 from a committer with a clearly
> stated "technical ground" counts as veto) well before a release, or even
> a beta version, containing it is distributed.
> 
> Overstating the problem or insisting on this, no longer fruitful,
> discussion would only drain resources from more important topics. I
> recommend that we put community over code, suspend this discussion, take
> a final vote when Pedro calls it and respect its outcome, whatever it is.
> 

independent of this thread and just for completeness

see http://www.apache.org/foundation/glossary.html#Veto

"According to the Apache methodology, a change which has been made or
proposed may be made moot through the exercise of a veto by a committer
to the codebase in question. If the R-T-C commit policy is in effect, a
veto prevents the change from being made. In either the R-T-C or C-T-R
environments, a veto applied to a change that has already been made
forces it to be reverted. Vetos may not be overridden nor voted down,
and only cease to apply when the committer who issued the veto withdraws
it. All vetos must be accompanied by a valid technical justification; a
veto without such a justification is invalid. Vetos only apply to code
changes; they do not apply to procedural issues such as software releases."

And to be honest the technical ground for the veto is in this thread,
especially Norbert's mail.

Juergen

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

Rob Weir wrote:
> On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote:
>> Fine. I would have started the vote earlier, but it's your code so I'll
>> respect your choice. And it's good to give people more time to think (not to
> We had a committer veto.  Why are having a vote?  A -1 from a
> commmitter is not something we vote on.

Vetos must be based on technical grounds and can be withdrawn, see
http://www.apache.org/foundation/voting.html#Veto
(no, I haven't seen a clearly stated "technical ground" in Kay's mail). 
Due to the exceptional amount of posts in this thread, a proper vote is 
now the clearest way out, and in case of opposition it will allow to 
record clearly what the technical reason was.

> The patch needs to be reverted, now.

Please do not go on and revert it now, and please do not escalate the 
problem again (this friendly advice applies to Pedro too). It is a 
trivial issue, with no side effects on the rest of the code, and it will 
be quickly solved by voting (where a -1 from a committer with a clearly 
stated "technical ground" counts as veto) well before a release, or even 
a beta version, containing it is distributed.

Overstating the problem or insisting on this, no longer fruitful, 
discussion would only drain resources from more important topics. I 
recommend that we put community over code, suspend this discussion, take 
a final vote when Pedro calls it and respect its outcome, whatever it is.

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

On 02/14/2013 07:52 AM, Rob Weir wrote:
>
> We had a committer veto.  Why are having a vote?  A -1 from a
> commmitter is not something we vote on.  The patch needs to be
> reverted, now.
I thought he said he vetoed it and it would be voted on later.

I was not aware that any committer could veto any other comitter. 
Interesting.

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

----- Messaggio originale -----
> Da: Rob Weir 
.--
> 
> We had a committer veto.  Why are having a vote?  A -1 from a
> commmitter is not something we vote on.  The patch needs to be
> reverted, now.
>

We actually have two *invalid* vetos

I recall you aduced the change is not backwards compatible.

Backwards compatibility is not a requirement for 4.0 release,
especially in this case since we are trying to comply with a
stricter standard. (Plus you added a section for backwards
incompatible changes in the Release notes, so I guess
you know it is OK).

http://www.apache.org/foundation/voting.html


"To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc. ). A veto without a justification is invalid and has no weight."



So you have two weeks to look for a valid technical justification:


Pedro.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti <pe...@apache.org> wrote:
> On 13/02/2013 Pedro Giffuni wrote:
>>
>> I will ask everyone to take a break for two weeks before starting the
>> voting procedure for this.
>
>
> Fine. I would have started the vote earlier, but it's your code so I'll
> respect your choice. And it's good to give people more time to think (not to


We had a committer veto.  Why are having a vote?  A -1 from a
commmitter is not something we vote on.  The patch needs to be
reverted, now.

-Rob

> write!) about the impact of this change, which can perfectly stay in daily
> builds at the moment... maybe someone will find more significant examples of
> spreadsheets relying on the result of 0 ^ 0.
>
> I won't reply to recent discussions on this thread since the point is not to
> explain to people what "implementation-defined" means or investigate what
> the several branches of mathematics use.
>
>
>> Independently of the vote result I will be effectively stopping the
>> development work I intended to do on Calc as I have lost all
>> interest on improving it given the current situation.
>
>
> This is sad, but understandable. Anyway, as Juergen clarified, contributions
> are always welcome; it is really rare that code (assuming that people who
> posted to this thread did read the code...) gets this level of public
> discussion and most of the proposed improvements should be uncontroversial,
> so when you feel like to hack on Calc again just do it (sending a note here
> before any backwards-incompatible changes) and everybody will be happy,
> hopefully!
>
> Regards,
>   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

On 13/02/2013 Pedro Giffuni wrote:
> I will ask everyone to take a break for two weeks before starting the
> voting procedure for this.

Fine. I would have started the vote earlier, but it's your code so I'll 
respect your choice. And it's good to give people more time to think 
(not to write!) about the impact of this change, which can perfectly 
stay in daily builds at the moment... maybe someone will find more 
significant examples of spreadsheets relying on the result of 0 ^ 0.

I won't reply to recent discussions on this thread since the point is 
not to explain to people what "implementation-defined" means or 
investigate what the several branches of mathematics use.

> Independently of the vote result I will be effectively stopping the
> development work I intended to do on Calc as I have lost all
> interest on improving it given the current situation.

This is sad, but understandable. Anyway, as Juergen clarified, 
contributions are always welcome; it is really rare that code (assuming 
that people who posted to this thread did read the code...) gets this 
level of public discussion and most of the proposed improvements should 
be uncontroversial, so when you feel like to hack on Calc again just do 
it (sending a note here before any backwards-incompatible changes) and 
everybody will be happy, hopefully!

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

----- Messaggio originale -----
> Da: Andrew Douglas Pitonyak 
...
> 
> 
> On 02/13/2013 02:46 PM, Pedro Giffuni wrote:
>>  Independently of the vote result I will be effectively stopping the
>>  development work I intended to do on Calc as I have lost all
>>  interest on improving it given the current situation.
> I totally understand.
> 

It is sort of sad as I think Calc can certainly be improved with
a lot of the things that are finely implemented in Boost.

On the other hand, most of what I was planning to do is
already in gnumeric, so maybe it was a waste of my time
to re-implement it ;).

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Hello Juergen;

----- Messaggio originale -----
> Da: Jürgen Schmidt 

> 
> On 2/14/13 2:29 AM, Andrew Douglas Pitonyak wrote:
>> 
>>  On 02/13/2013 02:46 PM, Pedro Giffuni wrote:
>>>  Independently of the vote result I will be effectively stopping the
>>>  development work I intended to do on Calc as I have lost all
>>>  interest on improving it given the current situation.
>>  I totally understand.
>> 
> 
> I don't understand it. You are doing great work and the project
> appreciate what you are doing.
> Now a fix you have made is controversial which is understandable when
> taking the discussion into account. We have an old behaviour which is ok
> from the spec and we have a new one which is also ok from the spec
> perspective. You prefer the new one which reflect your fix, which is
> fine. Others see a potential risk to break backward compatibility which
> is fine as well. By the way I have personally no preference here ;-)
> 

First of all, I am not stopping from doing other changes in less controversial
areas ... updating python to the final 2.7.4 version of fixing the java7 build
seem to be reasonable uncontroversial and necessary tasks.

The work I was planning to do on Calc involved a much deeper revision
on how math is done. The idea was only sketched in some of the patches
I left in Bugzilla and meant:

- Replacing the native implementations of most functionality with the
Boost counterparts.
- Implementation of new functionality: including more complex functions,
better statistics support and several random functions in line with what
gnumeric does.

Now, this meant quite an investment of my time to ensure that we move
from something that works acceptably well to something that works
better.

This small change that caused the bikeshed is in those same lines:
the POWER function we have works, but it can be better. As it is
now POWER (x, 0) is a no-op (always 1), in my enhancement it
regains it's mathematical value. This particular change had to be
done only before a major release or not done at all.


> Now it is our responsibility to find consensus for the solution we want
> support in the future. Many opinions and less who are doing the work,
> not really surprising and a general problem of such a big project. But
> we need to find consensus.
>

The thing is, and it is, I suppose, normal in any project, that I was
willing to the work, I am not willing to spend time on the bikeshed
part of it: mathematics is not something that should be left for
democracy. 

  
> I am sure you would accept the result of vote (if necessary when no
> consensus can be found) but at the same time you say that you will stop
> all your intended work in this area. And that is something that I don't
> understand. Well it's your decision and you can do what you want but is
> this the right approach? I believe not.
> 


I am OK with losing the vote: for all purposes people won't even notice the
effect of the change. The lack of consensus is worrying though. It is a clear
signal that work on Calc is not really welcome without an incredibly expensive
discussion process and my time for such things is really limited nowadays.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Jürgen Schmidt <jo...@gmail.com>]

On 2/14/13 2:29 AM, Andrew Douglas Pitonyak wrote:
> 
> On 02/13/2013 02:46 PM, Pedro Giffuni wrote:
>> Independently of the vote result I will be effectively stopping the
>> development work I intended to do on Calc as I have lost all
>> interest on improving it given the current situation.
> I totally understand.
> 

I don't understand it. You are doing great work and the project
appreciate what you are doing.
Now a fix you have made is controversial which is understandable when
taking the discussion into account. We have an old behaviour which is ok
from the spec and we have a new one which is also ok from the spec
perspective. You prefer the new one which reflect your fix, which is
fine. Others see a potential risk to break backward compatibility which
is fine as well. By the way I have personally no preference here ;-)

Now it is our responsibility to find consensus for the solution we want
support in the future. Many opinions and less who are doing the work,
not really surprising and a general problem of such a big project. But
we need to find consensus.

I am sure you would accept the result of vote (if necessary when no
consensus can be found) but at the same time you say that you will stop
all your intended work in this area. And that is something that I don't
understand. Well it's your decision and you can do what you want but is
this the right approach? I believe not.

I believe we should listen to each other and should at least try to
understand and accept other opinions. And fixes which have a direct
influence to our users are always special.

I learned it as well in the last weeks when discussion about
incompatible API/config changes came up that were long discussed and
planned and where people starting now to understand what it really
means. I still believe we need such changes but the way how we introduce
them is important. In this special case I believe we still have time to
inform extension developers and show the easy migration path.

We all have to learn that changes can result in controversial discussion
where at the end a decision have to be made (by vote if necessary but
not preferred). I know for sure that I will hate it if something that I
drive and where I do the work will be blocked mainly by people who
prefer talking. But I have to learn to accept it and will do my best.
Otherwise we will fail to move this project forward.

So please continue your work and discuss the changes on the dev list as
you did of course. And we all should try to give feedback early to any
kind of proposed change from anybody to find consensus early before the
work is done.

Sorry, a little bit off topic from the thread.

Juergen

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

On 02/13/2013 02:46 PM, Pedro Giffuni wrote:
> Independently of the vote result I will be effectively stopping the
> development work I intended to do on Calc as I have lost all
> interest on improving it given the current situation.
I totally understand.

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

>
> Da: Kay Schenk 
...
>
>On Wed, Feb 13, 2013 at 9:30 AM, Rob Weir <ro...@apache.org> wrote:
>
>> On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer <jo...@yahoo.com>
>> wrote:
>> > OTOH I haven't seen anyone issue a technical
>> > veto on this change, which is really what's
>> > required before Pedro actually needs to revert
>> > anything.
>> >
>>
>> I was waiting to see if there were any persuasive arguments in favor
>> of breaking backwards compatibility before deciding whether to do
>> that.  I think things are getting a little clearer now with Norbert's
>> contribution to the discussion.  But if (as it seems now) that
>> "mathematical correctness" does not justify the change, then my
>> position would be that we don't break backwards compatibility.
>>
>> Also, a veto would be a blunt instrument and I'd rather avoid it if
>> further discussion leads to a consensus.
>>
>> -Rob
>>
>
>Given this discussion and research I've done on my own, I will veto this
>change and would like to see it reverted. Sorry, Pedro!  and thanks you
>Norbert and others for this worthy discussion.
>

Well, it admittedly comes as a surprise to me that there is such a huge
resistance to change without some real argumentation.

I will ask everyone to take a break for two weeks before starting the
voting procedure for this.

Independently of the vote result I will be effectively stopping the
development work I intended to do on Calc as I have lost all
interest on improving it given the current situation.

Pedro.

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Rob Weir <ro...@apache.org>]

On Sun, Feb 17, 2013 at 7:15 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hello;
>
>
> Well, as you might imagine I am really tired of the flame storm that
> went around the 0 ^ 0 issue. My intention here is not at all to re-start
> that discussion. I really have much more fun things to do.
> I am actualy a fan of Clint Eastwood so let me remember one of
> my favorite movies ever.
>
> THE GOOD
>
> It didn't really take me long but I found a technical solution for the
> dilemma.
>
> - The numerical issues were caused by a copy-paste error where the
> C++ wrapper used int for the exponent instead of a double. Once
> found it was trivial to fix.
>
> - Considering the "vetos" I still think they are invalid but I think they
> both reflect a community concern so I have addressed it.
>
> The new patch [1] now defines in SAL's math.h the following:
>
> #define SAL_STRICTER_MATH
>

Take out that #define and I think it would be fine.  Then if you want
to change the default behavior in your builds you can.  But the
default behavior remains compatible with existing OpenOffice,
LibreOffice and Symphony documents.

But my veto remains on any attempt to change this particular behavior
in AOO, no matter how many levels of indirection you wrap it in.

-Rob

>
> This currently only affects the power function and acts as a
> sort of "excel compatibility" flag. This is very simple at this time
> but it fulfills it's task: you can easily change the behaviour
> during compile time.
>
> It is actually an advance because having this in SAL gives us control:
> our current behavior is platform dependent.
>
> THE UGLY
>
> The discussion so far has been centered around the default. I
> consider myself agnostic in this case: I think that it is better
> to use the stricter criteria and be compatible with MS Excel.
> A lot of people worry about compatibility issues.
>
> With my FreeBSD hat on, I think in the unsupported platforms
> (FreeBSD, OS2, Solaris) the compatibility issue isn't really a
> concern (the ASF has never provided officially binaries) but
> the Excel behaviour is useful for interoperability.
>
> I think the best option would be if existing users take a decision
> before release what behaviour the want and if the case is to revert
> we can add something like
>
> #if defined(WINOS) || defined(MACOSX) || defined(LINUX)
> #defined SAL_STRICTER_MATH
> #endif
>
> You get the idea. Doing this is rather ugly but I can live with it as
> at least windows and MacOSX have the option to use Excel if they
> want to be serious about math.
>
> I guess we could add it as a configure option but we already have
> too many of them and even then there has to be a default.
>
> This is something I think the comunity has to decide on by voting
> before the release. I won't take the decision but since I take care
> for FreeBSD, I think we will opt for the Excel compatibility (I do
> have to consult with Maho though).
>
> THE BAD
>
> (Please stop reading here if you are sensible to non-technical issues)
>
> First I should thank Greg Stein for clarifying the correct sense and reach
> of the veto. I also want to thank people that have expressed their support
> in private or public. It is clear to me that we are still too young as a community
> in AOO and that people still have a long way to learn in matters of behaviour.
>
> I am not as much disappointed by the discussion (which I think
> doesn't correspond to the impact of the patch) but by the fact that
> I was not given the chance to work on it and that I have been
> insulted in the process.
>
> I strongly complained when Dave's commit was reverted and I find
> it absolutely unacceptable in the way it was done with me. First
> of all the harassment: I am a volunteer, I am not here to receive
> something in the lines of "Revert now or else ...", and second the
> lack of respect for my work.
>
> It *is* rude, really ... I *don't* care much what happens with the patch,
> if it should be disabled or not, but I DO want respect.
>
> I think I deserve reparation for the commit reversal: this shouldn't have
> happened. I request the code be restated as it should have never been
> reverted in the first place. This is all symbolical as there is a new version.
> Once the new version is in, I will let anyone else decide if you guys
> want to ifdef it or add a configure option or whatever: I don't really want
> to be involved in this anymore.
>
>
> I also want an assurance that this will never *ever* happen again (I am
> talking about the revert, I guess bikesheds are unavoidable).
>
> If people really don't like my patches (yes, according to the Berne convention
> I do own them)  I will take them with me but I prefer if there is a civilized
> discussion and not this circus we have been experiencing these last days.
>
> Pedro.
>
> [1] http://people.apache.org/~pfg/patches/patch-power00

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[janI <ja...@apache.org>]

On Feb 18, 2013 1:16 AM, "Pedro Giffuni" <pf...@apache.org> wrote:
>
> Hello;
>
>
> Well, as you might imagine I am really tired of the flame storm that
> went around the 0 ^ 0 issue. My intention here is not at all to re-start
> that discussion. I really have much more fun things to do.
> I am actualy a fan of Clint Eastwood so let me remember one of
> my favorite movies ever.
>
> THE GOOD
>
> It didn't really take me long but I found a technical solution for the
> dilemma.
>
> - The numerical issues were caused by a copy-paste error where the
> C++ wrapper used int for the exponent instead of a double. Once
> found it was trivial to fix.
>
> - Considering the "vetos" I still think they are invalid but I think they
> both reflect a community concern so I have addressed it.
>
> The new patch [1] now defines in SAL's math.h the following:
>
> #define SAL_STRICTER_MATH
>
+1 thanks for doing this. It shows flexibility and respect for the
community.

Now I hope, that some of those who have a profund knowledge of "backward
compatility" also see a need to move a little bit.

It would be very respectfull to have a tool to which the information was
shared.

I hope someone with knowledge makes a mwiki page with docs. procedures to
test compatibility, that way we can discuss facts and not just words.

rgds
jan i

>
> This currently only affects the power function and acts as a
> sort of "excel compatibility" flag. This is very simple at this time
> but it fulfills it's task: you can easily change the behaviour
> during compile time.
>
> It is actually an advance because having this in SAL gives us control:
> our current behavior is platform dependent.
>
> THE UGLY
>
> The discussion so far has been centered around the default. I
> consider myself agnostic in this case: I think that it is better
> to use the stricter criteria and be compatible with MS Excel.
> A lot of people worry about compatibility issues.
>
> With my FreeBSD hat on, I think in the unsupported platforms
> (FreeBSD, OS2, Solaris) the compatibility issue isn't really a
> concern (the ASF has never provided officially binaries) but
> the Excel behaviour is useful for interoperability.
>
> I think the best option would be if existing users take a decision
> before release what behaviour the want and if the case is to revert
> we can add something like
>
> #if defined(WINOS) || defined(MACOSX) || defined(LINUX)
> #defined SAL_STRICTER_MATH
> #endif
>
> You get the idea. Doing this is rather ugly but I can live with it as
> at least windows and MacOSX have the option to use Excel if they
> want to be serious about math.
>
> I guess we could add it as a configure option but we already have
> too many of them and even then there has to be a default.
>
> This is something I think the comunity has to decide on by voting
> before the release. I won't take the decision but since I take care
> for FreeBSD, I think we will opt for the Excel compatibility (I do
> have to consult with Maho though).
>
> THE BAD
>
> (Please stop reading here if you are sensible to non-technical issues)
>
> First I should thank Greg Stein for clarifying the correct sense and reach
> of the veto. I also want to thank people that have expressed their support
> in private or public. It is clear to me that we are still too young as a
community
> in AOO and that people still have a long way to learn in matters of
behaviour.
>
> I am not as much disappointed by the discussion (which I think
> doesn't correspond to the impact of the patch) but by the fact that
> I was not given the chance to work on it and that I have been
> insulted in the process.
>
> I strongly complained when Dave's commit was reverted and I find
> it absolutely unacceptable in the way it was done with me. First
> of all the harassment: I am a volunteer, I am not here to receive
> something in the lines of "Revert now or else ...", and second the
> lack of respect for my work.
>
> It *is* rude, really ... I *don't* care much what happens with the patch,
> if it should be disabled or not, but I DO want respect.
>
> I think I deserve reparation for the commit reversal: this shouldn't have
> happened. I request the code be restated as it should have never been
> reverted in the first place. This is all symbolical as there is a new
version.
> Once the new version is in, I will let anyone else decide if you guys
> want to ifdef it or add a configure option or whatever: I don't really
want
> to be involved in this anymore.
>
>
> I also want an assurance that this will never *ever* happen again (I am
> talking about the revert, I guess bikesheds are unavoidable).
>
> If people really don't like my patches (yes, according to the Berne
convention
> I do own them)  I will take them with me but I prefer if there is a
civilized
> discussion and not this circus we have been experiencing these last days.
>
> Pedro.
>
> [1] http://people.apache.org/~pfg/patches/patch-power00

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Rob Weir <ro...@apache.org>]

On Wed, Feb 20, 2013 at 6:10 PM, Dennis E. Hamilton <or...@apache.org> wrote:
> Ah, very good.  Yes I see Normative Appendix F in ISO/IEC 9899:1999 (C99), along with
>
> "An implementation that defines _ _STDC_IEC_559_ _ shall conform to the specifications
>  in this annex. Where a binding between the C language and IEC 60559 is indicated,
>  the IEC 60559-specified behavior is adopted by reference, unless stated otherwise."
>  [section F.1]
>
> which is, of course, why it is not bolted into the main text of the standard.
>
> This carries through to ISO/IEC 9899:2011.
>
> Thanks for connecting that particular dot,
>

I don't know the background story on this, but it seems almost like a
"profile".  There is the core conformance clauses, in which some
things are implementation-defined, and then this additional annex
which profiles the requirements of the specification for use with
IEEE-conforming floating point processors.  So it tightens the
requirements.  Of course, one could claim conformance with or without
the Annex F requirements.

For traditional desktop use of AOO, I bet the Annex describes the
relevant set of requirements.  But down the road there are two areas
that might make this less certain:  1) mobile devices and 2) GPU's.
I'm not sure that IEEE 754 is guaranteed in those cases.    But if we
ever support those kinds of processors then we'll have bigger
headaches to worry about ;-)

Regards,

-Rob

>  - Dennis
>
> PS: There is no counterpart of Appendix F in ISO/IEC 14882:1998 (C++) nor ISO/IEC 14882:2003 and ISO/IEC 14882:2011.  I assume this is because C++ has the numeric_limits class to account for the variations in implementations without any mention of IEC 60559 (or the IEEE counterpart on which it derives).  Also, these rely on a variable is_iec559 and specify a number of numeric_limits conditionally on iec559 != false.  The declaration of conformance to IEC [60]559 (IEEE 754) does not make any of the exceptions that are in ISO C Appendix F.
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Wednesday, February 20, 2013 14:08
> To: dev@openoffice.apache.org; orcmid@apache.org
> Subject: Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
>
> On Wed, Feb 20, 2013 at 4:37 PM, Dennis E. Hamilton <or...@apache.org> wrote:
>> I earlier quoted the applicable (and only) texts from the Standards themselves, particularly C++ and also the latest C Standard (2011 and C99 with all Technical Corrigenda through 2007).
>>
>> No matter what is said about pow(0,0) in the C99 Rationale v5.10 Appendix F of April 2003, there are no such requirements in the Standards, including those versions that have been adopted since 2003.
>>
>>  - Dennis
>>
> [ ... ]
>
> In other words, C99, in a normative Annex F, section 9.4.4, for
> implementations that conform to IEEE 754 floating point, says:
>
> "pow(x, ±0) returns 1 for any x, even a NaN."
>
> Do you see something different?
>
> I'd like to make sure we're seeing the same thing here.
>
> -Rob
>
>
> [ ... ]
>

RE: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

["Dennis E. Hamilton" <or...@apache.org>]

Ah, very good.  Yes I see Normative Appendix F in ISO/IEC 9899:1999 (C99), along with

"An implementation that defines _ _STDC_IEC_559_ _ shall conform to the specifications 
 in this annex. Where a binding between the C language and IEC 60559 is indicated, 
 the IEC 60559-specified behavior is adopted by reference, unless stated otherwise."
 [section F.1]

which is, of course, why it is not bolted into the main text of the standard.  

This carries through to ISO/IEC 9899:2011.  

Thanks for connecting that particular dot,

 - Dennis

PS: There is no counterpart of Appendix F in ISO/IEC 14882:1998 (C++) nor ISO/IEC 14882:2003 and ISO/IEC 14882:2011.  I assume this is because C++ has the numeric_limits class to account for the variations in implementations without any mention of IEC 60559 (or the IEEE counterpart on which it derives).  Also, these rely on a variable is_iec559 and specify a number of numeric_limits conditionally on iec559 != false.  The declaration of conformance to IEC [60]559 (IEEE 754) does not make any of the exceptions that are in ISO C Appendix F.

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Wednesday, February 20, 2013 14:08
To: dev@openoffice.apache.org; orcmid@apache.org
Subject: Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

On Wed, Feb 20, 2013 at 4:37 PM, Dennis E. Hamilton <or...@apache.org> wrote:
> I earlier quoted the applicable (and only) texts from the Standards themselves, particularly C++ and also the latest C Standard (2011 and C99 with all Technical Corrigenda through 2007).
>
> No matter what is said about pow(0,0) in the C99 Rationale v5.10 Appendix F of April 2003, there are no such requirements in the Standards, including those versions that have been adopted since 2003.
>
>  - Dennis
>
[ ... ]

In other words, C99, in a normative Annex F, section 9.4.4, for
implementations that conform to IEEE 754 floating point, says:

"pow(x, ±0) returns 1 for any x, even a NaN."

Do you see something different?

I'd like to make sure we're seeing the same thing here.

-Rob


[ ... ]

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Rob Weir <ro...@apache.org>]

On Wed, Feb 20, 2013 at 4:37 PM, Dennis E. Hamilton <or...@apache.org> wrote:
> I earlier quoted the applicable (and only) texts from the Standards themselves, particularly C++ and also the latest C Standard (2011 and C99 with all Technical Corrigenda through 2007).
>
> No matter what is said about pow(0,0) in the C99 Rationale v5.10 Appendix F of April 2003, there are no such requirements in the Standards, including those versions that have been adopted since 2003.
>
>  - Dennis
>
> PS: I mentioned cpow(0,0) because of the mathematical relationship and I was observing that is consistent with the subset that pow(x,y) supports.
>
> DETAILS
>
> The definition of domain error is that an implementation-defined value is returned *and* errno is set to EDOM.  There is also the option of triggering a floating-point exception. I assume that "capable of representation" *includes* silent NaN and +infinity but for all I know those return with non-exception domain errors too.  Plauger certainly prepared to encounter those in his implementation (though he also chose pow(0,0) = 1.0).
>
> The C 99 Rationale is not an ISO/IEC International Standard, regardless of the INCITS J11 and SC22 WG14 participation.  It is not necessary to even know about it.  In particular,
>
>         "This Rationale discusses some language or library features which were not adopted into the
> Standard. These are usually features which are popular in some C implementations, so that a
> user of those implementations might question why they do not appear in the Standard." [p.5 preceding section 0.1]  The Rationale doesn't address that question users might have.
>
>         "**[T]his rationale is not part of the Standard**" [bottom of page 5, their emphasis]
>
> Then there is Appendix F.  I have no idea what it means to have "normative" in the title.  This appears to be an IEC 60559 floating-point profile from NCEC, with certain exceptions to 60559, although not even that is entirely clear.  pow(+inf,0) = pow(0,0) = 1 are stated as required under Appendix F (bottom of page 180)  Adding pow(NaN,0) = 1 (page 182) by taking power(x,0)=1 as settled for all x is particularly marvelous.
>

In other words, C99, in a normative Annex F, section 9.4.4, for
implementations that conform to IEEE 754 floating point, says:

"pow(x, ±0) returns 1 for any x, even a NaN."

Do you see something different?

I'd like to make sure we're seeing the same thing here.

-Rob


> The developers of C 2011 also didn't seem to be under any compulsion with regard to the C99 Rationale.
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Wednesday, February 20, 2013 10:14
> To: dev@openoffice.apache.org
> Subject: Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
>
> [ ... ] I'm reading a requirement for pow(x,0) to
> return 1 for all values of x.  Are you seeing something else?  Are you
> seeing anything that says a conforming C/C++ runtime may *return*
> something other than 1?
>
> Btw, the rationale for this choice is described on page 182 of this document:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
>
> [ ... ]
>

RE: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

["Dennis E. Hamilton" <or...@apache.org>]

I earlier quoted the applicable (and only) texts from the Standards themselves, particularly C++ and also the latest C Standard (2011 and C99 with all Technical Corrigenda through 2007).  

No matter what is said about pow(0,0) in the C99 Rationale v5.10 Appendix F of April 2003, there are no such requirements in the Standards, including those versions that have been adopted since 2003.

 - Dennis

PS: I mentioned cpow(0,0) because of the mathematical relationship and I was observing that is consistent with the subset that pow(x,y) supports.

DETAILS

The definition of domain error is that an implementation-defined value is returned *and* errno is set to EDOM.  There is also the option of triggering a floating-point exception. I assume that "capable of representation" *includes* silent NaN and +infinity but for all I know those return with non-exception domain errors too.  Plauger certainly prepared to encounter those in his implementation (though he also chose pow(0,0) = 1.0).

The C 99 Rationale is not an ISO/IEC International Standard, regardless of the INCITS J11 and SC22 WG14 participation.  It is not necessary to even know about it.  In particular, 

	"This Rationale discusses some language or library features which were not adopted into the
Standard. These are usually features which are popular in some C implementations, so that a
user of those implementations might question why they do not appear in the Standard." [p.5 preceding section 0.1]  The Rationale doesn't address that question users might have.

	"**[T]his rationale is not part of the Standard**" [bottom of page 5, their emphasis]

Then there is Appendix F.  I have no idea what it means to have "normative" in the title.  This appears to be an IEC 60559 floating-point profile from NCEC, with certain exceptions to 60559, although not even that is entirely clear.  pow(+inf,0) = pow(0,0) = 1 are stated as required under Appendix F (bottom of page 180)  Adding pow(NaN,0) = 1 (page 182) by taking power(x,0)=1 as settled for all x is particularly marvelous.  

The developers of C 2011 also didn't seem to be under any compulsion with regard to the C99 Rationale.

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Wednesday, February 20, 2013 10:14
To: dev@openoffice.apache.org
Subject: Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[ ... ] I'm reading a requirement for pow(x,0) to
return 1 for all values of x.  Are you seeing something else?  Are you
seeing anything that says a conforming C/C++ runtime may *return*
something other than 1?

Btw, the rationale for this choice is described on page 182 of this document:

http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

[ ... ]

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Rob Weir <ro...@apache.org>]

On Wed, Feb 20, 2013 at 12:27 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I don't want to get into this.  I think enough has been said.
>
> I do want to avoid anyone misunderstanding what the ANSI/ISO Standards for C and C++ say about pow(0,0) however.
>
> In general, C/C++ pow(0,0) is left implementation-defined.  There may be a domain error (this is an implementation-defined result plus setting of a global condition).  There may be a silent return of NaN.
>

A domain error is something that an implementation might express via
call to matherr() and setting errno to EDOM is a different question
than the return value.   I'm reading a requirement for pow(x,0) to
return 1 for all values of x.  Are you seeing something else?  Are you
seeing anything that says a conforming C/C++ runtime may *return*
something other than 1?

Btw, the rationale for this choice is described on page 182 of this document:

http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

And I don't think cpow() is relevant to the topic.

Regards,

-Rob

>  - Dennis
>
> DETAILS
>
> In ISO/IEC 14882-1998 (C++) the numeric_limits account for specializations in arithmetic that provide for +infinity and silent (non-exception-triggering) NaN among other cases.  The value for *complex* pow(0,0) is implementation-defined in 26.2.8.  For <cmath> (section 26.5) the definitions are deferred to the C Standard <math.h>, although more type specializations are provided for numtype pow(numtype1, numtype2).
>
> In ISO/IEC 14882-2003 (C++) is the same.  I haven't checked -2011 and the standardization of some of the Boost library.
>
> In ISO/IEC 9899:2011 (C) the specification of cpow( ) does not say anything about cpow(0,0).  The specification of pow(x,y) says that a domain error may occur if x is zero and y is zero.  The same language appears in ISO C99 (including its Technical Corrigenda).  In ANSI/ISO C (way back, before 1992) the rule was that "A domain error occurs if the result cannot be represented when x is zero and y is less than or equal to zero."  (A domain error involves return of an implementation-defined value and the global error variable is set - exceptions aren't used in Standard C libraries.)  So, considerable variability is provided. Quiet NaN and +Inf are representations, of course, if available in the library and arithmetic implementation.  These are accounted for in 9899:2011.
>
>  Plauger's "Standard C Library" (in 1992) assumes IEEE floating point and handles NaN and +Inf (and his implementation appears to return 1 for pow(0,0) -- the code is pretty snarly).
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Wednesday, February 20, 2013 07:08
> To: dev@openoffice.apache.org
> Subject: Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
>
> [ ... ] ANSI C, C99, ISO C++ all require that
> pow(x,0) return 1 for all values of x.
>
> [ ... ]
>

RE: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

["Dennis E. Hamilton" <de...@acm.org>]

I don't want to get into this.  I think enough has been said.

I do want to avoid anyone misunderstanding what the ANSI/ISO Standards for C and C++ say about pow(0,0) however.

In general, C/C++ pow(0,0) is left implementation-defined.  There may be a domain error (this is an implementation-defined result plus setting of a global condition).  There may be a silent return of NaN.  

 - Dennis

DETAILS

In ISO/IEC 14882-1998 (C++) the numeric_limits account for specializations in arithmetic that provide for +infinity and silent (non-exception-triggering) NaN among other cases.  The value for *complex* pow(0,0) is implementation-defined in 26.2.8.  For <cmath> (section 26.5) the definitions are deferred to the C Standard <math.h>, although more type specializations are provided for numtype pow(numtype1, numtype2).

In ISO/IEC 14882-2003 (C++) is the same.  I haven't checked -2011 and the standardization of some of the Boost library.

In ISO/IEC 9899:2011 (C) the specification of cpow( ) does not say anything about cpow(0,0).  The specification of pow(x,y) says that a domain error may occur if x is zero and y is zero.  The same language appears in ISO C99 (including its Technical Corrigenda).  In ANSI/ISO C (way back, before 1992) the rule was that "A domain error occurs if the result cannot be represented when x is zero and y is less than or equal to zero."  (A domain error involves return of an implementation-defined value and the global error variable is set - exceptions aren't used in Standard C libraries.)  So, considerable variability is provided. Quiet NaN and +Inf are representations, of course, if available in the library and arithmetic implementation.  These are accounted for in 9899:2011.

 Plauger's "Standard C Library" (in 1992) assumes IEEE floating point and handles NaN and +Inf (and his implementation appears to return 1 for pow(0,0) -- the code is pretty snarly).  

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Wednesday, February 20, 2013 07:08
To: dev@openoffice.apache.org
Subject: Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[ ... ] ANSI C, C99, ISO C++ all require that
pow(x,0) return 1 for all values of x. 

[ ... ]

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Rob Weir <ro...@apache.org>]

On Wed, Feb 20, 2013 at 9:54 AM, Pedro Giffuni <pf...@apache.org> wrote:
> I guess I shouldn't be surprised that this thread keeps reappearing
> in my inbox ;).
>
> ----- Messaggio originale -----
>> Da: Andrea Pescetti
> ...
>>
>>>>  what the result of the power function in edge cases should be.
>>>  So let me suggest a solution ... this really needs to be a per-document
>>>  setting. ...
>>>  3) If we make it a runtime setting --- all legacy documents in ODF
>>>  format are evaluated according to the legacy mode.  So no
>>>  compatibility break.   Users have a choice for mode for all new
>>>  documents.  All Excel format documents by default are in
>>>  Excel-compatibility mode.
>>
>> This seems the only solution where we could have consensus. It is a non-trivial
>> enhancement but it has advantages.
>>
>
> It is certainly not impossible but my experience with people changing colors
> of bikeshed is that:
>
> 1) there must be some default value, which will lead to yet another
> bikeshed color dispute.
> 2) No one will do anything about it because they lack the skills or
> they never wanted the change done at all.
>
> I am pretty sure the result will be (2).
>
>
>>>>  Are you really suggesting to ship AOO on FreeBSD with different
>> behavior
>>>>  then on eg Windows? ... Please don't do that.
>>
>> Yes, this should be avoided if possible. Let's try to avoid inconsistencies
>> across operating systems.
>>
>
>
> In this case there is actually no inconsistency as AOO has no
> control over what pow() does. Technically the behaviour has always
> been system dependent
>

I don't believe this is true.  ANSI C, C99, ISO C++ all require that
pow(x,0) return 1 for all values of x. This is also a POSIX
requirement.    ODF 1.2 permits other values, but to the extent we use
the standard C library's pow() function we should be consistent on all
platforms, to the extent their C runtime is conforming.

-Rob

> There is a long history of patches for bugzilla issues that OOo was
> very slow to adopt. The fact that distributions can now use
> a very different Python version already induces much more
> inconsistencies.
>
> Oh, and python is a good example on how breaking backwards
> compatibility is not a valid reason for a veto. I am of the opinion
> that introducing python3 as the internal python would cause
> too much trouble now to existing users (LO has less such users), but
> the real reason why the change hasn't been made is not a veto:
> people asked for it but no one has offered the work required in the
> python module (and the MacOSX port).
>
> cheers,
>
> Pedro.
>

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Pedro Giffuni <pf...@apache.org>]

I guess I shouldn't be surprised that this thread keeps reappearing
in my inbox ;).

----- Messaggio originale -----
> Da: Andrea Pescetti 
...
> 
>>>  what the result of the power function in edge cases should be.
>>  So let me suggest a solution ... this really needs to be a per-document
>>  setting. ...
>>  3) If we make it a runtime setting --- all legacy documents in ODF
>>  format are evaluated according to the legacy mode.  So no
>>  compatibility break.   Users have a choice for mode for all new
>>  documents.  All Excel format documents by default are in
>>  Excel-compatibility mode.
> 
> This seems the only solution where we could have consensus. It is a non-trivial 
> enhancement but it has advantages.
>

It is certainly not impossible but my experience with people changing colors
of bikeshed is that:

1) there must be some default value, which will lead to yet another
bikeshed color dispute.
2) No one will do anything about it because they lack the skills or
they never wanted the change done at all.

I am pretty sure the result will be (2).
  

>>>  Are you really suggesting to ship AOO on FreeBSD with different 
> behavior
>>>  then on eg Windows? ... Please don't do that.
> 
> Yes, this should be avoided if possible. Let's try to avoid inconsistencies 
> across operating systems.
> 


In this case there is actually no inconsistency as AOO has no
control over what pow() does. Technically the behaviour has always
been system dependent

There is a long history of patches for bugzilla issues that OOo was
very slow to adopt. The fact that distributions can now use
a very different Python version already induces much more
inconsistencies.

Oh, and python is a good example on how breaking backwards
compatibility is not a valid reason for a veto. I am of the opinion
that introducing python3 as the internal python would cause
too much trouble now to existing users (LO has less such users), but
the real reason why the change hasn't been made is not a veto:
people asked for it but no one has offered the work required in the
python module (and the MacOSX port).

cheers,

Pedro.

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Andrea Pescetti <pe...@apache.org>]

On 20/02/2013 Andrea Pescetti wrote:
>>>> [Pedro]
>>>> I also want an assurance that this will never *ever* happen again (I am
>>>> talking about the revert, I guess bikesheds are unavoidable). ...
> what I will do ... is to propose changes to
> http://www.apache.org/foundation/glossary.html#Veto that make it clear
> that it is considered disrespectful or anti-social to revert someone
> else's patches. This will allow better handling of similar problems in
> future.

(Don't worry, I am not reopening the 0 ^ 0 discussion... just a follow-up)

After a thorough review on the members list as advised by Ross in
http://www.mail-archive.com/dev@openoffice.apache.org/msg04423.html
and several tweaks the changes to the glossary page were published this 
weekend. Note that the glossary uses a neutral wording in general, so 
the patch respects the general tone of the glossary.

See http://www.apache.org/foundation/glossary.html#Veto

The new text reads:

-     invalid. Vetos only apply to code changes; they do not apply to
+     invalid; in case of doubt, deciding whether a technical
+     justification is valid is up to the PMC. Vetos force discussion
+     and, if supported, version control rollback or appropriate code 
changes. Vetoed code commits
+     are best reverted by the original committer, unless an urgent
+     solution is needed (e.g., build breakers). Vetos only apply to
+     code changes; they do not apply to
       procedural issues such as software releases.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Andrea Pescetti <pe...@apache.org>]

On 18/02/2013 Rob Weir wrote:
> On Mon, Feb 18, 2013 at 3:58 AM, Andre Fischer wrote:
>> On 18.02.2013 01:15, Pedro Giffuni wrote:
>> [Andre] turn this into a switch that can be altered via Tools->Options
>> at runtime by the user.  The user is ultimately the only person who knows
>> what the result of the power function in edge cases should be.
> So let me suggest a solution ... this really needs to be a per-document
> setting. ...
> 3) If we make it a runtime setting --- all legacy documents in ODF
> format are evaluated according to the legacy mode.  So no
> compatibility break.   Users have a choice for mode for all new
> documents.  All Excel format documents by default are in
> Excel-compatibility mode.

This seems the only solution where we could have consensus. It is a 
non-trivial enhancement but it has advantages.

>> Are you really suggesting to ship AOO on FreeBSD with different behavior
>> then on eg Windows? ... Please don't do that.

Yes, this should be avoided if possible. Let's try to avoid 
inconsistencies across operating systems.

>>> It *is* rude, really ... I *don't* care much what happens with the patch,
>>> if it should be disabled or not, but I DO want respect. ...
>>> I also want an assurance that this will never *ever* happen again (I am
>>> talking about the revert, I guess bikesheds are unavoidable).

Symbolically reverting the patch again and then back out is something 
that could have worked if done immediately, but I feel it would be 
excessive at the moment. In any case, what I see more important, and 
what I will do later this week, is to propose changes to 
http://www.apache.org/foundation/glossary.html#Veto that make it clear 
that it is considered disrespectful or anti-social to revert someone 
else's patches. This will allow better handling of similar problems in 
future.

Regards,
   Andrea.

RE: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

["Dennis E. Hamilton" <or...@apache.org>]

+1

This builds on an initial suggestion by Andrea Pescetti.

Introduction of spreadsheet settings for compatibility selections needs to be done carefully. The usability needs to be handled in a way that doesn't confuse anyone.  I think it is a great way to deal with the interoperability cases where there are implementation-defined/-dependent cases that vary between current AOO (and, generally, LibO) behavior and what Excel does.  

The use of an excel-compatibility setting in the document also works well for ODF spreadsheets (.ods files) produced *by* versions of Excel that, naturally, have differing implementations for these implementation-defined/-dependent cases.  

Anything that can be done to cut down on discrepancies that prevent interchange and create support problems, discourage users, etc., is a big win.

It takes more systematic work, touching multiple parts of the implementation to do this.  There also needs to be agreement to how this is represented in the ODF document in a way that preserves conformance and interchange.

I think it is workable, if there is agreement that the effort to achieve such interoperability is worthwhile.

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Monday, February 18, 2013 06:27
To: dev@openoffice.apache.org
Subject: Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

On Mon, Feb 18, 2013 at 3:58 AM, Andre Fischer <aw...@gmail.com> wrote:
> On 18.02.2013 01:15, Pedro Giffuni wrote:
>>
>> Hello;
>>
>>
>> Well, as you might imagine I am really tired of the flame storm that
>> went around the 0 ^ 0 issue. My intention here is not at all to re-start
>> that discussion. I really have much more fun things to do.
>> I am actualy a fan of Clint Eastwood so let me remember one of
>> my favorite movies ever.
>>
>> THE GOOD
>>
>> It didn't really take me long but I found a technical solution for the
>> dilemma.
>>
>> - The numerical issues were caused by a copy-paste error where the
>> C++ wrapper used int for the exponent instead of a double. Once
>> found it was trivial to fix.
>>
>> - Considering the "vetos" I still think they are invalid but I think they
>> both reflect a community concern so I have addressed it.
>>
>> The new patch [1] now defines in SAL's math.h the following:
>>
>> #define SAL_STRICTER_MATH
>>
>>
>> This currently only affects the power function and acts as a
>> sort of "excel compatibility" flag. This is very simple at this time
>> but it fulfills it's task: you can easily change the behaviour
>> during compile time.
>
>
> I am sorry but I don't think this is a good idea because:
>
> - The SAL_STRICTER_MATH flag needs documentation as to what it shall
> accomplish.
>
> - At the moment only the rtl_math_powr() function uses this flag so it looks
> more like a quick fix then a general concept.
>
> - The value of the flag can not be set from the outside.  You have to change
> the source file in order to change it.   Such a change can not be made by a
> user and a developer has to know that a) the flag exists, b) has to locate
> the file where to change it, c) read the code to understand the consequences
> of doing so.
>
>
>
> I would suggest at least to make the flag overridable by the makefile via
> some -DSAL_STRICTER_MATH=ON/OFF definition.
>
> Better make this a configuration switch.  Yes, there are too many of these,
> but we probably have even more unmaintained compile time switches.
>
> Even better, turn this into a switch that can be altered via Tools->Options
> at runtime by the user.  The user is ultimately the only person who knows
> what the result of the power function in edge cases should be.
>

I think this is a key observation.  Working in an Excel-compatible
mode versus an OpenOffice-backwards-compatible mode doesn't make sense
as a build-time mode.  That is not how the product is used.  We don't
have users who only access Excel documents and never access legacy
OpenOffice, LibreOffice, Symphony or Calligra documents.  And we don't
have users who never access Excel documents.   A user can access an
Excel document and then 5 minutes later need to open an older
OpenOffice document, and then after lunch need to edit an old Excel
document.  We're not improving things if we treat these preferences as
hard-coded compile-time options.

Also, the value of 0^0 is just one of 61 different
implementation-defined values in OpenFormula, and not the most
interesting one of them either.  There are others that impact, to a
greater degree, interop with MS Office.  But I think we'd all agree
that defining compile-time options for all 61 would be crazy.  So
let's not start down that road.

So let me suggest a solution that I hope would gain a greater degree
of consensus, based on the observation (which I owe to a comment
Dennis made in Bugzilla) that this really needs to be a per-document
setting.

A full solution would look like this:

1) There are a bundle of formula-evaluation related behaviors that we
treat together, as belonging to either "Excel-compatibility mode" or
"legacy mode".  The value of 0^0 would be one of these behaviors.

2) There would be a run-time mode that could be configured to evaluate
a spreadsheet in one mode or the other.

3) When a new spreadsheet is created and saved as ODF we store the
mode used to evaluate the document as document metadata.   So when the
document is read we know exactly the assumptions made to evaluate it.

4) Earlier versions of AOO/OOo and LibreOffice and Symphony will not
understand this metadata, but this will improve over time as more
people upgrade to AOO 4.0.  We can also coordinate with LibreOffice
and Calligra and maybe they would be interested in adopting a similar
setting.

5) When a new spreadsheet is created it uses a user-defined mode of
evaluation.  By default in AOO 4.0 the mode would be "legacy mode".
But this would be a user-settable in a dialog.  In future versions of
AOO, we can reconsider changing the default.  It will be easier to
transition this once the install base has moved over to versions of
AOO that support "excel-compatibility mode".

6) When loading a Excel format document (XLS or XLSX) we automatically
switch into excel-compatibility-mode, since that format is typically
used to interop with Excel or with Excel-compatible applications.


So more work, yes.  But look at the different in interoperability.

1) Current situation in the code -- We're always in "legacy-mode",
even when processing documents that come from Excel.  This is true not
only for 0^0, but a range of other calculation-related behaviors.   So
users today have some interop problems.

2) Pedro's solution only deals with 0^0 and does it with an
undocumented, obscure compile time setting and breaks legacy
compatibility in order to improve Excel compatibility.  It is forcing
users to choose -- do I install a backwards compatible version of AOO
or an Excel-compatible version?   It is using an axe where a scalpel
is needed.

3) If we make it a runtime setting --- all legacy documents in ODF
format are evaluated according to the legacy mode.  So no
compatibility break.   Users have a choice for mode for all new
documents.  All Excel format documents by default are in
Excel-compatibility mode.

So I think option #3 is an all-around better solution that we should
aim for.   It is an open question whether such an approach can be
extended to other areas beyond calculation modes, e.g., layout in
Writer.

Regards,

-Rob

>
>>
>> It is actually an advance because having this in SAL gives us control:
>> our current behavior is platform dependent.
>>
>> THE UGLY
>>
>> The discussion so far has been centered around the default. I
>> consider myself agnostic in this case: I think that it is better
>> to use the stricter criteria and be compatible with MS Excel.
>> A lot of people worry about compatibility issues.
>>
>> With my FreeBSD hat on, I think in the unsupported platforms
>> (FreeBSD, OS2, Solaris) the compatibility issue isn't really a
>> concern (the ASF has never provided officially binaries) but
>> the Excel behaviour is useful for interoperability.
>>
>> I think the best option would be if existing users take a decision
>> before release what behaviour the want and if the case is to revert
>> we can add something like
>>
>> #if defined(WINOS) || defined(MACOSX) || defined(LINUX)
>> #defined SAL_STRICTER_MATH
>> #endif
>
>
> I am not sure that the logic is right here.  First you say that for FreeBSD,
> OS2 and Solaris compatibility is not an issue and imply that using
> "stricter" math on these platforms where OK.  But then you define
> SAL_STRICTER_MATH for Windows, MacOS and Linux.  Which one is right?
>
> Besides, I hope that this code snipped will not go into a source file like
> rtl/math.hxx.  The SAL_STRICTER_MATH flag is technically not tied to any
> platform.  But a test like the one above would suggest that it does only run
> on Windows, Mac, and Linux.
>
>
> But the most important point is that with logic like this the choice of
> using "stricter" math still has to be made when AOO is built, ie not by
> users but by developers and ultimately by the release engineer.
>
>
>>
>> You get the idea. Doing this is rather ugly but I can live with it
>
>
> I can not.
>
>
>>   as
>> at least windows and MacOSX have the option to use Excel if they
>> want to be serious about math.
>>
>> I guess we could add it as a configure option but we already have
>> too many of them and even then there has to be a default.
>>
>> This is something I think the comunity has to decide on by voting
>> before the release. I won't take the decision but since I take care
>> for FreeBSD, I think we will opt for the Excel compatibility (I do
>> have to consult with Maho though).
>
>
> Are you really suggesting to ship AOO on FreeBSD with different behavior
> then on eg Windows?
> What good can come from that?  Documents would not be compatible inside the
> same application when moved from one platform to another.  Please don't do
> that.
>
> -Andre
>
>
>>
>> THE BAD
>>
>> (Please stop reading here if you are sensible to non-technical issues)
>>
>> First I should thank Greg Stein for clarifying the correct sense and reach
>> of the veto. I also want to thank people that have expressed their support
>> in private or public. It is clear to me that we are still too young as a
>> community
>> in AOO and that people still have a long way to learn in matters of
>> behaviour.
>>
>> I am not as much disappointed by the discussion (which I think
>> doesn't correspond to the impact of the patch) but by the fact that
>> I was not given the chance to work on it and that I have been
>> insulted in the process.
>>
>> I strongly complained when Dave's commit was reverted and I find
>> it absolutely unacceptable in the way it was done with me. First
>> of all the harassment: I am a volunteer, I am not here to receive
>> something in the lines of "Revert now or else ...", and second the
>> lack of respect for my work.
>>
>> It *is* rude, really ... I *don't* care much what happens with the patch,
>> if it should be disabled or not, but I DO want respect.
>>
>> I think I deserve reparation for the commit reversal: this shouldn't have
>> happened. I request the code be restated as it should have never been
>> reverted in the first place. This is all symbolical as there is a new
>> version.
>> Once the new version is in, I will let anyone else decide if you guys
>> want to ifdef it or add a configure option or whatever: I don't really
>> want
>> to be involved in this anymore.
>>
>>
>> I also want an assurance that this will never *ever* happen again (I am
>> talking about the revert, I guess bikesheds are unavoidable).
>>
>> If people really don't like my patches (yes, according to the Berne
>> convention
>> I do own them)  I will take them with me but I prefer if there is a
>> civilized
>> discussion and not this circus we have been experiencing these last days.
>>
>> Pedro.
>>
>> [1] http://people.apache.org/~pfg/patches/patch-power00
>
>

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Rob Weir <ro...@apache.org>]

On Mon, Feb 18, 2013 at 3:58 AM, Andre Fischer <aw...@gmail.com> wrote:
> On 18.02.2013 01:15, Pedro Giffuni wrote:
>>
>> Hello;
>>
>>
>> Well, as you might imagine I am really tired of the flame storm that
>> went around the 0 ^ 0 issue. My intention here is not at all to re-start
>> that discussion. I really have much more fun things to do.
>> I am actualy a fan of Clint Eastwood so let me remember one of
>> my favorite movies ever.
>>
>> THE GOOD
>>
>> It didn't really take me long but I found a technical solution for the
>> dilemma.
>>
>> - The numerical issues were caused by a copy-paste error where the
>> C++ wrapper used int for the exponent instead of a double. Once
>> found it was trivial to fix.
>>
>> - Considering the "vetos" I still think they are invalid but I think they
>> both reflect a community concern so I have addressed it.
>>
>> The new patch [1] now defines in SAL's math.h the following:
>>
>> #define SAL_STRICTER_MATH
>>
>>
>> This currently only affects the power function and acts as a
>> sort of "excel compatibility" flag. This is very simple at this time
>> but it fulfills it's task: you can easily change the behaviour
>> during compile time.
>
>
> I am sorry but I don't think this is a good idea because:
>
> - The SAL_STRICTER_MATH flag needs documentation as to what it shall
> accomplish.
>
> - At the moment only the rtl_math_powr() function uses this flag so it looks
> more like a quick fix then a general concept.
>
> - The value of the flag can not be set from the outside.  You have to change
> the source file in order to change it.   Such a change can not be made by a
> user and a developer has to know that a) the flag exists, b) has to locate
> the file where to change it, c) read the code to understand the consequences
> of doing so.
>
>
>
> I would suggest at least to make the flag overridable by the makefile via
> some -DSAL_STRICTER_MATH=ON/OFF definition.
>
> Better make this a configuration switch.  Yes, there are too many of these,
> but we probably have even more unmaintained compile time switches.
>
> Even better, turn this into a switch that can be altered via Tools->Options
> at runtime by the user.  The user is ultimately the only person who knows
> what the result of the power function in edge cases should be.
>

I think this is a key observation.  Working in an Excel-compatible
mode versus an OpenOffice-backwards-compatible mode doesn't make sense
as a build-time mode.  That is not how the product is used.  We don't
have users who only access Excel documents and never access legacy
OpenOffice, LibreOffice, Symphony or Calligra documents.  And we don't
have users who never access Excel documents.   A user can access an
Excel document and then 5 minutes later need to open an older
OpenOffice document, and then after lunch need to edit an old Excel
document.  We're not improving things if we treat these preferences as
hard-coded compile-time options.

Also, the value of 0^0 is just one of 61 different
implementation-defined values in OpenFormula, and not the most
interesting one of them either.  There are others that impact, to a
greater degree, interop with MS Office.  But I think we'd all agree
that defining compile-time options for all 61 would be crazy.  So
let's not start down that road.

So let me suggest a solution that I hope would gain a greater degree
of consensus, based on the observation (which I owe to a comment
Dennis made in Bugzilla) that this really needs to be a per-document
setting.

A full solution would look like this:

1) There are a bundle of formula-evaluation related behaviors that we
treat together, as belonging to either "Excel-compatibility mode" or
"legacy mode".  The value of 0^0 would be one of these behaviors.

2) There would be a run-time mode that could be configured to evaluate
a spreadsheet in one mode or the other.

3) When a new spreadsheet is created and saved as ODF we store the
mode used to evaluate the document as document metadata.   So when the
document is read we know exactly the assumptions made to evaluate it.

4) Earlier versions of AOO/OOo and LibreOffice and Symphony will not
understand this metadata, but this will improve over time as more
people upgrade to AOO 4.0.  We can also coordinate with LibreOffice
and Calligra and maybe they would be interested in adopting a similar
setting.

5) When a new spreadsheet is created it uses a user-defined mode of
evaluation.  By default in AOO 4.0 the mode would be "legacy mode".
But this would be a user-settable in a dialog.  In future versions of
AOO, we can reconsider changing the default.  It will be easier to
transition this once the install base has moved over to versions of
AOO that support "excel-compatibility mode".

6) When loading a Excel format document (XLS or XLSX) we automatically
switch into excel-compatibility-mode, since that format is typically
used to interop with Excel or with Excel-compatible applications.


So more work, yes.  But look at the different in interoperability.

1) Current situation in the code -- We're always in "legacy-mode",
even when processing documents that come from Excel.  This is true not
only for 0^0, but a range of other calculation-related behaviors.   So
users today have some interop problems.

2) Pedro's solution only deals with 0^0 and does it with an
undocumented, obscure compile time setting and breaks legacy
compatibility in order to improve Excel compatibility.  It is forcing
users to choose -- do I install a backwards compatible version of AOO
or an Excel-compatible version?   It is using an axe where a scalpel
is needed.

3) If we make it a runtime setting --- all legacy documents in ODF
format are evaluated according to the legacy mode.  So no
compatibility break.   Users have a choice for mode for all new
documents.  All Excel format documents by default are in
Excel-compatibility mode.

So I think option #3 is an all-around better solution that we should
aim for.   It is an open question whether such an approach can be
extended to other areas beyond calculation modes, e.g., layout in
Writer.

Regards,

-Rob

>
>>
>> It is actually an advance because having this in SAL gives us control:
>> our current behavior is platform dependent.
>>
>> THE UGLY
>>
>> The discussion so far has been centered around the default. I
>> consider myself agnostic in this case: I think that it is better
>> to use the stricter criteria and be compatible with MS Excel.
>> A lot of people worry about compatibility issues.
>>
>> With my FreeBSD hat on, I think in the unsupported platforms
>> (FreeBSD, OS2, Solaris) the compatibility issue isn't really a
>> concern (the ASF has never provided officially binaries) but
>> the Excel behaviour is useful for interoperability.
>>
>> I think the best option would be if existing users take a decision
>> before release what behaviour the want and if the case is to revert
>> we can add something like
>>
>> #if defined(WINOS) || defined(MACOSX) || defined(LINUX)
>> #defined SAL_STRICTER_MATH
>> #endif
>
>
> I am not sure that the logic is right here.  First you say that for FreeBSD,
> OS2 and Solaris compatibility is not an issue and imply that using
> "stricter" math on these platforms where OK.  But then you define
> SAL_STRICTER_MATH for Windows, MacOS and Linux.  Which one is right?
>
> Besides, I hope that this code snipped will not go into a source file like
> rtl/math.hxx.  The SAL_STRICTER_MATH flag is technically not tied to any
> platform.  But a test like the one above would suggest that it does only run
> on Windows, Mac, and Linux.
>
>
> But the most important point is that with logic like this the choice of
> using "stricter" math still has to be made when AOO is built, ie not by
> users but by developers and ultimately by the release engineer.
>
>
>>
>> You get the idea. Doing this is rather ugly but I can live with it
>
>
> I can not.
>
>
>>   as
>> at least windows and MacOSX have the option to use Excel if they
>> want to be serious about math.
>>
>> I guess we could add it as a configure option but we already have
>> too many of them and even then there has to be a default.
>>
>> This is something I think the comunity has to decide on by voting
>> before the release. I won't take the decision but since I take care
>> for FreeBSD, I think we will opt for the Excel compatibility (I do
>> have to consult with Maho though).
>
>
> Are you really suggesting to ship AOO on FreeBSD with different behavior
> then on eg Windows?
> What good can come from that?  Documents would not be compatible inside the
> same application when moved from one platform to another.  Please don't do
> that.
>
> -Andre
>
>
>>
>> THE BAD
>>
>> (Please stop reading here if you are sensible to non-technical issues)
>>
>> First I should thank Greg Stein for clarifying the correct sense and reach
>> of the veto. I also want to thank people that have expressed their support
>> in private or public. It is clear to me that we are still too young as a
>> community
>> in AOO and that people still have a long way to learn in matters of
>> behaviour.
>>
>> I am not as much disappointed by the discussion (which I think
>> doesn't correspond to the impact of the patch) but by the fact that
>> I was not given the chance to work on it and that I have been
>> insulted in the process.
>>
>> I strongly complained when Dave's commit was reverted and I find
>> it absolutely unacceptable in the way it was done with me. First
>> of all the harassment: I am a volunteer, I am not here to receive
>> something in the lines of "Revert now or else ...", and second the
>> lack of respect for my work.
>>
>> It *is* rude, really ... I *don't* care much what happens with the patch,
>> if it should be disabled or not, but I DO want respect.
>>
>> I think I deserve reparation for the commit reversal: this shouldn't have
>> happened. I request the code be restated as it should have never been
>> reverted in the first place. This is all symbolical as there is a new
>> version.
>> Once the new version is in, I will let anyone else decide if you guys
>> want to ifdef it or add a configure option or whatever: I don't really
>> want
>> to be involved in this anymore.
>>
>>
>> I also want an assurance that this will never *ever* happen again (I am
>> talking about the revert, I guess bikesheds are unavoidable).
>>
>> If people really don't like my patches (yes, according to the Berne
>> convention
>> I do own them)  I will take them with me but I prefer if there is a
>> civilized
>> discussion and not this circus we have been experiencing these last days.
>>
>> Pedro.
>>
>> [1] http://people.apache.org/~pfg/patches/patch-power00
>
>

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Andre Fischer <aw...@gmail.com>]

On 18.02.2013 01:15, Pedro Giffuni wrote:
> Hello;
>
>
> Well, as you might imagine I am really tired of the flame storm that
> went around the 0 ^ 0 issue. My intention here is not at all to re-start
> that discussion. I really have much more fun things to do.
> I am actualy a fan of Clint Eastwood so let me remember one of
> my favorite movies ever.
>
> THE GOOD
>
> It didn't really take me long but I found a technical solution for the
> dilemma.
>
> - The numerical issues were caused by a copy-paste error where the
> C++ wrapper used int for the exponent instead of a double. Once
> found it was trivial to fix.
>
> - Considering the "vetos" I still think they are invalid but I think they
> both reflect a community concern so I have addressed it.
>
> The new patch [1] now defines in SAL's math.h the following:
>
> #define SAL_STRICTER_MATH
>
>
> This currently only affects the power function and acts as a
> sort of "excel compatibility" flag. This is very simple at this time
> but it fulfills it's task: you can easily change the behaviour
> during compile time.

I am sorry but I don't think this is a good idea because:

- The SAL_STRICTER_MATH flag needs documentation as to what it shall 
accomplish.

- At the moment only the rtl_math_powr() function uses this flag so it 
looks more like a quick fix then a general concept.

- The value of the flag can not be set from the outside.  You have to 
change the source file in order to change it.   Such a change can not be 
made by a user and a developer has to know that a) the flag exists, b) 
has to locate the file where to change it, c) read the code to 
understand the consequences of doing so.



I would suggest at least to make the flag overridable by the makefile 
via some -DSAL_STRICTER_MATH=ON/OFF definition.

Better make this a configuration switch.  Yes, there are too many of 
these, but we probably have even more unmaintained compile time switches.

Even better, turn this into a switch that can be altered via 
Tools->Options at runtime by the user.  The user is ultimately the only 
person who knows what the result of the power function in edge cases 
should be.

>
> It is actually an advance because having this in SAL gives us control:
> our current behavior is platform dependent.
>
> THE UGLY
>
> The discussion so far has been centered around the default. I
> consider myself agnostic in this case: I think that it is better
> to use the stricter criteria and be compatible with MS Excel.
> A lot of people worry about compatibility issues.
>
> With my FreeBSD hat on, I think in the unsupported platforms
> (FreeBSD, OS2, Solaris) the compatibility issue isn't really a
> concern (the ASF has never provided officially binaries) but
> the Excel behaviour is useful for interoperability.
>
> I think the best option would be if existing users take a decision
> before release what behaviour the want and if the case is to revert
> we can add something like
>
> #if defined(WINOS) || defined(MACOSX) || defined(LINUX)
> #defined SAL_STRICTER_MATH
> #endif

I am not sure that the logic is right here.  First you say that for 
FreeBSD, OS2 and Solaris compatibility is not an issue and imply that 
using "stricter" math on these platforms where OK.  But then you define 
SAL_STRICTER_MATH for Windows, MacOS and Linux.  Which one is right?

Besides, I hope that this code snipped will not go into a source file 
like rtl/math.hxx.  The SAL_STRICTER_MATH flag is technically not tied 
to any platform.  But a test like the one above would suggest that it 
does only run on Windows, Mac, and Linux.


But the most important point is that with logic like this the choice of 
using "stricter" math still has to be made when AOO is built, ie not by 
users but by developers and ultimately by the release engineer.

>
> You get the idea. Doing this is rather ugly but I can live with it

I can not.

>   as
> at least windows and MacOSX have the option to use Excel if they
> want to be serious about math.
>
> I guess we could add it as a configure option but we already have
> too many of them and even then there has to be a default.
>
> This is something I think the comunity has to decide on by voting
> before the release. I won't take the decision but since I take care
> for FreeBSD, I think we will opt for the Excel compatibility (I do
> have to consult with Maho though).

Are you really suggesting to ship AOO on FreeBSD with different behavior 
then on eg Windows?
What good can come from that?  Documents would not be compatible inside 
the same application when moved from one platform to another.  Please 
don't do that.

-Andre

>
> THE BAD
>
> (Please stop reading here if you are sensible to non-technical issues)
>
> First I should thank Greg Stein for clarifying the correct sense and reach
> of the veto. I also want to thank people that have expressed their support
> in private or public. It is clear to me that we are still too young as a community
> in AOO and that people still have a long way to learn in matters of behaviour.
>
> I am not as much disappointed by the discussion (which I think
> doesn't correspond to the impact of the patch) but by the fact that
> I was not given the chance to work on it and that I have been
> insulted in the process.
>
> I strongly complained when Dave's commit was reverted and I find
> it absolutely unacceptable in the way it was done with me. First
> of all the harassment: I am a volunteer, I am not here to receive
> something in the lines of "Revert now or else ...", and second the
> lack of respect for my work.
>
> It *is* rude, really ... I *don't* care much what happens with the patch,
> if it should be disabled or not, but I DO want respect.
>
> I think I deserve reparation for the commit reversal: this shouldn't have
> happened. I request the code be restated as it should have never been
> reverted in the first place. This is all symbolical as there is a new version.
> Once the new version is in, I will let anyone else decide if you guys
> want to ifdef it or add a configure option or whatever: I don't really want
> to be involved in this anymore.
>
>
> I also want an assurance that this will never *ever* happen again (I am
> talking about the revert, I guess bikesheds are unavoidable).
>
> If people really don't like my patches (yes, according to the Berne convention
> I do own them)  I will take them with me but I prefer if there is a civilized
> discussion and not this circus we have been experiencing these last days.
>
> Pedro.
>
> [1] http://people.apache.org/~pfg/patches/patch-power00

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Kay Schenk <ka...@gmail.com>]

On Mon, Feb 18, 2013 at 12:26 AM, Jürgen Schmidt <jo...@gmail.com>wrote:

> On 2/18/13 1:15 AM, Pedro Giffuni wrote:
> > Hello;
> >
> >
> > Well, as you might imagine I am really tired of the flame storm that
> > went around the 0 ^ 0 issue. My intention here is not at all to re-start
> > that discussion. I really have much more fun things to do.
> > I am actualy a fan of Clint Eastwood so let me remember one of
> > my favorite movies ever.
> >
> > THE GOOD
> >
> > It didn't really take me long but I found a technical solution for the
> > dilemma.
> >
> > - The numerical issues were caused by a copy-paste error where the
> > C++ wrapper used int for the exponent instead of a double. Once
> > found it was trivial to fix.
> >
> > - Considering the "vetos" I still think they are invalid but I think they
> > both reflect a community concern so I have addressed it.
> >
> > The new patch [1] now defines in SAL's math.h the following:
> >
> > #define SAL_STRICTER_MATH
> >
> >
> > This currently only affects the power function and acts as a
> > sort of "excel compatibility" flag. This is very simple at this time
> > but it fulfills it's task: you can easily change the behaviour
> > during compile time.
>
> I don't think that this new define is a clean and good approach to move
> forward. I would prefer to introduce a further power function that
> behaves like Excel.


+1 on this suggestion...

It seems to me that a user controlled option might work best in this case.


> The import filter should be changed to use the new
> one in the future. The export will revert this. When I remember it
> correctly there is already some mode for this.
>
> >
> > It is actually an advance because having this in SAL gives us control:
> > our current behavior is platform dependent.
> >
> > THE UGLY
> >
> > The discussion so far has been centered around the default. I
> > consider myself agnostic in this case: I think that it is better
> > to use the stricter criteria and be compatible with MS Excel.
> > A lot of people worry about compatibility issues.
>
> sure and I believe there is a better way for this specific case by
> introducing a further power function as described above.
>
> >
> > With my FreeBSD hat on, I think in the unsupported platforms
> > (FreeBSD, OS2, Solaris) the compatibility issue isn't really a
> > concern (the ASF has never provided officially binaries) but
> > the Excel behaviour is useful for interoperability.
>
> please don't move on this level. I am sure sure we don't really want a
> different behaviour on different platforms. Our users would be
> completely confused and nobody would understand what's happened.
>
> >
> > I think the best option would be if existing users take a decision
> > before release what behaviour the want and if the case is to revert
> > we can add something like
> >
> > #if defined(WINOS) || defined(MACOSX) || defined(LINUX)
> > #defined SAL_STRICTER_MATH
> > #endif
> >
> > You get the idea. Doing this is rather ugly but I can live with it as
> > at least windows and MacOSX have the option to use Excel if they
> > want to be serious about math.
>
> yes I get your idea and don't like it because I think it gives the
> completely wrong impression. I believe that majority now want the old
> behaviour and if we want support for the excel behaviour we have to
> discuss and to find a new approach.
>
> >
> > I guess we could add it as a configure option but we already have
> > too many of them and even then there has to be a default.
> >
> > This is something I think the comunity has to decide on by voting
> > before the release. I won't take the decision but since I take care
> > for FreeBSD, I think we will opt for the Excel compatibility (I do
> > have to consult with Maho though).
>
> again if you prefer to go your own way here for one platform I believe
> it is the completely wrong way and you potentially damage much more with
> such a direction.
>
> >
> > THE BAD
> >
> > (Please stop reading here if you are sensible to non-technical issues)
> >
> > First I should thank Greg Stein for clarifying the correct sense and
> reach
> > of the veto. I also want to thank people that have expressed their
> support
> > in private or public. It is clear to me that we are still too young as a
> community
> > in AOO and that people still have a long way to learn in matters of
> behaviour.
> >
> > I am not as much disappointed by the discussion (which I think
> > doesn't correspond to the impact of the patch) but by the fact that
> > I was not given the chance to work on it and that I have been
> > insulted in the process.
> >
> > I strongly complained when Dave's commit was reverted and I find
> > it absolutely unacceptable in the way it was done with me. First
> > of all the harassment: I am a volunteer, I am not here to receive
> > something in the lines of "Revert now or else ...", and second the
> > lack of respect for my work.
> >
> > It *is* rude, really ... I *don't* care much what happens with the patch,
> > if it should be disabled or not, but I DO want respect.
> >
> > I think I deserve reparation for the commit reversal: this shouldn't have
> > happened.
>
> +1, it shouldn't have happened
>
> I request the code be restated as it should have never been
> > reverted in the first place. This is all symbolical as there is a new
> version.
> > Once the new version is in, I will let anyone else decide if you guys
> > want to ifdef it or add a configure option or whatever: I don't really
> want
> > to be involved in this anymore.
>
> I am personally strongly against this, we are not in a play school. Rob
> had made a mistake and he apologized for this already.
>
> If the patch gets reworked and the behaviour is as before without this
> ugly define option we can talk about it. Otherwise I would recommend to
> let is as it is now and seek a solution first.
>
> We can discuss the ifdef or configure option in another thread but I
> personally don't like both and believe it's the wrong way.
>
> >
> >
> > I also want an assurance that this will never *ever* happen again (I am
> > talking about the revert, I guess bikesheds are unavoidable).
> >
> > If people really don't like my patches (yes, according to the Berne
> convention
> > I do own them)  I will take them with me but I prefer if there is a
> civilized
> > discussion and not this circus we have been experiencing these last days.
> >
>
> sorry Petro, I very much appreciate what you are doing but you are a big
> part of this so called circus from my pov. Really clever would have been
> to revert the patch immediately on your own, show understanding for the
> concerns and move into further discussion. Or better not integrate the
> patch at all because there were already concerns when I get it correct.
>
> Juergen
>
>
>
> > Pedro.
> >
> > [1] http://people.apache.org/~pfg/patches/patch-power00
> >
>
>


-- 
----------------------------------------------------------------------------------------
MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Jürgen Schmidt <jo...@gmail.com>]

On 2/18/13 1:15 AM, Pedro Giffuni wrote:
> Hello;
> 
> 
> Well, as you might imagine I am really tired of the flame storm that
> went around the 0 ^ 0 issue. My intention here is not at all to re-start
> that discussion. I really have much more fun things to do.
> I am actualy a fan of Clint Eastwood so let me remember one of
> my favorite movies ever.
> 
> THE GOOD
> 
> It didn't really take me long but I found a technical solution for the
> dilemma.
> 
> - The numerical issues were caused by a copy-paste error where the
> C++ wrapper used int for the exponent instead of a double. Once
> found it was trivial to fix.
> 
> - Considering the "vetos" I still think they are invalid but I think they
> both reflect a community concern so I have addressed it.
> 
> The new patch [1] now defines in SAL's math.h the following:
> 
> #define SAL_STRICTER_MATH
> 
> 
> This currently only affects the power function and acts as a
> sort of "excel compatibility" flag. This is very simple at this time
> but it fulfills it's task: you can easily change the behaviour
> during compile time.

I don't think that this new define is a clean and good approach to move
forward. I would prefer to introduce a further power function that
behaves like Excel. The import filter should be changed to use the new
one in the future. The export will revert this. When I remember it
correctly there is already some mode for this.

> 
> It is actually an advance because having this in SAL gives us control:
> our current behavior is platform dependent.
> 
> THE UGLY
> 
> The discussion so far has been centered around the default. I
> consider myself agnostic in this case: I think that it is better
> to use the stricter criteria and be compatible with MS Excel.
> A lot of people worry about compatibility issues.

sure and I believe there is a better way for this specific case by
introducing a further power function as described above.

> 
> With my FreeBSD hat on, I think in the unsupported platforms
> (FreeBSD, OS2, Solaris) the compatibility issue isn't really a
> concern (the ASF has never provided officially binaries) but
> the Excel behaviour is useful for interoperability.

please don't move on this level. I am sure sure we don't really want a
different behaviour on different platforms. Our users would be
completely confused and nobody would understand what's happened.

> 
> I think the best option would be if existing users take a decision
> before release what behaviour the want and if the case is to revert
> we can add something like
> 
> #if defined(WINOS) || defined(MACOSX) || defined(LINUX) 
> #defined SAL_STRICTER_MATH
> #endif
> 
> You get the idea. Doing this is rather ugly but I can live with it as
> at least windows and MacOSX have the option to use Excel if they
> want to be serious about math.

yes I get your idea and don't like it because I think it gives the
completely wrong impression. I believe that majority now want the old
behaviour and if we want support for the excel behaviour we have to
discuss and to find a new approach.

> 
> I guess we could add it as a configure option but we already have
> too many of them and even then there has to be a default.
> 
> This is something I think the comunity has to decide on by voting
> before the release. I won't take the decision but since I take care
> for FreeBSD, I think we will opt for the Excel compatibility (I do
> have to consult with Maho though).

again if you prefer to go your own way here for one platform I believe
it is the completely wrong way and you potentially damage much more with
such a direction.

> 
> THE BAD
> 
> (Please stop reading here if you are sensible to non-technical issues)
> 
> First I should thank Greg Stein for clarifying the correct sense and reach
> of the veto. I also want to thank people that have expressed their support
> in private or public. It is clear to me that we are still too young as a community
> in AOO and that people still have a long way to learn in matters of behaviour.
> 
> I am not as much disappointed by the discussion (which I think
> doesn't correspond to the impact of the patch) but by the fact that
> I was not given the chance to work on it and that I have been
> insulted in the process.
> 
> I strongly complained when Dave's commit was reverted and I find
> it absolutely unacceptable in the way it was done with me. First
> of all the harassment: I am a volunteer, I am not here to receive
> something in the lines of "Revert now or else ...", and second the
> lack of respect for my work.
> 
> It *is* rude, really ... I *don't* care much what happens with the patch,
> if it should be disabled or not, but I DO want respect.
> 
> I think I deserve reparation for the commit reversal: this shouldn't have
> happened. 

+1, it shouldn't have happened

I request the code be restated as it should have never been
> reverted in the first place. This is all symbolical as there is a new version.
> Once the new version is in, I will let anyone else decide if you guys
> want to ifdef it or add a configure option or whatever: I don't really want
> to be involved in this anymore. 

I am personally strongly against this, we are not in a play school. Rob
had made a mistake and he apologized for this already.

If the patch gets reworked and the behaviour is as before without this
ugly define option we can talk about it. Otherwise I would recommend to
let is as it is now and seek a solution first.

We can discuss the ifdef or configure option in another thread but I
personally don't like both and believe it's the wrong way.

> 
> 
> I also want an assurance that this will never *ever* happen again (I am
> talking about the revert, I guess bikesheds are unavoidable).
> 
> If people really don't like my patches (yes, according to the Berne convention
> I do own them)  I will take them with me but I prefer if there is a civilized
> discussion and not this circus we have been experiencing these last days.
> 

sorry Petro, I very much appreciate what you are doing but you are a big
part of this so called circus from my pov. Really clever would have been
to revert the patch immediately on your own, show understanding for the
concerns and move into further discussion. Or better not integrate the
patch at all because there were already concerns when I get it correct.

Juergen



> Pedro.
> 
> [1] http://people.apache.org/~pfg/patches/patch-power00
> 

Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)

[Pedro Giffuni <pf...@apache.org>]

Hello;


Well, as you might imagine I am really tired of the flame storm that
went around the 0 ^ 0 issue. My intention here is not at all to re-start
that discussion. I really have much more fun things to do.
I am actualy a fan of Clint Eastwood so let me remember one of
my favorite movies ever.

THE GOOD

It didn't really take me long but I found a technical solution for the
dilemma.

- The numerical issues were caused by a copy-paste error where the
C++ wrapper used int for the exponent instead of a double. Once
found it was trivial to fix.

- Considering the "vetos" I still think they are invalid but I think they
both reflect a community concern so I have addressed it.

The new patch [1] now defines in SAL's math.h the following:

#define SAL_STRICTER_MATH


This currently only affects the power function and acts as a
sort of "excel compatibility" flag. This is very simple at this time
but it fulfills it's task: you can easily change the behaviour
during compile time.

It is actually an advance because having this in SAL gives us control:
our current behavior is platform dependent.

THE UGLY

The discussion so far has been centered around the default. I
consider myself agnostic in this case: I think that it is better
to use the stricter criteria and be compatible with MS Excel.
A lot of people worry about compatibility issues.

With my FreeBSD hat on, I think in the unsupported platforms
(FreeBSD, OS2, Solaris) the compatibility issue isn't really a
concern (the ASF has never provided officially binaries) but
the Excel behaviour is useful for interoperability.

I think the best option would be if existing users take a decision
before release what behaviour the want and if the case is to revert
we can add something like

#if defined(WINOS) || defined(MACOSX) || defined(LINUX) 
#defined SAL_STRICTER_MATH
#endif

You get the idea. Doing this is rather ugly but I can live with it as
at least windows and MacOSX have the option to use Excel if they
want to be serious about math.

I guess we could add it as a configure option but we already have
too many of them and even then there has to be a default.

This is something I think the comunity has to decide on by voting
before the release. I won't take the decision but since I take care
for FreeBSD, I think we will opt for the Excel compatibility (I do
have to consult with Maho though).

THE BAD

(Please stop reading here if you are sensible to non-technical issues)

First I should thank Greg Stein for clarifying the correct sense and reach
of the veto. I also want to thank people that have expressed their support
in private or public. It is clear to me that we are still too young as a community
in AOO and that people still have a long way to learn in matters of behaviour.

I am not as much disappointed by the discussion (which I think
doesn't correspond to the impact of the patch) but by the fact that
I was not given the chance to work on it and that I have been
insulted in the process.

I strongly complained when Dave's commit was reverted and I find
it absolutely unacceptable in the way it was done with me. First
of all the harassment: I am a volunteer, I am not here to receive
something in the lines of "Revert now or else ...", and second the
lack of respect for my work.

It *is* rude, really ... I *don't* care much what happens with the patch,
if it should be disabled or not, but I DO want respect.

I think I deserve reparation for the commit reversal: this shouldn't have
happened. I request the code be restated as it should have never been
reverted in the first place. This is all symbolical as there is a new version.
Once the new version is in, I will let anyone else decide if you guys
want to ifdef it or add a configure option or whatever: I don't really want
to be involved in this anymore. 


I also want an assurance that this will never *ever* happen again (I am
talking about the revert, I guess bikesheds are unavoidable).

If people really don't like my patches (yes, according to the Berne convention
I do own them)  I will take them with me but I prefer if there is a civilized
discussion and not this circus we have been experiencing these last days.

Pedro.

[1] http://people.apache.org/~pfg/patches/patch-power00

Re: Calc behavior: result of 0 ^ 0

[Kay Schenk <ka...@gmail.com>]

On Wed, Feb 13, 2013 at 9:30 AM, Rob Weir <ro...@apache.org> wrote:

> On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer <jo...@yahoo.com>
> wrote:
> > OTOH I haven't seen anyone issue a technical
> > veto on this change, which is really what's
> > required before Pedro actually needs to revert
> > anything.
> >
>
> I was waiting to see if there were any persuasive arguments in favor
> of breaking backwards compatibility before deciding whether to do
> that.  I think things are getting a little clearer now with Norbert's
> contribution to the discussion.  But if (as it seems now) that
> "mathematical correctness" does not justify the change, then my
> position would be that we don't break backwards compatibility.
>
> Also, a veto would be a blunt instrument and I'd rather avoid it if
> further discussion leads to a consensus.
>
> -Rob
>

Given this discussion and research I've done on my own, I will veto this
change and would like to see it reverted. Sorry, Pedro!  and thanks you
Norbert and others for this worthy discussion.


>
> >
> >
> >
> >
> >>________________________________
> >> From: Joe Schaefer <jo...@yahoo.com>
> >>To: "dev@openoffice.apache.org" <de...@openoffice.apache.org>; Pedro
> Giffuni <pf...@apache.org>
> >>Sent: Wednesday, February 13, 2013 10:53 AM
> >>Subject: Re: Calc behavior: result of 0 ^ 0
> >>
> >>
> >>Honestly I'd say that if anything is clear,
> >>it's that changing away from the status quo
> >>currently enjoys zero consensus.
> >>
> >>As a Ph.D. mathematician who knows about Bourbaki,
> >>all I can say is that line of argument is curious
> >>here.  There are no authorities other than the spec
> >>to turn to about how you want POWER(0,0) to behave-
> >>as a function of 2 variables returning an error is
> >>probably best mathematically because the POWER
> >>function isn't remotely continuous at (0,0), but as
> >>part of an implementation of power series
> >>representations of sums involving 0^0, returning 1
> >>is better.
> >>
> >>
> >>
> >>In any case, the idea for how issues like this should
> >>be resolved at Apache is always in favor of stability;
> >>that's why the impetus for consensus away from the current
> >>behavior is required, not a general discussion about
> >>which behavior is better given two equal choices
> >>in the abstract.  A prior decision has already been made
> >>about the code, and those that wish to change it need
> >>to demonstrate consensus for the change, not the other
> >>way around.
> >>
> >>
> >>
> >>HTH
> >>
> >>
> >>
> >>
> >>>________________________________
> >>> From: RGB ES <rg...@gmail.com>
> >>>To: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org>
> >>>Sent: Wednesday, February 13, 2013 10:43 AM
> >>>Subject: Re: Calc behavior: result of 0 ^ 0
> >>>
> >>>Not answering any particular message, so top posting.
> >>>
> >>>Two points:
> >>>
> >>>a) Of course you can always redefine a function to "fill holes" on non
> >>>defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on
> x=0
> >>>makes sense because you obtain a continuous function... but that's on 1
> >>>variable: when you go to two variables things become more difficult. In
> >>>fact, the limit for x^y with x *and* y tending to zero do NOT exists
> >>>(choose a different path and you'll get a different limit), then there
> is
> >>>NO way to make that function continuous on (0,0), let alone what happens
> >>>when x < 0... so the real question is: does it make sense to "fill the
> >>>hole" on x^y? *My* answer (and that leads to the second point) is no
> >>>because it do not give any added value.
> >>>
> >>>b) Considering that we are near to 90 messages on this thread it is
> quite
> >>>clear that an agreement is not possible. On this situation it is also
> clear
> >>>that
> >  choosing an error instead of a fixed value is the best bet.
> >>>
> >>>Just my 2¢
> >>>
> >>>Regards
> >>>Ricardo
> >>>
> >>>
> >>>2013/2/13 Pedro Giffuni <pf...@apache.org>
> >>>
> >>>> Hello;
> >>>>
> >>>> >
> >>>> > Da: Norbert Thiebaud
> >>>> ...
> >>>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com>
> wrote:
> >>>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org>
> wrote:
> >>>> >>
> >>>> >>> (OK, I guess it's better to re-subscribe to the list).
> >>>> >>>
> >>>> >>> In reply to Norbert Thiebaud*:
> >>>> >>>
> >>>> >>> In the Power rule, which *is* commonly used for differentiation,
> we
> >>>> take a series
> >>>> >>> of
> >  polinomials where n !=0. n is not only different than zero, most
> >>>> importantly,
> >>>> >>> it is a constant.
> >>>> >
> >>>> >Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
> >>>> >so for n=1  (which _is_ different of 0 !)
> >>>> >d/dx X = 1.x^0
> >>>> >for _all_ x. including x=0. (last I check f(x) = x is differentiable
> in 0.
> >>>> >
> >>>> >I know math can be challenging... but you don't get to invent
> >>>> >restriction on the Power Rule just to fit you argument.
> >>>> >
> >>>>
> >>>> I will put it in simple terms. You are saying that you can't
> calculate the
> >>>> slope of the equation:
> >>>>
> >>>> y =a*x + b
> >>>>
> >>>> because in the process you need to calculate the value of x^0.
> >>>>
> >>>>
> >>>> >>>
> >>>>
> >>>> >>> In the case of the set theory book, do note that the author is
> >>>> constructing
> >>>> >>> his own
> >  algebra,
> >>>> >
> >>>> >The fact that you call 'Nicola Bourbaki' 'the author', is in itself
> >>>> >very telling about your expertise in Math.
> >>>> >I nicely put a link to the wikipedia page, since laymen are indeed
> >>>> >unlikely to know 'who' Borbaki is.
> >>>> >
> >>>>
> >>>> Do I really care if the name of the author is fictitious or real?
> >>>>
> >>>> >>> that get outside his set: 0^0 and x/0 are such cases. The text is
> not
> >>>> >>> a demonstration, it is simply a statement taken out of context.
> >>>> >
> >>>> >You ask for a practical spreadsheet example, when one is given you
> >>>> >invent new 'rules' to ignore' it.
> >>>>
> >>>> You haven't provided so far that practical spreadsheet.
> >>>>
> >>>> >You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
> >>>> >And when I gave you the page and line from one of the most rigorous
> >>>> >mathematical
> >  body of work of the 20th century (yep Bourbaki... look it
> >>>> >up)
> >>>> >you and hand-wave, pretending the author did not mean it.. or even
> >>>> >better " if this author(sic) *is* using mathematics correctly."
> >>>> >
> >>>>
> >>>> The thing is that you are taking statements out of context. I don't
> >>>> claim being a mathematithian. I took a few courses from the career for
> >>>> fun.
> >>>>
> >>>> In the case of set theory you can define, for your own purposes, a
> special
> >>>> algebra where:
> >>>>
> >>>> - You redefine your own multiplication operator (x).
> >>>> - You don't define division.
> >>>> - You make yor algebra system fit into a set of properties that
> >>>> is useful for your own properties.
> >>>>
> >>>> Once you define your own multiplication (which is not the same
> >>>> multiplication supported in a spreadsheet) You work around the
> >>>> issue in the power operator by defining the undefined
> >  case.
> >>>>
> >>>> These are all nice mathematical models that don't apply to a
> spreadsheet.
> >>>>
> >>>> >>>
> >>>> >>> I guess looking hard it may be possible to find an elaborated case
> >>>> where
> >>>> >>> someone manages to shoot himself in the foot
> >>>> >
> >>>> >Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
> >>>> >for shooting himself in the foot when doing math...
> >>>> >
> >>>> >For those interested in the actual Math... in Math words have meaning
> >>>> >and that meaning have often context. let me develop a bit the notion
> >>>> >of 'form' mentioned earlier:
> >>>> >for instance in the expression 'in an indeterminate form', there is
> >>>> >'form' and it matter because in the context of determining extension
> >>>> >by continuity of a function, there are certain case where you can
> >>>> >transform you equation into another 'form' but
> >  if these transformation
> >>>> >lead you to an 'indeterminate form', you have to find another
> >>>> >transformation to continue...
> >>>> >hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once
> it
> >>>> >is establish that h actually converge in the operating set, and that
> >>>> >is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
> >>>> >passing 'to the limit' in each term would yield 0^0 with is a
> >>>> >indeterminable 'form' (not a value, not a number, not claimed to be
> >>>> >the result of a calculation of power(0,0), but a 'form' of the
> >>>> >equation that is indeterminate...) at which point you cannot
> conclude,
> >>>> >what the limit is. What a mathematician is to do is to 'trans-form'
> >>>> >the original h in such a way that it lead him to a path to an actual
> >>>> >value.
> >>>> >
> >>>> >in other words that is a very specific
> >  meaning for a very specific
> >>>> >subset of mathematics, that does not conflict with defining
> power(0,0)
> >>>> >= 1.
> >>>> >
> >>>> >
> >>>> >wrt to the 'context' of the quote I gave earlier:
> >>>> >
> >>>> >"Proposition 9: : Let X and Y be two sets, a and b their respective
> >>>> >cardinals, then the set X{superscript Y} has cardinal a {superscript
> >>>> >b}. "
> >>>> >
> >>>> >( I will use x^y here from now on to note x {superscript y} for
> >>>> readability )
> >>>> >
> >>>> >"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
> >>>> >and 0^a = 0 if a != 0
> >>>> >
> >>>> >For there exist a unique mapping of 'empty-set' into any given set
> >>>> >(namely, the mapping whose graph is the empty set); the set of
> >>>> >mappings of a set consisting of a single element into an arbitrary
> set
> >>>> >X is equipotent to X (Chapter II, pragraph 5.3); there
> >  exist a unique
> >>>> >mapping of an arbitrary set into a set consisting of a single
> element;
> >>>> >and finally there is not mapping of a non-empty set into the
> >>>> >empty-set;
> >>>> >* Note in particular that 0^0 = 1
> >>>> >"
> >>>>
> >>>> Again, I will stand to what I said: this statement is not a
> demonstration
> >>>> and is taken out of context. The definition is given to conform with
> this
> >>>> "unique mapping" which unfortunately doesn't exist in the real world.
> >>>>
> >>>>
> >>>> >
> >>>> >Here is the full context of the quote. And if you think you have a
> >>>> >proof that there is a mathematical error there, by all means, rush to
> >>>> >your local university, as surely proving that half-way to the first
> >>>> >volume, on set theory, of a body of work that is acclaimed for it's
> >>>> >rigor and aim at grounding the entire field of mathematics soundly in
> >>>> >the rigor of set
> >  theory, there is an 'error', will surely promptly get
> >>>> >you a PhD in math... since that has escaped the attentive scrutiny
> and
> >>>> >peer review of the entire world of mathematicians for decades...
> >>>> >
> >>>>
> >>>> I lost contact with my teacher, indeed quite an authority, but for
> some
> >>>> reason he disliked computer math to the extreme anyways.
> >>>>
> >>>> Pedro.
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
>



-- 
----------------------------------------------------------------------------------------
MzK

"A great deal of talent is lost to the world
      for want of a little courage."
                             -- Sydney Smith

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> OTOH I haven't seen anyone issue a technical
> veto on this change, which is really what's
> required before Pedro actually needs to revert
> anything.
>

I was waiting to see if there were any persuasive arguments in favor
of breaking backwards compatibility before deciding whether to do
that.  I think things are getting a little clearer now with Norbert's
contribution to the discussion.  But if (as it seems now) that
"mathematical correctness" does not justify the change, then my
position would be that we don't break backwards compatibility.

Also, a veto would be a blunt instrument and I'd rather avoid it if
further discussion leads to a consensus.

-Rob

>
>
>
>
>>________________________________
>> From: Joe Schaefer <jo...@yahoo.com>
>>To: "dev@openoffice.apache.org" <de...@openoffice.apache.org>; Pedro Giffuni <pf...@apache.org>
>>Sent: Wednesday, February 13, 2013 10:53 AM
>>Subject: Re: Calc behavior: result of 0 ^ 0
>>
>>
>>Honestly I'd say that if anything is clear,
>>it's that changing away from the status quo
>>currently enjoys zero consensus.
>>
>>As a Ph.D. mathematician who knows about Bourbaki,
>>all I can say is that line of argument is curious
>>here.  There are no authorities other than the spec
>>to turn to about how you want POWER(0,0) to behave-
>>as a function of 2 variables returning an error is
>>probably best mathematically because the POWER
>>function isn't remotely continuous at (0,0), but as
>>part of an implementation of power series
>>representations of sums involving 0^0, returning 1
>>is better.
>>
>>
>>
>>In any case, the idea for how issues like this should
>>be resolved at Apache is always in favor of stability;
>>that's why the impetus for consensus away from the current
>>behavior is required, not a general discussion about
>>which behavior is better given two equal choices
>>in the abstract.  A prior decision has already been made
>>about the code, and those that wish to change it need
>>to demonstrate consensus for the change, not the other
>>way around.
>>
>>
>>
>>HTH
>>
>>
>>
>>
>>>________________________________
>>> From: RGB ES <rg...@gmail.com>
>>>To: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org>
>>>Sent: Wednesday, February 13, 2013 10:43 AM
>>>Subject: Re: Calc behavior: result of 0 ^ 0
>>>
>>>Not answering any particular message, so top posting.
>>>
>>>Two points:
>>>
>>>a) Of course you can always redefine a function to "fill holes" on non
>>>defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0
>>>makes sense because you obtain a continuous function... but that's on 1
>>>variable: when you go to two variables things become more difficult. In
>>>fact, the limit for x^y with x *and* y tending to zero do NOT exists
>>>(choose a different path and you'll get a different limit), then there is
>>>NO way to make that function continuous on (0,0), let alone what happens
>>>when x < 0... so the real question is: does it make sense to "fill the
>>>hole" on x^y? *My* answer (and that leads to the second point) is no
>>>because it do not give any added value.
>>>
>>>b) Considering that we are near to 90 messages on this thread it is quite
>>>clear that an agreement is not possible. On this situation it is also clear
>>>that
>  choosing an error instead of a fixed value is the best bet.
>>>
>>>Just my 2¢
>>>
>>>Regards
>>>Ricardo
>>>
>>>
>>>2013/2/13 Pedro Giffuni <pf...@apache.org>
>>>
>>>> Hello;
>>>>
>>>> >
>>>> > Da: Norbert Thiebaud
>>>> ...
>>>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>>>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>>> >>
>>>> >>> (OK, I guess it's better to re-subscribe to the list).
>>>> >>>
>>>> >>> In reply to Norbert Thiebaud*:
>>>> >>>
>>>> >>> In the Power rule, which *is* commonly used for differentiation, we
>>>> take a series
>>>> >>> of
>  polinomials where n !=0. n is not only different than zero, most
>>>> importantly,
>>>> >>> it is a constant.
>>>> >
>>>> >Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
>>>> >so for n=1  (which _is_ different of 0 !)
>>>> >d/dx X = 1.x^0
>>>> >for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
>>>> >
>>>> >I know math can be challenging... but you don't get to invent
>>>> >restriction on the Power Rule just to fit you argument.
>>>> >
>>>>
>>>> I will put it in simple terms. You are saying that you can't calculate the
>>>> slope of the equation:
>>>>
>>>> y =a*x + b
>>>>
>>>> because in the process you need to calculate the value of x^0.
>>>>
>>>>
>>>> >>>
>>>>
>>>> >>> In the case of the set theory book, do note that the author is
>>>> constructing
>>>> >>> his own
>  algebra,
>>>> >
>>>> >The fact that you call 'Nicola Bourbaki' 'the author', is in itself
>>>> >very telling about your expertise in Math.
>>>> >I nicely put a link to the wikipedia page, since laymen are indeed
>>>> >unlikely to know 'who' Borbaki is.
>>>> >
>>>>
>>>> Do I really care if the name of the author is fictitious or real?
>>>>
>>>> >>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>>>> >>> a demonstration, it is simply a statement taken out of context.
>>>> >
>>>> >You ask for a practical spreadsheet example, when one is given you
>>>> >invent new 'rules' to ignore' it.
>>>>
>>>> You haven't provided so far that practical spreadsheet.
>>>>
>>>> >You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
>>>> >And when I gave you the page and line from one of the most rigorous
>>>> >mathematical
>  body of work of the 20th century (yep Bourbaki... look it
>>>> >up)
>>>> >you and hand-wave, pretending the author did not mean it.. or even
>>>> >better " if this author(sic) *is* using mathematics correctly."
>>>> >
>>>>
>>>> The thing is that you are taking statements out of context. I don't
>>>> claim being a mathematithian. I took a few courses from the career for
>>>> fun.
>>>>
>>>> In the case of set theory you can define, for your own purposes, a special
>>>> algebra where:
>>>>
>>>> - You redefine your own multiplication operator (x).
>>>> - You don't define division.
>>>> - You make yor algebra system fit into a set of properties that
>>>> is useful for your own properties.
>>>>
>>>> Once you define your own multiplication (which is not the same
>>>> multiplication supported in a spreadsheet) You work around the
>>>> issue in the power operator by defining the undefined
>  case.
>>>>
>>>> These are all nice mathematical models that don't apply to a spreadsheet.
>>>>
>>>> >>>
>>>> >>> I guess looking hard it may be possible to find an elaborated case
>>>> where
>>>> >>> someone manages to shoot himself in the foot
>>>> >
>>>> >Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
>>>> >for shooting himself in the foot when doing math...
>>>> >
>>>> >For those interested in the actual Math... in Math words have meaning
>>>> >and that meaning have often context. let me develop a bit the notion
>>>> >of 'form' mentioned earlier:
>>>> >for instance in the expression 'in an indeterminate form', there is
>>>> >'form' and it matter because in the context of determining extension
>>>> >by continuity of a function, there are certain case where you can
>>>> >transform you equation into another 'form' but
>  if these transformation
>>>> >lead you to an 'indeterminate form', you have to find another
>>>> >transformation to continue...
>>>> >hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
>>>> >is establish that h actually converge in the operating set, and that
>>>> >is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
>>>> >passing 'to the limit' in each term would yield 0^0 with is a
>>>> >indeterminable 'form' (not a value, not a number, not claimed to be
>>>> >the result of a calculation of power(0,0), but a 'form' of the
>>>> >equation that is indeterminate...) at which point you cannot conclude,
>>>> >what the limit is. What a mathematician is to do is to 'trans-form'
>>>> >the original h in such a way that it lead him to a path to an actual
>>>> >value.
>>>> >
>>>> >in other words that is a very specific
>  meaning for a very specific
>>>> >subset of mathematics, that does not conflict with defining power(0,0)
>>>> >= 1.
>>>> >
>>>> >
>>>> >wrt to the 'context' of the quote I gave earlier:
>>>> >
>>>> >"Proposition 9: : Let X and Y be two sets, a and b their respective
>>>> >cardinals, then the set X{superscript Y} has cardinal a {superscript
>>>> >b}. "
>>>> >
>>>> >( I will use x^y here from now on to note x {superscript y} for
>>>> readability )
>>>> >
>>>> >"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
>>>> >and 0^a = 0 if a != 0
>>>> >
>>>> >For there exist a unique mapping of 'empty-set' into any given set
>>>> >(namely, the mapping whose graph is the empty set); the set of
>>>> >mappings of a set consisting of a single element into an arbitrary set
>>>> >X is equipotent to X (Chapter II, pragraph 5.3); there
>  exist a unique
>>>> >mapping of an arbitrary set into a set consisting of a single element;
>>>> >and finally there is not mapping of a non-empty set into the
>>>> >empty-set;
>>>> >* Note in particular that 0^0 = 1
>>>> >"
>>>>
>>>> Again, I will stand to what I said: this statement is not a demonstration
>>>> and is taken out of context. The definition is given to conform with this
>>>> "unique mapping" which unfortunately doesn't exist in the real world.
>>>>
>>>>
>>>> >
>>>> >Here is the full context of the quote. And if you think you have a
>>>> >proof that there is a mathematical error there, by all means, rush to
>>>> >your local university, as surely proving that half-way to the first
>>>> >volume, on set theory, of a body of work that is acclaimed for it's
>>>> >rigor and aim at grounding the entire field of mathematics soundly in
>>>> >the rigor of set
>  theory, there is an 'error', will surely promptly get
>>>> >you a PhD in math... since that has escaped the attentive scrutiny and
>>>> >peer review of the entire world of mathematicians for decades...
>>>> >
>>>>
>>>> I lost contact with my teacher, indeed quite an authority, but for some
>>>> reason he disliked computer math to the extreme anyways.
>>>>
>>>> Pedro.
>>>>
>>>
>>>
>>>
>>
>>

Re: Calc behavior: result of 0 ^ 0

[Joe Schaefer <jo...@yahoo.com>]

OTOH I haven't seen anyone issue a technical
veto on this change, which is really what's
required before Pedro actually needs to revert
anything.





>________________________________
> From: Joe Schaefer <jo...@yahoo.com>
>To: "dev@openoffice.apache.org" <de...@openoffice.apache.org>; Pedro Giffuni <pf...@apache.org> 
>Sent: Wednesday, February 13, 2013 10:53 AM
>Subject: Re: Calc behavior: result of 0 ^ 0
> 
>
>Honestly I'd say that if anything is clear,
>it's that changing away from the status quo
>currently enjoys zero consensus.
>
>As a Ph.D. mathematician who knows about Bourbaki,
>all I can say is that line of argument is curious
>here.  There are no authorities other than the spec
>to turn to about how you want POWER(0,0) to behave-
>as a function of 2 variables returning an error is
>probably best mathematically because the POWER
>function isn't remotely continuous at (0,0), but as
>part of an implementation of power series
>representations of sums involving 0^0, returning 1
>is better.
>
>
>
>In any case, the idea for how issues like this should
>be resolved at Apache is always in favor of stability;
>that's why the impetus for consensus away from the current
>behavior is required, not a general discussion about
>which behavior is better given two equal choices
>in the abstract.  A prior decision has already been made
>about the code, and those that wish to change it need
>to demonstrate consensus for the change, not the other
>way around.
>
>
>
>HTH
>
>
>
>
>>________________________________
>> From: RGB ES <rg...@gmail.com>
>>To: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org> 
>>Sent: Wednesday, February 13, 2013 10:43 AM
>>Subject: Re: Calc behavior: result of 0 ^ 0
>> 
>>Not answering any particular message, so top posting.
>>
>>Two points:
>>
>>a) Of course you can always redefine a function to "fill holes" on non
>>defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0
>>makes sense because you obtain a continuous function... but that's on 1
>>variable: when you go to two variables things become more difficult. In
>>fact, the limit for x^y with x *and* y tending to zero do NOT exists
>>(choose a different path and you'll get a different limit), then there is
>>NO way to make that function continuous on (0,0), let alone what happens
>>when x < 0... so the real question is: does it make sense to "fill the
>>hole" on x^y? *My* answer (and that leads to the second point) is no
>>because it do not give any added value.
>>
>>b) Considering that we are near to 90 messages on this thread it is quite
>>clear that an agreement is not possible. On this situation it is also clear
>>that
 choosing an error instead of a fixed value is the best bet.
>>
>>Just my 2¢
>>
>>Regards
>>Ricardo
>>
>>
>>2013/2/13 Pedro Giffuni <pf...@apache.org>
>>
>>> Hello;
>>>
>>> >
>>> > Da: Norbert Thiebaud
>>> ...
>>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>> >>
>>> >>> (OK, I guess it's better to re-subscribe to the list).
>>> >>>
>>> >>> In reply to Norbert Thiebaud*:
>>> >>>
>>> >>> In the Power rule, which *is* commonly used for differentiation, we
>>> take a series
>>> >>> of
 polinomials where n !=0. n is not only different than zero, most
>>> importantly,
>>> >>> it is a constant.
>>> >
>>> >Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
>>> >so for n=1  (which _is_ different of 0 !)
>>> >d/dx X = 1.x^0
>>> >for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
>>> >
>>> >I know math can be challenging... but you don't get to invent
>>> >restriction on the Power Rule just to fit you argument.
>>> >
>>>
>>> I will put it in simple terms. You are saying that you can't calculate the
>>> slope of the equation:
>>>
>>> y =a*x + b
>>>
>>> because in the process you need to calculate the value of x^0.
>>>
>>>
>>> >>>
>>>
>>> >>> In the case of the set theory book, do note that the author is
>>> constructing
>>> >>> his own
 algebra,
>>> >
>>> >The fact that you call 'Nicola Bourbaki' 'the author', is in itself
>>> >very telling about your expertise in Math.
>>> >I nicely put a link to the wikipedia page, since laymen are indeed
>>> >unlikely to know 'who' Borbaki is.
>>> >
>>>
>>> Do I really care if the name of the author is fictitious or real?
>>>
>>> >>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>>> >>> a demonstration, it is simply a statement taken out of context.
>>> >
>>> >You ask for a practical spreadsheet example, when one is given you
>>> >invent new 'rules' to ignore' it.
>>>
>>> You haven't provided so far that practical spreadsheet.
>>>
>>> >You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
>>> >And when I gave you the page and line from one of the most rigorous
>>> >mathematical
 body of work of the 20th century (yep Bourbaki... look it
>>> >up)
>>> >you and hand-wave, pretending the author did not mean it.. or even
>>> >better " if this author(sic) *is* using mathematics correctly."
>>> >
>>>
>>> The thing is that you are taking statements out of context. I don't
>>> claim being a mathematithian. I took a few courses from the career for
>>> fun.
>>>
>>> In the case of set theory you can define, for your own purposes, a special
>>> algebra where:
>>>
>>> - You redefine your own multiplication operator (x).
>>> - You don't define division.
>>> - You make yor algebra system fit into a set of properties that
>>> is useful for your own properties.
>>>
>>> Once you define your own multiplication (which is not the same
>>> multiplication supported in a spreadsheet) You work around the
>>> issue in the power operator by defining the undefined
 case.
>>>
>>> These are all nice mathematical models that don't apply to a spreadsheet.
>>>
>>> >>>
>>> >>> I guess looking hard it may be possible to find an elaborated case
>>> where
>>> >>> someone manages to shoot himself in the foot
>>> >
>>> >Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
>>> >for shooting himself in the foot when doing math...
>>> >
>>> >For those interested in the actual Math... in Math words have meaning
>>> >and that meaning have often context. let me develop a bit the notion
>>> >of 'form' mentioned earlier:
>>> >for instance in the expression 'in an indeterminate form', there is
>>> >'form' and it matter because in the context of determining extension
>>> >by continuity of a function, there are certain case where you can
>>> >transform you equation into another 'form' but
 if these transformation
>>> >lead you to an 'indeterminate form', you have to find another
>>> >transformation to continue...
>>> >hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
>>> >is establish that h actually converge in the operating set, and that
>>> >is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
>>> >passing 'to the limit' in each term would yield 0^0 with is a
>>> >indeterminable 'form' (not a value, not a number, not claimed to be
>>> >the result of a calculation of power(0,0), but a 'form' of the
>>> >equation that is indeterminate...) at which point you cannot conclude,
>>> >what the limit is. What a mathematician is to do is to 'trans-form'
>>> >the original h in such a way that it lead him to a path to an actual
>>> >value.
>>> >
>>> >in other words that is a very specific
 meaning for a very specific
>>> >subset of mathematics, that does not conflict with defining power(0,0)
>>> >= 1.
>>> >
>>> >
>>> >wrt to the 'context' of the quote I gave earlier:
>>> >
>>> >"Proposition 9: : Let X and Y be two sets, a and b their respective
>>> >cardinals, then the set X{superscript Y} has cardinal a {superscript
>>> >b}. "
>>> >
>>> >( I will use x^y here from now on to note x {superscript y} for
>>> readability )
>>> >
>>> >"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
>>> >and 0^a = 0 if a != 0
>>> >
>>> >For there exist a unique mapping of 'empty-set' into any given set
>>> >(namely, the mapping whose graph is the empty set); the set of
>>> >mappings of a set consisting of a single element into an arbitrary set
>>> >X is equipotent to X (Chapter II, pragraph 5.3); there
 exist a unique
>>> >mapping of an arbitrary set into a set consisting of a single element;
>>> >and finally there is not mapping of a non-empty set into the
>>> >empty-set;
>>> >* Note in particular that 0^0 = 1
>>> >"
>>>
>>> Again, I will stand to what I said: this statement is not a demonstration
>>> and is taken out of context. The definition is given to conform with this
>>> "unique mapping" which unfortunately doesn't exist in the real world.
>>>
>>>
>>> >
>>> >Here is the full context of the quote. And if you think you have a
>>> >proof that there is a mathematical error there, by all means, rush to
>>> >your local university, as surely proving that half-way to the first
>>> >volume, on set theory, of a body of work that is acclaimed for it's
>>> >rigor and aim at grounding the entire field of mathematics soundly in
>>> >the rigor of set
 theory, there is an 'error', will surely promptly get
>>> >you a PhD in math... since that has escaped the attentive scrutiny and
>>> >peer review of the entire world of mathematicians for decades...
>>> >
>>>
>>> I lost contact with my teacher, indeed quite an authority, but for some
>>> reason he disliked computer math to the extreme anyways.
>>>
>>> Pedro.
>>>
>>
>>
>>
>
>

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud <nt...@gmail.com>]

On Wed, Feb 13, 2013 at 9:53 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Honestly I'd say that if anything is clear,
> it's that changing away from the status quo
> currently enjoys zero consensus.
>
> As a Ph.D. mathematician who knows about Bourbaki,
> all I can say is that line of argument is curious
> here.  There are no authorities other than the spec
> to turn to about how you want POWER(0,0) to behave-
> as a function of 2 variables returning an error is
> probably best mathematically because the POWER
> function isn't remotely continuous at (0,0)

Sure it is not continuous at 0,0 but the sign function is not either,
that does not prevent sign(0) to be defined a 0
So continuity is not a necessary requirement.

>, but as
> part of an implementation of power series
> representations of sums involving 0^0, returning 1
> is better.

Indeed. I guess my point was : '0^0=1 is obviously(sic) mathematically
wrong' is just non-sens.
There are valid backward/cross-ward compatibility arguments, there are
valid implementation/performance arguments.
but the 'Mathematical correctness' argument (for either 1 or
undefined) is completely bogus.

Norbert

Re: Calc behavior: result of 0 ^ 0

[Joe Schaefer <jo...@yahoo.com>]

Honestly I'd say that if anything is clear,
it's that changing away from the status quo
currently enjoys zero consensus.

As a Ph.D. mathematician who knows about Bourbaki,
all I can say is that line of argument is curious
here.  There are no authorities other than the spec
to turn to about how you want POWER(0,0) to behave-
as a function of 2 variables returning an error is
probably best mathematically because the POWER
function isn't remotely continuous at (0,0), but as
part of an implementation of power series
representations of sums involving 0^0, returning 1
is better.


In any case, the idea for how issues like this should
be resolved at Apache is always in favor of stability;
that's why the impetus for consensus away from the current
behavior is required, not a general discussion about
which behavior is better given two equal choices
in the abstract.  A prior decision has already been made
about the code, and those that wish to change it need
to demonstrate consensus for the change, not the other
way around.


HTH




>________________________________
> From: RGB ES <rg...@gmail.com>
>To: dev@openoffice.apache.org; Pedro Giffuni <pf...@apache.org> 
>Sent: Wednesday, February 13, 2013 10:43 AM
>Subject: Re: Calc behavior: result of 0 ^ 0
> 
>Not answering any particular message, so top posting.
>
>Two points:
>
>a) Of course you can always redefine a function to "fill holes" on non
>defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0
>makes sense because you obtain a continuous function... but that's on 1
>variable: when you go to two variables things become more difficult. In
>fact, the limit for x^y with x *and* y tending to zero do NOT exists
>(choose a different path and you'll get a different limit), then there is
>NO way to make that function continuous on (0,0), let alone what happens
>when x < 0... so the real question is: does it make sense to "fill the
>hole" on x^y? *My* answer (and that leads to the second point) is no
>because it do not give any added value.
>
>b) Considering that we are near to 90 messages on this thread it is quite
>clear that an agreement is not possible. On this situation it is also clear
>that choosing an error instead of a fixed value is the best bet.
>
>Just my 2¢
>
>Regards
>Ricardo
>
>
>2013/2/13 Pedro Giffuni <pf...@apache.org>
>
>> Hello;
>>
>> >
>> > Da: Norbert Thiebaud
>> ...
>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>> >>
>> >>> (OK, I guess it's better to re-subscribe to the list).
>> >>>
>> >>> In reply to Norbert Thiebaud*:
>> >>>
>> >>> In the Power rule, which *is* commonly used for differentiation, we
>> take a series
>> >>> of polinomials where n !=0. n is not only different than zero, most
>> importantly,
>> >>> it is a constant.
>> >
>> >Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
>> >so for n=1  (which _is_ different of 0 !)
>> >d/dx X = 1.x^0
>> >for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
>> >
>> >I know math can be challenging... but you don't get to invent
>> >restriction on the Power Rule just to fit you argument.
>> >
>>
>> I will put it in simple terms. You are saying that you can't calculate the
>> slope of the equation:
>>
>> y =a*x + b
>>
>> because in the process you need to calculate the value of x^0.
>>
>>
>> >>>
>>
>> >>> In the case of the set theory book, do note that the author is
>> constructing
>> >>> his own algebra,
>> >
>> >The fact that you call 'Nicola Bourbaki' 'the author', is in itself
>> >very telling about your expertise in Math.
>> >I nicely put a link to the wikipedia page, since laymen are indeed
>> >unlikely to know 'who' Borbaki is.
>> >
>>
>> Do I really care if the name of the author is fictitious or real?
>>
>> >>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>> >>> a demonstration, it is simply a statement taken out of context.
>> >
>> >You ask for a practical spreadsheet example, when one is given you
>> >invent new 'rules' to ignore' it.
>>
>> You haven't provided so far that practical spreadsheet.
>>
>> >You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
>> >And when I gave you the page and line from one of the most rigorous
>> >mathematical body of work of the 20th century (yep Bourbaki... look it
>> >up)
>> >you and hand-wave, pretending the author did not mean it.. or even
>> >better " if this author(sic) *is* using mathematics correctly."
>> >
>>
>> The thing is that you are taking statements out of context. I don't
>> claim being a mathematithian. I took a few courses from the career for
>> fun.
>>
>> In the case of set theory you can define, for your own purposes, a special
>> algebra where:
>>
>> - You redefine your own multiplication operator (x).
>> - You don't define division.
>> - You make yor algebra system fit into a set of properties that
>> is useful for your own properties.
>>
>> Once you define your own multiplication (which is not the same
>> multiplication supported in a spreadsheet) You work around the
>> issue in the power operator by defining the undefined case.
>>
>> These are all nice mathematical models that don't apply to a spreadsheet.
>>
>> >>>
>> >>> I guess looking hard it may be possible to find an elaborated case
>> where
>> >>> someone manages to shoot himself in the foot
>> >
>> >Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
>> >for shooting himself in the foot when doing math...
>> >
>> >For those interested in the actual Math... in Math words have meaning
>> >and that meaning have often context. let me develop a bit the notion
>> >of 'form' mentioned earlier:
>> >for instance in the expression 'in an indeterminate form', there is
>> >'form' and it matter because in the context of determining extension
>> >by continuity of a function, there are certain case where you can
>> >transform you equation into another 'form' but if these transformation
>> >lead you to an 'indeterminate form', you have to find another
>> >transformation to continue...
>> >hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
>> >is establish that h actually converge in the operating set, and that
>> >is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
>> >passing 'to the limit' in each term would yield 0^0 with is a
>> >indeterminable 'form' (not a value, not a number, not claimed to be
>> >the result of a calculation of power(0,0), but a 'form' of the
>> >equation that is indeterminate...) at which point you cannot conclude,
>> >what the limit is. What a mathematician is to do is to 'trans-form'
>> >the original h in such a way that it lead him to a path to an actual
>> >value.
>> >
>> >in other words that is a very specific meaning for a very specific
>> >subset of mathematics, that does not conflict with defining power(0,0)
>> >= 1.
>> >
>> >
>> >wrt to the 'context' of the quote I gave earlier:
>> >
>> >"Proposition 9: : Let X and Y be two sets, a and b their respective
>> >cardinals, then the set X{superscript Y} has cardinal a {superscript
>> >b}. "
>> >
>> >( I will use x^y here from now on to note x {superscript y} for
>> readability )
>> >
>> >"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
>> >and 0^a = 0 if a != 0
>> >
>> >For there exist a unique mapping of 'empty-set' into any given set
>> >(namely, the mapping whose graph is the empty set); the set of
>> >mappings of a set consisting of a single element into an arbitrary set
>> >X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
>> >mapping of an arbitrary set into a set consisting of a single element;
>> >and finally there is not mapping of a non-empty set into the
>> >empty-set;
>> >* Note in particular that 0^0 = 1
>> >"
>>
>> Again, I will stand to what I said: this statement is not a demonstration
>> and is taken out of context. The definition is given to conform with this
>> "unique mapping" which unfortunately doesn't exist in the real world.
>>
>>
>> >
>> >Here is the full context of the quote. And if you think you have a
>> >proof that there is a mathematical error there, by all means, rush to
>> >your local university, as surely proving that half-way to the first
>> >volume, on set theory, of a body of work that is acclaimed for it's
>> >rigor and aim at grounding the entire field of mathematics soundly in
>> >the rigor of set theory, there is an 'error', will surely promptly get
>> >you a PhD in math... since that has escaped the attentive scrutiny and
>> >peer review of the entire world of mathematicians for decades...
>> >
>>
>> I lost contact with my teacher, indeed quite an authority, but for some
>> reason he disliked computer math to the extreme anyways.
>>
>> Pedro.
>>
>
>
>

Re: Calc behavior: result of 0 ^ 0

[RGB ES <rg...@gmail.com>]

Not answering any particular message, so top posting.

Two points:

a) Of course you can always redefine a function to "fill holes" on non
defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0
makes sense because you obtain a continuous function... but that's on 1
variable: when you go to two variables things become more difficult. In
fact, the limit for x^y with x *and* y tending to zero do NOT exists
(choose a different path and you'll get a different limit), then there is
NO way to make that function continuous on (0,0), let alone what happens
when x < 0... so the real question is: does it make sense to "fill the
hole" on x^y? *My* answer (and that leads to the second point) is no
because it do not give any added value.

b) Considering that we are near to 90 messages on this thread it is quite
clear that an agreement is not possible. On this situation it is also clear
that choosing an error instead of a fixed value is the best bet.

Just my 2¢

Regards
Ricardo


2013/2/13 Pedro Giffuni <pf...@apache.org>

> Hello;
>
> >
> > Da: Norbert Thiebaud
> ...
> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
> >>
> >>> (OK, I guess it's better to re-subscribe to the list).
> >>>
> >>> In reply to Norbert Thiebaud*:
> >>>
> >>> In the Power rule, which *is* commonly used for differentiation, we
> take a series
> >>> of polinomials where n !=0. n is not only different than zero, most
> importantly,
> >>> it is a constant.
> >
> >Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
> >so for n=1  (which _is_ different of 0 !)
> >d/dx X = 1.x^0
> >for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
> >
> >I know math can be challenging... but you don't get to invent
> >restriction on the Power Rule just to fit you argument.
> >
>
> I will put it in simple terms. You are saying that you can't calculate the
> slope of the equation:
>
> y =a*x + b
>
> because in the process you need to calculate the value of x^0.
>
>
> >>>
>
> >>> In the case of the set theory book, do note that the author is
> constructing
> >>> his own algebra,
> >
> >The fact that you call 'Nicola Bourbaki' 'the author', is in itself
> >very telling about your expertise in Math.
> >I nicely put a link to the wikipedia page, since laymen are indeed
> >unlikely to know 'who' Borbaki is.
> >
>
> Do I really care if the name of the author is fictitious or real?
>
> >>> that get outside his set: 0^0 and x/0 are such cases. The text is not
> >>> a demonstration, it is simply a statement taken out of context.
> >
> >You ask for a practical spreadsheet example, when one is given you
> >invent new 'rules' to ignore' it.
>
> You haven't provided so far that practical spreadsheet.
>
> >You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
> >And when I gave you the page and line from one of the most rigorous
> >mathematical body of work of the 20th century (yep Bourbaki... look it
> >up)
> >you and hand-wave, pretending the author did not mean it.. or even
> >better " if this author(sic) *is* using mathematics correctly."
> >
>
> The thing is that you are taking statements out of context. I don't
> claim being a mathematithian. I took a few courses from the career for
> fun.
>
> In the case of set theory you can define, for your own purposes, a special
> algebra where:
>
> - You redefine your own multiplication operator (x).
> - You don't define division.
> - You make yor algebra system fit into a set of properties that
> is useful for your own properties.
>
> Once you define your own multiplication (which is not the same
> multiplication supported in a spreadsheet) You work around the
> issue in the power operator by defining the undefined case.
>
> These are all nice mathematical models that don't apply to a spreadsheet.
>
> >>>
> >>> I guess looking hard it may be possible to find an elaborated case
> where
> >>> someone manages to shoot himself in the foot
> >
> >Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
> >for shooting himself in the foot when doing math...
> >
> >For those interested in the actual Math... in Math words have meaning
> >and that meaning have often context. let me develop a bit the notion
> >of 'form' mentioned earlier:
> >for instance in the expression 'in an indeterminate form', there is
> >'form' and it matter because in the context of determining extension
> >by continuity of a function, there are certain case where you can
> >transform you equation into another 'form' but if these transformation
> >lead you to an 'indeterminate form', you have to find another
> >transformation to continue...
> >hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
> >is establish that h actually converge in the operating set, and that
> >is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
> >passing 'to the limit' in each term would yield 0^0 with is a
> >indeterminable 'form' (not a value, not a number, not claimed to be
> >the result of a calculation of power(0,0), but a 'form' of the
> >equation that is indeterminate...) at which point you cannot conclude,
> >what the limit is. What a mathematician is to do is to 'trans-form'
> >the original h in such a way that it lead him to a path to an actual
> >value.
> >
> >in other words that is a very specific meaning for a very specific
> >subset of mathematics, that does not conflict with defining power(0,0)
> >= 1.
> >
> >
> >wrt to the 'context' of the quote I gave earlier:
> >
> >"Proposition 9: : Let X and Y be two sets, a and b their respective
> >cardinals, then the set X{superscript Y} has cardinal a {superscript
> >b}. "
> >
> >( I will use x^y here from now on to note x {superscript y} for
> readability )
> >
> >"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
> >and 0^a = 0 if a != 0
> >
> >For there exist a unique mapping of 'empty-set' into any given set
> >(namely, the mapping whose graph is the empty set); the set of
> >mappings of a set consisting of a single element into an arbitrary set
> >X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
> >mapping of an arbitrary set into a set consisting of a single element;
> >and finally there is not mapping of a non-empty set into the
> >empty-set;
> >* Note in particular that 0^0 = 1
> >"
>
> Again, I will stand to what I said: this statement is not a demonstration
> and is taken out of context. The definition is given to conform with this
> "unique mapping" which unfortunately doesn't exist in the real world.
>
>
> >
> >Here is the full context of the quote. And if you think you have a
> >proof that there is a mathematical error there, by all means, rush to
> >your local university, as surely proving that half-way to the first
> >volume, on set theory, of a body of work that is acclaimed for it's
> >rigor and aim at grounding the entire field of mathematics soundly in
> >the rigor of set theory, there is an 'error', will surely promptly get
> >you a PhD in math... since that has escaped the attentive scrutiny and
> >peer review of the entire world of mathematicians for decades...
> >
>
> I lost contact with my teacher, indeed quite an authority, but for some
> reason he disliked computer math to the extreme anyways.
>
> Pedro.
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

Hello;

>
> Da: Norbert Thiebaud
...
>On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
>> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>>> (OK, I guess it's better to re-subscribe to the list).
>>>
>>> In reply to Norbert Thiebaud*:
>>>
>>> In the Power rule, which *is* commonly used for differentiation, we take a series
>>> of polinomials where n !=0. n is not only different than zero, most importantly,
>>> it is a constant.
>
>Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
>so for n=1  (which _is_ different of 0 !)
>d/dx X = 1.x^0
>for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
>
>I know math can be challenging... but you don't get to invent
>restriction on the Power Rule just to fit you argument.
>

I will put it in simple terms. You are saying that you can't calculate the
slope of the equation:

y =a*x + b

because in the process you need to calculate the value of x^0.


>>>

>>> In the case of the set theory book, do note that the author is constructing
>>> his own algebra,
>
>The fact that you call 'Nicola Bourbaki' 'the author', is in itself
>very telling about your expertise in Math.
>I nicely put a link to the wikipedia page, since laymen are indeed
>unlikely to know 'who' Borbaki is.
>

Do I really care if the name of the author is fictitious or real?

>>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>>> a demonstration, it is simply a statement taken out of context.
>
>You ask for a practical spreadsheet example, when one is given you
>invent new 'rules' to ignore' it.

You haven't provided so far that practical spreadsheet.

>You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
>And when I gave you the page and line from one of the most rigorous
>mathematical body of work of the 20th century (yep Bourbaki... look it
>up)
>you and hand-wave, pretending the author did not mean it.. or even
>better " if this author(sic) *is* using mathematics correctly."
>

The thing is that you are taking statements out of context. I don't
claim being a mathematithian. I took a few courses from the career for fun. 

In the case of set theory you can define, for your own purposes, a special
algebra where:

- You redefine your own multiplication operator (x).
- You don't define division.
- You make yor algebra system fit into a set of properties that
is useful for your own properties.

Once you define your own multiplication (which is not the same
multiplication supported in a spreadsheet) You work around the
issue in the power operator by defining the undefined case.

These are all nice mathematical models that don't apply to a spreadsheet.

>>>
>>> I guess looking hard it may be possible to find an elaborated case where
>>> someone manages to shoot himself in the foot
>
>Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
>for shooting himself in the foot when doing math...
>
>For those interested in the actual Math... in Math words have meaning
>and that meaning have often context. let me develop a bit the notion
>of 'form' mentioned earlier:
>for instance in the expression 'in an indeterminate form', there is
>'form' and it matter because in the context of determining extension
>by continuity of a function, there are certain case where you can
>transform you equation into another 'form' but if these transformation
>lead you to an 'indeterminate form', you have to find another
>transformation to continue...
>hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
>is establish that h actually converge in the operating set, and that
>is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
>passing 'to the limit' in each term would yield 0^0 with is a
>indeterminable 'form' (not a value, not a number, not claimed to be
>the result of a calculation of power(0,0), but a 'form' of the
>equation that is indeterminate...) at which point you cannot conclude,
>what the limit is. What a mathematician is to do is to 'trans-form'
>the original h in such a way that it lead him to a path to an actual
>value.
>
>in other words that is a very specific meaning for a very specific
>subset of mathematics, that does not conflict with defining power(0,0)
>= 1.
>
>
>wrt to the 'context' of the quote I gave earlier:
>
>"Proposition 9: : Let X and Y be two sets, a and b their respective
>cardinals, then the set X{superscript Y} has cardinal a {superscript
>b}. "
>
>( I will use x^y here from now on to note x {superscript y} for readability )
>
>"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
>and 0^a = 0 if a != 0
>
>For there exist a unique mapping of 'empty-set' into any given set
>(namely, the mapping whose graph is the empty set); the set of
>mappings of a set consisting of a single element into an arbitrary set
>X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
>mapping of an arbitrary set into a set consisting of a single element;
>and finally there is not mapping of a non-empty set into the
>empty-set;
>* Note in particular that 0^0 = 1
>"

Again, I will stand to what I said: this statement is not a demonstration
and is taken out of context. The definition is given to conform with this
"unique mapping" which unfortunately doesn't exist in the real world.


>
>Here is the full context of the quote. And if you think you have a
>proof that there is a mathematical error there, by all means, rush to
>your local university, as surely proving that half-way to the first
>volume, on set theory, of a body of work that is acclaimed for it's
>rigor and aim at grounding the entire field of mathematics soundly in
>the rigor of set theory, there is an 'error', will surely promptly get
>you a PhD in math... since that has escaped the attentive scrutiny and
>peer review of the entire world of mathematicians for decades...
>

I lost contact with my teacher, indeed quite an authority, but for some
reason he disliked computer math to the extreme anyways.

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud <nt...@gmail.com>]

On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir <ra...@gmail.com> wrote:
> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
>> (OK, I guess it's better to re-subscribe to the list).
>>
>> In reply to Norbert Thiebaud*:
>>
>> In the Power rule, which *is* commonly used for differentiation, we take a series
>> of polinomials where n !=0. n is not only different than zero, most importantly,
>> it is a constant.

Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
so for n=1  (which _is_ different of 0 !)
d/dx X = 1.x^0
for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.

I know math can be challenging... but you don't get to invent
restriction on the Power Rule just to fit you argument.

>> and we just can't assume every speadsheet
>> user will use a restricted set of capabilities.
>>
>> Now, in a spreadsheet this formula would be used if you have a polinomial and
>> you want to calculate and/or graph it's derivative. Since we don't do symbolic
>> math in the speadsheet you would actually do this by hand and you would resolve
>> the trivial constant^0 cases.

Really... but extending by continuity a function in 0, without
consideration for convergence,  _that_ is something that is done by
spreadsheet ?
iow just because 0^0 is an indeterminate _form_ does not mean that 0^0
can not have a value... it just mean that when searching for a limit
for a function h(x)
if your _transformation_ lead you to 0^0 you cannot conclude from that
_form_ that means that the rule and tools that allow you to jump form
lim -> 0 to a value in 0 do not hold when they lead to that 'form'. I
know math is a tricky thing... but the definition of words and their
scope of application is kind of important in Math.

>>
>> In the case of the set theory book, do note that the author is constructing
>> his own algebra,

The fact that you call 'Nicola Bourbaki' 'the author', is in itself
very telling about your expertise in Math.
I nicely put a link to the wikipedia page, since laymen are indeed
unlikely to know 'who' Borbaki is.

>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>> a demonstration, it is simply a statement taken out of context.

You ask for a practical spreadsheet example, when one is given you
invent new 'rules' to ignore' it.
You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
And when I gave you the page and line from one of the most rigorous
mathematical body of work of the 20th century (yep Bourbaki... look it
up)
you and hand-wave, pretending the author did not mean it.. or even
better " if this author(sic) *is* using mathematics correctly."

>>
>> I guess looking hard it may be possible to find an elaborated case where
>> someone manages to shoot himself in the foot

Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
for shooting himself in the foot when doing math...

For those interested in the actual Math... in Math words have meaning
and that meaning have often context. let me develop a bit the notion
of 'form' mentioned earlier:
for instance in the expression 'in an indeterminate form', there is
'form' and it matter because in the context of determining extension
by continuity of a function, there are certain case where you can
transform you equation into another 'form' but if these transformation
lead you to an 'indeterminate form', you have to find another
transformation to continue...
hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
is establish that h actually converge in the operating set, and that
is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
passing 'to the limit' in each term would yield 0^0 with is a
indeterminable 'form' (not a value, not a number, not claimed to be
the result of a calculation of power(0,0), but a 'form' of the
equation that is indeterminate...) at which point you cannot conclude,
what the limit is. What a mathematician is to do is to 'trans-form'
the original h in such a way that it lead him to a path to an actual
value.

in other words that is a very specific meaning for a very specific
subset of mathematics, that does not conflict with defining power(0,0)
= 1.


wrt to the 'context' of the quote I gave earlier:

"Proposition 9: : Let X and Y be two sets, a and b their respective
cardinals, then the set X{superscript Y} has cardinal a {superscript
b}. "

( I will use x^y here from now on to note x {superscript y} for readability )

"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
and 0^a = 0 if a != 0

For there exist a unique mapping of 'empty-set' into any given set
(namely, the mapping whose graph is the empty set); the set of
mappings of a set consisting of a single element into an arbitrary set
X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
mapping of an arbitrary set into a set consisting of a single element;
and finally there is not mapping of a non-empty set into the
empty-set;
* Note in particular that 0^0 = 1
"

Here is the full context of the quote. And if you think you have a
proof that there is a mathematical error there, by all means, rush to
your local university, as surely proving that half-way to the first
volume, on set theory, of a body of work that is acclaimed for it's
rigor and aim at grounding the entire field of mathematics soundly in
the rigor of set theory, there is an 'error', will surely promptly get
you a PhD in math... since that has escaped the attentive scrutiny and
peer review of the entire world of mathematicians for decades...

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ra...@gmail.com>]

On Feb 12, 2013, at 10:39 PM, Pedro Giffuni <pf...@apache.org> wrote:

> (OK, I guess it's better to re-subscribe to the list).
>
> In reply to Norbert Thiebaud*:
>
> In the Power rule, which *is* commonly used for differentiation, we take a series
> of polinomials where n !=0. n is not only different than zero, most importantly,
> it is a constant.
>
> Of course we can use the power function a^b in your spreadsheet when the b
> is a constant but you have to understand the assumptions being made before
> blindingly applying formulas, and we just can't assume every speadsheet
> user will use a restricted set of capabilities.
>
> Now, in a spreadsheet this formula would be used if you have a polinomial and
> you want to calculate and/or graph it's derivative. Since we don't do symbolic
> math in the speadsheet you would actually do this by hand and you would resolve
> the trivial constant^0 cases.
>
> In the case of the set theory book, do note that the author is constructing
> his own algebra, and it's natural that he might not want indefinite values
> that get outside his set: 0^0 and x/0 are such cases. The text is not
> a demonstration, it is simply a statement taken out of context.
>
> I guess looking hard it may be possible to find an elaborated case where
> someone manages to shoot himself in the foot but ultimately I would
> wonder. if this author *is* using mathematics correctly. 0^0 is a good indication
> that there is something wrong in your calculation and evidently Excel users
> have come to accept it.
>


Well, can you then give an example of a real-world spreadsheet where a
user has evaluated 0^0 in error and has not noticed it?  That would be
the claimed beneficiary of your change, yes?  So what is the example?

-Rob

> Pedro.
>
> *Welcome to this list ;).

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni <pf...@apache.org>]

(OK, I guess it's better to re-subscribe to the list).

In reply to Norbert Thiebaud*:

In the Power rule, which *is* commonly used for differentiation, we take a series
of polinomials where n !=0. n is not only different than zero, most importantly,
it is a constant.

Of course we can use the power function a^b in your spreadsheet when the b
is a constant but you have to understand the assumptions being made before
blindingly applying formulas, and we just can't assume every speadsheet
user will use a restricted set of capabilities.

Now, in a spreadsheet this formula would be used if you have a polinomial and
you want to calculate and/or graph it's derivative. Since we don't do symbolic
math in the speadsheet you would actually do this by hand and you would resolve
the trivial constant^0 cases.

In the case of the set theory book, do note that the author is constructing
his own algebra, and it's natural that he might not want indefinite values
that get outside his set: 0^0 and x/0 are such cases. The text is not
a demonstration, it is simply a statement taken out of context.

I guess looking hard it may be possible to find an elaborated case where
someone manages to shoot himself in the foot but ultimately I would
wonder. if this author *is* using mathematics correctly. 0^0 is a good indication
that there is something wrong in your calculation and evidently Excel users
have come to accept it.

Pedro.

*Welcome to this list ;).

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud <nt...@gmail.com>]

On Tue, Feb 12, 2013 at 7:39 PM, Norbert Thiebaud <nt...@gmail.com> wrote:
> I also invite the numerous mathematicians on this list to refer to "N.
> Boubaki (*),  Element of Mathematics, Set Theory, p164:  III.3.5
> Proposition 11. "[...] Note in particular that 0^0 = 1."

http://books.google.com/books?id=IL-SI67hjI4C&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=snippet&q=Note%20in%20particular%20proposiiton%2012&f=false

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud <nt...@gmail.com>]

On Tue, Feb 12, 2013 at 6:00 PM, Andrea Pescetti <pe...@apache.org> wrote:
>
> 1) Nobody so far exhibited a spreadsheet that would be broken by the new
> behavior.

I think attachment to the list are stripped... but... any spreadsheet
that try to teach the Power Rule
( http://en.wikipedia.org/wiki/Power_rule )
with interactivity where you can plug the value for x and it calculate
the derivative of a polynomial f(x)
would all the sudden claim that polynomial functions with a component
in x^1 are not differentiable in 0...

and that is just one common and practical use of 0^0.

Just because some people are tempted to talk about the value of a
limit, or even wore for a mathematician, trying to 'calculate it'
before establishing convergence does not mean that the 'notation' 0^0
can not be defined.
just like 0! is _defined_ to be 1, 0^0 is _defined_ to be 1.

I also invite the numerous mathematicians on this list to refer to "N.
Boubaki (*),  Element of Mathematics, Set Theory, p164:  III.3.5
Proposition 11. "[...] Note in particular that 0^0 = 1."

(*) http://en.wikipedia.org/wiki/Nicolas_Bourbaki

Norbert

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

Dennis E. Hamilton wrote:
> The objective is to achieve consensus.  I believe it is clear that there is
> no consensus on the proposed change and the proposal fails.

I still have to see some credible arguments here, since most of the 
feedback was misplaced. What we learned so far is:

1) Nobody so far exhibited a spreadsheet that would be broken by the new 
behavior. Rob has one, which was even published, so I'm sure he can 
share it for everybody to have a look. Even better, we have a fantastic 
collection of Calc templates at 
http://templates.openoffice.org/en/taxonomy/term/3923 ; seeing one of 
those templates break would help.

2) Everybody feels the need to say something about 0 ^ 0, but threads 
like this one are not pleasant to read. If you have nothing to say, 
please don't say anything. And if you have a lot to say, please limit 
yourself to what's strictly needed. Especially, undoing a volunteer's 
work without some concrete (in ODF format, in this case!) reasons is 
something the project must avoid.

3) Mathematics and the standards are two different worlds. If a standard 
is mathematically wrong, change the standard and come back.

4) We implement a standard, ODF. There 0 ^ 0 can legitimately be 
evaluated to 0, 1 or an error.

5) We read another standard, OOXML. There 0 ^ 0 can only be evaluated as 
an error; the fact that OpenOffice will evaluate 0 ^ 0 from a XLSX file 
to 1 is a bug.

6) Anyone whose spreadsheets depend on 0 ^ 0 being evaluated to 1 (or to 
zero, or to an error for that matter) has entered the dangerous world of 
"implementation-defined" behavior: even if you save in a standard format 
like ODF, your spreadsheet depends on a particular ODF implementation 
(e.g., on the specific version of OpenOffice you used).

Based on 5 and 6 I would actually still believe that it's good to 
evaluate 0 ^ 0 to error (so that we fix the bug in 5 and we choose the 
most strict behavior in 6). But I fully agree with Marcus in saying this 
issue is much smaller than the discussion around it, so I can surely 
change my opinion if I finally see some real-world spreadsheets impacted 
by the change. When we have those, also Pedro will likely see reasons 
for reverting the change. In short: provide concrete examples and 
everybody will be happy.

Regards,
   Andrea.

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <de...@acm.org>]

RESOLUTION OF THE PROPOSAL

The proposed change was made under CTR (Commit then Review). There has been
a subsequent review and, as Don points out, the discussion has been lengthy
and vocal. 

The objective is to achieve consensus.  I believe it is clear that there is
no consensus on the proposed change and the proposal fails.

I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
this up.  If the lack of consensus is affirmed, Pedro can revert the change
and adjust the Bugzilla issue.

THE ESSENCE OF THE PROPOSAL

The proposal is to enact the breaking change as described on 
the Community Wiki at 
<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes>
.

It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
Support.

"Exponentiation

"The current version of Calc produces 1 for POWER(0,0).  This is one of the 
implementation-defined results that is permitted by ODF 1.2 OpenFormula.

"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
permitted as the implementation-defined result.  This is also compatible
with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
Spreadsheets. ..."

OUTCOME

The proposed change is tracked in Bugzilla Issue #114430,
< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.

A patch to implement this proposal is already included in the SVN.  
If the proposal is not accepted as the result of CTR review, the 
Issue will be closed and the patch reverted.
 
 - Dennis

-----Original Message-----
From: Donald Whytock [mailto:dwhytock@gmail.com] 
Sent: Tuesday, February 12, 2013 09:20
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

...So I got curious, and I paged back in my email archive, and it
seems this is the biggest AOO dev thread since the graduation vote
back in early September.

At this point, does anyone care enough about changing the status quo
as to put up a coherent proposal to be voted on?

Don

Re: Calc behavior: result of 0 ^ 0

[Donald Whytock <dw...@gmail.com>]

...So I got curious, and I paged back in my email archive, and it
seems this is the biggest AOO dev thread since the graduation vote
back in early September.

At this point, does anyone care enough about changing the status quo
as to put up a coherent proposal to be voted on?

Don

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

On 11/02/2013 Andre Fischer wrote:
> On 11.02.2013 17:10, Andrea Pescetti wrote:
>> A specification may need to leave room for implementation-defined
>> behavior. Look at the C or C++ standard for example.
> Do you know of any example where this is actually a good thing?

It is good for developers who need to implement the standard, but indeed 
not for users!

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Andre Fischer <aw...@gmail.com>]

On 11.02.2013 17:10, Andrea Pescetti wrote:
> Andre Fischer wrote:
>> If the spec said that 2 is the only valid return value then we would
>> have to return 2.
>
> But then, since we also read XLSX and the OOXML standard prescribes 
> that 0 ^ 0 should return an error, returning an error would be the 
> common ground here: of course we don't want to depend on the file 
> format, so choosing something where the standards agree makes sense. 
> (As Dennis noted, Excel returns an error indeed, but a different one 
> than what the OOXML specification prescribes... so this seems a 
> difficult question there too!).

Fair point.

>
>> We should change the ODF spec first instead. A spec that basically says
>> "whatever you want to return is fine" is of no value, as was proven in
>> this thread.
>
> A specification may need to leave room for implementation-defined 
> behavior. Look at the C or C++ standard for example. 

Do you know of any example where this is actually a good thing?

> ODF is indeed not too strong (I didn't check all details, but I think 
> it might be possible to have Calc evaluate ="two"+"two" as "five" -or 
> "four" for that matter- and not break the ODF specification), but this 
> doesn't necessarily mean that the standard is flawed, only that it 
> admits implementations that differ on this detail.

It probably depends on who uses a spec.  A user to find out what the 
result of a certain operation should be.  Or a developer implementing 
the spec.  For the later it might be good to have some freedom.  A user 
might prefer a spec that clearly states what the expected result for a 
given set of arguments is.  Especially when that result is not canonical 
like 1+1=2.

-Andre

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

Andre Fischer wrote:
> If the spec said that 2 is the only valid return value then we would
> have to return 2.

But then, since we also read XLSX and the OOXML standard prescribes that 
0 ^ 0 should return an error, returning an error would be the common 
ground here: of course we don't want to depend on the file format, so 
choosing something where the standards agree makes sense. (As Dennis 
noted, Excel returns an error indeed, but a different one than what the 
OOXML specification prescribes... so this seems a difficult question 
there too!).

> We should change the ODF spec first instead. A spec that basically says
> "whatever you want to return is fine" is of no value, as was proven in
> this thread.

A specification may need to leave room for implementation-defined 
behavior. Look at the C or C++ standard for example. ODF is indeed not 
too strong (I didn't check all details, but I think it might be possible 
to have Calc evaluate ="two"+"two" as "five" -or "four" for that matter- 
and not break the ODF specification), but this doesn't necessarily mean 
that the standard is flawed, only that it admits implementations that 
differ on this detail.

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Mon, Feb 11, 2013 at 4:25 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 11/02/2013 21:40, Rob Weir a écrit :
>
>> Again, you are looking for the "one true answer" and declaring that
>> other answers are wrong.
>
>
> No. Even if my personal inclination is for the undefined result, I can
> understand the value 1.
> But let the user decide and just warn him that he's facing a corner case
> that requests his attention.
> That's all.
>

Maybe we should have spellchecker give a error for "their" because it
is often confused with "there" ?

Another example:  When entering a number, a percentage sign multiplies
the number by 0.01.

This usually works fine, e.g., 5% is automatically translated into
0.05.  But if you enter =5% % it will enter the value 0.0005.  My
guess is this feature is more often the result of a mistake than an
intentional user input.

There are dozens of such weird things in spreadsheets.

I could imagine a special mode for giving warnings about things like
this, but in normal operations I don't think we should distract the
user about things that are not errors.  And I certainly don't think we
should treat all of these items as errors, at least not by default.

Now back to the spell checking mode.  In some spell checkers they are
smart enough to give an error for "their".  That is because they are
*sensitive to the context*.  They look at the context and can detect
whether the word is misused in that context.  I think we've all seen
tools that do this.  Personally, I find the, annoying since they given
many false-positive error message.  But treating "their" as an error
in all cases?  That is to give false-positives in almost all cases.
That doesn't make sense to me.

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 11/02/2013 21:40, Rob Weir a écrit :
> Again, you are looking for the "one true answer" and declaring that
> other answers are wrong.

No. Even if my personal inclination is for the undefined result, I can understand the value 1.
But let the user decide and just warn him that he's facing a corner case that requests his attention.
That's all.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

Oh no, please no popup....

when I paste that formula into 1000 cells, I don't want 1000 popups. 
Sadly, I sometimes do stupid things like that when I have a warning in 
functions that I write myself and a debug message pops up during 
testing. Yeah, scary! Now, a single warning that is only ever shown 
once, yeah, ok, maybe.


On 02/11/2013 06:45 PM, Fred Ollinger wrote:
> I love it. I'd prefer a warning rather than silently giving me 1 even
> if I had that in the past.
>
> Another idea is to return 1, but have a popup which says: "We are
> returning 1 to 0^0 due to backwards compatability, but we this might
> change in the fure. Click here to never show this warning again and
> continue to return 1. Also, you can use strict (or whatever) to flag
> these warnings as errors."
>
> Fred
>
> On Mon, Feb 11, 2013 at 3:04 PM, Dennis E. Hamilton <or...@apache.org> wrote:
>> My apologies.  I replied to the wrong message, so the context was lost.  I was responding to a statement that "0^0 = 1" is not wrong mathematically.  I wanted to point out that is misleading, because it is also not right mathematically.  POWER(x,y) implements an arithmetic function, and I agree that is not a mathematical usage.
>>
>> I rose to object based on this statement:
>>
>> "But returning 1 for 0^0 is not wrong.  It is not wrong mathematically.
>>   It is not wrong per the ODF 1.2 standard."
>>
>> (I think there are strings attached to the ODF 1.2 case and those strings need to be tied, as has already been discussed.)
>>
>> To make amends for the diversion, I also want to offer my +1 for the following which I did not see the first time:
>>
>> "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."
>>
>> -----Original Message-----
>> From: Rob Weir [mailto:robweir@apache.org]
>> Sent: Monday, February 11, 2013 14:30
>> To: dev@openoffice.apache.org; dennis.hamilton@acm.org
>> Subject: Re: Calc behavior: result of 0 ^ 0
>>
>> On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>> This is not a vote.  There is a statement about what is acceptable mathematically that I cannot leave unchallenged.  However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that.
>>>
>>>   - Dennis
>>>
>>> MATHEMATICAL RIGHT/WRONG-NESS
>>>
>>> I'm sorry, I will not accept that 0^0 = 1 as a definition is "not wrong mathematically."  It is not right mathematically either.  That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory.
>>>
>> [ ... ]
>> If OpenOffice were a theorem proving system and we put in 0^0 ==1 as
>> an axiom, then you might have a point there.   But it isn't.  The only
>> entity making logical conclusions and extrapolating to other
>> mathematical problems from the behavior of POWER() is the user.  So
>> your concern is not really valid in this context.
>>
>> -Rob
>>
>> [ ... ]
>>

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 12/02/2013 00:45, Fred Ollinger a écrit :
> Another idea is to return 1, but have a popup which says: "We are
> returning 1 to 0^0 due to backwards compatability, but we this might
> change in the fure. Click here to never show this warning again and
> continue to return 1. Also, you can use strict (or whatever) to flag
> these warnings as errors."

That's a lot of code for such a small occurrence.
Isn't there more urgents issues? A mere error message is good enough.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Fred Ollinger <fo...@gmail.com>]

I love it. I'd prefer a warning rather than silently giving me 1 even
if I had that in the past.

Another idea is to return 1, but have a popup which says: "We are
returning 1 to 0^0 due to backwards compatability, but we this might
change in the fure. Click here to never show this warning again and
continue to return 1. Also, you can use strict (or whatever) to flag
these warnings as errors."

Fred

On Mon, Feb 11, 2013 at 3:04 PM, Dennis E. Hamilton <or...@apache.org> wrote:
> My apologies.  I replied to the wrong message, so the context was lost.  I was responding to a statement that "0^0 = 1" is not wrong mathematically.  I wanted to point out that is misleading, because it is also not right mathematically.  POWER(x,y) implements an arithmetic function, and I agree that is not a mathematical usage.
>
> I rose to object based on this statement:
>
> "But returning 1 for 0^0 is not wrong.  It is not wrong mathematically.
>  It is not wrong per the ODF 1.2 standard."
>
> (I think there are strings attached to the ODF 1.2 case and those strings need to be tied, as has already been discussed.)
>
> To make amends for the diversion, I also want to offer my +1 for the following which I did not see the first time:
>
> "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."
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, February 11, 2013 14:30
> To: dev@openoffice.apache.org; dennis.hamilton@acm.org
> Subject: Re: Calc behavior: result of 0 ^ 0
>
> On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> This is not a vote.  There is a statement about what is acceptable mathematically that I cannot leave unchallenged.  However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that.
>>
>>  - Dennis
>>
>> MATHEMATICAL RIGHT/WRONG-NESS
>>
>> I'm sorry, I will not accept that 0^0 = 1 as a definition is "not wrong mathematically."  It is not right mathematically either.  That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory.
>>
> [ ... ]
>>
>
> If OpenOffice were a theorem proving system and we put in 0^0 ==1 as
> an axiom, then you might have a point there.   But it isn't.  The only
> entity making logical conclusions and extrapolating to other
> mathematical problems from the behavior of POWER() is the user.  So
> your concern is not really valid in this context.
>
> -Rob
>
> [ ... ]
>

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <or...@apache.org>]

My apologies.  I replied to the wrong message, so the context was lost.  I was responding to a statement that "0^0 = 1" is not wrong mathematically.  I wanted to point out that is misleading, because it is also not right mathematically.  POWER(x,y) implements an arithmetic function, and I agree that is not a mathematical usage.

I rose to object based on this statement:

"But returning 1 for 0^0 is not wrong.  It is not wrong mathematically.
 It is not wrong per the ODF 1.2 standard."

(I think there are strings attached to the ODF 1.2 case and those strings need to be tied, as has already been discussed.)

To make amends for the diversion, I also want to offer my +1 for the following which I did not see the first time:

"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."

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Monday, February 11, 2013 14:30
To: dev@openoffice.apache.org; dennis.hamilton@acm.org
Subject: Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> This is not a vote.  There is a statement about what is acceptable mathematically that I cannot leave unchallenged.  However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that.
>
>  - Dennis
>
> MATHEMATICAL RIGHT/WRONG-NESS
>
> I'm sorry, I will not accept that 0^0 = 1 as a definition is "not wrong mathematically."  It is not right mathematically either.  That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory.
>
[ ... ]
>

If OpenOffice were a theorem proving system and we put in 0^0 ==1 as
an axiom, then you might have a point there.   But it isn't.  The only
entity making logical conclusions and extrapolating to other
mathematical problems from the behavior of POWER() is the user.  So
your concern is not really valid in this context.

-Rob

[ ... ]

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> This is not a vote.  There is a statement about what is acceptable mathematically that I cannot leave unchallenged.  However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that.
>
>  - Dennis
>
> MATHEMATICAL RIGHT/WRONG-NESS
>
> I'm sorry, I will not accept that 0^0 = 1 as a definition is "not wrong mathematically."  It is not right mathematically either.  That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory.
>
> The problem with 0^0 = 1 as a rule is that it has as a consequence that 0/0 = 1 as well or else standard mathematics is inconsistent.  But 0/0 = 1 (or any fixed value) makes mathematics unavoidably inconsistent anyhow (as the well-known defective proofs used to claim paradoxes like 0 = 1 and 1 = 2 demonstrate).  There is no escaping the fact that x/0 needs to be undefined and that includes 0/0, so 0^0 needs to go along.
>

If OpenOffice were a theorem proving system and we put in 0^0 ==1 as
an axiom, then you might have a point there.   But it isn't.  The only
entity making logical conclusions and extrapolating to other
mathematical problems from the behavior of POWER() is the user.  So
your concern is not really valid in this context.

-Rob

> Let us not confuse computational expedient or algorithmic simplicity with mathematical rigor.  When a computer arithmetic had no provision for coding errors and indefinable cases, computational concessions were unavoidable (as is the case for integer types in common programming languages).  That is not the case with spreadsheets, which do include error values, nor is it the case with modern floating-point arithmetic implementations (and the standards they satisfy).
>
> I understand Knuth's argument (and its form in "Concrete Mathematics" and in "Art of Computer Programming").  But adding rules to *mathematics* that make the standard model of arithmetic inconsistent is not mathematically justifiable.  It is very handy, in certain contexts relying on mathematical definitions, to define the x^0 case to always be 1 regardless of x.  In the case of the binomial theorem, it appears to be an appropriate simplification in providing algorithms that are "easier" to reason about in some respect.  That context is specifically (a+b)^n by polynomial expansion and in this context the particular case of n = 0 and b = -a is perhaps not all that interesting in comparison to the serious cases.
>
> Unfortunately, the computation, POWER(x,0) has no mathematical context.  It is not known what POWER(x,0) is being used for, and what the nature of x is.
>
> Although the standards for C and C++ have division by 0 to be undefined, there is not such clarity for pow(x,y).  The ANSI/ISO Standards for C thought of as C90 define pow(x,y) to be a domain error if the "result cannot be represented when x is zero and y is less than or equal to zero."  Even so, Plauger's 1992 "The Standard C Library" has pow(x,0.0) return 1.0 so long as x is neither NaN nor an Inf.  Harbison and Steele's "C: A Reference Manual", 4th (1995) edition simply assert that pow(0.0,0.0) is a domain error.  The ISO C99 specification says that "a domain error *may* occur if x is xero and y is less than or equal to zero [emphasis mine]."  The C++ library, for non-complex x or y, has pow(x,y) be as defined for C (without reference to any details) and <math.h>, at least in the 1999 book on "The C++ Standard Library."  By ISO C++ 2003, pow(0,0) is implementation defined.  Of course none of this is about mathematics.  It is about constraints on the definitions of computer software libraries and the compromises that are made in order to find agreement on standards.  People vote on those.  Mathematics is not defined at the ballot box (and legislation of the value of pi is not mathematics [QED]).
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, February 11, 2013 12:40
> To: dev@openoffice.apache.org
> Subject: Re: Calc behavior: result of 0 ^ 0
>
> On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest <ha...@laposte.net> wrote:
>> Le 11/02/2013 09:13, Andre Fischer a écrit :
>>
>>> We should change the ODF spec first instead.  A spec that basically says
>>> "whatever you want to return is fine" is of no value, as was proven in this
>>> thread.  This is something that I would only accept from a "random()"
>>> function.
>>
>>
>> +1. That's also what has been said by other posters (with some between the
>> lines reading).
>>
>>
>>
>>> Besides, my emacs calc says that 0^0 is 1, so that can be the only correct
>>> answer, right?
>>
>>
>> :-)
>> But is there anyone with some real maths application that could check (R or
>> Mathlab, ...)?
>>
>
> Again, you are looking for the "one true answer" and declaring that
> other answers are wrong.  That is not the case here.  Please review
> this survey of the question from the sci.math FAQ on this point:
>
> "Consensus has recently been built around setting the value of 0^0 = 1"
>
> http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/
>
> Regards,
>
> -Rob
>
>
>> Hagar
>

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <de...@acm.org>]

This is not a vote.  There is a statement about what is acceptable mathematically that I cannot leave unchallenged.  However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that.

 - Dennis

MATHEMATICAL RIGHT/WRONG-NESS

I'm sorry, I will not accept that 0^0 = 1 as a definition is "not wrong mathematically."  It is not right mathematically either.  That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory.

The problem with 0^0 = 1 as a rule is that it has as a consequence that 0/0 = 1 as well or else standard mathematics is inconsistent.  But 0/0 = 1 (or any fixed value) makes mathematics unavoidably inconsistent anyhow (as the well-known defective proofs used to claim paradoxes like 0 = 1 and 1 = 2 demonstrate).  There is no escaping the fact that x/0 needs to be undefined and that includes 0/0, so 0^0 needs to go along.

Let us not confuse computational expedient or algorithmic simplicity with mathematical rigor.  When a computer arithmetic had no provision for coding errors and indefinable cases, computational concessions were unavoidable (as is the case for integer types in common programming languages).  That is not the case with spreadsheets, which do include error values, nor is it the case with modern floating-point arithmetic implementations (and the standards they satisfy).  

I understand Knuth's argument (and its form in "Concrete Mathematics" and in "Art of Computer Programming").  But adding rules to *mathematics* that make the standard model of arithmetic inconsistent is not mathematically justifiable.  It is very handy, in certain contexts relying on mathematical definitions, to define the x^0 case to always be 1 regardless of x.  In the case of the binomial theorem, it appears to be an appropriate simplification in providing algorithms that are "easier" to reason about in some respect.  That context is specifically (a+b)^n by polynomial expansion and in this context the particular case of n = 0 and b = -a is perhaps not all that interesting in comparison to the serious cases.  

Unfortunately, the computation, POWER(x,0) has no mathematical context.  It is not known what POWER(x,0) is being used for, and what the nature of x is. 

Although the standards for C and C++ have division by 0 to be undefined, there is not such clarity for pow(x,y).  The ANSI/ISO Standards for C thought of as C90 define pow(x,y) to be a domain error if the "result cannot be represented when x is zero and y is less than or equal to zero."  Even so, Plauger's 1992 "The Standard C Library" has pow(x,0.0) return 1.0 so long as x is neither NaN nor an Inf.  Harbison and Steele's "C: A Reference Manual", 4th (1995) edition simply assert that pow(0.0,0.0) is a domain error.  The ISO C99 specification says that "a domain error *may* occur if x is xero and y is less than or equal to zero [emphasis mine]."  The C++ library, for non-complex x or y, has pow(x,y) be as defined for C (without reference to any details) and <math.h>, at least in the 1999 book on "The C++ Standard Library."  By ISO C++ 2003, pow(0,0) is implementation defined.  Of course none of this is about mathematics.  It is about constraints on the definitions of computer software libraries and the compromises that are made in order to find agreement on standards.  People vote on those.  Mathematics is not defined at the ballot box (and legislation of the value of pi is not mathematics [QED]).

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Monday, February 11, 2013 12:40
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 11/02/2013 09:13, Andre Fischer a écrit :
>
>> We should change the ODF spec first instead.  A spec that basically says
>> "whatever you want to return is fine" is of no value, as was proven in this
>> thread.  This is something that I would only accept from a "random()"
>> function.
>
>
> +1. That's also what has been said by other posters (with some between the
> lines reading).
>
>
>
>> Besides, my emacs calc says that 0^0 is 1, so that can be the only correct
>> answer, right?
>
>
> :-)
> But is there anyone with some real maths application that could check (R or
> Mathlab, ...)?
>

Again, you are looking for the "one true answer" and declaring that
other answers are wrong.  That is not the case here.  Please review
this survey of the question from the sci.math FAQ on this point:

"Consensus has recently been built around setting the value of 0^0 = 1"

http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/

Regards,

-Rob


> Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 11/02/2013 09:13, Andre Fischer a écrit :
>
>> We should change the ODF spec first instead.  A spec that basically says
>> "whatever you want to return is fine" is of no value, as was proven in this
>> thread.  This is something that I would only accept from a "random()"
>> function.
>
>
> +1. That's also what has been said by other posters (with some between the
> lines reading).
>
>
>
>> Besides, my emacs calc says that 0^0 is 1, so that can be the only correct
>> answer, right?
>
>
> :-)
> But is there anyone with some real maths application that could check (R or
> Mathlab, ...)?
>

Again, you are looking for the "one true answer" and declaring that
other answers are wrong.  That is not the case here.  Please review
this survey of the question from the sci.math FAQ on this point:

"Consensus has recently been built around setting the value of 0^0 = 1"

http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/

Regards,

-Rob


> Hagar

Re: Calc behavior: result of 0 ^ 0

[Donald Whytock <dw...@gmail.com>]

Google docs spreadsheet gives 1.

On Mon, Feb 11, 2013 at 3:41 PM, RGB ES <rg...@gmail.com> wrote:
> 2013/2/11 Hagar Delest <ha...@laposte.net>
>
>> Le 11/02/2013 09:13, Andre Fischer a écrit :
>>
>>  We should change the ODF spec first instead.  A spec that basically says
>>> "whatever you want to return is fine" is of no value, as was proven in this
>>> thread.  This is something that I would only accept from a "random()"
>>> function.
>>>
>>
>> +1. That's also what has been said by other posters (with some between the
>> lines reading).
>>
>>
>>
>>  Besides, my emacs calc says that 0^0 is 1, so that can be the only
>>> correct answer, right?
>>>
>>
>> :-)
>> But is there anyone with some real maths application that could check (R
>> or Mathlab, ...)?
>
>
> Maxima (a computer algebra system) gives an error. FreeMat (a Matlab clone)
> gives 1. SciDAVis (an originLab clone) gives an error. Calligra Sheets
> gives 1 (but you need to insert a "=" before, otherwise it takes it as text)
>
> Also, remember that any change will break someone's workflow:
>
> http://xkcd.com/1172/
>
> Regards
> Ricardo
>
>
>
>>
>>
>> Hagar
>>

Re: Calc behavior: result of 0 ^ 0

[RGB ES <rg...@gmail.com>]

2013/2/11 Hagar Delest <ha...@laposte.net>

> Le 11/02/2013 09:13, Andre Fischer a écrit :
>
>  We should change the ODF spec first instead.  A spec that basically says
>> "whatever you want to return is fine" is of no value, as was proven in this
>> thread.  This is something that I would only accept from a "random()"
>> function.
>>
>
> +1. That's also what has been said by other posters (with some between the
> lines reading).
>
>
>
>  Besides, my emacs calc says that 0^0 is 1, so that can be the only
>> correct answer, right?
>>
>
> :-)
> But is there anyone with some real maths application that could check (R
> or Mathlab, ...)?


Maxima (a computer algebra system) gives an error. FreeMat (a Matlab clone)
gives 1. SciDAVis (an originLab clone) gives an error. Calligra Sheets
gives 1 (but you need to insert a "=" before, otherwise it takes it as text)

Also, remember that any change will break someone's workflow:

http://xkcd.com/1172/

Regards
Ricardo



>
>
> Hagar
>

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 11/02/2013 09:13, Andre Fischer a écrit :
> We should change the ODF spec first instead.  A spec that basically says "whatever you want to return is fine" is of no value, as was proven in this thread.  This is something that I would only accept from a "random()" function.

+1. That's also what has been said by other posters (with some between the lines reading).


> Besides, my emacs calc says that 0^0 is 1, so that can be the only correct answer, right?

:-)
But is there anyone with some real maths application that could check (R or Mathlab, ...)?

Hagar

Re: Calc behavior: result of 0 ^ 0

[Andre Fischer <aw...@gmail.com>]

On 10.02.2013 00:11, 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
> - 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
> - We gain interoperability since Excel returns an error too
> - We lose backwards compatibility if someone was relying on the fact 
> that OpenOffice returns 1 as the result of "=0 ^ 0"
>
> 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 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).
>
> Is there consensus that this is a reasonable backwards-incompatible 
> change, or compelling reasons to revert it?

I would like to propose to revert the change because, as Rob said 
elsewhere in this thread, this is not a mathematical question.  If the 
the ODF spec says that 0,1, and error are valid return values and we 
return 1 then there is no error (despite the three exclamation marks in 
the title of the bug).

If the spec said that 2 is the only valid return value then we would 
have to return 2.

We should change the ODF spec first instead.  A spec that basically says 
"whatever you want to return is fine" is of no value, as was proven in 
this thread.  This is something that I would only accept from a 
"random()" function.

Besides, my emacs calc says that 0^0 is 1, so that can be the only 
correct answer, right?

Regards,
Andre

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <or...@apache.org>]

For the record, I checked IS29500-1 (:2008 and :2011) on what the rules are for OOXML. 

OOXML does not specify any edge cases or failure modes for SERIESSUM whatsoever.  It simply gives the mathematical expansion and provides a non-revealing example.  

On the other hand, POWER(0,0) is defined to return #DIV/0!  The definitions are carried over verbatim from ECMA-376-4 of December 2006.  

Nevertheless, Excel 2010 and 2013 (Preview) both result in #NUM! for =POWER(0,0).  

(Sigh)

-----Original Message-----
From: Dennis E. Hamilton [mailto:orcmid@apache.org] 
Sent: Sunday, February 10, 2013 16:49
To: dev@openoffice.apache.org
Subject: RE: Calc behavior: result of 0 ^ 0

[ ... ]

PS: It appears that Excel does not satisfy the OpenFormula definition.  =SERIESSUM(0,0,1,C1:C1) where C1 = PI() returns #NUM!  SERIESSUM(1,0,1,C1:C1) returns PI().  This is the case for Excel 2010 and Excel 2013 (Preview).  Since SERIESSUM has no implementation in Apache OpenOffice, any interchange-interoperability failure is yet to come. 

-----Original Message-----
From: Regina Henschel [mailto:rb.henschel@t-online.de] 
Sent: Sunday, February 10, 2013 15:10
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

Hi all,

Here my view:
We should not change the current behavior, because
- It is one of three allowed result, so it is not an error.
- Changing it, would break old documents.
- returning 1 will be consistent with SERIESSUM (I know, that SERIESSUM 
is currently not yet adapted to ODF1.2, but for SERIESSUM there is no 
choice.)
- returning 1 is the same as in BASIC.


[ ... ]

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <or...@apache.org>]

I don't see how this discussion impacts the results of SERIESSUM.  The nice aspect of SERIESSUM is that it specifies precisely what the result should be.  So long as no exponents are negative, it requires that SERIESSUM(0;...) be either c[0] or 0 depending on whether or not 0 is included in the set of exponents.  c[0] is the coefficient for the term having exponent 0.  That's a very specific, whether or not astonishing, definition.  

There is no requirement that SERIESSUM use POWER(a,n) as the implementation for the 0^0 case. The SERIESUM definition appears to be independent of what an implementation-defined 0^0 might be.

I'm not challenging your preference.  I'm just observing that the SERIESSUM definition is explicitly separate from the POWER definition concerning 0^0.

 - Dennis

PS: It appears that Excel does not satisfy the OpenFormula definition.  =SERIESSUM(0,0,1,C1:C1) where C1 = PI() returns #NUM!  SERIESSUM(1,0,1,C1:C1) returns PI().  This is the case for Excel 2010 and Excel 2013 (Preview).  Since SERIESSUM has no implementation in Apache OpenOffice, any interchange-interoperability failure is yet to come. 

-----Original Message-----
From: Regina Henschel [mailto:rb.henschel@t-online.de] 
Sent: Sunday, February 10, 2013 15:10
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

Hi all,

Here my view:
We should not change the current behavior, because
- It is one of three allowed result, so it is not an error.
- Changing it, would break old documents.
- returning 1 will be consistent with SERIESSUM (I know, that SERIESSUM 
is currently not yet adapted to ODF1.2, but for SERIESSUM there is no 
choice.)
- returning 1 is the same as in BASIC.


Andrea Pescetti schrieb:
> 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
> - 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
> - We gain interoperability since Excel returns an error too
> - We lose backwards compatibility if someone was relying on the fact
> that OpenOffice returns 1 as the result of "=0 ^ 0"
>
> 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.

It allows you to design a generic table of value in some cases, without 
the need to use always case distinction.

  A side
> benefit would be 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).

The question is, whether "0^0=1" is more useful than "0^0=undefined".

>
> Is there consensus that this is a reasonable backwards-incompatible
> change, or compelling reasons to revert it?

There is no consensus.

Kind regards
Regina

Re: Calc behavior: result of 0 ^ 0

[Regina Henschel <rb...@t-online.de>]

Hi all,

Here my view:
We should not change the current behavior, because
- It is one of three allowed result, so it is not an error.
- Changing it, would break old documents.
- returning 1 will be consistent with SERIESSUM (I know, that SERIESSUM 
is currently not yet adapted to ODF1.2, but for SERIESSUM there is no 
choice.)
- returning 1 is the same as in BASIC.


Andrea Pescetti schrieb:
> 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
> - 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
> - We gain interoperability since Excel returns an error too
> - We lose backwards compatibility if someone was relying on the fact
> that OpenOffice returns 1 as the result of "=0 ^ 0"
>
> 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.

It allows you to design a generic table of value in some cases, without 
the need to use always case distinction.

  A side
> benefit would be 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).

The question is, whether "0^0=1" is more useful than "0^0=undefined".

>
> Is there consensus that this is a reasonable backwards-incompatible
> change, or compelling reasons to revert it?

There is no consensus.

Kind regards
Regina

Re: Calc behavior: result of 0 ^ 0

[TJ Frazier <tj...@cfl.rr.com>]

On 2/9/2013 18:11, 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
> - 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
> - We gain interoperability since Excel returns an error too
> - We lose backwards compatibility if someone was relying on the fact
> that OpenOffice returns 1 as the result of "=0 ^ 0"
>
> 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 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).
>
> Is there consensus that this is a reasonable backwards-incompatible
> change, or compelling reasons to revert it?
>
> Regards,
>    Andrea.
>
If we keep the change (+1 from me), someone more adept than I should 
write something like a POWER0(a,b) function. This can be substituted 
easily for POWER, or a ^ b, and returns 0^0=0. If we're sure to break 
some spreadsheets, let's make a quick fix easy. (I'd bet that in half of 
the "broken" cases, someone will say, "Aha! That value should never be 
0! We've finally found that old bug!" In short, we'll be helping some 
folks.)

/tj/

Re: Calc behavior: result of 0 ^ 0

["Marcus (OOo)" <ma...@wtnet.de>]

Am 02/10/2013 12:11 AM, schrieb Andrea Pescetti:
> 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
> - 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
> - We gain interoperability since Excel returns an error too
> - We lose backwards compatibility if someone was relying on the fact
> that OpenOffice returns 1 as the result of "=0 ^ 0"
>
> 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 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).

Right, the change has a *very* narrow and limited group of users. I mean 
not the power function itself but the result of "0 ^ 0".

> Is there consensus that this is a reasonable backwards-incompatible
> change, or compelling reasons to revert it?

I don't see any problem to change the behavior for *this special* case. 
Before it was behaving within the ODF standard and after the commit it's 
still the same. And when we can improve the interoperability with MS 
Office - even if it's just 0.5% - then even better.

So, +1 to keep Pedro's change.

Marcus

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <or...@apache.org>]

Please, I think I made it very clear that whatever the direction, the documentation needs to be explicit.  I also looked in the embedded help for POWER and it is not helpful.  

That is the only point of the note being replied to below.

Knuth and I will continue to disagree about that.  Either way, I rest my case.

And as far as the February 1900 calendar bug goes, please recall that it was to remain downward compatible with Lotus 1-2-3.  At the international standard level, that was not tolerated, as you know.  Think of this as delayed karma for Apache OpenOffice.  

In this case, allowing any of 0, 1, or error to be implementation-defined is not helpful and the compelling case for me is alignment with Excel on "error."

I see no point in reiterating on this.  I am not going to change my recommendation.  All of the considerations have been presented.  Now it remains to determine how to go forward.  I have no idea what the consensus will be.  I await what others have to say.  I have no need to say any more.

 - Dennis  

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Saturday, February 09, 2013 16:57
To: dev@openoffice.apache.org; orcmid@apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

On Sat, Feb 9, 2013 at 7:39 PM, Dennis E. Hamilton <or...@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.

[ ... ]

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <or...@apache.org>]

Please, I think I made it very clear that whatever the agreed direction, the documentation needs to be explicit.  I also looked in the AOO embedded help for POWER and it is not helpful.  (By the way, it would be great if it remained possible to access the on-line help even if the embedded help is installed.)

That is the only point of the note being replied to below.

Knuth and I will continue to disagree about what is an appropriate result for 0^0 (maybe even 0/0).  Either way, I rest my case.  0 is already an exception in the laws of arithmetic.  One must always make exceptions to avoid reasoning through a division by 0 (a common trick for proving that 0 = 1).

And as far as the February 1900 calendar bug goes, please recall that it was to remain downward compatible with Lotus 1-2-3.  At the international standard level that was not tolerated, as you know.  Think of this as delayed karma for Apache OpenOffice.  

In this case, allowing any of 0, 1, or error to be implementation-defined is not helpful and the compelling case for me is alignment with Excel on "error."

I see no point in reiterating on this.  I am not going to change my recommendation.  All of the considerations have been presented.  Now it remains to determine how to go forward.  I have no idea what the consensus will be.  I await what others have to say.  I have no need to say any more.

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Saturday, February 09, 2013 16:57
To: dev@openoffice.apache.org; orcmid@apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

On Sat, Feb 9, 2013 at 7:39 PM, Dennis E. Hamilton <or...@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.

[ ... ]

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sat, Feb 9, 2013 at 7:39 PM, Dennis E. Hamilton <or...@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:robweir@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 <pe...@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.
>

Re: Calc behavior: result of 0 ^ 0

[David Gerard <dg...@gmail.com>]

On 10 February 2013 00:39, Dennis E. Hamilton <or...@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.


Out of curiosity, I just tried on OOo 1.0.3, 2.2 and 2.4 and LO 4.0
(all Windows); all return value 1 for =0^0 . MS Word 2007, of course,
returns NaN.

For interop, there is LO 4.0 to consider as well as MS Word.


- d.

RE: Calc behavior: result of 0 ^ 0

["Dennis E. Hamilton" <or...@apache.org>]

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:robweir@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 <pe...@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.

Re: Calc behavior: result of 0 ^ 0

[Торохов Сергей <to...@yandex.ru>]

P.S.

The over example:

[1-exp(x)]/x

  tends to "-1" while x -> "0"

Re: Calc behavior: result of 0 ^ 0

[Торохов Сергей <to...@yandex.ru>]

02/10/13 04:43, Guenter Marxen пишет:
> Hi,
>
> I've looked in Wikipedia
> http://en.wikipedia.org/wiki/Zero_power_zero#Zero_to_the_power_of_zero
> and for me it seems very reasonable to keep the old behaviour, as 
> according to this article many math and other software treats 0^0 = 1 
> (see the paragraphs under "Treatment on computers").
>
> According to the German wikipedia Donald Knuth refuses to define 
> 0^0=undefined but claims = 1 because otherwise many mathematical 
> theorema would need special case treatments.
>
> So also mathematicians define 0^0=1. So let 0^0=1 in AOO.
>
> Günter Marxen
>
>
>

In this case the expression 0^0 could be represents like f(x)^g(x) and 
the limit of this expression will depends of how rapidly each of f(x) 
and g(x) functions tends to NULL. So evaluation of indeterminate must be 
made individually in every case. To resolve it needs to take logarithm 
of initial expression and then try to find it's limit.

For example the  limit of x^x while x tends to 0 will be equal 1
(if I don't make a mistake)

---
Sergey Torokhov

Re: Calc behavior: result of 0 ^ 0

[Guenter Marxen <gu...@googlemail.com>]

Hi,

I've looked in Wikipedia
http://en.wikipedia.org/wiki/Zero_power_zero#Zero_to_the_power_of_zero
and for me it seems very reasonable to keep the old behaviour, as 
according to this article many math and other software treats 0^0 = 1 
(see the paragraphs under "Treatment on computers").

According to the German wikipedia Donald Knuth refuses to define 
0^0=undefined but claims = 1 because otherwise many mathematical 
theorema would need special case treatments.

So also mathematicians define 0^0=1. So let 0^0=1 in AOO.

Günter Marxen


Am 10.02.2013 00:43, schrieb Rob Weir:
> On Sat, Feb 9, 2013 at 6:11 PM, Andrea Pescetti <pe...@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.

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Indeed, I've seen.
But not much for the moment.
But Of course, the proposal seems a good one.

Hagar

Le 10/02/2013 17:26, Andrea Pescetti a écrit :

> On 10/02/2013 Hagar Delest wrote:
>> you don't mind breaking the backward compatibility of the whole
>> extensions eco-system? See:
>> http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html
>> I'm lost about the priorities...
>
> For the record, there's an after-FOSDEM followup to that thread with a discussion of how it might be possible to incorporate the new changes without disrupting the workflow of people who are using extensions in 3.x and want to use the same extensions in 4.x.
>
> Regards,
>    Andrea.

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

On 10/02/2013 Hagar Delest wrote:
> you don't mind breaking the backward compatibility of the whole
> extensions eco-system? See:
> http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html
> I'm lost about the priorities...

For the record, there's an after-FOSDEM followup to that thread with a 
discussion of how it might be possible to incorporate the new changes 
without disrupting the workflow of people who are using extensions in 
3.x and want to use the same extensions in 4.x.

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 11:39 PM, Andrew Douglas Pitonyak
<an...@pitonyak.org> wrote:
>
> On 02/10/2013 10:04 AM, Rory O'Farrell wrote:
>>
>> My thinking is the Calc should return the mathematically correct answer.
>
> ODF standard defines what can be returned. If there is a single
> mathematically correct answer, I would expect the standard to define it. If
> the standard is wrong (like defining 1+1=3), then the standard should be
> changed.
>
> At the end of the day, it amuses me that the standard allows for three
> different values. I suppose that if the people writing the standard could
> not agree on a single answer, I doubt if you will receive a decent consensus
> here.
>

The goal when writing the ODF 1.2 OpenFormula specification was to
describe current spreadsheet behavior.  It was not our goal to define
a new spreadsheet formula language that was cleaner, better-designed,
more consistent than what was already out there.  It would have been
legitimate to define an entirely new language and open up all past
design decisions.  But that is not what we aimed to do.

If you recall MS Office 2007 was not interoperable with OpenOffice
spreadsheets.  Every single formula was incompatible.  Even basic
functions like SUM() and AVERAGE() were lost when Office opened an ODF
document.

By having a new ODF 1.2 formula specification that encompasses the
range of behaviors in real-world spreadsheets today, we now have an MS
Office Excel that is compatible with the vast majority of OpenOffice
spreadsheets, even though there may be differences in edge cases like
0^0.  So from the standardization perspective I think this is a
success, both technically and politically.  It vastly improved
interoperability.

-Rob

> I would find it a bit offensive if 0/0 returned 0 or 1 (not that it might
> not be occasionally useful). I can probably claim the same for 0^0.
>
> The fact that the standard does not take a stand leaves me a bit bewildered,
> but I can guess as to why.
>
> --
> Andrew Pitonyak
> My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
> Info:  http://www.pitonyak.org/oo.php
>

Re: Calc behavior: result of 0 ^ 0

[Jürgen Schmidt <jo...@gmail.com>]

On 2/11/13 5:39 AM, Andrew Douglas Pitonyak wrote:
> 
> On 02/10/2013 10:04 AM, Rory O'Farrell wrote:
>> My thinking is the Calc should return the mathematically correct answer.
> ODF standard defines what can be returned. If there is a single
> mathematically correct answer, I would expect the standard to define it.
> If the standard is wrong (like defining 1+1=3), then the standard should
> be changed.
> 
> At the end of the day, it amuses me that the standard allows for three
> different values. 

that is indeed the most interesting thing of this whole thread.

Juergen


I suppose that if the people writing the standard
> could not agree on a single answer, I doubt if you will receive a decent
> consensus here.
> 
> I would find it a bit offensive if 0/0 returned 0 or 1 (not that it
> might not be occasionally useful). I can probably claim the same for 0^0.
> 
> The fact that the standard does not take a stand leaves me a bit
> bewildered, but I can guess as to why.
> 

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

On 02/10/2013 10:04 AM, Rory O'Farrell wrote:
> My thinking is the Calc should return the mathematically correct answer.
ODF standard defines what can be returned. If there is a single 
mathematically correct answer, I would expect the standard to define it. 
If the standard is wrong (like defining 1+1=3), then the standard should 
be changed.

At the end of the day, it amuses me that the standard allows for three 
different values. I suppose that if the people writing the standard 
could not agree on a single answer, I doubt if you will receive a decent 
consensus here.

I would find it a bit offensive if 0/0 returned 0 or 1 (not that it 
might not be occasionally useful). I can probably claim the same for 0^0.

The fact that the standard does not take a stand leaves me a bit 
bewildered, but I can guess as to why.

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 10:04 AM, Rory O'Farrell <of...@iol.ie> wrote:
> On Sun, 10 Feb 2013 15:44:38 +0100
> RGB ES <rg...@gmail.com> wrote:
>
>> 2013/2/10 Hagar Delest <ha...@laposte.net>
>>
>> > Le 10/02/2013 00:43, Rob Weir a écrit :
>> >
>> >  Spreadsheets are used by businessmen and not only mathematicians.
>> >>
>> >
>> > I think that very few mathematicians use AOO at all.
>> > Even in the industry (in which I work for almost 15 years), MS Excel is
>> > not used to perform high level calculations. Even the nice charts we can
>> > see from complex tests are in fact exports from dedicated software that
>> > just give the numbers and let MS Excel draw the chart with all the bells
>> > and whistles needed (secondary grid, axis, legends, ...).
>> > Real calculation is made with specific applications, often developed by
>> > the companies to be sure they master the process.
>>
>>
>>
>> +1. I remember a conference (I'm physicist) on which one person presented
>> charts made with excel. One of the senior scientist on the audience then
>> said "you are masochist, don't you?"
>>
>> Regards
>> Ricardo
>
> My thinking is the Calc should return the mathematically correct answer.  Consider a parallel case: suppose some other widely used spreadsheet was to define Pi as 3 (following the Indiana Pi Bill, bill #246 of the 1897 sitting of the Indiana General Assembly), ar to say that 2+2=5, should Calc follow?  No, we should be correct; it is open to anyone who doesn't like this to use another application.
>

We're discussing conventions, not facts.  The value of Pi is a fact,
not a convention.

http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/

" This means that depending on the context where 0^0 occurs, you might
   wish to substitute it with 1, indeterminate or undefined/nonexistent.

   Some people feel that giving a value to a function with an essential
   discontinuity at a point, such as x^y at (0,0) , is an inelegant patch
   and should not be done. Others point out correctly that in
   mathematics, usefulness and consistency are very important, and that
   under these parameters 0^0 = 1 is the natural choice."

So I'm in favor of "usefulness and consistency'" over pedantry.  I
think users and application developers would agree.

-Rob

>> >
>> >  - 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.
>> >>
>> >
>> > It just means that an acceptable shortcut was used. Giving 'error' would
>> > be valid too (regarding the ODF compliance).
>> > But I would not say that mathematics POV 1 as a result is valid. Even if
>> > some tend to think that 1 is OK.
>> >
>> >
>> >
>> >  Microsoft has gone decades with treating the year 1900 as a leap year.
>> >>    Should we?
>> >>
>> >
>> > Agreed, who cares what MS Excel does? It should not dictate what AOO
>> > should do.
>> >
>> >
>> >
>> >  - 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.
>> >>
>> >
>> > First, how many users would face such a problem when both the base and
>> > exponent are null???
>> > Again, real maths are not done in spreadsheets. So it's very likely the
>> > 0^0 cases would not break that many sheets and with an error, users will be
>> > able to spot quickly the issue and adapt to prevent that situation to be
>> > calculated.
>> >
>> > Second, and that's my main point here: you're angry about such a minor
>> > change when you don't mind breaking the backward compatibility of the whole
>> > extensions eco-system? See: http://www.mail-archive.com/**
>> > api@openoffice.apache.org/**msg00107.html<http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html>
>> > I'm lost about the priorities... and how end-users fit in your agenda.
>> >
>> > Hagar
>> >
>
>
> --
> Rory O'Farrell <of...@iol.ie>

Re: Calc behavior: result of 0 ^ 0

[Rory O'Farrell <of...@iol.ie>]

On Sun, 10 Feb 2013 15:44:38 +0100
RGB ES <rg...@gmail.com> wrote:

> 2013/2/10 Hagar Delest <ha...@laposte.net>
> 
> > Le 10/02/2013 00:43, Rob Weir a écrit :
> >
> >  Spreadsheets are used by businessmen and not only mathematicians.
> >>
> >
> > I think that very few mathematicians use AOO at all.
> > Even in the industry (in which I work for almost 15 years), MS Excel is
> > not used to perform high level calculations. Even the nice charts we can
> > see from complex tests are in fact exports from dedicated software that
> > just give the numbers and let MS Excel draw the chart with all the bells
> > and whistles needed (secondary grid, axis, legends, ...).
> > Real calculation is made with specific applications, often developed by
> > the companies to be sure they master the process.
> 
> 
> 
> +1. I remember a conference (I'm physicist) on which one person presented
> charts made with excel. One of the senior scientist on the audience then
> said "you are masochist, don't you?"
> 
> Regards
> Ricardo

My thinking is the Calc should return the mathematically correct answer.  Consider a parallel case: suppose some other widely used spreadsheet was to define Pi as 3 (following the Indiana Pi Bill, bill #246 of the 1897 sitting of the Indiana General Assembly), ar to say that 2+2=5, should Calc follow?  No, we should be correct; it is open to anyone who doesn't like this to use another application.

> >
> >  - 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.
> >>
> >
> > It just means that an acceptable shortcut was used. Giving 'error' would
> > be valid too (regarding the ODF compliance).
> > But I would not say that mathematics POV 1 as a result is valid. Even if
> > some tend to think that 1 is OK.
> >
> >
> >
> >  Microsoft has gone decades with treating the year 1900 as a leap year.
> >>    Should we?
> >>
> >
> > Agreed, who cares what MS Excel does? It should not dictate what AOO
> > should do.
> >
> >
> >
> >  - 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.
> >>
> >
> > First, how many users would face such a problem when both the base and
> > exponent are null???
> > Again, real maths are not done in spreadsheets. So it's very likely the
> > 0^0 cases would not break that many sheets and with an error, users will be
> > able to spot quickly the issue and adapt to prevent that situation to be
> > calculated.
> >
> > Second, and that's my main point here: you're angry about such a minor
> > change when you don't mind breaking the backward compatibility of the whole
> > extensions eco-system? See: http://www.mail-archive.com/**
> > api@openoffice.apache.org/**msg00107.html<http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html>
> > I'm lost about the priorities... and how end-users fit in your agenda.
> >
> > Hagar
> >


-- 
Rory O'Farrell <of...@iol.ie>

Re: Calc behavior: result of 0 ^ 0

[RGB ES <rg...@gmail.com>]

2013/2/10 Hagar Delest <ha...@laposte.net>

> Le 10/02/2013 00:43, Rob Weir a écrit :
>
>  Spreadsheets are used by businessmen and not only mathematicians.
>>
>
> I think that very few mathematicians use AOO at all.
> Even in the industry (in which I work for almost 15 years), MS Excel is
> not used to perform high level calculations. Even the nice charts we can
> see from complex tests are in fact exports from dedicated software that
> just give the numbers and let MS Excel draw the chart with all the bells
> and whistles needed (secondary grid, axis, legends, ...).
> Real calculation is made with specific applications, often developed by
> the companies to be sure they master the process.



+1. I remember a conference (I'm physicist) on which one person presented
charts made with excel. One of the senior scientist on the audience then
said "you are masochist, don't you?"

Regards
Ricardo




>
>
>
>  - 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.
>>
>
> It just means that an acceptable shortcut was used. Giving 'error' would
> be valid too (regarding the ODF compliance).
> But I would not say that mathematics POV 1 as a result is valid. Even if
> some tend to think that 1 is OK.
>
>
>
>  Microsoft has gone decades with treating the year 1900 as a leap year.
>>    Should we?
>>
>
> Agreed, who cares what MS Excel does? It should not dictate what AOO
> should do.
>
>
>
>  - 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.
>>
>
> First, how many users would face such a problem when both the base and
> exponent are null???
> Again, real maths are not done in spreadsheets. So it's very likely the
> 0^0 cases would not break that many sheets and with an error, users will be
> able to spot quickly the issue and adapt to prevent that situation to be
> calculated.
>
> Second, and that's my main point here: you're angry about such a minor
> change when you don't mind breaking the backward compatibility of the whole
> extensions eco-system? See: http://www.mail-archive.com/**
> api@openoffice.apache.org/**msg00107.html<http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html>
> I'm lost about the priorities... and how end-users fit in your agenda.
>
> Hagar
>

Re: Calc behavior: result of 0 ^ 0

[Ariel Constenla-Haile <ar...@apache.org>]

On Sun, Feb 10, 2013 at 09:51:25PM +0100, Hagar Delest wrote:
> And have you read my previous message?  I don't understand why there
> is almost nothing aired when there are talks about breaking the
> compatibility of ALL the extensions because of a minor issue. And here
> you're challenging a change that will affect very few users.
> 
> You told in your first message that you were concerned that the change
> would break the backward compatibility.  But are you not concerned by
> all the users having their extensions deactivated by a minor API
> change???

That change is in the configuration schema, not in the API; so, this
isn't an API change.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

Re: Calc behavior: result of 0 ^ 0

[Jürgen Schmidt <jo...@gmail.com>]

On 2/10/13 9:51 PM, Hagar Delest wrote:
> Le 10/02/2013 21:21, Rob Weir a écrit :
>> Did you not notice the title of this thread? Has it entirely escaped
>> you that we're talking about 0^0 here?  If you want to start another
>> threat about extensions, then go ahead and I will comment there.  But
>> anyone of the intelligence of a grapefruit would not find it strange
>> that I am discussing only 0^0 in this thread.
> 
> And have you read my previous message?
> I don't understand why there is almost nothing aired when there are
> talks about breaking the compatibility of ALL the extensions because of
> a minor issue. And here you're challenging a change that will affect
> very few users.

"ALL the extensions" is of course completely nonsense. The change we
talked about is only for extensions that define an own toolbar.

And we can of course start a new discussion about the missing
cooperation of extension developers to work with core developers. It can
be relatively easy fixed by any extension developer. And of course with
a little extra work in a way that breaks nothing. Minor effort in the
extensions, much more and more complex code in the core.

The question is always how we want to move forward. Changes are good if
they help to attract more developers and if they help to improve the
product over time.

If developers can't change things and can't improve code etc. over time
we will have a problem to find enough developers who are willing to
maintain old incomprehensible code that we have in many areas.

That don't mean that I support any kind of incompatible change but when
we have a simple migration path in place and when we talk about a major
version I will probably support most of them.

Juergen

> 
> You told in your first message that you were concerned that the change
> would break the backward compatibility.
> But are you not concerned by all the users having their extensions
> deactivated by a minor API change???
> 
> There is your other message:
> Le 09/02/2013 18:40, Rob Weir a écrit :
>> I've added a new section to the 4.0 Release Notes for tracking changes
>> that impact backwards compatibility:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
>>
>>
>> This would include changes to the public interfaces of AOO, including
>> incompatible changes to API's (including spreadsheet functions), file
>> formats, etc.
> 
> But I don't see any reference to the extensions issue.
> 
> If there is a real problem to be talked about, it's more the API change
> that would break extensions compatibility.
> Honestly, I don't care about the 0^0 issue. Not enough users will be
> impacted.
> 
> Hagar

Re: Calc behavior: result of 0 ^ 0

[Ariel Constenla-Haile <ar...@apache.org>]

On Mon, Feb 11, 2013 at 12:57:57AM +0100, Andrea Pescetti wrote:
> It is unavoidable that we will open a discussion about the
> extensions compatibility; I started this one about 0 ^ 0 which is
> enjoying unexpected popularity (and I would appreciate, for the sake
> of completeness, to see one example of a spreadsheet that would be
> broken by the new behavior), but when this one has settled I'll open
> one about extensions

There is already a thread on api@, where it belongs. Please don't start
spreading threads everywhere! (It already hard to follow
endless/pointless discussion on these mailing lists, to follow them in
parallel in several lists).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti <pe...@apache.org>]

Rob Weir wrote:
> On Sun, Feb 10, 2013 at 4:26 PM, Hagar Delest wrote:
>> No, what bothers me is your silence in the other topics.
> Congratulations for being the first one -- to my knowledge at least --
> to argue that I should be giving more opinions

Well, the others are probably fine with the current amount of discussion!

It is unavoidable that we will open a discussion about the extensions 
compatibility; I started this one about 0 ^ 0 which is enjoying 
unexpected popularity (and I would appreciate, for the sake of 
completeness, to see one example of a spreadsheet that would be broken 
by the new behavior), but when this one has settled I'll open one about 
extensions unless Hagar or someone else does it first (in case, try to 
describe impact and possible mitigation, as well as some popular 
extensions that would be broken).

Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 4:26 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 21:57, Rob Weir a écrit :
>
>> Just because I don't hijack this thread to discuss an unrelated issue
>> does not mean anything.  I am also against torture, high public debt
>> and rap music, but that does not mean I am going to discuss them in
>> this thread. And it certainly does not mean that my silence on these
>> topics in this particular thread means that I approve of them.
>
>
> No, what bothers me is your silence in the other topics.

Congratulations for being the first one -- to my knowledge at least --
to argue that I should be giving more opinions, not fewer, on the
list.  I thank you for that, sir !

-Rob

> You're verbose on minor issues and silent on more critical ones.
> It's a kind of hijacking, sorry, but at least the problem is in the open
> now.
> And BTW, there is nothing about the API change for the extensions except on
> the API list.
>
> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 21:57, Rob Weir a écrit :
> Just because I don't hijack this thread to discuss an unrelated issue
> does not mean anything.  I am also against torture, high public debt
> and rap music, but that does not mean I am going to discuss them in
> this thread. And it certainly does not mean that my silence on these
> topics in this particular thread means that I approve of them.

No, what bothers me is your silence in the other topics.
You're verbose on minor issues and silent on more critical ones.
It's a kind of hijacking, sorry, but at least the problem is in the open now.
And BTW, there is nothing about the API change for the extensions except on the API list.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 3:51 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 21:21, Rob Weir a écrit :
>
>> Did you not notice the title of this thread? Has it entirely escaped
>> you that we're talking about 0^0 here?  If you want to start another
>> threat about extensions, then go ahead and I will comment there.  But
>> anyone of the intelligence of a grapefruit would not find it strange
>> that I am discussing only 0^0 in this thread.
>
>
> And have you read my previous message?
> I don't understand why there is almost nothing aired when there are talks
> about breaking the compatibility of ALL the extensions because of a minor
> issue. And here you're challenging a change that will affect very few users.
>
> You told in your first message that you were concerned that the change would
> break the backward compatibility.
> But are you not concerned by all the users having their extensions
> deactivated by a minor API change???
>

Just because I don't hijack this thread to discuss an unrelated issue
does not mean anything.  I am also against torture, high public debt
and rap music, but that does not mean I am going to discuss them in
this thread. And it certainly does not mean that my silence on these
topics in this particular thread means that I approve of them.

-Rob

> There is your other message:
> Le 09/02/2013 18:40, Rob Weir a écrit :
>>
>> I've added a new section to the 4.0 Release Notes for tracking changes
>> that impact backwards compatibility:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
>>
>> This would include changes to the public interfaces of AOO, including
>> incompatible changes to API's (including spreadsheet functions), file
>> formats, etc.
>
>
> But I don't see any reference to the extensions issue.
>
> If there is a real problem to be talked about, it's more the API change that
> would break extensions compatibility.
> Honestly, I don't care about the 0^0 issue. Not enough users will be
> impacted.
>
> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 21:21, Rob Weir a écrit :
> Did you not notice the title of this thread? Has it entirely escaped
> you that we're talking about 0^0 here?  If you want to start another
> threat about extensions, then go ahead and I will comment there.  But
> anyone of the intelligence of a grapefruit would not find it strange
> that I am discussing only 0^0 in this thread.

And have you read my previous message?
I don't understand why there is almost nothing aired when there are talks about breaking the compatibility of ALL the extensions because of a minor issue. And here you're challenging a change that will affect very few users.

You told in your first message that you were concerned that the change would break the backward compatibility.
But are you not concerned by all the users having their extensions deactivated by a minor API change???

There is your other message:
Le 09/02/2013 18:40, Rob Weir a écrit :
> I've added a new section to the 4.0 Release Notes for tracking changes
> that impact backwards compatibility:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
>
> This would include changes to the public interfaces of AOO, including
> incompatible changes to API's (including spreadsheet functions), file
> formats, etc.

But I don't see any reference to the extensions issue.

If there is a real problem to be talked about, it's more the API change that would break extensions compatibility.
Honestly, I don't care about the 0^0 issue. Not enough users will be impacted.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 2:58 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 17:07, Rob Weir a écrit :
>
>> But it is not question of mathematics. It is a question about how we
>> make controversial changes and how we keep the ecosystem informed
>> about breaking changes.   Hiding behind one (but not the only)
>> mathematical convention for this calculation avoids dealing with the
>> fact that a broken changes was checked in without any review on this
>> list and without any attempt to inform users and application
>> developers about it.  I hope we agree that this should not be how we
>> do things.
>
>
> Agreed. But for the 0^0 issue, you were very verbose against such a change,
> when it affects very few users whereas for the broken extensions issue, that
> would affect a good deal of users (perhaps millions), you were just asking
> about how to communicate. Nothing said about the comments from Bernard and
> Hans. The difference in the handling of both issues is what I find rather
> strange.
>

Did you not notice the title of this thread? Has it entirely escaped
you that we're talking about 0^0 here?  If you want to start another
threat about extensions, then go ahead and I will comment there.  But
anyone of the intelligence of a grapefruit would not find it strange
that I am discussing only 0^0 in this thread.

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 17:07, Rob Weir a écrit :
> But it is not question of mathematics. It is a question about how we
> make controversial changes and how we keep the ecosystem informed
> about breaking changes.   Hiding behind one (but not the only)
> mathematical convention for this calculation avoids dealing with the
> fact that a broken changes was checked in without any review on this
> list and without any attempt to inform users and application
> developers about it.  I hope we agree that this should not be how we
> do things.

Agreed. But for the 0^0 issue, you were very verbose against such a change, when it affects very few users whereas for the broken extensions issue, that would affect a good deal of users (perhaps millions), you were just asking about how to communicate. Nothing said about the comments from Bernard and Hans. The difference in the handling of both issues is what I find rather strange.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 10:49 AM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 16:30, Rob Weir a écrit :
>
>> It does not follow that if "real mathematicians" do not use
>> spreadsheets, that making breaking changes does not have consequences.
>>   That logic is nonsensical.
>
>
> I said that the consequences would be very limited. And that using
> "mathematicians using spreadsheets" point is almost irrelevant.
> Some users may face the 0^0 situation, of course.
>
>
>
>> And again, it is mistaken to assume that the person who suffers
>> because of a newly introduced error is the person who can correct the
>> error.  Just as with extensions, the person who designs a sheet and
>> the person who uses the sheet might be different people.
>
>
> Again, how many will be affected by such a sheet using this kind of
> calculation?
> But that's a good point for the extensions topic.
>
>
>
>> Don't put words in my mouth.  I'm not angry.  And when did I ever say
>> I was happy about breaking extension compatibility?  Quite the
>> opposite.  I've called for all breaking changes to be proposed and
>> reviewed on the dev list.
>
>
> OK, wrong wording.
> But I feel that you were not that dynamic about the extension issue compared
> to your posts in this calculation problem.
> Of course, no plain text to quote but it's your activity that makes me think
> this.
>

Remember, it was I, and no one else, who added a new section to the
Release Notes for breaking changes and called for all such changes to
be reviewed on this list.  So I think my "activity" here has gone
beyond yours or anyone else's.

In any case, I'm not saying we cannot make any breaking changes.  I'm
only arguing for them to be reviewed and communicated early so
application developers can react and be prepared before we release AOO
4.0.

All this pedantic argument about the mathematics totally misses the
point.  This is not a question about mathematics.  There are multiple
conventions and I could point to authorities from Euler to Knuth for
saying that the correct answer is 1.

But it is not question of mathematics. It is a question about how we
make controversial changes and how we keep the ecosystem informed
about breaking changes.   Hiding behind one (but not the only)
mathematical convention for this calculation avoids dealing with the
fact that a broken changes was checked in without any review on this
list and without any attempt to inform users and application
developers about it.  I hope we agree that this should not be how we
do things.

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 16:30, Rob Weir a écrit :
> It does not follow that if "real mathematicians" do not use
> spreadsheets, that making breaking changes does not have consequences.
>   That logic is nonsensical.

I said that the consequences would be very limited. And that using "mathematicians using spreadsheets" point is almost irrelevant.
Some users may face the 0^0 situation, of course.


> And again, it is mistaken to assume that the person who suffers
> because of a newly introduced error is the person who can correct the
> error.  Just as with extensions, the person who designs a sheet and
> the person who uses the sheet might be different people.

Again, how many will be affected by such a sheet using this kind of calculation?
But that's a good point for the extensions topic.


> Don't put words in my mouth.  I'm not angry.  And when did I ever say
> I was happy about breaking extension compatibility?  Quite the
> opposite.  I've called for all breaking changes to be proposed and
> reviewed on the dev list.

OK, wrong wording.
But I feel that you were not that dynamic about the extension issue compared to your posts in this calculation problem.
Of course, no plain text to quote but it's your activity that makes me think this.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 8:57 AM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 00:43, Rob Weir a écrit :
>
>> Spreadsheets are used by businessmen and not only mathematicians.
>
>
> I think that very few mathematicians use AOO at all.
> Even in the industry (in which I work for almost 15 years), MS Excel is not
> used to perform high level calculations. Even the nice charts we can see
> from complex tests are in fact exports from dedicated software that just
> give the numbers and let MS Excel draw the chart with all the bells and
> whistles needed (secondary grid, axis, legends, ...).
> Real calculation is made with specific applications, often developed by the
> companies to be sure they master the process.
>
>
>
>>> - 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.
>
>
> It just means that an acceptable shortcut was used. Giving 'error' would be
> valid too (regarding the ODF compliance).
> But I would not say that mathematics POV 1 as a result is valid. Even if
> some tend to think that 1 is OK.
>
>
>
>> Microsoft has gone decades with treating the year 1900 as a leap year.
>>    Should we?
>
>
> Agreed, who cares what MS Excel does? It should not dictate what AOO should
> do.
>
>
>
>>> - 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.
>
>
> First, how many users would face such a problem when both the base and
> exponent are null???
> Again, real maths are not done in spreadsheets. So it's very likely the 0^0
> cases would not break that many sheets and with an error, users will be able
> to spot quickly the issue and adapt to prevent that situation to be
> calculated.
>

It does not follow that if "real mathematicians" do not use
spreadsheets, that making breaking changes does not have consequences.
 That logic is nonsensical.

And again, it is mistaken to assume that the person who suffers
because of a newly introduced error is the person who can correct the
error.  Just as with extensions, the person who designs a sheet and
the person who uses the sheet might be different people.

> Second, and that's my main point here: you're angry about such a minor
> change when you don't mind breaking the backward compatibility of the whole
> extensions eco-system? See:
> http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html
> I'm lost about the priorities... and how end-users fit in your agenda.
>

Don't put words in my mouth.  I'm not angry.  And when did I ever say
I was happy about breaking extension compatibility?  Quite the
opposite.  I've called for all breaking changes to be proposed and
reviewed on the dev list.

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 00:43, Rob Weir a écrit :
> Spreadsheets are used by businessmen and not only mathematicians.

I think that very few mathematicians use AOO at all.
Even in the industry (in which I work for almost 15 years), MS Excel is not used to perform high level calculations. Even the nice charts we can see from complex tests are in fact exports from dedicated software that just give the numbers and let MS Excel draw the chart with all the bells and whistles needed (secondary grid, axis, legends, ...).
Real calculation is made with specific applications, often developed by the companies to be sure they master the process.


>> - 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.

It just means that an acceptable shortcut was used. Giving 'error' would be valid too (regarding the ODF compliance).
But I would not say that mathematics POV 1 as a result is valid. Even if some tend to think that 1 is OK.


> Microsoft has gone decades with treating the year 1900 as a leap year.
>    Should we?

Agreed, who cares what MS Excel does? It should not dictate what AOO should do.


>> - 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.

First, how many users would face such a problem when both the base and exponent are null???
Again, real maths are not done in spreadsheets. So it's very likely the 0^0 cases would not break that many sheets and with an error, users will be able to spot quickly the issue and adapt to prevent that situation to be calculated.

Second, and that's my main point here: you're angry about such a minor change when you don't mind breaking the backward compatibility of the whole extensions eco-system? See: http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html
I'm lost about the priorities... and how end-users fit in your agenda.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sat, Feb 9, 2013 at 6:11 PM, Andrea Pescetti <pe...@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.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 3:16 PM, Stuart <De...@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
>

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Mon, Feb 11, 2013 at 3:26 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 11/02/2013 05:57, Andrew Douglas Pitonyak a écrit :
>
>> I usually want things to just work. If an arbitrary value is used, and it
>> is not brought to my attention, I may not be producing the answer that I
>> really want. Not returning an error gives me a false sense of security.
>
>
> That's precisely my point. As long as the software gives an answer, you
> can't suspect a problem somewhere.
>
> Do we want Calc to give an answer even if it's wrong and make users angry
> because Calc gave a wrong value? Or prevent him to spot a corner case (like
> #DIV/0! does)?
> Of course, it's much easier to say that it could break compatibility and
> continue to give a nice politically correct value (1).
>
> Rob, you talked about the 1900 leap year, it's exactly the same: should we
> continue providing a questionable value for the sake of compatibility with
> old files (even if there are very few of them with this situation) and
> compatibility with MS Office?
>

But returning 1 for 0^0 is not wrong.  It is not wrong mathematically.
 It is not wrong per the ODF 1.2 standard.

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 11/02/2013 05:57, Andrew Douglas Pitonyak a écrit :
> I usually want things to just work. If an arbitrary value is used, and it is not brought to my attention, I may not be producing the answer that I really want. Not returning an error gives me a false sense of security.

That's precisely my point. As long as the software gives an answer, you can't suspect a problem somewhere.

Do we want Calc to give an answer even if it's wrong and make users angry because Calc gave a wrong value? Or prevent him to spot a corner case (like #DIV/0! does)?
Of course, it's much easier to say that it could break compatibility and continue to give a nice politically correct value (1).

Rob, you talked about the 1900 leap year, it's exactly the same: should we continue providing a questionable value for the sake of compatibility with old files (even if there are very few of them with this situation) and compatibility with MS Office?

Hagar

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

Sadly, ODF allows any of three values to be returned, any user assuming 
any specific behavior is foolish. Load the document in any product or 
version, and it may change.

If I order my preference, it is error, 1, and then 0.

On 02/10/2013 04:18 PM, Hagar Delest wrote:
> The problem is to give the answer that is the most useful for the user. 

I agree with this statement. I am unsure what the most useful answer is. 
Off hand, I would have to say that it is dependent on what I am doing at 
the time. I cannot even tell you what I probably want it to be most of 
the time. For the crazy things that I do, I am just as likely to vary 
x^0 as 0^x (and one has limit behavior of 1 and the other 0)

I usually want things to just work. If an arbitrary value is used, and 
it is not brought to my attention, I may not be producing the answer 
that I really want. Not returning an error gives me a false sense of 
security.

The problem is summed up very nicely here:

http://community.wolframalpha.com/viewtopic.php?f=35&t=11131

The summary is as follows:

******

0^0 itself is undefined. The lack of a well-defined meaning for this 
quantity follows from the mutually contradictory facts that a^0 is 
always 1, so 0^0 should equal 1, but 0^a is always 0 (for a>0), so 0^0 
should equal 0. It could be argued that 0^0=1 is a natural definition since
lim_(n->0)n^n=lim_(n->0^+)n^n=lim_(n->0^-)n^n=1.

However, the limit does not exist for general complex values of n. 
Therefore, the choice of definition for 0^0 is usually defined to be 
indeterminate.

******



-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 4:18 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 21:53, Rob Weir a écrit :
>
>> The error in your thinking is to persist in arguing that there is only
>> one correct answer.  That is false.  I can point to mathematical
>> authorities of great reputation to argue for any of three answers. The
>> question is whether we change from the correct answer we give in AOO
>> 3.4.1 and before to a different correct answer, and in doing so break
>> compatibility.
>
>
> The problem is to give the answer that is the most useful for the user.
> Shall we tell him 1 or tell him that there is an error because he came upon
> a corner case?
> Of course I see your point. But is it the best behavior to hide a potential
> issue to the user, letting him think that everything is OK?
>
>
>
>> Let me show you how lame this argument is.  What is sqrt(4)?   2,
>> right?  Well, that is one convention.  -2 is also a valid answer.
>> Would you be OK if we changed the code to return -2?  What about an
>> error message because it is ambiguous?  Of course, not, because we
>> adopt the convention to return the positive root only.
>
>
> But there is no uncertainty here. Like angles and trigonometric functions,
> there are 2 possibilities. There are no corner case here. It is assumed that
> the user knows what he's doing.
>
> I've no problem with conventions, as long as they give the best answer to
> the user.
> What about giving 1 or 0 to 0/0? That would be very comfortable! But giving
> an error is the best way because it warns the user that there is a problem

Try to argue your point honestly.  You know very well that there is no
common convention where 0/0 == 1.

> (that would get unnoticed else and lead to definitively wrong results). We
> all have experienced this #DIV/0! error and we are happy with it because we
> can investigate and find out that there was a mistake somewhere.
> Same for the 0^0 issue. Giving an error could make the user aware that there
> is a mistake in his calculation. Giving a result can hide such mistakes.
>

This goes against the general design of spreadsheets.  They are not
programming languages for programmers.  They are intended to just
work, to give reasonable answers for user inputs.  The error handling
mechanisms are very primitive.  That is why spreadsheets do all sorts
of things to avoid giving errors.

For example:

RIGHT("foo";1000) returns "foo" not an error.

MID("foo"; 100;1000) returns an empty string, not a error.

Many programming language would give an exception here.  Spreadsheets
don't.  Spreadsheets try to be robust.  This is a design that has
worked well for over 20 years.

Now you could imagine, designing from scratch a new spreadsheet
application, without concerns about backwards compatibility.  In such
a case you might do all sorts of things differently, including
enforcing type safety, index checking, better error handling support,
etc.  But that is not the situation we're in.  We have a 12 year old
application with millions of users and many millions of documents.  We
can't pretend that all design options are on the table.

-Rob


> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 21:53, Rob Weir a écrit :
> The error in your thinking is to persist in arguing that there is only
> one correct answer.  That is false.  I can point to mathematical
> authorities of great reputation to argue for any of three answers. The
> question is whether we change from the correct answer we give in AOO
> 3.4.1 and before to a different correct answer, and in doing so break
> compatibility.

The problem is to give the answer that is the most useful for the user. Shall we tell him 1 or tell him that there is an error because he came upon a corner case?
Of course I see your point. But is it the best behavior to hide a potential issue to the user, letting him think that everything is OK?


> Let me show you how lame this argument is.  What is sqrt(4)?   2,
> right?  Well, that is one convention.  -2 is also a valid answer.
> Would you be OK if we changed the code to return -2?  What about an
> error message because it is ambiguous?  Of course, not, because we
> adopt the convention to return the positive root only.

But there is no uncertainty here. Like angles and trigonometric functions, there are 2 possibilities. There are no corner case here. It is assumed that the user knows what he's doing.

I've no problem with conventions, as long as they give the best answer to the user.
What about giving 1 or 0 to 0/0? That would be very comfortable! But giving an error is the best way because it warns the user that there is a problem (that would get unnoticed else and lead to definitively wrong results). We all have experienced this #DIV/0! error and we are happy with it because we can investigate and find out that there was a mistake somewhere.
Same for the 0^0 issue. Giving an error could make the user aware that there is a mistake in his calculation. Giving a result can hide such mistakes.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 3:42 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 21:34, Rob Weir a écrit :
>
>> This is NOT a complex math problem.  It is trivial one, with three
>> perfectly valid answers.  Debating among them is merely a time-wasting
>> form of bikeshedding.  Everyone and his little sister has an opinion
>> on 0^0.
>
>
> Then you should update the wiki page to make clear what should be the
> correct result (undefined or 1).
>
>
>
>> The real problem is this:  once we have adopted a convention for this
>> debatable expression, under what conditions do we change the
>> convention and break comptibility?  Any other formulation of the
>> question is missing the essence of this decision.
>
>
> If this is a simple problem with a simple answer, then there is no need of
> convention at all. Just put the correct result.
>

The error in your thinking is to persist in arguing that there is only
one correct answer.  That is false.  I can point to mathematical
authorities of great reputation to argue for any of three answers. The
question is whether we change from the correct answer we give in AOO
3.4.1 and before to a different correct answer, and in doing so break
compatibility.

Let me show you how lame this argument is.  What is sqrt(4)?   2,
right?  Well, that is one convention.  -2 is also a valid answer.
Would you be OK if we changed the code to return -2?  What about an
error message because it is ambiguous?  Of course, not, because we
adopt the convention to return the positive root only.

>From linguistics, what is the value of =lower("Σ") (capital Greek
sigma).  There are two forms of lower case sigma, one used only in
final word position, another used elsewhere.  So the question is
ambiguous.  There is no single correct answer. So we adopt a useful
answer by convention. Should we instead return an error in that case,
arguing that a user should be avoiding asking such questions of sigma,
and should code more complex logic to handle this edge case?  Of
course not.  We try to avoid returning error values where there is a
reasonable convention we can adopt.

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 21:34, Rob Weir a écrit :
> This is NOT a complex math problem.  It is trivial one, with three
> perfectly valid answers.  Debating among them is merely a time-wasting
> form of bikeshedding.  Everyone and his little sister has an opinion
> on 0^0.

Then you should update the wiki page to make clear what should be the correct result (undefined or 1).


> The real problem is this:  once we have adopted a convention for this
> debatable expression, under what conditions do we change the
> convention and break comptibility?  Any other formulation of the
> question is missing the essence of this decision.

If this is a simple problem with a simple answer, then there is no need of convention at all. Just put the correct result.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Rob Weir <ro...@apache.org>]

On Sun, Feb 10, 2013 at 3:26 PM, Hagar Delest <ha...@laposte.net> wrote:
> Le 10/02/2013 21:16, Stuart a écrit :
>
>> 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.
>
>
> Hardly doable I guess.
> Very few users may be aware of the trick behind the 0^0 problem.
> The software has to give the most correct answer as possible. If the user
> needs the result to be 1, then ISERROR may help.
>
> If we let the user decide how functions should behave it will be quickly a
> real mess. And users will be lost too. They want something that works, not
> something that ask them about their opinion about complex maths problems.
>

This is NOT a complex math problem.  It is trivial one, with three
perfectly valid answers.  Debating among them is merely a time-wasting
form of bikeshedding.  Everyone and his little sister has an opinion
on 0^0.

The real problem is this:  once we have adopted a convention for this
debatable expression, under what conditions do we change the
convention and break comptibility?  Any other formulation of the
question is missing the essence of this decision.

-Rob


> Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest <ha...@laposte.net>]

Le 10/02/2013 21:16, Stuart a écrit :
> 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.

Hardly doable I guess.
Very few users may be aware of the trick behind the 0^0 problem.
The software has to give the most correct answer as possible. If the user needs the result to be 1, then ISERROR may help.

If we let the user decide how functions should behave it will be quickly a real mess. And users will be lost too. They want something that works, not something that ask them about their opinion about complex maths problems.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Stuart <De...@web.de>]

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.

Stuart