Saf- err, you might want to reconsider those basics again. 0
n = 0, not 1. At least for all n > 0. For all n < 0, it's infinite, as is 1/0. And consider n
0 = 1 - at least, for all n other than 0. The problem is that there are several possible "obvious" values for 0
0, and they conflict. Thus, it's reasonable to call the value undefined.
Jim- in general, I'd agree - it would make more sense to throw an exception here. But the design
philosophy of
Java floating -point arithmetic seems to be to avoid throwing exceptions whenever possible - e.g. dividing by zero returns Double.POSITIVE_INFINITY (even though the sign should really be unspecified here). My guess is that whoever wrote the function considered 1 to be the most-likely-expected value for most users - perhaps there is some IEEE standard, or a standard C library that leads people to expect this behavior? Whatever - at least the behavior is documented in the API. I guess it's up to users to make their own decisions about what behavior is appropriate for their own applications, and cover the special cases with hand-coded if-then statements if they don't like the library bahavior.
[This message has been edited by Jim Yingst (edited July 06, 2001).]