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
