Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: net.lang.c Subject: Re: C vs. FORTRAN (was: What should be added to C) Message-ID: <1356@brl-smoke.ARPA> Date: Sun, 15-Jun-86 01:59:12 EDT Article-I.D.: brl-smok.1356 Posted: Sun Jun 15 01:59:12 1986 Date-Received: Sat, 21-Jun-86 07:38:43 EDT References: <1253@brl-smoke.ARPA> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 19 In article <1253@brl-smoke.ARPA> rgh%inmet.uucp@BRL.Arpa writes: -GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV -From: Root Boy Jim -Doug, I am surprised that you ignored DMR's rationale for not putting -exponentiation into C, or were you merely requesting a library function. -Yes, I know you didn't write this but I'm responding to you here anyway. What in the world does the last sentence mean?? And who wrote it??? This has passed over the borderline separating reality from fantasy.. In any case, the reason for not including exponentiation in the language directly is that it would obscure the otherwise evident fact that this is an expensive operation. There is nothing preventing an implementor from recognizing lpow(a,b) (or, better, _lpow(a,b)) as a special case and generating in-line code if he has hardware that directly implements integer exponentiation. I don't know of any machines like that, though. The implementor should of course also provide a portable C source for lpow()/_lpow() so that applications can be ported to other machines. I hope to get around to writing and posting a portable lpow() soon.