Alert: Those who hate discussions about mathematics should skip immediately to the second section of this node. Thank you. :-)

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)ⁿ = bⁿ). 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⁰ = 1, which I'm fine with. As far as 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 compile-time 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 3-minute 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:
[download]

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