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

[Andrea Pescetti]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

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

[Rob Weir]

On Wed, Feb 20, 2013 at 6:10 PM, Dennis E. Hamilton  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:robw...@apache.org]
> Sent: Wednesday, February 20, 2013 14:08
> To: dev@openoffice.apache.org; orc...@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  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]

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:robw...@apache.org] 
Sent: Wednesday, February 20, 2013 14:08
To: dev@openoffice.apache.org; orc...@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  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]

On Wed, Feb 20, 2013 at 4:37 PM, Dennis E. Hamilton  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:robw...@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]

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:robw...@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]

On Wed, Feb 20, 2013 at 12:27 PM, Dennis E. Hamilton
 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  (section 26.5) the definitions 
> are deferred to the C Standard , 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:robw...@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]

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  (section 26.5) the definitions are deferred to the C 
Standard , 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:robw...@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]

On Wed, Feb 20, 2013 at 9:54 AM, Pedro Giffuni  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]

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]

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)

[Kay Schenk]

On Mon, Feb 18, 2013 at 12:26 AM, Jürgen Schmidt 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,
> >

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

[Dennis E. Hamilton]

+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:robw...@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  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 c

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

[Rob Weir]

On Mon, Feb 18, 2013 at 3:58 AM, Andre Fischer  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 interoperabilit

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

[Andre Fischer]

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

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

[Jürgen Schmidt]

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 a

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

[janI]

On Feb 18, 2013 1:16 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
>
+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]

On Sun, Feb 17, 2013 at 7:15 PM, 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
>

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

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

[Pedro Giffuni]

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

[Rob Weir]

On Sun, Feb 17, 2013 at 6:40 PM, Pedro Giffuni  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]

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]

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:p...@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 th

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti]

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]

On Sat, Feb 16, 2013 at 5:19 PM, Hagar Delest  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]

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: :Re: Calc behavior: result of 0 ^ 0

[Dennis E. Hamilton]

I did not test with your patch.  I reported on behavior of available
releases.

 - Dennis

-Original Message-
From: Pedro Giffuni [mailto:p...@apache.org] 
Sent: Thursday, February 14, 2013 19:42
To: rabas...@gmail.com; dev@openoffice.apache.org
Subject: :Re: Calc behavior: result of 0 ^ 0

Thats alright I just needed to know it was not linux.

In the bugzilla issue Dennis had reported those were OK in some platform.

Ah well, given the monster thread this caused excuse me if I dont hurry to
fix it ;).

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak]

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

[Pedro Giffuni]

Thats alright I just needed to know it was not linux.

In the bugzilla issue Dennis had reported those were OK in some platform.

Ah well, given the monster thread this caused excuse me if I dont hurry to fix 
it ;).

Pedro.

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Feb 14, 2013, at 8:51 PM, Pedro Giffuni  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 
>> A: dev@openoffice.apache.org; Pedro Giffuni 
>> 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  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]

Rob;

Can you confirm the platform where you got those results?

Thanks,

Pedro.


- Messaggio originale -
> Da: Rob Weir 
> A: dev@openoffice.apache.org; Pedro Giffuni 
> 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  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]

On Thu, Feb 14, 2013 at 5:18 PM, Pedro Giffuni  wrote:
>
>
>
>
> - Messaggio originale -
>> Da: Rob Weir
>
>>
>> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni  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]

- Messaggio originale -
> Da: Rob Weir 

> 
> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni  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

[Kay Schenk]

On Thu, Feb 14, 2013 at 11:17 AM, Pedro Giffuni  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]

On Thu, Feb 14, 2013 at 4:47 PM, Rob Weir  wrote:
> On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni  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

[Regina Henschel]

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

[Rob Weir]

On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni  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]

- 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]

On Thu, Feb 14, 2013 at 3:42 PM, Rob Weir  wrote:
> On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni  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]

On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni  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]

- 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]

On Thu, Feb 14, 2013 at 2:58 PM, Pedro Giffuni  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]

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]

On Thu, Feb 14, 2013 at 1:58 PM, Kay Schenk  wrote:
> On Thu, Feb 14, 2013 at 5:49 AM, 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.
>
>
> 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

