Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
From: TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
Newsgroups: comp.lang.c
Subject: Re: power operator
Message-ID: <11235@brl-adm.ARPA>
Date: 13 Jan 88 05:03:29 GMT
Sender: news@brl-adm.ARPA
Lines: 54

COM%"ericb@athertn.Atherton.COM" writes:
>In article <3812@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>>I guess most people who are talking about problems with pow()
>>can't think like a (draft proposed) ANSI C compiler.
>>
>>Suppose you have a dumb math library.  In <math.h> you put a declaration like:
>>
>>    double pow(double, double);
>>[...]
>>Now suppose that you have a smart compiler and math library.  In
>><math.h> you do:
>>
>>    #define    pow    _compiler_pow
>>
>>where _compiler_pow is recognized as a keyword by the compiler.
>>[...]
>>Does *anybody* have a problem with this???
>
>Seems to work as far as it goes...
>Your solution still requires the arguments to first be promoted to double,
>and the return result converted from double to whatever.  I have done
>graphics and number crunching where that conversion both ways is
>not desired (float precision is adequate) and it takes an unacceptable
>performance hit.
>[ some stuff deleted here ]
>Now, in the first instance above, it is clear that the arguments MUST
>be converted to double.  In the second (the builtin), I suppose the
>compiler could somehow be told (a #pragma?) not to do that, but
>that's really wierd and unexpected behavior.

John described something important here.  He showed how USING THE CURRENT
ANSI DRAFT SPECS an implementor could offer a more optimized power
operator.  It is important to remember that the implementor can do this
for many things like this.

No, it would not take a pragma.  In the first instance above, yes, things
will be promoted to doubles.  In the second, the compiler could decide
what to do (inline the best code or call the proper function).

When ANSI is accepted, syntax ambiguities and library incompleteness will
not be factors.  This will allow vendors to specialize and make compilers
that are particularly fast (for prototypeing code), that generate
particularly fast code, that do extra good jobs with math, or who knows
what.

Obviously, if you are doing math programming, you'd pick a compiler that
specializes in good math (they'd do what John suggests for pow(), etc).

Personally, I will be going for the compiler with the best debugger  :-)

                             Tom Limoncelli
  Drew U/Box 1060/Madison NJ 07940     Bitnet: tlimonce@drew.BITNET
  Disclaimer: These are my views, not my employer or Drew Univesity.
--------------------------------------------------------------------------