On 12/4/06, Howard Hinnant <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
> On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
>> Richard,
>>
>> Somewhere, in a mail lost in my large e-mail clash with my ISP
>> (verizon), you said that gfortran couldn't profit from the pow(x,
>> 1./3.)
>> -> cbrt(x) conversion because gfortran didn't "know" of cbrt.
>>
>> Could you be more explicit about this - I'd like to repair this
>> deficiency, if at all possible.
>>
>> Thanks in advance !
>
> It's a matter of making the cbrt builtin available - I have a patch
> for this,
> but wondered if the fortran frontend can rely on the cbrt library
> call being
> available? Or available in a fast variant, not a fallback
> implementation in
> libgfortran which does pow (x, 1./3.) which will then of course
> pessimize
> pow (x, 2./3.) -> tmp = cbrt(x); tmp * tmp expansion.
Is pow(x, 1./3.) == cbrt(x) ?
My handheld calculator says (imagining a 3 decimal digit machine):
pow(64.0, .333) == 3.99
In other words, can pow assume that if it sees .333, that the client
actually meant the non-representable 1/3? Or must pow assume that .
333 means .333?
It certainly will _not_ recognize 0.333 as 1/3 (or 0.333333 as used in
Polyhedron aermod). Instead it will require the exponent to be
exactly equal to the result of 1./3. in the precision of the exponent,
with correct rounding.
My inclination is that if pow(x, 1./3.) (computed
correctly to the last bit) ever differs from cbrt(x) (computed
correctly to the last bit) then this substitution should not be done.
C99 7.12.7.1 says "The cbrt functions compute the real cube root
of x." and "The cbrt functions return x**1/3". So it looks to me
that cbrt is required to return the same as pow(x, 1/3).
Richard.
