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, I don't work for Microsoft, I didn't patch Excel to change results. Pedro.