[Pedro Giffuni]

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

[Kay Schenk]

On Thu, Feb 14, 2013 at 5:49 AM, 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.


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]

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

[Pedro Giffuni]

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]

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

[Pedro Giffuni]

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

[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 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

[Pedro Giffuni]

- 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

[Andrew Douglas Pitonyak]

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

[Rob Weir]

On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti  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]

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

[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 ;-)

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

[Pedro Giffuni]

- 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]

- 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

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

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

Re: Interval arithmetic [was Re: Calc behavior: result of 0 ^ 0]

[Andrew Douglas Pitonyak]

On 02/13/2013 11:14 AM, Rob Weir wrote:

On Wed, Feb 13, 2013 at 10:43 AM, Pedro Giffuni  wrote:

FWIW;


- Messaggio originale -

Da: Andrew Douglas Pitonyak

  Of course, had I implemented quaternion math using Boost, no one would be

complaining. :-P

  Pedro.

  [1] http://bikeshed.org

Do it, do it, do it; PLEESSEEE. :-)

Quaternions are cool.


I think it is easy, and likely a nice exercise for someone wanting to start
AOO development. Perhaps GSoC material.


After that, how about interval arithmetic! I think that is even more fun!


I don't know about that, sorry ;).


It could be used as a form of sensitivity analysis.  A value in a
spreadsheet might be a known value, like a sales tax rate, that is
certain.  But you also might have other values that are measurements
with measurement error, or estimates with confidence levels.  If you
treat these unknowns as intervals then you can get some interesting
results:

http://en.wikipedia.org/wiki/Interval_arithmetic

Even better is to allow cells to have an associated distribution,
e.g., normal with given mean and variance, uniform within a given
interval, etc.  If you also have the ability to define covariances
between the variables then you can do a monte carlo simulation to
determine the distribution of the result cells.  Very powerful
technique.

Today, conceptually at least, a spreadsheet commonly has these
different "layers" that are associated with each cell:

1) Contents, e.g., a number, string, formula, blank.

2) A value, e.g., the evaluation of the formula, or the value of a literal.

3) A format, e.g., currency 2 decimal places

4) A style, e.g., green background, bold text

There is a lot we could do if we made it easy for extension authors to
add more "layers" to a spreadsheet.  For example, a layer for
dimensions and units (meters, inches, foot-pounds/second, etc. ) would
allow error checking for incorrectly mixing dimensions as well
automatically converting units.  So adding a cell containing seconds
to one containing meters would be flagged as an error.  But adding
meters and feet might be permitted and a conversion factor
automatically made.   You could also imagine a layer for probability
distribution, etc.

There is no need for the core of Calc to understand the custom layers
other than to respect them during editing operations, e.g., a cut and
paste operation brings along contents, format, style, as well as any
custom layer metadata.
Sadly, I expect it would be difficult to pull-off, but, if you did, then 
you could use that for all sorts of things; intervals, complex numbers, 
etc.


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

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


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 
>To: "dev@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 
>>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  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 
>>>>To: "dev@openoffice.apache.org" ; Pedro Giffuni 
>>>>
>>>>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
>&g

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

>
> Da: Kay Schenk 
...
>
>On Wed, Feb 13, 2013 at 9:30 AM, Rob Weir  wrote:
>
>> On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer 
>> 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: Calc behavior: result of 0 ^ 0

[Kay Schenk]

On Wed, Feb 13, 2013 at 9:30 AM, Rob Weir  wrote:

> On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer 
> 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 
> >>To: "dev@openoffice.apache.org" ; Pedro
> Giffuni 
> >>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 
> >>>To: dev@openoffice.apache.org; Pedro Giffuni 
> >>>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 
> >>>
> >>>> Hello;
> >>>>
> >>>> >
> >>>> > Da: Norbert Thiebaud
> >>>> ...
> >>>> >On Tu

Re: Calc behavior: result of 0 ^ 0

