Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: net.lang.c Subject: Re: LPow correction Message-ID: <1880@brl-smoke.ARPA> Date: Tue, 1-Jul-86 19:07:04 EDT Article-I.D.: brl-smok.1880 Posted: Tue Jul 1 19:07:04 1986 Date-Received: Thu, 3-Jul-86 07:35:21 EDT References: <1809@brl-smoke.ARPA> <3055@utcsri.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Followup-To: net.math Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 25 In article <3055@utcsri.UUCP> greg@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.