LPow correction

[Doug Gwyn]

In article <3055 at utcsri.UUCP> greg at utcsri.UUCP (Gregory Smith) shows that
	limit as (x,y)->(0,0) of x^y
is path-dependent, which is quite correct and no news at all to anyone
who has studied complex analysis.  The reason I selected 1 as the return
value for 0^0 rather than my initially-coded 0 is that almost all (in a
technical sense) paths yield that value for the limit of x^y.  Of course,
0^0 really is not well-defined; I just wanted to return the most generally
useful value for that case, since I was explicitly not coding in any error
handling.  0^0 "=" 1 turns out to be much more useful in computation than
0^0 "=" 0; neither one is really "right".

My general philosophy about such things as 1/0, 0^0, atan2(0.,0.), etc.
is that the application programmer should never allow such situations to
occur in the first place, since they're obviously illegal, improper, ill-
defined, or whatever.  However, when implementing a general function that
may be used by careless programmers, a decision has to be made about how
to cope with such abuse.  For LPow(), I decided to always do something
sane, quietly, since this was intended as an example of how to obtain
run-time integer exponentiation without embedding it in the language.
Another good solution for math library functions in general is to trigger
matherr() or some similar error handling and recovery scheme.

In summary:  When writing code for general use, watch for abuse and
do SOMEthing deliberate (and relatively sensible) when it occurs.
When writing applications, never try to do anything ill-defined.