Author 
Message 
Ken Iverso #1 / 18

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 


Jefflead #2 / 18

Zero to the power zero
Please, no! This thread preiodically eats up sci.math (see their FAQ)...don't let it start here...

Wed, 30 Sep 1998 03:00:00 GMT 


Murray Eisenbe #3 / 18

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: 4135452859 (W) University of Massachusetts 4135491020 (H) Amherst, MA 01003 Fax: 413545180

Thu, 01 Oct 1998 03:00:00 GMT 


Mike Ken #4 / 18

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 


Mike Ken #5 / 18

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 question about indeterminates. 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 nonzero 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 nonzero 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 instead. 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 infinitedimensional 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 


John E. Howla #6 / 18

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) 7367480 715 Stadium Drive fax: (210) 7367477 San Antonio, Texas 782127200

Fri, 02 Oct 1998 03:00:00 GMT 


Reiter Clifford #7 / 18

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 : question about indeterminates. : : 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, 6102505277

Fri, 02 Oct 1998 03:00:00 GMT 


Harvey Davie #8 / 18

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 subdomain? In the case of 0^0, 1 is the limit from all directions except along the yaxis. 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) 4978661 P.O. Box 3000 Fax: (303) 4978690 Boulder, CO 803073000 http://www.unidata.ucar.edu/

Fri, 02 Oct 1998 03:00:00 GMT 


Raul Mill #9 / 18

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 


Raul Mill #10 / 18

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 


Harvey Davie #11 / 18

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 subarguments: (i) Result as in 1. If empty then raise error (ii) Error message (if nonempty). E.g. 0 ^ :: (a: ; 'Error in power (^)') 0 would abort with message 'Error in power (^)'
UCAR/Unidata Program Center Phone: (303) 4978661 P.O. Box 3000 Fax: (303) 4978690 Boulder, CO 803073000 http://www.unidata.ucar.edu/

Sat, 03 Oct 1998 03:00:00 GMT 


Page 1 of 2

[ 18 post ] 

Go to page:
[1]
[2] 
