Zero to the power zero
Author Message Zero to the power zero

Since the value assigned to the indeterminate case 0 to the power
0 in APL systems has always been 1, and since this differs from
other systems (such as Mathematica, which treats it as undefined),
a discussion of it might be of interest to this group. I would
welcome such discussion, including proofs of any assertions made.

Wed, 30 Sep 1998 03:00:00 GMT  Zero to the power zero
their FAQ)...don't let it start here...

Wed, 30 Sep 1998 03:00:00 GMT  Zero to the power zero
: Since the value assigned to the indeterminate case 0 to the power
: 0 in APL systems has always been 1, and since this differs from
: other systems (such as Mathematica, which treats it as undefined),
: a discussion of it might be of interest to this group. I would
: welcome such discussion, including proofs of any assertions made.
:
Here's one thought about why Mathematica deliberately leaves 0^0 as
undefined:  Mathematica has a primitive Limit function.  Having
defined a function f, using the command

Limit[f[x], x -> a]

calculates -- or puports to calculate -- the indicated limit.  What I
don't know, and do not recall having seen documented, is what
Mathematica actually does to find this limit.  Clearly for continuous
functions it can simply substitute a for x.  But it will also find,
e.g.,  the limit of x^x or of Sin[x]/x as x -> 0.

My wild speculation is that it would be dangerous to define 0^0 to be
1 since a "0^0" form f[x]^g[x] of course need not have limit 1 as x ->
0.

With a language such as J, which does not have explicit "symbolic"
capabilities like Mathematica's, the definition 0^0 perhaps has no
such danger.  (I say "perhaps" because one can attempt to determine
the limit of a function raised to a function power by numerical
experimentation, but then values of the argument too close to  0 could
get truncated and lead to a spurious limiting value.)

--

Mathematics & Statistics Dept.            Voice:  413-545-2859 (W)
University of Massachusetts                       413-549-1020 (H)
Amherst, MA 01003                           Fax:  413-545-180

Thu, 01 Oct 1998 03:00:00 GMT  Zero to the power zero
In my opinion, there is only one reasonable way to handle
indeterminates:  raise a DOMAIN ERROR.

--

Thu, 01 Oct 1998 03:00:00 GMT  Zero to the power zero

Quote:

> Since the value assigned to the indeterminate case 0 to the power
> 0 in APL systems has always been 1, and since this differs from
> other systems (such as Mathematica, which treats it as undefined),
> a discussion of it might be of interest to this group. I would
> welcome such discussion, including proofs of any assertions made.

I'm not going to make any provable (or disprovable) assertions ...

I suppose I should expand a little on my earlier response to Ken's

First let's consider an easy case, 0%0.  J gives 0 for this; APL
systems give 1.  Both answers are "reasonable" and that in itself
is enough (IMO) to show that neither answer is right.  The APL
answer proceeds from looking at the function f(x) given by x%x; the
J answer proceeds (I am guessing) from looking at the function f(x)
given as 0%x.  In both cases the answer supplied is the one that is
given by all non-zero values for x, and therefore is the limit as
x -> 0 of f(x); that is, it is the (unique) value which makes f(x)
continuous when x is 0.  But now consider f(x) given as (k*x)%x for
some constant k.  The value is k for all nonzero x, and so ANY
answer is "as good as" 0 or 1.

The case Ken raised, 0 ^ 0, is not very different.  For negative real
numbers x, 0 ^ x gives _; for positive real x, 0 ^ x gives 0.  For
(so 0 ^ x has NO continuous extension at x = 0).  For various
constant complex k and variable real x, 0 ^ k * x gives various
answers as x -> 0; for x positve, k = 1j1, the result is 1, for
instance.  Now if we look at x ^ 0, we do get 1 for all non-zero
values of x.  But ^ is a dyad.  And what we see is that the value
of (f x) ^ (g x) as x -> 0, in the case where f, g are [continuous,
differentiable, analytic] and f(0) = 0 = g(0) does not depend on the
limits alone, but on the specific behavior of the functions f, g
"near" zero.

[ FWIW, I'm a little nonplussed by the decision to include the
signed infinities in a system that supports complex numbers. ]

This kind of behavior is exactly what is meant by "indeterminate".

