I want to circle back and complete the relationship, if any, between the specifications of computations procedures and mathematics.
First, there is no prohibition between defining any number of algorithms as computations on computer-representations of numbers. Mathematics allows all sort of functions, including ones that rules can't be written down for. And computational algorithms are some of those that do have written-down rules that can be followed by a computer. The problem that is being seen here is what happens when (1) mathematically-defined functions are appealed to as the ideal that the computed procedure is intended to approach in some agreeable degree of approximation. This shows up in the description that is provided and in the notation and names that are used. When the computational functions are casually identified with mathematical ones and nothing more is said, what's left hanging are two things: (1) anything about *mathematical* edge cases and places where the mathematical function is undefined, and (2) difficulties where limitations of the computer representation of arithmetic prevent a result with some expected degree of reliability. (1) can be finessed by providing computationally-convenient results for edge cases, and a mathematically-precise definition can be provided in definition for the resulting modification. If a standard dictates such a definition, so be it. The POWER(x,y) computational function specified for OpenFormula is not the mathematical one anyhow. It is an approximation (sometimes quite good) for some limited cases of the mathematically-allowed (x,y). It can be defined to be a (limited) variant covering places where mathematics has nothing to offer, so long as there is agreement on what the variant is. - Dennis -----Original Message----- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Monday, February 11, 2013 14:24 To: dev@openoffice.apache.org Subject: 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]). [ ... ]
