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