Deciding what the value of an indeterminate "should" be is always
a matter of judgment and taste, or perhaps of the particular
problembeing considered, and any value selected will be wrong
in some cases.  FOR THIS REASON, I believe that the "best" answer
is the simplest:  don't give ANY answer, but raise DOMAIN ERROR

Now if there is some sense in which there is a single answer which
is right in "almost all" cases (where "almost all" might mean except
on a finite set, or except on a discrete set, or except on a set
of measure zero, or even except on a set which is "negligible" in
some topological sense -- dimension for instance), I could see where
a good argument could be made for extending the function to have
the distinguished value even in those cases.  But I am not competent
to construct the infinite-dimensional function and path spaces where
such an analysis can be made; I would suggest asking these sorts of
questions in sci.math.research, and getting answers from people well-
qualified in functional analysis might be a good starting point.

// Mike Kent

Fri, 02 Oct 1998 03:00:00 GMT  Zero to the power zero

Quote:

> In my opinion, there is only one reasonable way to handle
> indeterminates:  raise a DOMAIN ERROR.

Inexact IEEE arithmetic has an indeterminate value as does J.

Quote:
> --

--
________________________________________________________________
John E. Howland        url: http://www.cs.trinity.edu/~jhowland/

Trinity University   voice: (210) 736-7480
715 Stadium Drive      fax: (210) 736-7477
San Antonio, Texas  78212-7200

Fri, 02 Oct 1998 03:00:00 GMT  Zero to the power zero
: >
: > Since the value assigned to the indeterminate case 0 to the power
: > 0 in APL systems has always been 1, and since this differs from
: > other systems (such as Mathematica, which treats it as undefined),
: > a discussion of it might be of interest to this group. I would
: > welcome such discussion, including proofs of any assertions made.
:
: I'm not going to make any provable (or disprovable) assertions ...
:
: I suppose I should expand a little on my earlier response to Ken's
:
: First let's consider an easy case, 0%0.  J gives 0 for this; APL
: systems give 1.  Both answers are "reasonable" and that in itself
: is enough (IMO) to show that neither answer is right.  The APL

Obviously these choices cause problems whatever you choose - including
domain errors.  I really like 1 = 0^0 as I'll explain and have even
found 0=0%0 useful though I would probably have gone for -..

