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