in reply to More Fun with Zero!
0^{0}
Defining 0^{0}=1 is a good idea, because it makes the easy things easy and the hard things possible. For instance, the binomial theorem says
(a+b)^{n} = ∑_{k=0}^{n} C_{k,n} a^{k}b^{nk},
where C_{k,n}=n!/(k!(nk)!) is the binomial coefficient.
Only to you, it doesn't. Because when n=0, a=0 and b!=0, the left hand side is defined but the right hand side isn't. Of course, if you agreed that 0^{0}=1 then the right hand side would be defined and you'd have equality.
Or take the exponential function:
exp(x) = ∑_{n=0}^{∞} x^{n}/n!
(and similar expansions for sin and cos, not to mention any other Taylor expansion). This requires you to believe that 0!=0^{0}=1, or you'll have trouble reading the first term (which always uses 0!), and if x=0 you'll also have a 0^{0} there.
Or believing that a^{m+n} = a^{m}a^{n} (when a=0, m=n). It all requires you to believe that 0^{0}=1, or spend the rest of your life writing down pointless special cases.
Why is /0 an error?
So if 0^{0}=1 for convenience, why do I refuse to accept a more "convenient" behaviour of division by zero  return undef instead of an error?
Because the error is more convenient! First, note that there's no "convenient" value to return for x/0, ever. Which is why CheeseLord wants to get back the nonnumeric undef.
Which might be nice for $a=$b/$c. Except that then you have to test for defined($a) afterwards, where previously you'd test for $c==0 beforehand.
Next, there's the problem of implicit conversion of undef to 0 in numeric expressions. We certainly don't want 5+17/0 == 5 (and if you still think we do, do you also want 1/0 < 1/10?)
So we'd have to do something more clever about undef in numerical operations, say having all results undef in the presence of an undef operand. Apart from probably being slower (a wellworn excuse, and not particularly convincing by now), you still have to test your return value to see if it's undef. And you get significantly less information about the precise source of the undef (although with Perl6 attributes, perhaps you could get more information in such a case).
How does
And, of course, such "propogated undef" semantics break every existing line of Perl...
So here's a challenge for anyone (CheeseLord or otherwise) who'd like to have ! defined(x/0) in Perl, along with "propogated undef": show some code that is clearer to express with these semantics than in the present case.
Re: Re: More Fun with Zero! by CheeseLord (Deacon) on Jul 23, 2001 at 14:30 UTC 
Alert: Those who hate discussions about mathematics should skip immediately to the second section of this node. Thank you. :)
0^{0} == ??
Because when n=0, a=0 and b!=0, the left hand side is defined but the right hand side isn't.
Correct. But if a=0, what's the point of using the binomial theorem (since (a+b)^{n} = b^{n}). Likewise, if either a or b equal 0, the binomial theorem is a waste of energy. It makes sense to use a special case there, IMO.
As far as your remarks go on the Taylor expansions, I can't say my Calculus is as strong as it should be, and considering that you've said you're a mathematican, I'll accept that you know much more about this and very likely are correct.
But I do have to disagree with your comment about pointless special cases... Special cases have that name because that's what they are  occurrances that deserve special attention to be paid to them. In many cases, though, it has been dealt with by deciding that 0! = 1, or that x^{0} = 1, which I'm fine with. As far as 0^{0} goes, I don't really know what it should be. That's why I posted this. :) But without special cases, I can easily make the entire imaginary number system useless in about twenty seconds by proving that i = 1. Because sqrt(ab) == sqrt(a) * sqrt(b) only when both numbers are rational real, though, my plot to destroy mathematics has been foiled  for now, anyway. ;)
"if defined ($x / 0) ..."
...there's the problem of implicit conversion of undef to 0 in numeric expressions.
This problem doesn't exist now because the program will die if the exception isn't trapped. But note that this error will be noted if the script is coded with w on. In addition, this error will likely never occur if the programmer thinks ahead and does the c == 0 test you describe. My point is that Perl's watching out for a me a little more than I'd like it to.
I can give you an analogy... if you've ever used Java, you likely know the difference between an Exception and a RuntimeException  not catching the possibility of the former is a compiletime error, while checks for the latter can be omitted (after all, nobody wants to check for ArrayIndexOutOfBoundsException every time they access an array), but will still cause program termination if thrown. As I see it, dying on division by zero is like Java's forcing of checking for IOException whenever dealing with files. I like the fact that Perl gives me the option on an open call to check the return value. Sure, it may not promote great code, and I certainly won't do it when writing anything worthwhile, but I want to be free when writing my quick 3minute script to rename a bunch of files to not put or die "$!" after I open a file, dammit!! :)
And that's my complaint with the error for dividing by zero  Perl is pretty nice about not dying on most things, and right now, I don't understand why it's necessary to make it a fatal error. As it stands, changing the result of a division by zero to undef will not break any code that isn't already inherently broken (AFAIK). And it might allow me to get away with output like this (although, only without w):
Your average is:
Which, to me, anyway, is nicer than saying that my average is zero when I don't have any entries. :) Once again, though, it's just my opinion.
Update: Corrected idiotic mistake in terminology ("rational" v. "real").
His Royal Cheeziness  [reply] [d/l] 