I have found 0^0 being 1 very convenient for computing Vandermonde
matrices.  Suppose you want the coefficients to the polynomial of
degree k through the points (0,1), (1,2) , (2,1), (3,2), ... (k,1 or 2
depending on parity).  That is, the x points are x=.i.k+1 and the
y points are (k+1)\$1 2.  This is trivial in J or APL:
]x=.i.1+k=.5
0 1 2 3 4 5
]y=.(k+1)\$1 2
1 2 1 2 1 2
]c=.y %. x ^/ i.#x  NB. find the coeffecients
1 8.53333 _13.3333 7.33333 _1.66667 0.1333333
pv=.(#.|.)~"1 0   NB. polynomial evaluator
c pv x            NB. check answers
1 2 1 2 1 2

I find the choice of 0^0 as indeterminant as
very inconvenient for teaching interpolation
to undergraduates using Mathematica.  J is no problem.  Also, when
diagonalizing a matrix and applying it to formally computing matrix
powers using A^k = C D^k C^(-1) the whole point is that a matrix
power can be replaced by a scalar power D^k.  In Mathematica that
introduces a bunch of 0^0's that cause aggrevations.  I use MMA for
teaching this since J doesn't have c. implemented yet I think :(.

Lastly,
this is the one time I've been happy with 0=0%0 :
It gives a nice result for the unit vector associated with the
zero vector using a natural definition of unit vector.

unit=.% +/&.*:
unit 1 1
0.7071068 0.7071068
unit 1 1 0 1 0 1
0.5 0.5 0 0.5 0 0.5
unit 0 0 0
0 0 0

Cliff
--
Clifford A. Reiter
Mathematics Department, Lafayette College
Easton, PA 18042 USA,   610-250-5277

Fri, 02 Oct 1998 03:00:00 GMT  Zero to the power zero

Quote:

> Since the value assigned to the indeterminate case 0 to the power
> 0 in APL systems has always been 1, and since this differs from
> other systems (such as Mathematica, which treats it as undefined),
> a discussion of it might be of interest to this group. I would
> welcome such discussion, including proofs of any assertions made.

I gave a paper at APL95 on infinity arithmetic which discussed such
things as 0^0 and 0%0. I did promise Ken I would make some concrete
proposals on what should be done in J. I have not got around to this
until now, so here are some more comments and alternative proposals.

Most modern machines have IEEE floating point which includes a
representation for indeterminate which I will denote by '_.' as in J.

From a strictly mathematical viewpoint 0%0 and 0^0 are indeterminate
as there is no fixed limit as you approach the point (0,0) from all
possible directions. This is certainly an argument for choosing _. as
the result. However computing is a practical craft which involves more
than pure maths theorems.

Some relevant issues are:
1. Can wrong results be produced without user realising?
If so, how likely is this in practice?
E.g. I was embarrassed by producing wrong results from J without
realizing it.  A user questioned my results which turned out to
have involved means of empty arrays. I would like this to have
produced some obviously special result like '_.'.
2. How difficult is it to program common tasks? Is there a need to
consider special cases?
E.g. An obvious way to evaluate a polynomial is:
+/ C * x ^ i. # C
but this only works if 0^0 is 1.
3. Does a limit exist over a reasonable sub-domain? In the case of 0^0,
1 is the limit from all directions except along the y-axis.
But in the case of 0%0 every direction has a different limit!

So if I had to choose one fixed result for 0%0 it would have to be
indeterminate (_.).  For 0^0 I would choose 1, but with some mixed
feelings (that it too should be _.).

This would be practical if there was an easy way of testing for '_.'.
But as I pointed out in my APL95 paper, J
does some strange things with '_.' and it is hard to test whether a
value is '_.'.  It would be much simpler if the following were true (1):
_. = _.
But the IEEE f.p. standard does not help here - it states this should be
false and proposes a test for NAN (_.) equivalent to
-: &
since NAN and NAN alone is unequal to itself!

But does there have to be one fixed result?  I now think the best
solution is to provide an easy way of setting the desired result in
indeterminate situations. So, if one wants 0^0 to be 1, there should be
an easy way of doing it.

One possibility would be to use fit (!.) to specify the result of
special cases.  e.g. '% !. 1' could specify that 0%0 should be 1.  But
what about  1%0 _%_  _.%y etc.?  If you can control one, why
not the others?  You really need to specify a little 4x4 division table
for all the special numbers (0 _. _ __)!  And it would be nice to have
some way of specifying a 'result' of 'domain error' if this was not
the default.

Of course you could have system parameters controlled by 'foreign' (!:),
but this is inelegant.  However J already several of these such as
the default number of digits for format, so there are precedents.

The J 'adverse' conjunction (::) provides another possible solution.

If 0^0 generated a domain error then you could still program the above
polynomial evaluation as:
+/ C * x ^ :: 1: i. # C
I think this small increase in programming efffort would be a small
price to pay for safety.

If 0%0 generated a domain error then you could
generate an _. in calculating the mean of an empty array by:
+/ % :: (_. " 0) #
If you wanted 0 as the result it is even easier:
+/ % :: 0: #
whereas at the moment to generate _. you do something like:

which is a lot of work to get a little safety!
People will use safety equipment if it is easy to do so, but not if
it takes a lot of effort!

So I propose the following:
1. Arithmetic verbs (e.g. + - * % ^ ^.) should normally generate _.
for all  inderminate forms e.g. 0%0  0^0  _-_
2. Infinity arithmetic should be fully supported, including such
things as  _. = _.  which I suggest should give 1.
3. The adverse conjunction (::) should define a verb which is more
'error prone' than the left argument raw verb itself.
E.g. (0^::v 0)  should be (0 v 0) because with an arithmetic verb u,
any indeterminate form should generate an error and trap to verb v,
i.e. not behave as in 1.  This allows simple error handling as
discussed above.

UCAR/Unidata Program Center                  Phone: (303) 497-8661
P.O. Box 3000                                Fax:   (303) 497-8690
Boulder, CO  80307-3000
http://www.unidata.ucar.edu/

Fri, 02 Oct 1998 03:00:00 GMT  Zero to the power zero
Mike Kent:
This kind of behavior is exactly what is meant by "indeterminate".

Clifford A Reiter:
Obviously these choices cause problems whatever you choose -
including domain errors.  I really like 1 = 0^0 as I'll explain and
have even found 0=0%0 useful though I would probably have gone for
-..

It's perfectly reasonable to define 0^0 as indeterminate.  It's
perfectly reasonable to use an ammended variant of ^ where 0^0 is 1.

I think this issue would be best most cleanly by the K language -- it
treats functions of n arguments as n dimensional arrays, and indexed
assignment is defined to work on functions.  [Note: I'm talking about
the language as a *language* here.  I have little knowledge of the
implementation.]

I think the best J could do is provide some facility analogous to
adverse.  Here, some alternate function would be provided to resolve
cases which are indeterminate [provided 0^0 was made indeterminate].
Alternatively, J could also define a conjunction like } which lets
specific argument values to a function get altenate results.
Essentially, J's syntax make this kind of thing require some extra
verbiage.

APL could have its indexed assignment extended to allow function names
on the left side of the brackets, but I think that before allowing
indexed assignment to functions you'd want to deal with assignment of
functions to names.  I don't know enough about Dyalog (which allows
this) to know how well it fits into their model.