[Joe Schaefer]

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 
>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  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 
>>>To: "dev@openoffice.apache.org" ; Pedro Giffuni 
>>>
>>>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 
>>>>To: dev@openoffice.apache.org; Pedro Giffuni 
>>>>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¢
>>>>
>>>>Re

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer  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 
>>To: "dev@openoffice.apache.org" ; Pedro Giffuni 
>>
>>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 
>>>To: dev@openoffice.apache.org; Pedro Giffuni 
>>>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 
>>>
>>>> Hello;
>>>>
>>>> >
>>>> > Da: Norbert Thiebaud
>>>> ...
>>>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
>>>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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  (

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud]

On Wed, Feb 13, 2013 at 9:53 AM, Joe Schaefer  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]

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 
>To: "dev@openoffice.apache.org" ; Pedro Giffuni 
> 
>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 
>>To: dev@openoffice.apache.org; Pedro Giffuni  
>>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 
>>
>>> Hello;
>>>
>>> >
>>> > Da: Norbert Thiebaud
>>> ...
>>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
>>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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

Interval arithmetic [was Re: Calc behavior: result of 0 ^ 0]

[Rob Weir]

On Wed, Feb 13, 2013 at 10:43 AM, Pedro Giffuni  wrote:
> FWIW;
>
>
> - Messaggio originale -
>> Da: Andrew Douglas Pitonyak
>
>>>
>>>  Of course, had I implemented quaternion math using Boost, no one would be
>> complaining. :-P
>>>
>>>  Pedro.
>>>
>>>  [1] http://bikeshed.org
>> Do it, do it, do it; PLEESSEEE. :-)
>>
>> Quaternions are cool.
>>
>
> I think it is easy, and likely a nice exercise for someone wanting to start
> AOO development. Perhaps GSoC material.
>
>> After that, how about interval arithmetic! I think that is even more fun!
>>
>
> I don't know about that, sorry ;).
>

It could be used as a form of sensitivity analysis.  A value in a
spreadsheet might be a known value, like a sales tax rate, that is
certain.  But you also might have other values that are measurements
with measurement error, or estimates with confidence levels.  If you
treat these unknowns as intervals then you can get some interesting
results:

http://en.wikipedia.org/wiki/Interval_arithmetic

Even better is to allow cells to have an associated distribution,
e.g., normal with given mean and variance, uniform within a given
interval, etc.  If you also have the ability to define covariances
between the variables then you can do a monte carlo simulation to
determine the distribution of the result cells.  Very powerful
technique.

Today, conceptually at least, a spreadsheet commonly has these
different "layers" that are associated with each cell:

1) Contents, e.g., a number, string, formula, blank.

2) A value, e.g., the evaluation of the formula, or the value of a literal.

3) A format, e.g., currency 2 decimal places

4) A style, e.g., green background, bold text

There is a lot we could do if we made it easy for extension authors to
add more "layers" to a spreadsheet.  For example, a layer for
dimensions and units (meters, inches, foot-pounds/second, etc. ) would
allow error checking for incorrectly mixing dimensions as well
automatically converting units.  So adding a cell containing seconds
to one containing meters would be flagged as an error.  But adding
meters and feet might be permitted and a conversion factor
automatically made.   You could also imagine a layer for probability
distribution, etc.

There is no need for the core of Calc to understand the custom layers
other than to respect them during editing operations, e.g., a cut and
paste operation brings along contents, format, style, as well as any
custom layer metadata.

>From the ODF perspective, this could all be done using ODF 1.2's RDF
metadata capabilities.

-Rob

> Pedro.
>

Re: Calc behavior: result of 0 ^ 0

[Joe Schaefer]

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 
>To: dev@openoffice.apache.org; Pedro Giffuni  
>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 
>
>> Hello;
>>
>> >
>> > Da: Norbert Thiebaud
>> ...
>> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
>> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

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 
>A: dev@openoffice.apache.org; Pedro Giffuni  
>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 
>
>Hello;
>>
>>>
>>> Da: Norbert Thiebaud
>>...
>>
>>>On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
>>>> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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)

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

FWIW;


- Messaggio originale -
> Da: Andrew Douglas Pitonyak 

>> 
>>  Of course, had I implemented quaternion math using Boost, no one would be 
> complaining. :-P
>> 
>>  Pedro.
>> 
>>  [1] http://bikeshed.org
> Do it, do it, do it; PLEESSEEE. :-)
> 
> Quaternions are cool.
> 

