openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject OT: Calc behavior: result of 0 ^ 0
Date Tue, 12 Feb 2013 17:36:45 GMT
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 [] 
Sent: Monday, February 11, 2013 14:24
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

 - Dennis


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

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]).

[ ... ]

View raw message