--
Raul

Sat, 03 Oct 1998 03:00:00 GMT  Zero to the power zero
Mike Kent:
[ FWIW, I'm a little nonplussed by the decision to include the
signed infinities in a system that supports complex numbers. ]

I agree with Mike on this one.

It's sometimes disappointing that there's no support for complex
infinities at any angle.  Of course this leads into some related
issues having to do with precision and the representation of numbers.

Personally, I miss [fast, efficient] arbitrary precision integers
more.  (Then again, these things are so valuable that some
applications dealing with them are export restricted in the US, so
maybe this is a reason to leave them out.)

--
Raul

Sat, 03 Oct 1998 03:00:00 GMT  Zero to the power zero
Further to my posting yesterday (15 April):

1st there was an error in that posting:

Quote:
> false and proposes a test for NAN (_.) equivalent to
> -: &
> since NAN and NAN alone is unequal to itself!

This should be '-: ~'  not  '-:  &'

It would be possible to have different error behavior modes set
by 'foreign' (!:).  For example:
1. Current behaviour with such things as 0^0 giving 1
2. Domain error for indeterminate forms (e.g. 0^0). Allow _ but not _.
3. Do not allow _ or '_.'.  Domain error for any x%0, etc.
4. Full infinity arithmetic with result of _. for 0^0 and 0%0, _ for 1%0

I do not like modes and system parameters, but I think this is at least
worth considering.  It does provide backward compatibility.

Which reminds me of the following joke Ken Iverson told during his
talk in Melbourne in 1994:

"The reason it took only 6 days for God to create the world was that
he had no installed user base and thus did not have to provide
backward compatibility!"

My posting yesterday pointed out that the adverse conjunction (::)
already provides a convenient way of handling errors.  What limits
its use is that important conditions that you might want to handle
(e.g. 0^0) are not currently errors.  I pointed out that there is no
reason why more things could not be considered errors by the verb
defined by :: than by the left argument verb itself.

E.g. 0^0 could remain 1, but
0 ^ :: v 0
could raise an internal error condition and trap to v giving the result:
0 v 0

Such use of :: would be even more convenient if the right argument
could be a noun (n).  So instead of:
% :: (_. " 0)
one could use:
% :: _.

I suggest the following:
1. If n is open then treat as (n " u)
2. Also allow boxed list defining two sub-arguments:
(i)  Result as in 1. If empty then raise error
(ii) Error message (if non-empty).
E.g.
0 ^ :: (a: ; 'Error in power (^)') 0
would abort with message 'Error in power (^)'

UCAR/Unidata Program Center                  Phone: (303) 497-8661
P.O. Box 3000                                Fax:   (303) 497-8690
Boulder, CO  80307-3000
http://www.unidata.ucar.edu/

Sat, 03 Oct 1998 03:00:00 GMT

 Page 1 of 2 [ 18 post ] Go to page:  

Relevant Pages