I think it is easy, and likely a nice exercise for someone wanting to start
AOO development. Perhaps GSoC material.

> After that, how about interval arithmetic! I think that is even more fun!
>

I don't know about that, sorry ;).

Pedro.

Re: Calc behavior: result of 0 ^ 0

[RGB ES]

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 

> Hello;
>
> >
> > Da: Norbert Thiebaud
> ...
> >On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
> >> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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 

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

Hello;

>
> Da: Norbert Thiebaud
...
>On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
>> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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 

Re: Calc behavior: result of 0 ^ 0

[Guenter Marxen]

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 collabo

Re: Calc behavior: result of 0 ^ 0

[Andre Fischer]

On 13.02.2013 08:28, Norbert Thiebaud wrote:

On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:

On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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

[Norbert Thiebaud]

On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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
"

He

Re: R: Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak]

On 02/12/2013 11:21 PM, Pedro Giffuni wrote:

No, I cant, and I wont start scartching my head over it.

The issue is minuscule enough that I have been aware from the start that it 
wasnt worth this bikeshed thread [1].

Of course, had I implemented quaternion math using Boost, no one would be 
complaining. :-P

Pedro.

[1] http://bikeshed.org

Do it, do it, do it; PLEESSEEE. :-)

Quaternions are cool.

After that, how about interval arithmetic! I think that is even more fun!

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

[Andrew Douglas Pitonyak]

On 02/12/2013 05:45 PM, Rob Weir wrote:

On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest  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

[Andrew Douglas Pitonyak]

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

[Andrew Douglas Pitonyak]

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:dwhyt...@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

R: Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

No, I cant, and I wont start scartching my head over it.

The issue is minuscule enough that I have been aware from the start that it 
wasnt worth this bikeshed thread [1].

Of course, had I implemented quaternion math using Boost, no one would be 
complaining. :-P

Pedro.

[1] http://bikeshed.org

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  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]

(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]

On Tue, Feb 12, 2013 at 7:39 PM, Norbert Thiebaud  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]

On Tue, Feb 12, 2013 at 6:00 PM, Andrea Pescetti  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]

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

[Rob Weir]

On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest  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]

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

[Marcus (OOo)]

Am 02/12/2013 11:22 PM, schrieb Rob Weir:

On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo)  wrote:

Am 02/12/2013 10:39 PM, schrieb Rob Weir:


On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)
wrote:


Am 02/12/2013 08:46 PM, schrieb Rob Weir:


On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuniwrote:



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
A: dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
Giffuni'
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 p

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo)  wrote:
> Am 02/12/2013 10:39 PM, schrieb Rob Weir:
>
>> On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)
>> wrote:
>>>
>>> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>>>
>>>> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni   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
>>>>>> A: dev@openoffice.apache.org
>>>>>> Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
>>>>>> Giffuni'
>>>>>> 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
>>>>>

Re: Calc behavior: result of 0 ^ 0

[Marcus (OOo)]

Am 02/12/2013 10:39 PM, schrieb Rob Weir:

On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)  wrote:

Am 02/12/2013 08:46 PM, schrieb Rob Weir:


On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni   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
A: dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
Giffuni'
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:dwhyt...@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]

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

[Hagar Delest]

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

[Rob Weir]

On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)  wrote:
> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>
>> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni  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
>>>> A: dev@openoffice.apache.org
>>>> Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
>>>> Giffuni'
>>>> 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:dwhyt...@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

[Marcus (OOo)]

Am 02/12/2013 08:46 PM, schrieb Rob Weir:

On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni  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
A: dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'
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:dwhyt...@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]

On Tue, Feb 12, 2013 at 4:17 PM, Pedro Giffuni  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

[Dennis E. Hamilton]

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:p...@apache.org] 
Sent: Tuesday, February 12, 2013 11:12
To: dennis.hamil...@acm.org; dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@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 
>A: dev@openoffice.apache.org 
>Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'
 
>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:dwhyt...@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]

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

[Rob Weir]

On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni  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 
>>A: dev@openoffice.apache.org
>>Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' 
>>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:dwhyt...@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]

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 
>A: dev@openoffice.apache.org 
>Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'  
>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:dwhyt...@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]

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:dwhyt...@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]

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