Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
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)
On Wed, Feb 20, 2013 at 9:54 AM, Pedro Giffuni p...@apache.org wrote: I guess I shouldn't be surprised that this thread keeps reappearing in my inbox ;). - Messaggio originale - Da: Andrea Pescetti ... what the result of the power function in edge cases should be. So let me suggest a solution ... this really needs to be a per-document setting. ... 3) If we make it a runtime setting --- all legacy documents in ODF format are evaluated according to the legacy mode. So no compatibility break. Users have a choice for mode for all new documents. All Excel format documents by default are in Excel-compatibility mode. This seems the only solution where we could have consensus. It is a non-trivial enhancement but it has advantages. It is certainly not impossible but my experience with people changing colors of bikeshed is that: 1) there must be some default value, which will lead to yet another bikeshed color dispute. 2) No one will do anything about it because they lack the skills or they never wanted the change done at all. I am pretty sure the result will be (2). Are you really suggesting to ship AOO on FreeBSD with different behavior then on eg Windows? ... Please don't do that. Yes, this should be avoided if possible. Let's try to avoid inconsistencies across operating systems. In this case there is actually no inconsistency as AOO has no control over what pow() does. Technically the behaviour has always been system dependent I don't believe this is true. ANSI C, C99, ISO C++ all require that pow(x,0) return 1 for all values of x. This is also a POSIX requirement.ODF 1.2 permits other values, but to the extent we use the standard C library's pow() function we should be consistent on all platforms, to the extent their C runtime is conforming. -Rob There is a long history of patches for bugzilla issues that OOo was very slow to adopt. The fact that distributions can now use a very different Python version already induces much more inconsistencies. Oh, and python is a good example on how breaking backwards compatibility is not a valid reason for a veto. I am of the opinion that introducing python3 as the internal python would cause too much trouble now to existing users (LO has less such users), but the real reason why the change hasn't been made is not a veto: people asked for it but no one has offered the work required in the python module (and the MacOSX port). cheers, Pedro.
RE: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
I don't want to get into this. I think enough has been said. I do want to avoid anyone misunderstanding what the ANSI/ISO Standards for C and C++ say about pow(0,0) however. In general, C/C++ pow(0,0) is left implementation-defined. There may be a domain error (this is an implementation-defined result plus setting of a global condition). There may be a silent return of NaN. - Dennis DETAILS In ISO/IEC 14882-1998 (C++) the numeric_limits account for specializations in arithmetic that provide for +infinity and silent (non-exception-triggering) NaN among other cases. The value for *complex* pow(0,0) is implementation-defined in 26.2.8. For cmath (section 26.5) the definitions are deferred to the C Standard math.h, although more type specializations are provided for numtype pow(numtype1, numtype2). In ISO/IEC 14882-2003 (C++) is the same. I haven't checked -2011 and the standardization of some of the Boost library. In ISO/IEC 9899:2011 (C) the specification of cpow( ) does not say anything about cpow(0,0). The specification of pow(x,y) says that a domain error may occur if x is zero and y is zero. The same language appears in ISO C99 (including its Technical Corrigenda). In ANSI/ISO C (way back, before 1992) the rule was that A domain error occurs if the result cannot be represented when x is zero and y is less than or equal to zero. (A domain error involves return of an implementation-defined value and the global error variable is set - exceptions aren't used in Standard C libraries.) So, considerable variability is provided. Quiet NaN and +Inf are representations, of course, if available in the library and arithmetic implementation. These are accounted for in 9899:2011. Plauger's Standard C Library (in 1992) assumes IEEE floating point and handles NaN and +Inf (and his implementation appears to return 1 for pow(0,0) -- the code is pretty snarly). -Original Message- From: Rob Weir [mailto: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)
On Wed, Feb 20, 2013 at 12:27 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I don't want to get into this. I think enough has been said. I do want to avoid anyone misunderstanding what the ANSI/ISO Standards for C and C++ say about pow(0,0) however. In general, C/C++ pow(0,0) is left implementation-defined. There may be a domain error (this is an implementation-defined result plus setting of a global condition). There may be a silent return of NaN. A domain error is something that an implementation might express via call to matherr() and setting errno to EDOM is a different question than the return value. I'm reading a requirement for pow(x,0) to return 1 for all values of x. Are you seeing something else? Are you seeing anything that says a conforming C/C++ runtime may *return* something other than 1? Btw, the rationale for this choice is described on page 182 of this document: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf And I don't think cpow() is relevant to the topic. Regards, -Rob - Dennis DETAILS In ISO/IEC 14882-1998 (C++) the numeric_limits account for specializations in arithmetic that provide for +infinity and silent (non-exception-triggering) NaN among other cases. The value for *complex* pow(0,0) is implementation-defined in 26.2.8. For cmath (section 26.5) the definitions are deferred to the C Standard math.h, although more type specializations are provided for numtype pow(numtype1, numtype2). In ISO/IEC 14882-2003 (C++) is the same. I haven't checked -2011 and the standardization of some of the Boost library. In ISO/IEC 9899:2011 (C) the specification of cpow( ) does not say anything about cpow(0,0). The specification of pow(x,y) says that a domain error may occur if x is zero and y is zero. The same language appears in ISO C99 (including its Technical Corrigenda). In ANSI/ISO C (way back, before 1992) the rule was that A domain error occurs if the result cannot be represented when x is zero and y is less than or equal to zero. (A domain error involves return of an implementation-defined value and the global error variable is set - exceptions aren't used in Standard C libraries.) So, considerable variability is provided. Quiet NaN and +Inf are representations, of course, if available in the library and arithmetic implementation. These are accounted for in 9899:2011. Plauger's Standard C Library (in 1992) assumes IEEE floating point and handles NaN and +Inf (and his implementation appears to return 1 for pow(0,0) -- the code is pretty snarly). -Original Message- From: Rob Weir [mailto: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)
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)
On Wed, Feb 20, 2013 at 4:37 PM, Dennis E. Hamilton orc...@apache.org wrote: I earlier quoted the applicable (and only) texts from the Standards themselves, particularly C++ and also the latest C Standard (2011 and C99 with all Technical Corrigenda through 2007). No matter what is said about pow(0,0) in the C99 Rationale v5.10 Appendix F of April 2003, there are no such requirements in the Standards, including those versions that have been adopted since 2003. - Dennis PS: I mentioned cpow(0,0) because of the mathematical relationship and I was observing that is consistent with the subset that pow(x,y) supports. DETAILS The definition of domain error is that an implementation-defined value is returned *and* errno is set to EDOM. There is also the option of triggering a floating-point exception. I assume that capable of representation *includes* silent NaN and +infinity but for all I know those return with non-exception domain errors too. Plauger certainly prepared to encounter those in his implementation (though he also chose pow(0,0) = 1.0). The C 99 Rationale is not an ISO/IEC International Standard, regardless of the INCITS J11 and SC22 WG14 participation. It is not necessary to even know about it. In particular, This Rationale discusses some language or library features which were not adopted into the Standard. These are usually features which are popular in some C implementations, so that a user of those implementations might question why they do not appear in the Standard. [p.5 preceding section 0.1] The Rationale doesn't address that question users might have. **[T]his rationale is not part of the Standard** [bottom of page 5, their emphasis] Then there is Appendix F. I have no idea what it means to have normative in the title. This appears to be an IEC 60559 floating-point profile from NCEC, with certain exceptions to 60559, although not even that is entirely clear. pow(+inf,0) = pow(0,0) = 1 are stated as required under Appendix F (bottom of page 180) Adding pow(NaN,0) = 1 (page 182) by taking power(x,0)=1 as settled for all x is particularly marvelous. In other words, C99, in a normative Annex F, section 9.4.4, for implementations that conform to IEEE 754 floating point, says: pow(x, ±0) returns 1 for any x, even a NaN. Do you see something different? I'd like to make sure we're seeing the same thing here. -Rob The developers of C 2011 also didn't seem to be under any compulsion with regard to the C99 Rationale. -Original Message- From: Rob Weir [mailto: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)
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 orc...@apache.org wrote: I earlier quoted the applicable (and only) texts from the Standards themselves, particularly C++ and also the latest C Standard (2011 and C99 with all Technical Corrigenda through 2007). No matter what is said about pow(0,0) in the C99 Rationale v5.10 Appendix F of April 2003, there are no such requirements in the Standards, including those versions that have been adopted since 2003. - Dennis [ ... ] In other words, C99, in a normative Annex F, section 9.4.4, for implementations that conform to IEEE 754 floating point, says: pow(x, ±0) returns 1 for any x, even a NaN. Do you see something different? I'd like to make sure we're seeing the same thing here. -Rob [ ... ]
Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
On Wed, Feb 20, 2013 at 6:10 PM, Dennis E. Hamilton orc...@apache.org wrote: Ah, very good. Yes I see Normative Appendix F in ISO/IEC 9899:1999 (C99), along with An implementation that defines _ _STDC_IEC_559_ _ shall conform to the specifications in this annex. Where a binding between the C language and IEC 60559 is indicated, the IEC 60559-specified behavior is adopted by reference, unless stated otherwise. [section F.1] which is, of course, why it is not bolted into the main text of the standard. This carries through to ISO/IEC 9899:2011. Thanks for connecting that particular dot, I don't know the background story on this, but it seems almost like a profile. There is the core conformance clauses, in which some things are implementation-defined, and then this additional annex which profiles the requirements of the specification for use with IEEE-conforming floating point processors. So it tightens the requirements. Of course, one could claim conformance with or without the Annex F requirements. For traditional desktop use of AOO, I bet the Annex describes the relevant set of requirements. But down the road there are two areas that might make this less certain: 1) mobile devices and 2) GPU's. I'm not sure that IEEE 754 is guaranteed in those cases.But if we ever support those kinds of processors then we'll have bigger headaches to worry about ;-) Regards, -Rob - Dennis PS: There is no counterpart of Appendix F in ISO/IEC 14882:1998 (C++) nor ISO/IEC 14882:2003 and ISO/IEC 14882:2011. I assume this is because C++ has the numeric_limits class to account for the variations in implementations without any mention of IEC 60559 (or the IEEE counterpart on which it derives). Also, these rely on a variable is_iec559 and specify a number of numeric_limits conditionally on iec559 != false. The declaration of conformance to IEC [60]559 (IEEE 754) does not make any of the exceptions that are in ISO C Appendix F. -Original Message- From: Rob Weir [mailto: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 orc...@apache.org wrote: I earlier quoted the applicable (and only) texts from the Standards themselves, particularly C++ and also the latest C Standard (2011 and C99 with all Technical Corrigenda through 2007). No matter what is said about pow(0,0) in the C99 Rationale v5.10 Appendix F of April 2003, there are no such requirements in the Standards, including those versions that have been adopted since 2003. - Dennis [ ... ] In other words, C99, in a normative Annex F, section 9.4.4, for implementations that conform to IEEE 754 floating point, says: pow(x, ±0) returns 1 for any x, even a NaN. Do you see something different? I'd like to make sure we're seeing the same thing here. -Rob [ ... ]
Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
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)
On Feb 18, 2013 1:16 AM, Pedro Giffuni p...@apache.org wrote: Hello; Well, as you might imagine I am really tired of the flame storm that went around the 0 ^ 0 issue. My intention here is not at all to re-start that discussion. I really have much more fun things to do. I am actualy a fan of Clint Eastwood so let me remember one of my favorite movies ever. THE GOOD It didn't really take me long but I found a technical solution for the dilemma. - The numerical issues were caused by a copy-paste error where the C++ wrapper used int for the exponent instead of a double. Once found it was trivial to fix. - Considering the vetos I still think they are invalid but I think they both reflect a community concern so I have addressed it. The new patch [1] now defines in SAL's math.h the following: #define SAL_STRICTER_MATH +1 thanks for doing this. It shows flexibility and respect for the community. Now I hope, that some of those who have a profund knowledge of backward compatility also see a need to move a little bit. It would be very respectfull to have a tool to which the information was shared. I hope someone with knowledge makes a mwiki page with docs. procedures to test compatibility, that way we can discuss facts and not just words. rgds jan i This currently only affects the power function and acts as a sort of excel compatibility flag. This is very simple at this time but it fulfills it's task: you can easily change the behaviour during compile time. It is actually an advance because having this in SAL gives us control: our current behavior is platform dependent. THE UGLY The discussion so far has been centered around the default. I consider myself agnostic in this case: I think that it is better to use the stricter criteria and be compatible with MS Excel. A lot of people worry about compatibility issues. With my FreeBSD hat on, I think in the unsupported platforms (FreeBSD, OS2, Solaris) the compatibility issue isn't really a concern (the ASF has never provided officially binaries) but the Excel behaviour is useful for interoperability. I think the best option would be if existing users take a decision before release what behaviour the want and if the case is to revert we can add something like #if defined(WINOS) || defined(MACOSX) || defined(LINUX) #defined SAL_STRICTER_MATH #endif You get the idea. Doing this is rather ugly but I can live with it as at least windows and MacOSX have the option to use Excel if they want to be serious about math. I guess we could add it as a configure option but we already have too many of them and even then there has to be a default. This is something I think the comunity has to decide on by voting before the release. I won't take the decision but since I take care for FreeBSD, I think we will opt for the Excel compatibility (I do have to consult with Maho though). THE BAD (Please stop reading here if you are sensible to non-technical issues) First I should thank Greg Stein for clarifying the correct sense and reach of the veto. I also want to thank people that have expressed their support in private or public. It is clear to me that we are still too young as a community in AOO and that people still have a long way to learn in matters of behaviour. I am not as much disappointed by the discussion (which I think doesn't correspond to the impact of the patch) but by the fact that I was not given the chance to work on it and that I have been insulted in the process. I strongly complained when Dave's commit was reverted and I find it absolutely unacceptable in the way it was done with me. First of all the harassment: I am a volunteer, I am not here to receive something in the lines of Revert now or else ..., and second the lack of respect for my work. It *is* rude, really ... I *don't* care much what happens with the patch, if it should be disabled or not, but I DO want respect. I think I deserve reparation for the commit reversal: this shouldn't have happened. I request the code be restated as it should have never been reverted in the first place. This is all symbolical as there is a new version. Once the new version is in, I will let anyone else decide if you guys want to ifdef it or add a configure option or whatever: I don't really want to be involved in this anymore. I also want an assurance that this will never *ever* happen again (I am talking about the revert, I guess bikesheds are unavoidable). If people really don't like my patches (yes, according to the Berne convention I do own them) I will take them with me but I prefer if there is a civilized discussion and not this circus we have been experiencing these last days. Pedro. [1] http://people.apache.org/~pfg/patches/patch-power00
Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
On 2/18/13 1:15 AM, Pedro Giffuni wrote: Hello; Well, as you might imagine I am really tired of the flame storm that went around the 0 ^ 0 issue. My intention here is not at all to re-start that discussion. I really have much more fun things to do. I am actualy a fan of Clint Eastwood so let me remember one of my favorite movies ever. THE GOOD It didn't really take me long but I found a technical solution for the dilemma. - The numerical issues were caused by a copy-paste error where the C++ wrapper used int for the exponent instead of a double. Once found it was trivial to fix. - Considering the vetos I still think they are invalid but I think they both reflect a community concern so I have addressed it. The new patch [1] now defines in SAL's math.h the following: #define SAL_STRICTER_MATH This currently only affects the power function and acts as a sort of excel compatibility flag. This is very simple at this time but it fulfills it's task: you can easily change the behaviour during compile time. I don't think that this new define is a clean and good approach to move forward. I would prefer to introduce a further power function that behaves like Excel. The import filter should be changed to use the new one in the future. The export will revert this. When I remember it correctly there is already some mode for this. It is actually an advance because having this in SAL gives us control: our current behavior is platform dependent. THE UGLY The discussion so far has been centered around the default. I consider myself agnostic in this case: I think that it is better to use the stricter criteria and be compatible with MS Excel. A lot of people worry about compatibility issues. sure and I believe there is a better way for this specific case by introducing a further power function as described above. With my FreeBSD hat on, I think in the unsupported platforms (FreeBSD, OS2, Solaris) the compatibility issue isn't really a concern (the ASF has never provided officially binaries) but the Excel behaviour is useful for interoperability. please don't move on this level. I am sure sure we don't really want a different behaviour on different platforms. Our users would be completely confused and nobody would understand what's happened. I think the best option would be if existing users take a decision before release what behaviour the want and if the case is to revert we can add something like #if defined(WINOS) || defined(MACOSX) || defined(LINUX) #defined SAL_STRICTER_MATH #endif You get the idea. Doing this is rather ugly but I can live with it as at least windows and MacOSX have the option to use Excel if they want to be serious about math. yes I get your idea and don't like it because I think it gives the completely wrong impression. I believe that majority now want the old behaviour and if we want support for the excel behaviour we have to discuss and to find a new approach. I guess we could add it as a configure option but we already have too many of them and even then there has to be a default. This is something I think the comunity has to decide on by voting before the release. I won't take the decision but since I take care for FreeBSD, I think we will opt for the Excel compatibility (I do have to consult with Maho though). again if you prefer to go your own way here for one platform I believe it is the completely wrong way and you potentially damage much more with such a direction. THE BAD (Please stop reading here if you are sensible to non-technical issues) First I should thank Greg Stein for clarifying the correct sense and reach of the veto. I also want to thank people that have expressed their support in private or public. It is clear to me that we are still too young as a community in AOO and that people still have a long way to learn in matters of behaviour. I am not as much disappointed by the discussion (which I think doesn't correspond to the impact of the patch) but by the fact that I was not given the chance to work on it and that I have been insulted in the process. I strongly complained when Dave's commit was reverted and I find it absolutely unacceptable in the way it was done with me. First of all the harassment: I am a volunteer, I am not here to receive something in the lines of Revert now or else ..., and second the lack of respect for my work. It *is* rude, really ... I *don't* care much what happens with the patch, if it should be disabled or not, but I DO want respect. I think I deserve reparation for the commit reversal: this shouldn't have happened. +1, it shouldn't have happened I request the code be restated as it should have never been reverted in the first place. This is all symbolical as there is a new version. Once the new version is in, I will let anyone else decide if you guys want to ifdef it or add a configure option or whatever: I don't
Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
On 18.02.2013 01:15, Pedro Giffuni wrote: Hello; Well, as you might imagine I am really tired of the flame storm that went around the 0 ^ 0 issue. My intention here is not at all to re-start that discussion. I really have much more fun things to do. I am actualy a fan of Clint Eastwood so let me remember one of my favorite movies ever. THE GOOD It didn't really take me long but I found a technical solution for the dilemma. - The numerical issues were caused by a copy-paste error where the C++ wrapper used int for the exponent instead of a double. Once found it was trivial to fix. - Considering the vetos I still think they are invalid but I think they both reflect a community concern so I have addressed it. The new patch [1] now defines in SAL's math.h the following: #define SAL_STRICTER_MATH This currently only affects the power function and acts as a sort of excel compatibility flag. This is very simple at this time but it fulfills it's task: you can easily change the behaviour during compile time. I am sorry but I don't think this is a good idea because: - The SAL_STRICTER_MATH flag needs documentation as to what it shall accomplish. - At the moment only the rtl_math_powr() function uses this flag so it looks more like a quick fix then a general concept. - The value of the flag can not be set from the outside. You have to change the source file in order to change it. Such a change can not be made by a user and a developer has to know that a) the flag exists, b) has to locate the file where to change it, c) read the code to understand the consequences of doing so. I would suggest at least to make the flag overridable by the makefile via some -DSAL_STRICTER_MATH=ON/OFF definition. Better make this a configuration switch. Yes, there are too many of these, but we probably have even more unmaintained compile time switches. Even better, turn this into a switch that can be altered via Tools-Options at runtime by the user. The user is ultimately the only person who knows what the result of the power function in edge cases should be. It is actually an advance because having this in SAL gives us control: our current behavior is platform dependent. THE UGLY The discussion so far has been centered around the default. I consider myself agnostic in this case: I think that it is better to use the stricter criteria and be compatible with MS Excel. A lot of people worry about compatibility issues. With my FreeBSD hat on, I think in the unsupported platforms (FreeBSD, OS2, Solaris) the compatibility issue isn't really a concern (the ASF has never provided officially binaries) but the Excel behaviour is useful for interoperability. I think the best option would be if existing users take a decision before release what behaviour the want and if the case is to revert we can add something like #if defined(WINOS) || defined(MACOSX) || defined(LINUX) #defined SAL_STRICTER_MATH #endif I am not sure that the logic is right here. First you say that for FreeBSD, OS2 and Solaris compatibility is not an issue and imply that using stricter math on these platforms where OK. But then you define SAL_STRICTER_MATH for Windows, MacOS and Linux. Which one is right? Besides, I hope that this code snipped will not go into a source file like rtl/math.hxx. The SAL_STRICTER_MATH flag is technically not tied to any platform. But a test like the one above would suggest that it does only run on Windows, Mac, and Linux. But the most important point is that with logic like this the choice of using stricter math still has to be made when AOO is built, ie not by users but by developers and ultimately by the release engineer. You get the idea. Doing this is rather ugly but I can live with it I can not. as at least windows and MacOSX have the option to use Excel if they want to be serious about math. I guess we could add it as a configure option but we already have too many of them and even then there has to be a default. This is something I think the comunity has to decide on by voting before the release. I won't take the decision but since I take care for FreeBSD, I think we will opt for the Excel compatibility (I do have to consult with Maho though). Are you really suggesting to ship AOO on FreeBSD with different behavior then on eg Windows? What good can come from that? Documents would not be compatible inside the same application when moved from one platform to another. Please don't do that. -Andre THE BAD (Please stop reading here if you are sensible to non-technical issues) First I should thank Greg Stein for clarifying the correct sense and reach of the veto. I also want to thank people that have expressed their support in private or public. It is clear to me that we are still too young as a community in AOO and that people still have a long way to learn in matters of behaviour. I am not as much disappointed by the discussion (which I think doesn't
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 awf@gmail.com wrote: On 18.02.2013 01:15, Pedro Giffuni wrote: Hello; Well, as you might imagine I am really tired of the flame storm that went around the 0 ^ 0 issue. My intention here is not at all to re-start that discussion. I really have much more fun things to do. I am actualy a fan of Clint Eastwood so let me remember one of my favorite movies ever. THE GOOD It didn't really take me long but I found a technical solution for the dilemma. - The numerical issues were caused by a copy-paste error where the C++ wrapper used int for the exponent instead of a double. Once found it was trivial to fix. - Considering the vetos I still think they are invalid but I think they both reflect a community concern so I have addressed it. The new patch [1] now defines in SAL's math.h the following: #define SAL_STRICTER_MATH This currently only affects the power function and acts as a sort of excel compatibility flag. This is very simple at this time but it fulfills it's task: you can easily change the behaviour during compile time. I am sorry but I don't think this is a good idea because: - The SAL_STRICTER_MATH flag needs documentation as to what it shall accomplish. - At the moment only the rtl_math_powr() function uses this flag so it looks more like a quick fix then a general concept. - The value of the flag can not be set from the outside. You have to change the source file in order to change it. Such a change can not be made by a user and a developer has to know that a) the flag exists, b) has to locate the file where to change it, c) read the code to understand the consequences of doing so. I would suggest at least to make the flag overridable by the makefile via some -DSAL_STRICTER_MATH=ON/OFF definition. Better make this a configuration switch. Yes, there are too many of these, but we probably have even more unmaintained compile time switches. Even better, turn this into a switch that can be altered via Tools-Options at runtime by the user. The user is ultimately the only person who knows what the result of the power function in edge cases should be. I think this is a key observation. Working in an Excel-compatible mode versus an OpenOffice-backwards-compatible mode doesn't make sense as a build-time mode. That is not how the product is used. We don't have users who only access Excel documents and never access legacy OpenOffice, LibreOffice, Symphony or Calligra documents. And we don't have users who never access Excel documents. A user can access an Excel document and then 5 minutes later need to open an older OpenOffice document, and then after lunch need to edit an old Excel document. We're not improving things if we treat these preferences as hard-coded compile-time options. Also, the value of 0^0 is just one of 61 different implementation-defined values in OpenFormula, and not the most interesting one of them either. There are others that impact, to a greater degree, interop with MS Office. But I think we'd all agree that defining compile-time options for all 61 would be crazy. So let's not start down that road. So let me suggest a solution that I hope would gain a greater degree of consensus, based on the observation (which I owe to a comment Dennis made in Bugzilla) that this really needs to be a per-document setting. A full solution would look like this: 1) There are a bundle of formula-evaluation related behaviors that we treat together, as belonging to either Excel-compatibility mode or legacy mode. The value of 0^0 would be one of these behaviors. 2) There would be a run-time mode that could be configured to evaluate a spreadsheet in one mode or the other. 3) When a new spreadsheet is created and saved as ODF we store the mode used to evaluate the document as document metadata. So when the document is read we know exactly the assumptions made to evaluate it. 4) Earlier versions of AOO/OOo and LibreOffice and Symphony will not understand this metadata, but this will improve over time as more people upgrade to AOO 4.0. We can also coordinate with LibreOffice and Calligra and maybe they would be interested in adopting a similar setting. 5) When a new spreadsheet is created it uses a user-defined mode of evaluation. By default in AOO 4.0 the mode would be legacy mode. But this would be a user-settable in a dialog. In future versions of AOO, we can reconsider changing the default. It will be easier to transition this once the install base has moved over to versions of AOO that support excel-compatibility mode. 6) When loading a Excel format document (XLS or XLSX) we automatically switch into excel-compatibility-mode, since that format is typically used to interop with Excel or with Excel-compatible applications. So more work, yes. But look at the different in interoperability. 1) Current situation in the code -- We're always in legacy-mode, even when
RE: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
+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 awf@gmail.com wrote: On 18.02.2013 01:15, Pedro Giffuni wrote: Hello; Well, as you might imagine I am really tired of the flame storm that went around the 0 ^ 0 issue. My intention here is not at all to re-start that discussion. I really have much more fun things to do. I am actualy a fan of Clint Eastwood so let me remember one of my favorite movies ever. THE GOOD It didn't really take me long but I found a technical solution for the dilemma. - The numerical issues were caused by a copy-paste error where the C++ wrapper used int for the exponent instead of a double. Once found it was trivial to fix. - Considering the vetos I still think they are invalid but I think they both reflect a community concern so I have addressed it. The new patch [1] now defines in SAL's math.h the following: #define SAL_STRICTER_MATH This currently only affects the power function and acts as a sort of excel compatibility flag. This is very simple at this time but it fulfills it's task: you can easily change the behaviour during compile time. I am sorry but I don't think this is a good idea because: - The SAL_STRICTER_MATH flag needs documentation as to what it shall accomplish. - At the moment only the rtl_math_powr() function uses this flag so it looks more like a quick fix then a general concept. - The value of the flag can not be set from the outside. You have to change the source file in order to change it. Such a change can not be made by a user and a developer has to know that a) the flag exists, b) has to locate the file where to change it, c) read the code to understand the consequences of doing so. I would suggest at least to make the flag overridable by the makefile via some -DSAL_STRICTER_MATH=ON/OFF definition. Better make this a configuration switch. Yes, there are too many of these, but we probably have even more unmaintained compile time switches. Even better, turn this into a switch that can be altered via Tools-Options at runtime by the user. The user is ultimately the only person who knows what the result of the power function in edge cases should be. I think this is a key observation. Working in an Excel-compatible mode versus an OpenOffice-backwards-compatible mode doesn't make sense as a build-time mode. That is not how the product is used. We don't have users who only access Excel documents and never access legacy OpenOffice, LibreOffice, Symphony or Calligra documents. And we don't have users who never access Excel documents. A user can access an Excel document and then 5 minutes later need to open an older OpenOffice document, and then after lunch need to edit an old Excel document. We're not improving things if we treat these preferences as hard-coded compile-time options. Also, the value of 0^0 is just one of 61 different implementation-defined values in OpenFormula, and not the most interesting one of them either. There are others that impact, to a greater degree, interop with MS Office. But I think we'd all agree that defining compile-time options for all 61 would be crazy. So let's not start down that road. So let me suggest a solution that I hope would gain a greater degree of consensus, based on the observation (which I owe to a comment Dennis made in Bugzilla) that this really needs to be a per-document setting. A full solution would look like this: 1) There are a bundle of formula-evaluation related behaviors that we treat together, as belonging to either Excel-compatibility mode
Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
On Mon, Feb 18, 2013 at 12:26 AM, Jürgen Schmidt jogischm...@gmail.comwrote: On 2/18/13 1:15 AM, Pedro Giffuni wrote: Hello; Well, as you might imagine I am really tired of the flame storm that went around the 0 ^ 0 issue. My intention here is not at all to re-start that discussion. I really have much more fun things to do. I am actualy a fan of Clint Eastwood so let me remember one of my favorite movies ever. THE GOOD It didn't really take me long but I found a technical solution for the dilemma. - The numerical issues were caused by a copy-paste error where the C++ wrapper used int for the exponent instead of a double. Once found it was trivial to fix. - Considering the vetos I still think they are invalid but I think they both reflect a community concern so I have addressed it. The new patch [1] now defines in SAL's math.h the following: #define SAL_STRICTER_MATH This currently only affects the power function and acts as a sort of excel compatibility flag. This is very simple at this time but it fulfills it's task: you can easily change the behaviour during compile time. I don't think that this new define is a clean and good approach to move forward. I would prefer to introduce a further power function that behaves like Excel. +1 on this suggestion... It seems to me that a user controlled option might work best in this case. The import filter should be changed to use the new one in the future. The export will revert this. When I remember it correctly there is already some mode for this. It is actually an advance because having this in SAL gives us control: our current behavior is platform dependent. THE UGLY The discussion so far has been centered around the default. I consider myself agnostic in this case: I think that it is better to use the stricter criteria and be compatible with MS Excel. A lot of people worry about compatibility issues. sure and I believe there is a better way for this specific case by introducing a further power function as described above. With my FreeBSD hat on, I think in the unsupported platforms (FreeBSD, OS2, Solaris) the compatibility issue isn't really a concern (the ASF has never provided officially binaries) but the Excel behaviour is useful for interoperability. please don't move on this level. I am sure sure we don't really want a different behaviour on different platforms. Our users would be completely confused and nobody would understand what's happened. I think the best option would be if existing users take a decision before release what behaviour the want and if the case is to revert we can add something like #if defined(WINOS) || defined(MACOSX) || defined(LINUX) #defined SAL_STRICTER_MATH #endif You get the idea. Doing this is rather ugly but I can live with it as at least windows and MacOSX have the option to use Excel if they want to be serious about math. yes I get your idea and don't like it because I think it gives the completely wrong impression. I believe that majority now want the old behaviour and if we want support for the excel behaviour we have to discuss and to find a new approach. I guess we could add it as a configure option but we already have too many of them and even then there has to be a default. This is something I think the comunity has to decide on by voting before the release. I won't take the decision but since I take care for FreeBSD, I think we will opt for the Excel compatibility (I do have to consult with Maho though). again if you prefer to go your own way here for one platform I believe it is the completely wrong way and you potentially damage much more with such a direction. THE BAD (Please stop reading here if you are sensible to non-technical issues) First I should thank Greg Stein for clarifying the correct sense and reach of the veto. I also want to thank people that have expressed their support in private or public. It is clear to me that we are still too young as a community in AOO and that people still have a long way to learn in matters of behaviour. I am not as much disappointed by the discussion (which I think doesn't correspond to the impact of the patch) but by the fact that I was not given the chance to work on it and that I have been insulted in the process. I strongly complained when Dave's commit was reverted and I find it absolutely unacceptable in the way it was done with me. First of all the harassment: I am a volunteer, I am not here to receive something in the lines of Revert now or else ..., and second the lack of respect for my work. It *is* rude, really ... I *don't* care much what happens with the patch, if it should be disabled or not, but I DO want respect. I think I deserve reparation for the commit reversal: this shouldn't have happened. +1, it shouldn't have happened I request
Re: Calc behavior: result of 0 ^ 0
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
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 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
Re: Calc behavior: result of 0 ^ 0
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
On Sat, Feb 16, 2013 at 5:19 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 14/02/2013 23:34, Rob Weir a écrit : In any case, I don't think anyone should care who reverts. Once a veto has been stated, the code needs to be reverted. Who does it is a matter of convenience. Please don't be offended if someone else does it. The vetoes were very poorly documented. Nobody has commented about Pedro's remark about the context of Bourbaki's work (this point being the most technical point of this whole topic). I've not taken the care to look at it (my maths lessons are rather old now). The question is: was the work presented applicable to real world or was it a custom maths space with a custom set of laws that would not fit the reality of a spreadsheet for real work? Even if the patch case is now closed, I'm rather disappointed by the way it has been handled. I can't see how this kind of behavior could attract new developers. Side question: we have see that the backward compatibility was the most important point here. What about a future improvement that would break the backward compatibility? Does it mean that it would be vetoed as well? I don't think anyone can respond to a vague hypothetical. But I would recommend that anyone who wants to make a future improvement that would break the backward compatibility propose it on the list first and have the discussion first. We might find out that it is not an either/or situation, but that it is possible to both preserve compatibility and improve. -Rob -Rob Hagar
Re: Calc behavior: result of 0 ^ 0
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
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
- Messaggio originale - Da: Rob Weir .-- We had a committer veto. Why are having a vote? A -1 from a commmitter is not something we vote on. The patch needs to be reverted, now. We actually have two *invalid* vetos I recall you aduced the change is not backwards compatible. Backwards compatibility is not a requirement for 4.0 release, especially in this case since we are trying to comply with a stricter standard. (Plus you added a section for backwards incompatible changes in the Release notes, so I guess you know it is OK). http://www.apache.org/foundation/voting.html To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc. ). A veto without a justification is invalid and has no weight. So you have two weeks to look for a valid technical justification: Pedro.
Re: Calc behavior: result of 0 ^ 0
Rob Weir 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
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
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
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
On Thu, Feb 14, 2013 at 1:58 PM, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Feb 14, 2013 at 5:49 AM, Andrea Pescetti pesce...@apache.orgwrote: 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#Vetohttp://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
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
On Thu, Feb 14, 2013 at 2:58 PM, Pedro Giffuni p...@apache.org wrote: Man.. do I have to repeat everything again? - Messaggio originale - Da: Rob Weir And so it is clear, my technical objection is: Backwards compatibility of spreadsheet documents, and calculations specifically, is critical. If AOO 4.0 returns results that are even a penny different than earlier versions than this would be a severe defect. If we found such a defect even the day before a major release we would probably treat it as a stop ship blocking issue. Any change that breaks backwards compatibility is a technical issue. Breaking backwards compatibility is acceptable for 4.0 Release given that we are attempting to comply with a stricter standard. If it were prohibited to do such changes then other Apache Projects would be in big trouble: look at Apache Lucene: I am not talking about backwards compatibility in general. I am talking specifically about spreadsheet formulas. We have never had a discussion, and certainly not consensus, about breaking spreadsheet formula backwards compatibility for AOO 4.0. If I am in error in this, please point me to the thread. http://lucene.apache.org/core/4_1_0/changes/Changes.html We are talking about spreadsheet formula evaluation in AOO 4,0. I'm not talking about Lucerne. The same number of compatibility-related changes than optimizations! Fact: Pedro's patch changes the results of spreadsheet calculations in OpenOffice, introducing an error where there was not one before. OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. I have not seen anything that took a legitimate formula and changed it to an error. I'm not ab absolutist. I'm willing to consider changes at the 8th decimal points. But not gross level breaks in compatibility. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. For purposes of a veto I only need to show that I have a technical objection. -Rob Oh, and Microsoft Excel, which holds a bigger market share than all the above mentioned alternatives is evidently buried within such mountain. :). Is this really the best you got? Why not take my offer and give it a two weeks thought? You may come up with something more elaborate. Pedro.
Re: Calc behavior: result of 0 ^ 0
- 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
On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir ... OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. I have not seen anything that took a legitimate formula and changed it to an error. I'm not ab absolutist. I'm willing to consider changes at the 8th decimal points. But not gross level breaks in compatibility. Please note that we don't return an error: this is not something that will cause core dumps or affect stability: we return Not a Number (NaN), which is more in line with the mathematical behavior of the real function and signals the end user that he likely made has to revisit his formulation (all very good IMHO). The distinction is important. I surely didn't introduce a bug. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. For purposes of a veto I only need to show that I have a technical objection. And I don't see a valid technical objection, just different criteria. Now, it is probably not fair for me to judge if your technical objection is valid or not. It surely doesn't fall within the common examples ( does not open a security exposure, negatively affects performance, etc) You have two vetos. Are you going to revert or shall I do it for you? You are welcome to continue the discussion all you want, but that should be done with the change reverted first. -Rob There should probably be an objective judge for these things (the PMC?) but it is not defined within the Apache procedures. Pedro.
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 3:42 PM, Rob Weir robw...@apache.org wrote: On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir ... OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. I have not seen anything that took a legitimate formula and changed it to an error. I'm not ab absolutist. I'm willing to consider changes at the 8th decimal points. But not gross level breaks in compatibility. Please note that we don't return an error: this is not something that will cause core dumps or affect stability: we return Not a Number (NaN), which is more in line with the mathematical behavior of the real function and signals the end user that he likely made has to revisit his formulation (all very good IMHO). The distinction is important. I surely didn't introduce a bug. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. For purposes of a veto I only need to show that I have a technical objection. And I don't see a valid technical objection, just different criteria. Now, it is probably not fair for me to judge if your technical objection is valid or not. It surely doesn't fall within the common examples ( does not open a security exposure, negatively affects performance, etc) You have two vetos. Are you going to revert or shall I do it for you? You are welcome to continue the discussion all you want, but that should be done with the change reverted first. And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. -Rob -Rob There should probably be an objective judge for these things (the PMC?) but it is not defined within the Apache procedures. Pedro.
Re: Calc behavior: result of 0 ^ 0
- 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
On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Calc behavior: result of 0 ^ 0
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
On Thu, Feb 14, 2013 at 4:47 PM, Rob Weir robw...@apache.org wrote: On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. And I should mention that this would come up quite frequently, due to the way Calc treats empty cells. So if a user had a spreadsheet for users to fill out and did: =a1^a2 and used that return in a calculation, and initially had A1 and A2 blank for the user to fill in, then before there was no error before the user entered data, but now there is. So it is essentially changing the UI of template spreadsheets. -Rob 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Calc behavior: result of 0 ^ 0
- Messaggio originale - Da: Rob Weir On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: Now that I recall, I did indeed test that and had noticed some strange errors but I thought it may be related with my systems' libc (I am also an OS developer in my spare time). 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. The last 4 values would've been sufficiently technical to cause the revert but I should be given the chance to revert it my self. in particular since the change in main/sc/source/core/inc/interpre.hxx were correct cleanups. Pedro.
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 5:18 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: Now that I recall, I did indeed test that and had noticed some strange errors but I thought it may be related with my systems' libc (I am also an OS developer in my spare time). 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. The last 4 values would've been sufficiently technical to cause the revert but I should be given the chance to revert it my self. in particular since the change in Sorry, but I believed you when you stated emphatically that you would not revert this patch: https://issues.apache.org/ooo/show_bug.cgi?id=114430#c28 In any case, I don't think anyone should care who reverts. Once a veto has been stated, the code needs to be reverted. Who does it is a matter of convenience. Please don't be offended if someone else does it. -Rob main/sc/source/core/inc/interpre.hxx were correct cleanups. Pedro.
Re: Calc behavior: result of 0 ^ 0
Rob; Can you confirm the platform where you got those results? Thanks, Pedro. - Messaggio originale - Da: Rob Weir robw...@apache.org A: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Cc: Inviato: Giovedì 14 Febbraio 2013 16:47 Oggetto: Re: Calc behavior: result of 0 ^ 0 On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Calc behavior: result of 0 ^ 0
On Feb 14, 2013, at 8:51 PM, Pedro Giffuni p...@apache.org wrote: Rob; Can you confirm the platform where you got those results? I believe this was WinXP SP3 (32-bit), but I can confirm in the morning. -Rob Thanks, Pedro. - Messaggio originale - Da: Rob Weir robw...@apache.org A: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Cc: Inviato: Giovedì 14 Febbraio 2013 16:47 Oggetto: Re: Calc behavior: result of 0 ^ 0 On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
:Re: Calc behavior: result of 0 ^ 0
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
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: :Re: Calc behavior: result of 0 ^ 0
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
On 13.02.2013 08:28, Norbert Thiebaud wrote:
On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote:
On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote:
(OK, I guess it's better to re-subscribe to the list).
In reply to Norbert Thiebaud*:
In the Power rule, which *is* commonly used for differentiation, we take a
series
of polinomials where n !=0. n is not only different than zero, most importantly,
it is a constant.
[...]
For those interested in the actual Math... in Math words have meaning
and that meaning have often context. let me develop a bit the notion
of 'form' mentioned earlier:
for instance in the expression 'in an indeterminate form', there is
'form' and it matter because in the context of determining extension
by continuity of a function, there are certain case where you can
transform you equation into another 'form' but if these transformation
lead you to an 'indeterminate form', you have to find another
transformation to continue...
hence h = f^g with f(x)-0 x-inf and g(x)-0 x-inf then -- once it
is establish that h actually converge in the operating set, and that
is another topic altogether -- lim h(x) x-0 = (lim f)^(lim g).
passing 'to the limit' in each term would yield 0^0 with is a
indeterminable 'form' (not a value, not a number, not claimed to be
the result of a calculation of power(0,0), but a 'form' of the
equation that is indeterminate...) at which point you cannot conclude,
what the limit is. What a mathematician is to do is to 'trans-form'
the original h in such a way that it lead him to a path to an actual
value.
in other words that is a very specific meaning for a very specific
subset of mathematics, that does not conflict with defining power(0,0)
= 1.
wrt to the 'context' of the quote I gave earlier:
Proposition 9: : Let X and Y be two sets, a and b their respective
cardinals, then the set X{superscript Y} has cardinal a {superscript
b}.
( I will use x^y here from now on to note x {superscript y} for readability )
Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
and 0^a = 0 if a != 0
For there exist a unique mapping of 'empty-set' into any given set
(namely, the mapping whose graph is the empty set); the set of
mappings of a set consisting of a single element into an arbitrary set
X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
mapping of an arbitrary set into a set consisting of a single element;
and finally there is not mapping of a non-empty set into the
empty-set;
* Note in particular that 0^0 = 1
Here is the full context of the quote. And if you think you have a
proof that there is a mathematical error there, by all means, rush to
your local university, as surely proving that half-way to the first
volume, on set theory, of a body of work that is acclaimed for it's
rigor and aim at grounding the entire field of mathematics soundly in
the rigor of set theory, there is an 'error', will surely promptly get
you a PhD in math... since that has escaped the attentive scrutiny and
peer review of the entire world of mathematicians for decades...
Thanks for providing some real math into this thread. I don't claim to
have understood everything you write, but still, I learned something new.
And I would never have expected to hear the name of Bourbaki on the dev
list. Thanks for that, too.
-Andre
Re: Calc behavior: result of 0 ^ 0
Hi, I reply to this mail, because I have some remarks to Andrea's statements (see below). But please excuse, if I (as german) perhaps use not always the right english words/expressions/definitions.) But first: Norbert Thibaud has cleared the mathematical questions and shown, that statements like Petros 0^0 = 1 is NOT mathematically correct. are meaningless. 0^0 is a shortcut or symbol for something meaningfull in special cases or models. Mathematic is a set of theories that has (at least) 2 great sectors: Theoretical/pure mathematics and applied mathematics which are different in methodology. Pure models or theories are based on axioms and definitions. Axioms must be complete and not contradictory but are otherwise free. Definitions have to be reasonable (and helpfull). Statements/proofs (if derived correctly out of the axioms) are true only in the respective model. In other models they make no sense. As the definition of 0^0 = 1 is _not_ wrong and not unreasonable (false is a wrong category in this case), for me the problems reduces to: Are there more (and heavier) advantages than disadvantages when changing the behaviour in Calc? The whole line of OOo-versions (I have tested also with StarOffice 7 and 8, if necessary I can also test with V5.2 but I think it's not worth the time to install etc.) defines 0^0=1. So generations of Calc-Spreadsheets rely on this even if only a very few may explicitly use this features. On the other side only one advantage was cited: The compatibilty with Excel. For me, the backward-compatibility is worth more. (See also my comment to 5) below.) Am 13.02.2013 01:00, schrieb Andrea Pescetti: Dennis E. Hamilton wrote: The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I still have to see some credible arguments here, since most of the feedback was misplaced. What we learned so far is: 1) Nobody so far exhibited a spreadsheet that would be broken by the new behavior. Rob has one, which was even published, so I'm sure he can and Norbert has given another Example where the old definition allows to model the correct mathematical behaviour for x^y. And you forget the many generations of older spreadsheets. share it for everybody to have a look. Even better, we have a fantastic collection of Calc templates at http://templates.openoffice.org/en/taxonomy/term/3923 ; seeing one of those templates break would help. 2) Everybody feels the need to say something about 0 ^ 0, but threads like this one are not pleasant to read. If you have nothing to say, please don't say anything. And if you have a lot to say, please limit yourself to what's strictly needed. Especially, undoing a volunteer's work without some concrete (in ODF format, in this case!) reasons is something the project must avoid. Generally I agree with must avoid. But I did not see a discussion, if this change shouldt be done. 3) Mathematics and the standards are two different worlds. If a standard is mathematically wrong, change the standard and come back. That is false: The standard is mathematically correct. 4) We implement a standard, ODF. There 0 ^ 0 can legitimately be evaluated to 0, 1 or an error. 5) We read another standard, OOXML. There 0 ^ 0 can only be evaluated as an error; the fact that OpenOffice will evaluate 0 ^ 0 from a XLSX file to 1 is a bug. This is false: It is no bug! If Excel were the standard it would be true. And if, then calc must also implement the leap-year bug. (And I think nobody would want to implement such an error.) But true is, that Calc now is not Excel-compatibel in this case which leads to the core-question backwards-comp. vs. Excel comp.. 6) Anyone whose spreadsheets depend on 0 ^ 0 being evaluated to 1 (or to zero, or to an error for that matter) has entered the dangerous world of implementation-defined behavior: even if you save in a standard format I'm a little bit confused. Everthing in applications is implementation-defined what else? like ODF, your spreadsheet depends on a particular ODF implementation (e.g., on the specific version of OpenOffice you used). Also the change would be implementation-defined and the behaviour would shurely depend on the OOo-Version used. Based on 5 and 6 I would actually still believe that it's good to evaluate 0 ^ 0 to error (so that we fix the bug in 5 and we choose the most strict behavior in 6). But I fully agree with Marcus in saying this issue is much smaller than the discussion around it, so I can surely change my opinion if I finally see some real-world spreadsheets impacted by the change. When we have those, also Pedro will likely see reasons for reverting the change. In short: provide concrete examples and everybody will be happy. Making controverse changes against many good reasons if not somebody else proves that it is negative, is no good collaboration. I understand,
Re: Calc behavior: result of 0 ^ 0
Hello;
Da: Norbert Thiebaud
...
On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote:
On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote:
(OK, I guess it's better to re-subscribe to the list).
In reply to Norbert Thiebaud*:
In the Power rule, which *is* commonly used for differentiation, we take a
series
of polinomials where n !=0. n is not only different than zero, most
importantly,
it is a constant.
Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed.
so for n=1 (which _is_ different of 0 !)
d/dx X = 1.x^0
for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
I know math can be challenging... but you don't get to invent
restriction on the Power Rule just to fit you argument.
I will put it in simple terms. You are saying that you can't calculate the
slope of the equation:
y =a*x + b
because in the process you need to calculate the value of x^0.
In the case of the set theory book, do note that the author is constructing
his own algebra,
The fact that you call 'Nicola Bourbaki' 'the author', is in itself
very telling about your expertise in Math.
I nicely put a link to the wikipedia page, since laymen are indeed
unlikely to know 'who' Borbaki is.
Do I really care if the name of the author is fictitious or real?
that get outside his set: 0^0 and x/0 are such cases. The text is not
a demonstration, it is simply a statement taken out of context.
You ask for a practical spreadsheet example, when one is given you
invent new 'rules' to ignore' it.
You haven't provided so far that practical spreadsheet.
You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
And when I gave you the page and line from one of the most rigorous
mathematical body of work of the 20th century (yep Bourbaki... look it
up)
you and hand-wave, pretending the author did not mean it.. or even
better if this author(sic) *is* using mathematics correctly.
The thing is that you are taking statements out of context. I don't
claim being a mathematithian. I took a few courses from the career for fun.
In the case of set theory you can define, for your own purposes, a special
algebra where:
- You redefine your own multiplication operator (x).
- You don't define division.
- You make yor algebra system fit into a set of properties that
is useful for your own properties.
Once you define your own multiplication (which is not the same
multiplication supported in a spreadsheet) You work around the
issue in the power operator by defining the undefined case.
These are all nice mathematical models that don't apply to a spreadsheet.
I guess looking hard it may be possible to find an elaborated case where
someone manages to shoot himself in the foot
Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
for shooting himself in the foot when doing math...
For those interested in the actual Math... in Math words have meaning
and that meaning have often context. let me develop a bit the notion
of 'form' mentioned earlier:
for instance in the expression 'in an indeterminate form', there is
'form' and it matter because in the context of determining extension
by continuity of a function, there are certain case where you can
transform you equation into another 'form' but if these transformation
lead you to an 'indeterminate form', you have to find another
transformation to continue...
hence h = f^g with f(x)-0 x-inf and g(x)-0 x-inf then -- once it
is establish that h actually converge in the operating set, and that
is another topic altogether -- lim h(x) x-0 = (lim f)^(lim g).
passing 'to the limit' in each term would yield 0^0 with is a
indeterminable 'form' (not a value, not a number, not claimed to be
the result of a calculation of power(0,0), but a 'form' of the
equation that is indeterminate...) at which point you cannot conclude,
what the limit is. What a mathematician is to do is to 'trans-form'
the original h in such a way that it lead him to a path to an actual
value.
in other words that is a very specific meaning for a very specific
subset of mathematics, that does not conflict with defining power(0,0)
= 1.
wrt to the 'context' of the quote I gave earlier:
Proposition 9: : Let X and Y be two sets, a and b their respective
cardinals, then the set X{superscript Y} has cardinal a {superscript
b}.
( I will use x^y here from now on to note x {superscript y} for readability )
Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
and 0^a = 0 if a != 0
For there exist a unique mapping of 'empty-set' into any given set
(namely, the mapping whose graph is the empty set); the set of
mappings of a set consisting of a single element into an arbitrary set
X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
mapping of an arbitrary set into a set consisting of a single element;
and finally there is not mapping of a non-empty set into the
empty-set;
* Note in particular that 0^0 = 1
Again, I will
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 p...@apache.org Hello; Da: Norbert Thiebaud ... On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote: On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote: (OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed. so for n=1 (which _is_ different of 0 !) d/dx X = 1.x^0 for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0. I know math can be challenging... but you don't get to invent restriction on the Power Rule just to fit you argument. I will put it in simple terms. You are saying that you can't calculate the slope of the equation: y =a*x + b because in the process you need to calculate the value of x^0. In the case of the set theory book, do note that the author is constructing his own algebra, The fact that you call 'Nicola Bourbaki' 'the author', is in itself very telling about your expertise in Math. I nicely put a link to the wikipedia page, since laymen are indeed unlikely to know 'who' Borbaki is. Do I really care if the name of the author is fictitious or real? that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. You ask for a practical spreadsheet example, when one is given you invent new 'rules' to ignore' it. You haven't provided so far that practical spreadsheet. You claim that 'real mathematician' consider 0^0=... NaN ? Error ? And when I gave you the page and line from one of the most rigorous mathematical body of work of the 20th century (yep Bourbaki... look it up) you and hand-wave, pretending the author did not mean it.. or even better if this author(sic) *is* using mathematics correctly. The thing is that you are taking statements out of context. I don't claim being a mathematithian. I took a few courses from the career for fun. In the case of set theory you can define, for your own purposes, a special algebra where: - You redefine your own multiplication operator (x). - You don't define division. - You make yor algebra system fit into a set of properties that is useful for your own properties. Once you define your own multiplication (which is not the same multiplication supported in a spreadsheet) You work around the issue in the power operator by defining the undefined case. These are all nice mathematical models that don't apply to a spreadsheet. I guess looking hard it may be possible to find an elaborated case where someone manages to shoot himself in the foot Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious for shooting himself in the foot when doing math... For those interested in the actual Math... in Math words have meaning and that meaning have often context. let me develop a bit the notion of 'form' mentioned earlier: for instance in the expression 'in an indeterminate form', there is 'form' and it matter because in the context of determining extension by continuity of a function, there are certain case where you can transform you equation into another 'form' but if these transformation lead you to an 'indeterminate form', you have to find another transformation to continue... hence h = f^g with f(x)-0 x-inf and g(x)-0 x-inf then -- once it is establish that h actually converge in the operating set, and that is another topic altogether -- lim h(x) x-0 = (lim f)^(lim g). passing 'to the limit' in each term would yield 0^0 with is a indeterminable 'form' (not a value, not a number, not claimed to be the result of a calculation of power(0,0), but a 'form' of the equation that is indeterminate...) at which point you cannot conclude,
Re: Calc behavior: result of 0 ^ 0
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
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 rgb.m...@gmail.com A: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Inviato: Mercoledì 13 Febbraio 2013 10:43 Oggetto: Re: Calc behavior: result of 0 ^ 0 Not answering any particular message, so top posting. Two points: a) Of course you can always redefine a function to fill holes on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit), then there is NO way to make that function continuous on (0,0), let alone what happens when x 0... so the real question is: does it make sense to fill the hole on x^y? *My* answer (and that leads to the second point) is no because it do not give any added value. b) Considering that we are near to 90 messages on this thread it is quite clear that an agreement is not possible. On this situation it is also clear that choosing an error instead of a fixed value is the best bet. Just my 2¢ Regards Ricardo 2013/2/13 Pedro Giffuni p...@apache.org Hello; Da: Norbert Thiebaud ... On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote: On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote: (OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed. so for n=1 (which _is_ different of 0 !) d/dx X = 1.x^0 for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0. I know math can be challenging... but you don't get to invent restriction on the Power Rule just to fit you argument. I will put it in simple terms. You are saying that you can't calculate the slope of the equation: y =a*x + b because in the process you need to calculate the value of x^0. In the case of the set theory book, do note that the author is constructing his own algebra, The fact that you call 'Nicola Bourbaki' 'the author', is in itself very telling about your expertise in Math. I nicely put a link to the wikipedia page, since laymen are indeed unlikely to know 'who' Borbaki is. Do I really care if the name of the author is fictitious or real? that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. You ask for a practical spreadsheet example, when one is given you invent new 'rules' to ignore' it. You haven't provided so far that practical spreadsheet. You claim that 'real mathematician' consider 0^0=... NaN ? Error ? And when I gave you the page and line from one of the most rigorous mathematical body of work of the 20th century (yep Bourbaki... look it up) you and hand-wave, pretending the author did not mean it.. or even better if this author(sic) *is* using mathematics correctly. The thing is that you are taking statements out of context. I don't claim being a mathematithian. I took a few courses from the career for fun. In the case of set theory you can define, for your own purposes, a special algebra where: - You redefine your own multiplication operator (x). - You don't define division. - You make yor algebra system fit into a set of properties that is useful for your own properties. Once you define your own multiplication (which is not the same multiplication supported in a spreadsheet) You work around the issue in the power operator by defining the undefined case. These are all nice mathematical models that don't apply to a spreadsheet. I guess looking hard it may be possible to find an elaborated case where someone manages to shoot himself in the foot Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious for shooting himself in the foot when doing math... For those interested in the actual Math... in Math words have meaning and that meaning have often context. let me develop a bit the notion of 'form' mentioned earlier: for instance in the expression 'in an indeterminate form', there is 'form' and it matter because in the context of determining extension by continuity of a function, there are certain case where you can transform you equation into another 'form' but if these transformation lead you to an 'indeterminate form
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 rgb.m...@gmail.com To: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:43 AM Subject: Re: Calc behavior: result of 0 ^ 0 Not answering any particular message, so top posting. Two points: a) Of course you can always redefine a function to fill holes on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit), then there is NO way to make that function continuous on (0,0), let alone what happens when x 0... so the real question is: does it make sense to fill the hole on x^y? *My* answer (and that leads to the second point) is no because it do not give any added value. b) Considering that we are near to 90 messages on this thread it is quite clear that an agreement is not possible. On this situation it is also clear that choosing an error instead of a fixed value is the best bet. Just my 2¢ Regards Ricardo 2013/2/13 Pedro Giffuni p...@apache.org Hello; Da: Norbert Thiebaud ... On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote: On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote: (OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed. so for n=1 (which _is_ different of 0 !) d/dx X = 1.x^0 for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0. I know math can be challenging... but you don't get to invent restriction on the Power Rule just to fit you argument. I will put it in simple terms. You are saying that you can't calculate the slope of the equation: y =a*x + b because in the process you need to calculate the value of x^0. In the case of the set theory book, do note that the author is constructing his own algebra, The fact that you call 'Nicola Bourbaki' 'the author', is in itself very telling about your expertise in Math. I nicely put a link to the wikipedia page, since laymen are indeed unlikely to know 'who' Borbaki is. Do I really care if the name of the author is fictitious or real? that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. You ask for a practical spreadsheet example, when one is given you invent new 'rules' to ignore' it. You haven't provided so far that practical spreadsheet. You claim that 'real mathematician' consider 0^0=... NaN ? Error ? And when I gave you the page and line from one of the most rigorous mathematical body of work of the 20th century (yep Bourbaki... look it up) you and hand-wave, pretending the author did not mean it.. or even better if this author(sic) *is* using mathematics correctly. The thing is that you are taking statements out of context. I don't claim being a mathematithian. I took a few courses from the career for fun. In the case of set theory you can define, for your own purposes, a special algebra where: - You redefine your own multiplication operator (x). - You don't define division. - You make yor algebra system fit into a set of properties that is useful for your own properties. Once you define your own multiplication (which is not the same multiplication supported in a spreadsheet) You work around the issue in the power operator by defining the undefined case. These are all nice mathematical models that don't apply to a spreadsheet. I
Interval arithmetic [was Re: Calc behavior: result of 0 ^ 0]
On Wed, Feb 13, 2013 at 10:43 AM, Pedro Giffuni p...@apache.org 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
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 joe_schae...@yahoo.com To: dev@openoffice.apache.org dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:53 AM Subject: Re: Calc behavior: result of 0 ^ 0 Honestly I'd say that if anything is clear, it's that changing away from the status quo currently enjoys zero consensus. As a Ph.D. mathematician who knows about Bourbaki, all I can say is that line of argument is curious here. There are no authorities other than the spec to turn to about how you want POWER(0,0) to behave- as a function of 2 variables returning an error is probably best mathematically because the POWER function isn't remotely continuous at (0,0), but as part of an implementation of power series representations of sums involving 0^0, returning 1 is better. In any case, the idea for how issues like this should be resolved at Apache is always in favor of stability; that's why the impetus for consensus away from the current behavior is required, not a general discussion about which behavior is better given two equal choices in the abstract. A prior decision has already been made about the code, and those that wish to change it need to demonstrate consensus for the change, not the other way around. HTH From: RGB ES rgb.m...@gmail.com To: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:43 AM Subject: Re: Calc behavior: result of 0 ^ 0 Not answering any particular message, so top posting. Two points: a) Of course you can always redefine a function to fill holes on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit), then there is NO way to make that function continuous on (0,0), let alone what happens when x 0... so the real question is: does it make sense to fill the hole on x^y? *My* answer (and that leads to the second point) is no because it do not give any added value. b) Considering that we are near to 90 messages on this thread it is quite clear that an agreement is not possible. On this situation it is also clear that choosing an error instead of a fixed value is the best bet. Just my 2¢ Regards Ricardo 2013/2/13 Pedro Giffuni p...@apache.org Hello; Da: Norbert Thiebaud ... On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote: On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote: (OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed. so for n=1 (which _is_ different of 0 !) d/dx X = 1.x^0 for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0. I know math can be challenging... but you don't get to invent restriction on the Power Rule just to fit you argument. I will put it in simple terms. You are saying that you can't calculate the slope of the equation: y =a*x + b because in the process you need to calculate the value of x^0. In the case of the set theory book, do note that the author is constructing his own algebra, The fact that you call 'Nicola Bourbaki' 'the author', is in itself very telling about your expertise in Math. I nicely put a link to the wikipedia page, since laymen are indeed unlikely to know 'who' Borbaki is. Do I really care if the name of the author is fictitious or real? that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. You ask for a practical spreadsheet example, when one is given you invent new 'rules' to ignore' it. You haven't provided so far that practical spreadsheet. You claim that 'real mathematician' consider 0^0=... NaN ? Error ? And when I gave you the page and line from one of the most rigorous mathematical body of work of the 20th century (yep Bourbaki... look it up) you and hand-wave, pretending the author did not mean it.. or even better if this author(sic) *is* using mathematics correctly. The thing is that you are taking statements out of context. I don't claim being a mathematithian. I took a few courses from the career for fun. In the case of set theory you can define, for your own purposes, a special algebra where: - You redefine your own multiplication
Re: Calc behavior: result of 0 ^ 0
On Wed, Feb 13, 2013 at 9:53 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Honestly I'd say that if anything is clear, it's that changing away from the status quo currently enjoys zero consensus. As a Ph.D. mathematician who knows about Bourbaki, all I can say is that line of argument is curious here. There are no authorities other than the spec to turn to about how you want POWER(0,0) to behave- as a function of 2 variables returning an error is probably best mathematically because the POWER function isn't remotely continuous at (0,0) Sure it is not continuous at 0,0 but the sign function is not either, that does not prevent sign(0) to be defined a 0 So continuity is not a necessary requirement. , but as part of an implementation of power series representations of sums involving 0^0, returning 1 is better. Indeed. I guess my point was : '0^0=1 is obviously(sic) mathematically wrong' is just non-sens. There are valid backward/cross-ward compatibility arguments, there are valid implementation/performance arguments. but the 'Mathematical correctness' argument (for either 1 or undefined) is completely bogus. Norbert
Re: Calc behavior: result of 0 ^ 0
On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer joe_schae...@yahoo.com wrote: OTOH I haven't seen anyone issue a technical veto on this change, which is really what's required before Pedro actually needs to revert anything. I was waiting to see if there were any persuasive arguments in favor of breaking backwards compatibility before deciding whether to do that. I think things are getting a little clearer now with Norbert's contribution to the discussion. But if (as it seems now) that mathematical correctness does not justify the change, then my position would be that we don't break backwards compatibility. Also, a veto would be a blunt instrument and I'd rather avoid it if further discussion leads to a consensus. -Rob From: Joe Schaefer joe_schae...@yahoo.com To: dev@openoffice.apache.org dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:53 AM Subject: Re: Calc behavior: result of 0 ^ 0 Honestly I'd say that if anything is clear, it's that changing away from the status quo currently enjoys zero consensus. As a Ph.D. mathematician who knows about Bourbaki, all I can say is that line of argument is curious here. There are no authorities other than the spec to turn to about how you want POWER(0,0) to behave- as a function of 2 variables returning an error is probably best mathematically because the POWER function isn't remotely continuous at (0,0), but as part of an implementation of power series representations of sums involving 0^0, returning 1 is better. In any case, the idea for how issues like this should be resolved at Apache is always in favor of stability; that's why the impetus for consensus away from the current behavior is required, not a general discussion about which behavior is better given two equal choices in the abstract. A prior decision has already been made about the code, and those that wish to change it need to demonstrate consensus for the change, not the other way around. HTH From: RGB ES rgb.m...@gmail.com To: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:43 AM Subject: Re: Calc behavior: result of 0 ^ 0 Not answering any particular message, so top posting. Two points: a) Of course you can always redefine a function to fill holes on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit), then there is NO way to make that function continuous on (0,0), let alone what happens when x 0... so the real question is: does it make sense to fill the hole on x^y? *My* answer (and that leads to the second point) is no because it do not give any added value. b) Considering that we are near to 90 messages on this thread it is quite clear that an agreement is not possible. On this situation it is also clear that choosing an error instead of a fixed value is the best bet. Just my 2¢ Regards Ricardo 2013/2/13 Pedro Giffuni p...@apache.org Hello; Da: Norbert Thiebaud ... On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote: On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote: (OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed. so for n=1 (which _is_ different of 0 !) d/dx X = 1.x^0 for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0. I know math can be challenging... but you don't get to invent restriction on the Power Rule just to fit you argument. I will put it in simple terms. You are saying that you can't calculate the slope of the equation: y =a*x + b because in the process you need to calculate the value of x^0. In the case of the set theory book, do note that the author is constructing his own algebra, The fact that you call 'Nicola Bourbaki' 'the author', is in itself very telling about your expertise in Math. I nicely put a link to the wikipedia page, since laymen are indeed unlikely to know 'who' Borbaki is. Do I really care if the name of the author is fictitious or real? that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. You ask for a practical spreadsheet example, when one is given you invent new 'rules' to ignore' it. You haven't provided so far that practical spreadsheet. You claim that 'real mathematician' consider
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 robw...@apache.org To: dev@openoffice.apache.org Sent: Wednesday, February 13, 2013 12:30 PM Subject: Re: Calc behavior: result of 0 ^ 0 On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer joe_schae...@yahoo.com wrote: OTOH I haven't seen anyone issue a technical veto on this change, which is really what's required before Pedro actually needs to revert anything. I was waiting to see if there were any persuasive arguments in favor of breaking backwards compatibility before deciding whether to do that. I think things are getting a little clearer now with Norbert's contribution to the discussion. But if (as it seems now) that mathematical correctness does not justify the change, then my position would be that we don't break backwards compatibility. Also, a veto would be a blunt instrument and I'd rather avoid it if further discussion leads to a consensus. -Rob From: Joe Schaefer joe_schae...@yahoo.com To: dev@openoffice.apache.org dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:53 AM Subject: Re: Calc behavior: result of 0 ^ 0 Honestly I'd say that if anything is clear, it's that changing away from the status quo currently enjoys zero consensus. As a Ph.D. mathematician who knows about Bourbaki, all I can say is that line of argument is curious here. There are no authorities other than the spec to turn to about how you want POWER(0,0) to behave- as a function of 2 variables returning an error is probably best mathematically because the POWER function isn't remotely continuous at (0,0), but as part of an implementation of power series representations of sums involving 0^0, returning 1 is better. In any case, the idea for how issues like this should be resolved at Apache is always in favor of stability; that's why the impetus for consensus away from the current behavior is required, not a general discussion about which behavior is better given two equal choices in the abstract. A prior decision has already been made about the code, and those that wish to change it need to demonstrate consensus for the change, not the other way around. HTH From: RGB ES rgb.m...@gmail.com To: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:43 AM Subject: Re: Calc behavior: result of 0 ^ 0 Not answering any particular message, so top posting. Two points: a) Of course you can always redefine a function to fill holes on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit), then there is NO way to make that function continuous on (0,0), let alone what happens when x 0... so the real question is: does it make sense to fill the hole on x^y? *My* answer (and that leads to the second point) is no because it do not give any added value. b) Considering that we are near to 90 messages on this thread it is quite clear that an agreement is not possible. On this situation it is also clear that choosing an error instead of a fixed value is the best bet. Just my 2¢ Regards Ricardo 2013/2/13 Pedro Giffuni p...@apache.org Hello; Da: Norbert Thiebaud ... On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote: On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote: (OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed. so for n=1 (which _is_ different of 0 !) d/dx X = 1.x^0 for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0. I know math can be challenging... but you don't get to invent restriction on the Power Rule just to fit you argument. I will put it in simple terms. You are saying that you can't calculate the slope of the equation: y =a*x + b because in the process you need to calculate the value of x^0. In the case of the set theory book, do note that the author
Re: Calc behavior: result of 0 ^ 0
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 joe_schae...@yahoo.com To: dev@openoffice.apache.org 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 robw...@apache.org To: dev@openoffice.apache.org Sent: Wednesday, February 13, 2013 12:30 PM Subject: Re: Calc behavior: result of 0 ^ 0 On Wed, Feb 13, 2013 at 11:56 AM, Joe Schaefer joe_schae...@yahoo.com wrote: OTOH I haven't seen anyone issue a technical veto on this change, which is really what's required before Pedro actually needs to revert anything. I was waiting to see if there were any persuasive arguments in favor of breaking backwards compatibility before deciding whether to do that. I think things are getting a little clearer now with Norbert's contribution to the discussion. But if (as it seems now) that mathematical correctness does not justify the change, then my position would be that we don't break backwards compatibility. Also, a veto would be a blunt instrument and I'd rather avoid it if further discussion leads to a consensus. -Rob From: Joe Schaefer joe_schae...@yahoo.com To: dev@openoffice.apache.org dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:53 AM Subject: Re: Calc behavior: result of 0 ^ 0 Honestly I'd say that if anything is clear, it's that changing away from the status quo currently enjoys zero consensus. As a Ph.D. mathematician who knows about Bourbaki, all I can say is that line of argument is curious here. There are no authorities other than the spec to turn to about how you want POWER(0,0) to behave- as a function of 2 variables returning an error is probably best mathematically because the POWER function isn't remotely continuous at (0,0), but as part of an implementation of power series representations of sums involving 0^0, returning 1 is better. In any case, the idea for how issues like this should be resolved at Apache is always in favor of stability; that's why the impetus for consensus away from the current behavior is required, not a general discussion about which behavior is better given two equal choices in the abstract. A prior decision has already been made about the code, and those that wish to change it need to demonstrate consensus for the change, not the other way around. HTH From: RGB ES rgb.m...@gmail.com To: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Sent: Wednesday, February 13, 2013 10:43 AM Subject: Re: Calc behavior: result of 0 ^ 0 Not answering any particular message, so top posting. Two points: a) Of course you can always redefine a function to fill holes on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit
Re: Interval arithmetic [was Re: Calc behavior: result of 0 ^ 0]
On 02/13/2013 11:14 AM, Rob Weir wrote: On Wed, Feb 13, 2013 at 10:43 AM, Pedro Giffuni p...@apache.org 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
On 02/13/2013 02:46 PM, Pedro Giffuni wrote: Independently of the vote result I will be effectively stopping the development work I intended to do on Calc as I have lost all interest on improving it given the current situation. I totally understand. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Calc behavior: result of 0 ^ 0
- 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
- 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
On 11/02/2013 Andre Fischer wrote: On 11.02.2013 17:10, Andrea Pescetti wrote: A specification may need to leave room for implementation-defined behavior. Look at the C or C++ standard for example. Do you know of any example where this is actually a good thing? It is good for developers who need to implement the standard, but indeed not for users! Regards, Andrea.
Re: Calc behavior: result of 0 ^ 0
...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
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
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 dennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto: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
On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni p...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. Regards, -Rob Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamilton dennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto: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
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
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 dennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto: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
On Tue, Feb 12, 2013 at 4:17 PM, Pedro Giffuni p...@apache.org wrote: Ugh.. I haven't been following this thread at all ... I recommend reading the archives then, since every argument that could be made, has been made already. -Rob I unsubscribed from the -dev list because I always ended up in absurd discussions and there was not much technical content either. I suspected it would be bikeshed.org material but in any case let me make things clear. - 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 is 1, however when you consider the limit when x tends to -0, the limit is infinite. This is called Indeterminate Form. http://en.wikipedia.org/wiki/Indeterminate_form If you wonder, I failed a math quiz in the University for blindly using the value my HP Calculator gave (1), so I am sort of glad that this has been a free educational experience for some of you. The implementation in OOo doesn't return explicitly a 1 value but instead relies on what the libc pow() function does. The standard libc lets you do 0^0 but it also lets you divide by zero without aborting . Modern IEEE 754 2008 implements three power functions pow(), pown() and powr(), powr() being the most similar to the real mathematical function. The implementation is non intrusive: I added a wrapper in SAL that behaves like powr() so that we don't affect other formulas that use pow() internally. So far no one has given an example where shooting yourself in the foot by expecting pow(0,0) to be 1 is a good thing. I am gladly surprised that Excel does the same, but the real reason why I went ahead and implemented a solution is to do the right thing, mathematically speaking. Mathematical correctness is not something that IMHO pertains to democracy. Sure it would be nice to have an option to adjust your results for mathematically undetermined cases like 0^0 or 0/0 but unless you are planning to implement it don't expected such features to appear magically either. I would be extremely disappointed to have to revert a correct fix for non-technical reasons. I think I would lose any motivation to improve other functions in Calc. Pedro.
Re: Calc behavior: result of 0 ^ 0
Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto: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
On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. Regards, -Rob I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto: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
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
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
Am 02/12/2013 10:39 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. And what is your *serious* use case for this spreadsheet? Beside to use it as a test document? And you have it created before the discussion has started? I'll ask my question again: Is there more than one who can deliever a *serious and valid use case*? Thanks Marcus I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto: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
On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 02/12/2013 10:39 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. And what is your *serious* use case for this spreadsheet? Beside to use it as a test document? And you have it created before the discussion has started? The spreadsheet I am thinking about is over 4 years old, has been published and is used by others as well. I'd also point out that asking your question on this list is not really telling you anything. We've had 37 million downloads of AOO 3.4. Only 400 people subscribe to this list. So I don't think this is great evidence for saying it has zero impact. But again, if you think that situation never comes up in real use, then let's not make the change, since it would have no benefit. -Rob I'll ask my question again: Is there more than one who can deliever a *serious and valid use case*? Thanks Marcus I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto: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
Re: Calc behavior: result of 0 ^ 0
Am 02/12/2013 11:22 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 10:39 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.orgwrote: 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. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement
Re: Calc behavior: result of 0 ^ 0
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
(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
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
Re: Calc behavior: result of 0 ^ 0
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
On 02/12/2013 05:45 PM, Rob Weir wrote: On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 12/02/2013 23:22, Rob Weir a écrit : But again, if you think that situation never comes up in real use, then let's not make the change, since it would have no benefit. You don't seem to see the benefit of the change: warn the user that there is something weird in the formula that requires his attention. Perhaps that there are users getting wrong results because a value is returned and therefore hides the problem. And your solution is to give users error messages where they do not have a problem ?! What if they the examine the formula and find out that it is exactly what they wanted? Your solution would force them to rewrite their formulas for no good reason. Again this is like giving an spelling error for their because some users might confuse it with there. -Rob I am torn as to which is worse. because loading the document in any other program able to read ODF might exhibit completely different behavior; and still be valid to the spec. Although I would prefer returning an error, if it does not, then it should stay as it is (as opposed to changing to one of the other supported values) -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Calc behavior: result of 0 ^ 0
On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote:
On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote:
(OK, I guess it's better to re-subscribe to the list).
In reply to Norbert Thiebaud*:
In the Power rule, which *is* commonly used for differentiation, we take a
series
of polinomials where n !=0. n is not only different than zero, most
importantly,
it is a constant.
Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed.
so for n=1 (which _is_ different of 0 !)
d/dx X = 1.x^0
for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
I know math can be challenging... but you don't get to invent
restriction on the Power Rule just to fit you argument.
and we just can't assume every speadsheet
user will use a restricted set of capabilities.
Now, in a spreadsheet this formula would be used if you have a polinomial and
you want to calculate and/or graph it's derivative. Since we don't do
symbolic
math in the speadsheet you would actually do this by hand and you would
resolve
the trivial constant^0 cases.
Really... but extending by continuity a function in 0, without
consideration for convergence, _that_ is something that is done by
spreadsheet ?
iow just because 0^0 is an indeterminate _form_ does not mean that 0^0
can not have a value... it just mean that when searching for a limit
for a function h(x)
if your _transformation_ lead you to 0^0 you cannot conclude from that
_form_ that means that the rule and tools that allow you to jump form
lim - 0 to a value in 0 do not hold when they lead to that 'form'. I
know math is a tricky thing... but the definition of words and their
scope of application is kind of important in Math.
In the case of the set theory book, do note that the author is constructing
his own algebra,
The fact that you call 'Nicola Bourbaki' 'the author', is in itself
very telling about your expertise in Math.
I nicely put a link to the wikipedia page, since laymen are indeed
unlikely to know 'who' Borbaki is.
that get outside his set: 0^0 and x/0 are such cases. The text is not
a demonstration, it is simply a statement taken out of context.
You ask for a practical spreadsheet example, when one is given you
invent new 'rules' to ignore' it.
You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
And when I gave you the page and line from one of the most rigorous
mathematical body of work of the 20th century (yep Bourbaki... look it
up)
you and hand-wave, pretending the author did not mean it.. or even
better if this author(sic) *is* using mathematics correctly.
I guess looking hard it may be possible to find an elaborated case where
someone manages to shoot himself in the foot
Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
for shooting himself in the foot when doing math...
For those interested in the actual Math... in Math words have meaning
and that meaning have often context. let me develop a bit the notion
of 'form' mentioned earlier:
for instance in the expression 'in an indeterminate form', there is
'form' and it matter because in the context of determining extension
by continuity of a function, there are certain case where you can
transform you equation into another 'form' but if these transformation
lead you to an 'indeterminate form', you have to find another
transformation to continue...
hence h = f^g with f(x)-0 x-inf and g(x)-0 x-inf then -- once it
is establish that h actually converge in the operating set, and that
is another topic altogether -- lim h(x) x-0 = (lim f)^(lim g).
passing 'to the limit' in each term would yield 0^0 with is a
indeterminable 'form' (not a value, not a number, not claimed to be
the result of a calculation of power(0,0), but a 'form' of the
equation that is indeterminate...) at which point you cannot conclude,
what the limit is. What a mathematician is to do is to 'trans-form'
the original h in such a way that it lead him to a path to an actual
value.
in other words that is a very specific meaning for a very specific
subset of mathematics, that does not conflict with defining power(0,0)
= 1.
wrt to the 'context' of the quote I gave earlier:
Proposition 9: : Let X and Y be two sets, a and b their respective
cardinals, then the set X{superscript Y} has cardinal a {superscript
b}.
( I will use x^y here from now on to note x {superscript y} for readability )
Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
and 0^a = 0 if a != 0
For there exist a unique mapping of 'empty-set' into any given set
(namely, the mapping whose graph is the empty set); the set of
mappings of a set consisting of a single element into an arbitrary set
X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
mapping of an arbitrary set into a set consisting of a single element;
and finally there is not mapping of a non-empty set into the
empty-set;
* Note in particular that 0^0 = 1
Here is the full context of the
Re: Calc behavior: result of 0 ^ 0
On 2/11/13 5:39 AM, Andrew Douglas Pitonyak wrote: On 02/10/2013 10:04 AM, Rory O'Farrell wrote: My thinking is the Calc should return the mathematically correct answer. ODF standard defines what can be returned. If there is a single mathematically correct answer, I would expect the standard to define it. If the standard is wrong (like defining 1+1=3), then the standard should be changed. At the end of the day, it amuses me that the standard allows for three different values. that is indeed the most interesting thing of this whole thread. Juergen I suppose that if the people writing the standard could not agree on a single answer, I doubt if you will receive a decent consensus here. I would find it a bit offensive if 0/0 returned 0 or 1 (not that it might not be occasionally useful). I can probably claim the same for 0^0. The fact that the standard does not take a stand leaves me a bit bewildered, but I can guess as to why.
Re: Calc behavior: result of 0 ^ 0
On 10.02.2013 00:11, Andrea Pescetti wrote: A good practical example of backwards-incompatible changes in version 4.0 is the behavior of Calc while computing 0 ^ 0. You can find a long issue, with different points of view, about this at: https://issues.apache.org/ooo/show_bug.cgi?id=114430 but in short: - Obviously, 0 ^ 0 is an illegal operation in mathematics and the result is undefined/invalid - In 3.4.1, =0 ^ 0 returns 1 - In 4.0, as patched by Pedro (see issue), =0 ^ 0 would return an error - According to ODF, valid results are 0, 1, error - We gain interoperability since Excel returns an error too - We lose backwards compatibility if someone was relying on the fact that OpenOffice returns 1 as the result of =0 ^ 0 I'm OK with the proposed change, provided we advertise it in the release notes. I'm not aware of any cases where someone is actively using the fact that in Calc 0 ^ 0 evaluates to 1, and even if someone did, I would say that his spreadsheets should not compute 0 ^ 0 at all. A side benefit would be that school students quickly wanting to find out what is the result of 0 ^ 0 would be told the truth (it's an error) instead of being presented with a numeric result and no warnings. (Then the student would go on and write = - 2 ^ 2 and have a lot of fun, but this is out of scope here). Is there consensus that this is a reasonable backwards-incompatible change, or compelling reasons to revert it? I would like to propose to revert the change because, as Rob said elsewhere in this thread, this is not a mathematical question. If the the ODF spec says that 0,1, and error are valid return values and we return 1 then there is no error (despite the three exclamation marks in the title of the bug). If the spec said that 2 is the only valid return value then we would have to return 2. We should change the ODF spec first instead. A spec that basically says whatever you want to return is fine is of no value, as was proven in this thread. This is something that I would only accept from a random() function. Besides, my emacs calc says that 0^0 is 1, so that can be the only correct answer, right? Regards, Andre
Re: Calc behavior: result of 0 ^ 0
On 2/10/13 9:51 PM, Hagar Delest wrote: Le 10/02/2013 21:21, Rob Weir a écrit : Did you not notice the title of this thread? Has it entirely escaped you that we're talking about 0^0 here? If you want to start another threat about extensions, then go ahead and I will comment there. But anyone of the intelligence of a grapefruit would not find it strange that I am discussing only 0^0 in this thread. And have you read my previous message? I don't understand why there is almost nothing aired when there are talks about breaking the compatibility of ALL the extensions because of a minor issue. And here you're challenging a change that will affect very few users. ALL the extensions is of course completely nonsense. The change we talked about is only for extensions that define an own toolbar. And we can of course start a new discussion about the missing cooperation of extension developers to work with core developers. It can be relatively easy fixed by any extension developer. And of course with a little extra work in a way that breaks nothing. Minor effort in the extensions, much more and more complex code in the core. The question is always how we want to move forward. Changes are good if they help to attract more developers and if they help to improve the product over time. If developers can't change things and can't improve code etc. over time we will have a problem to find enough developers who are willing to maintain old incomprehensible code that we have in many areas. That don't mean that I support any kind of incompatible change but when we have a simple migration path in place and when we talk about a major version I will probably support most of them. Juergen You told in your first message that you were concerned that the change would break the backward compatibility. But are you not concerned by all the users having their extensions deactivated by a minor API change??? There is your other message: Le 09/02/2013 18:40, Rob Weir a écrit : I've added a new section to the 4.0 Release Notes for tracking changes that impact backwards compatibility: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes This would include changes to the public interfaces of AOO, including incompatible changes to API's (including spreadsheet functions), file formats, etc. But I don't see any reference to the extensions issue. If there is a real problem to be talked about, it's more the API change that would break extensions compatibility. Honestly, I don't care about the 0^0 issue. Not enough users will be impacted. Hagar
Re: Calc behavior: result of 0 ^ 0
On Mon, Feb 11, 2013 at 12:57:57AM +0100, Andrea Pescetti wrote: It is unavoidable that we will open a discussion about the extensions compatibility; I started this one about 0 ^ 0 which is enjoying unexpected popularity (and I would appreciate, for the sake of completeness, to see one example of a spreadsheet that would be broken by the new behavior), but when this one has settled I'll open one about extensions There is already a thread on api@, where it belongs. Please don't start spreading threads everywhere! (It already hard to follow endless/pointless discussion on these mailing lists, to follow them in parallel in several lists). Regards -- Ariel Constenla-Haile La Plata, Argentina pgpnE1s06ZjII.pgp Description: PGP signature
Re: Calc behavior: result of 0 ^ 0
On Sun, Feb 10, 2013 at 11:39 PM, Andrew Douglas Pitonyak and...@pitonyak.org wrote: On 02/10/2013 10:04 AM, Rory O'Farrell wrote: My thinking is the Calc should return the mathematically correct answer. ODF standard defines what can be returned. If there is a single mathematically correct answer, I would expect the standard to define it. If the standard is wrong (like defining 1+1=3), then the standard should be changed. At the end of the day, it amuses me that the standard allows for three different values. I suppose that if the people writing the standard could not agree on a single answer, I doubt if you will receive a decent consensus here. The goal when writing the ODF 1.2 OpenFormula specification was to describe current spreadsheet behavior. It was not our goal to define a new spreadsheet formula language that was cleaner, better-designed, more consistent than what was already out there. It would have been legitimate to define an entirely new language and open up all past design decisions. But that is not what we aimed to do. If you recall MS Office 2007 was not interoperable with OpenOffice spreadsheets. Every single formula was incompatible. Even basic functions like SUM() and AVERAGE() were lost when Office opened an ODF document. By having a new ODF 1.2 formula specification that encompasses the range of behaviors in real-world spreadsheets today, we now have an MS Office Excel that is compatible with the vast majority of OpenOffice spreadsheets, even though there may be differences in edge cases like 0^0. So from the standardization perspective I think this is a success, both technically and politically. It vastly improved interoperability. -Rob I would find it a bit offensive if 0/0 returned 0 or 1 (not that it might not be occasionally useful). I can probably claim the same for 0^0. The fact that the standard does not take a stand leaves me a bit bewildered, but I can guess as to why. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Calc behavior: result of 0 ^ 0
Andre Fischer wrote: If the spec said that 2 is the only valid return value then we would have to return 2. But then, since we also read XLSX and the OOXML standard prescribes that 0 ^ 0 should return an error, returning an error would be the common ground here: of course we don't want to depend on the file format, so choosing something where the standards agree makes sense. (As Dennis noted, Excel returns an error indeed, but a different one than what the OOXML specification prescribes... so this seems a difficult question there too!). We should change the ODF spec first instead. A spec that basically says whatever you want to return is fine is of no value, as was proven in this thread. A specification may need to leave room for implementation-defined behavior. Look at the C or C++ standard for example. ODF is indeed not too strong (I didn't check all details, but I think it might be possible to have Calc evaluate =two+two as five -or four for that matter- and not break the ODF specification), but this doesn't necessarily mean that the standard is flawed, only that it admits implementations that differ on this detail. Regards, Andrea.
Re: Calc behavior: result of 0 ^ 0
Le 11/02/2013 05:57, Andrew Douglas Pitonyak a écrit : I usually want things to just work. If an arbitrary value is used, and it is not brought to my attention, I may not be producing the answer that I really want. Not returning an error gives me a false sense of security. That's precisely my point. As long as the software gives an answer, you can't suspect a problem somewhere. Do we want Calc to give an answer even if it's wrong and make users angry because Calc gave a wrong value? Or prevent him to spot a corner case (like #DIV/0! does)? Of course, it's much easier to say that it could break compatibility and continue to give a nice politically correct value (1). Rob, you talked about the 1900 leap year, it's exactly the same: should we continue providing a questionable value for the sake of compatibility with old files (even if there are very few of them with this situation) and compatibility with MS Office? Hagar
Re: Calc behavior: result of 0 ^ 0
Le 11/02/2013 09:13, Andre Fischer a écrit : We should change the ODF spec first instead. A spec that basically says whatever you want to return is fine is of no value, as was proven in this thread. This is something that I would only accept from a random() function. +1. That's also what has been said by other posters (with some between the lines reading). Besides, my emacs calc says that 0^0 is 1, so that can be the only correct answer, right? :-) But is there anyone with some real maths application that could check (R or Mathlab, ...)? Hagar
Re: Calc behavior: result of 0 ^ 0
On Mon, Feb 11, 2013 at 3:26 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 11/02/2013 05:57, Andrew Douglas Pitonyak a écrit : I usually want things to just work. If an arbitrary value is used, and it is not brought to my attention, I may not be producing the answer that I really want. Not returning an error gives me a false sense of security. That's precisely my point. As long as the software gives an answer, you can't suspect a problem somewhere. Do we want Calc to give an answer even if it's wrong and make users angry because Calc gave a wrong value? Or prevent him to spot a corner case (like #DIV/0! does)? Of course, it's much easier to say that it could break compatibility and continue to give a nice politically correct value (1). Rob, you talked about the 1900 leap year, it's exactly the same: should we continue providing a questionable value for the sake of compatibility with old files (even if there are very few of them with this situation) and compatibility with MS Office? But returning 1 for 0^0 is not wrong. It is not wrong mathematically. It is not wrong per the ODF 1.2 standard. -Rob Hagar
Re: Calc behavior: result of 0 ^ 0
On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 11/02/2013 09:13, Andre Fischer a écrit : We should change the ODF spec first instead. A spec that basically says whatever you want to return is fine is of no value, as was proven in this thread. This is something that I would only accept from a random() function. +1. That's also what has been said by other posters (with some between the lines reading). Besides, my emacs calc says that 0^0 is 1, so that can be the only correct answer, right? :-) But is there anyone with some real maths application that could check (R or Mathlab, ...)? Again, you are looking for the one true answer and declaring that other answers are wrong. That is not the case here. Please review this survey of the question from the sci.math FAQ on this point: Consensus has recently been built around setting the value of 0^0 = 1 http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/ Regards, -Rob Hagar
Re: Calc behavior: result of 0 ^ 0
2013/2/11 Hagar Delest hagar.del...@laposte.net Le 11/02/2013 09:13, Andre Fischer a écrit : We should change the ODF spec first instead. A spec that basically says whatever you want to return is fine is of no value, as was proven in this thread. This is something that I would only accept from a random() function. +1. That's also what has been said by other posters (with some between the lines reading). Besides, my emacs calc says that 0^0 is 1, so that can be the only correct answer, right? :-) But is there anyone with some real maths application that could check (R or Mathlab, ...)? Maxima (a computer algebra system) gives an error. FreeMat (a Matlab clone) gives 1. SciDAVis (an originLab clone) gives an error. Calligra Sheets gives 1 (but you need to insert a = before, otherwise it takes it as text) Also, remember that any change will break someone's workflow: http://xkcd.com/1172/ Regards Ricardo Hagar
Re: Calc behavior: result of 0 ^ 0
02/10/13 04:43, Guenter Marxen пишет: Hi, I've looked in Wikipedia http://en.wikipedia.org/wiki/Zero_power_zero#Zero_to_the_power_of_zero and for me it seems very reasonable to keep the old behaviour, as according to this article many math and other software treats 0^0 = 1 (see the paragraphs under Treatment on computers). According to the German wikipedia Donald Knuth refuses to define 0^0=undefined but claims = 1 because otherwise many mathematical theorema would need special case treatments. So also mathematicians define 0^0=1. So let 0^0=1 in AOO. Günter Marxen In this case the expression 0^0 could be represents like f(x)^g(x) and the limit of this expression will depends of how rapidly each of f(x) and g(x) functions tends to NULL. So evaluation of indeterminate must be made individually in every case. To resolve it needs to take logarithm of initial expression and then try to find it's limit. For example the limit of x^x while x tends to 0 will be equal 1 (if I don't make a mistake) --- Sergey Torokhov
Re: Calc behavior: result of 0 ^ 0
Le 11/02/2013 21:40, Rob Weir a écrit : Again, you are looking for the one true answer and declaring that other answers are wrong. No. Even if my personal inclination is for the undefined result, I can understand the value 1. But let the user decide and just warn him that he's facing a corner case that requests his attention. That's all. Hagar
Re: Calc behavior: result of 0 ^ 0
P.S. The over example: [1-exp(x)]/x tends to -1 while x - 0
RE: Calc behavior: result of 0 ^ 0
This is not a vote. There is a statement about what is acceptable mathematically that I cannot leave unchallenged. However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that. - Dennis MATHEMATICAL RIGHT/WRONG-NESS I'm sorry, I will not accept that 0^0 = 1 as a definition is not wrong mathematically. It is not right mathematically either. That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory. The problem with 0^0 = 1 as a rule is that it has as a consequence that 0/0 = 1 as well or else standard mathematics is inconsistent. But 0/0 = 1 (or any fixed value) makes mathematics unavoidably inconsistent anyhow (as the well-known defective proofs used to claim paradoxes like 0 = 1 and 1 = 2 demonstrate). There is no escaping the fact that x/0 needs to be undefined and that includes 0/0, so 0^0 needs to go along. Let us not confuse computational expedient or algorithmic simplicity with mathematical rigor. When a computer arithmetic had no provision for coding errors and indefinable cases, computational concessions were unavoidable (as is the case for integer types in common programming languages). That is not the case with spreadsheets, which do include error values, nor is it the case with modern floating-point arithmetic implementations (and the standards they satisfy). I understand Knuth's argument (and its form in Concrete Mathematics and in Art of Computer Programming). But adding rules to *mathematics* that make the standard model of arithmetic inconsistent is not mathematically justifiable. It is very handy, in certain contexts relying on mathematical definitions, to define the x^0 case to always be 1 regardless of x. In the case of the binomial theorem, it appears to be an appropriate simplification in providing algorithms that are easier to reason about in some respect. That context is specifically (a+b)^n by polynomial expansion and in this context the particular case of n = 0 and b = -a is perhaps not all that interesting in comparison to the serious cases. Unfortunately, the computation, POWER(x,0) has no mathematical context. It is not known what POWER(x,0) is being used for, and what the nature of x is. Although the standards for C and C++ have division by 0 to be undefined, there is not such clarity for pow(x,y). The ANSI/ISO Standards for C thought of as C90 define pow(x,y) to be a domain error if the result cannot be represented when x is zero and y is less than or equal to zero. Even so, Plauger's 1992 The Standard C Library has pow(x,0.0) return 1.0 so long as x is neither NaN nor an Inf. Harbison and Steele's C: A Reference Manual, 4th (1995) edition simply assert that pow(0.0,0.0) is a domain error. The ISO C99 specification says that a domain error *may* occur if x is xero and y is less than or equal to zero [emphasis mine]. The C++ library, for non-complex x or y, has pow(x,y) be as defined for C (without reference to any details) and math.h, at least in the 1999 book on The C++ Standard Library. By ISO C++ 2003, pow(0,0) is implementation defined. Of course none of this is about mathematics. It is about constraints on the definitions of computer software libraries and the compromises that are made in order to find agreement on standards. People vote on those. Mathematics is not defined at the ballot box (and legislation of the value of pi is not mathematics [QED]). -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, February 11, 2013 12:40 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 11/02/2013 09:13, Andre Fischer a écrit : We should change the ODF spec first instead. A spec that basically says whatever you want to return is fine is of no value, as was proven in this thread. This is something that I would only accept from a random() function. +1. That's also what has been said by other posters (with some between the lines reading). Besides, my emacs calc says that 0^0 is 1, so that can be the only correct answer, right? :-) But is there anyone with some real maths application that could check (R or Mathlab, ...)? Again, you are looking for the one true answer and declaring that other answers are wrong. That is not the case here. Please review this survey of the question from the sci.math FAQ on this point: Consensus has recently been built around setting the value of 0^0 = 1 http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/ Regards, -Rob Hagar
Re: Calc behavior: result of 0 ^ 0
On Mon, Feb 11, 2013 at 4:25 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 11/02/2013 21:40, Rob Weir a écrit : Again, you are looking for the one true answer and declaring that other answers are wrong. No. Even if my personal inclination is for the undefined result, I can understand the value 1. But let the user decide and just warn him that he's facing a corner case that requests his attention. That's all. Maybe we should have spellchecker give a error for their because it is often confused with there ? Another example: When entering a number, a percentage sign multiplies the number by 0.01. This usually works fine, e.g., 5% is automatically translated into 0.05. But if you enter =5% % it will enter the value 0.0005. My guess is this feature is more often the result of a mistake than an intentional user input. There are dozens of such weird things in spreadsheets. I could imagine a special mode for giving warnings about things like this, but in normal operations I don't think we should distract the user about things that are not errors. And I certainly don't think we should treat all of these items as errors, at least not by default. Now back to the spell checking mode. In some spell checkers they are smart enough to give an error for their. That is because they are *sensitive to the context*. They look at the context and can detect whether the word is misused in that context. I think we've all seen tools that do this. Personally, I find the, annoying since they given many false-positive error message. But treating their as an error in all cases? That is to give false-positives in almost all cases. That doesn't make sense to me. -Rob Hagar
Re: Calc behavior: result of 0 ^ 0
On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: This is not a vote. There is a statement about what is acceptable mathematically that I cannot leave unchallenged. However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that. - Dennis MATHEMATICAL RIGHT/WRONG-NESS I'm sorry, I will not accept that 0^0 = 1 as a definition is not wrong mathematically. It is not right mathematically either. That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory. The problem with 0^0 = 1 as a rule is that it has as a consequence that 0/0 = 1 as well or else standard mathematics is inconsistent. But 0/0 = 1 (or any fixed value) makes mathematics unavoidably inconsistent anyhow (as the well-known defective proofs used to claim paradoxes like 0 = 1 and 1 = 2 demonstrate). There is no escaping the fact that x/0 needs to be undefined and that includes 0/0, so 0^0 needs to go along. If OpenOffice were a theorem proving system and we put in 0^0 ==1 as an axiom, then you might have a point there. But it isn't. The only entity making logical conclusions and extrapolating to other mathematical problems from the behavior of POWER() is the user. So your concern is not really valid in this context. -Rob Let us not confuse computational expedient or algorithmic simplicity with mathematical rigor. When a computer arithmetic had no provision for coding errors and indefinable cases, computational concessions were unavoidable (as is the case for integer types in common programming languages). That is not the case with spreadsheets, which do include error values, nor is it the case with modern floating-point arithmetic implementations (and the standards they satisfy). I understand Knuth's argument (and its form in Concrete Mathematics and in Art of Computer Programming). But adding rules to *mathematics* that make the standard model of arithmetic inconsistent is not mathematically justifiable. It is very handy, in certain contexts relying on mathematical definitions, to define the x^0 case to always be 1 regardless of x. In the case of the binomial theorem, it appears to be an appropriate simplification in providing algorithms that are easier to reason about in some respect. That context is specifically (a+b)^n by polynomial expansion and in this context the particular case of n = 0 and b = -a is perhaps not all that interesting in comparison to the serious cases. Unfortunately, the computation, POWER(x,0) has no mathematical context. It is not known what POWER(x,0) is being used for, and what the nature of x is. Although the standards for C and C++ have division by 0 to be undefined, there is not such clarity for pow(x,y). The ANSI/ISO Standards for C thought of as C90 define pow(x,y) to be a domain error if the result cannot be represented when x is zero and y is less than or equal to zero. Even so, Plauger's 1992 The Standard C Library has pow(x,0.0) return 1.0 so long as x is neither NaN nor an Inf. Harbison and Steele's C: A Reference Manual, 4th (1995) edition simply assert that pow(0.0,0.0) is a domain error. The ISO C99 specification says that a domain error *may* occur if x is xero and y is less than or equal to zero [emphasis mine]. The C++ library, for non-complex x or y, has pow(x,y) be as defined for C (without reference to any details) and math.h, at least in the 1999 book on The C++ Standard Library. By ISO C++ 2003, pow(0,0) is implementation defined. Of course none of this is about mathematics. It is about constraints on the definitions of computer software libraries and the compromises that are made in order to find agreement on standards. People vote on those. Mathematics is not defined at the ballot box (and legislation of the value of pi is not mathematics [QED]). -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, February 11, 2013 12:40 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 11/02/2013 09:13, Andre Fischer a écrit : We should change the ODF spec first instead. A spec that basically says whatever you want to return is fine is of no value, as was proven in this thread. This is something that I would only accept from a random() function. +1. That's also what has been said by other posters (with some between the lines reading). Besides, my emacs calc says that 0^0 is 1, so that can be the only correct answer, right? :-) But is there anyone with some real maths application that could check (R or Mathlab, ...)? Again, you are looking for the one true answer and declaring that other
Re: Calc behavior: result of 0 ^ 0
I love it. I'd prefer a warning rather than silently giving me 1 even if I had that in the past. Another idea is to return 1, but have a popup which says: We are returning 1 to 0^0 due to backwards compatability, but we this might change in the fure. Click here to never show this warning again and continue to return 1. Also, you can use strict (or whatever) to flag these warnings as errors. Fred On Mon, Feb 11, 2013 at 3:04 PM, Dennis E. Hamilton orc...@apache.org wrote: My apologies. I replied to the wrong message, so the context was lost. I was responding to a statement that 0^0 = 1 is not wrong mathematically. I wanted to point out that is misleading, because it is also not right mathematically. POWER(x,y) implements an arithmetic function, and I agree that is not a mathematical usage. I rose to object based on this statement: But returning 1 for 0^0 is not wrong. It is not wrong mathematically. It is not wrong per the ODF 1.2 standard. (I think there are strings attached to the ODF 1.2 case and those strings need to be tied, as has already been discussed.) To make amends for the diversion, I also want to offer my +1 for the following which I did not see the first time: An interesting option would be to enable a strict or audit mode of calculation where all error-prone expressions are reported to the user. This mode would be slower than a normal calculation, but would allow us to point out things like: 1) Use of implementation-defined formulas that might impact interoperability (0^0 is one example, but there are several others) 2) Dependency on automatic string to number conversion operations that might be interpreted differently in different locales. 3) Operations that involve exact comparisons of results to constant floating numbers, something that is very risky due to round-off errors and precision limitations. 4) String operations that silently returned reasonable values despite parameters that exceeded the bounds of the string. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, February 11, 2013 14:30 To: dev@openoffice.apache.org; dennis.hamil...@acm.org Subject: Re: Calc behavior: result of 0 ^ 0 On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: This is not a vote. There is a statement about what is acceptable mathematically that I cannot leave unchallenged. However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that. - Dennis MATHEMATICAL RIGHT/WRONG-NESS I'm sorry, I will not accept that 0^0 = 1 as a definition is not wrong mathematically. It is not right mathematically either. That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory. [ ... ] If OpenOffice were a theorem proving system and we put in 0^0 ==1 as an axiom, then you might have a point there. But it isn't. The only entity making logical conclusions and extrapolating to other mathematical problems from the behavior of POWER() is the user. So your concern is not really valid in this context. -Rob [ ... ]
Re: Calc behavior: result of 0 ^ 0
Oh no, please no popup when I paste that formula into 1000 cells, I don't want 1000 popups. Sadly, I sometimes do stupid things like that when I have a warning in functions that I write myself and a debug message pops up during testing. Yeah, scary! Now, a single warning that is only ever shown once, yeah, ok, maybe. On 02/11/2013 06:45 PM, Fred Ollinger wrote: I love it. I'd prefer a warning rather than silently giving me 1 even if I had that in the past. Another idea is to return 1, but have a popup which says: We are returning 1 to 0^0 due to backwards compatability, but we this might change in the fure. Click here to never show this warning again and continue to return 1. Also, you can use strict (or whatever) to flag these warnings as errors. Fred On Mon, Feb 11, 2013 at 3:04 PM, Dennis E. Hamilton orc...@apache.org wrote: My apologies. I replied to the wrong message, so the context was lost. I was responding to a statement that 0^0 = 1 is not wrong mathematically. I wanted to point out that is misleading, because it is also not right mathematically. POWER(x,y) implements an arithmetic function, and I agree that is not a mathematical usage. I rose to object based on this statement: But returning 1 for 0^0 is not wrong. It is not wrong mathematically. It is not wrong per the ODF 1.2 standard. (I think there are strings attached to the ODF 1.2 case and those strings need to be tied, as has already been discussed.) To make amends for the diversion, I also want to offer my +1 for the following which I did not see the first time: An interesting option would be to enable a strict or audit mode of calculation where all error-prone expressions are reported to the user. This mode would be slower than a normal calculation, but would allow us to point out things like: 1) Use of implementation-defined formulas that might impact interoperability (0^0 is one example, but there are several others) 2) Dependency on automatic string to number conversion operations that might be interpreted differently in different locales. 3) Operations that involve exact comparisons of results to constant floating numbers, something that is very risky due to round-off errors and precision limitations. 4) String operations that silently returned reasonable values despite parameters that exceeded the bounds of the string. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, February 11, 2013 14:30 To: dev@openoffice.apache.org; dennis.hamil...@acm.org Subject: Re: Calc behavior: result of 0 ^ 0 On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: This is not a vote. There is a statement about what is acceptable mathematically that I cannot leave unchallenged. However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that. - Dennis MATHEMATICAL RIGHT/WRONG-NESS I'm sorry, I will not accept that 0^0 = 1 as a definition is not wrong mathematically. It is not right mathematically either. That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory. [ ... ] If OpenOffice were a theorem proving system and we put in 0^0 ==1 as an axiom, then you might have a point there. But it isn't. The only entity making logical conclusions and extrapolating to other mathematical problems from the behavior of POWER() is the user. So your concern is not really valid in this context. -Rob [ ... ] -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
