openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Calc behavior: result of 0 ^ 0
Date Mon, 11 Feb 2013 22:30:16 GMT
On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
<dennis.hamilton@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:robweir@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.delest@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
>

Mime
View raw message