Question on valid transformations for cbrt

Question on valid transformations for cbrt

[Kaveh R. Ghazi]

I'm in the process of writing some transformations for builtin cbrt.
However it occurs to me that certain combinations might be invalid
when converting to pow, because pow doesn't like negative values with
non-integral powers.  E.g.:

	cbrt(sqrt(x)) -> pow(x, 1/6)

can be considered "safe" with -ffast-math IMO because if x was
negative the original sqrt would have choked anyway.  However here:

	cbrt(pow(x,y)) -> pow(x,y/3)

if x is negative and y is say 5, the first form would succeed but the
second would get an error EDOM because 5/3 is non-integral.  So I
don't think the latter is a valid transformation even with
-ffast-math.

(Perhaps the latter is okay if x passes tree_expr_nonnegative_p, but
that might not be worth it.)

Thoughts?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Question on valid transformations for cbrt

[Roger Sayle]

On Sat, 6 Mar 2004, Kaveh R. Ghazi wrote:
> I'm in the process of writing some transformations for builtin cbrt.
> However it occurs to me that certain combinations might be invalid
> when converting to pow, because pow doesn't like negative values with
> non-integral powers.  E.g.:
>
> 	cbrt(sqrt(x)) -> pow(x, 1/6)
>
> can be considered "safe" with -ffast-math IMO because if x was
> negative the original sqrt would have choked anyway.  However here:
>
> 	cbrt(pow(x,y)) -> pow(x,y/3)
>
> if x is negative and y is say 5, the first form would succeed but the
> second would get an error EDOM because 5/3 is non-integral.  So I
> don't think the latter is a valid transformation even with
> -ffast-math.
>
> (Perhaps the latter is okay if x passes tree_expr_nonnegative_p, but
> that might not be worth it.)
>
> Thoughts?

I think you're right, and we can't in general simplify cbrt(pow(x,y))
even with -ffast-math.  I've had to give some thought to GCC's existing
sqrt(pow(x,y)) to see whether we need to disable that.  However I've
conviced myself that its safe with -ffast-math.  If x is negative,
y must be an integer to satisfy pow, and then must be an even integer
to satisfy sqrt.  Hence our existing transform is safe.

The problem with cbrt, unlike sqrt, is that its is more expressive than
pow.  i.e. cbrt(-29.7) = -3.1 but pow(-29.7,1.0/3.0) => EDOM.  Hence
we can't normalize cbrt(x) as pow(x,1.0/3.0), but we can safely go the
other way pow(x,1.0/3.0) => cbrt(x).

Roger
--

Re: Question on valid transformations for cbrt

[Segher Boessenkool]

> The problem with cbrt, unlike sqrt, is that its is more expressive than
> pow.  i.e. cbrt(-29.7) = -3.1 but pow(-29.7,1.0/3.0) => EDOM.  Hence
> we can't normalize cbrt(x) as pow(x,1.0/3.0),

You can "normalize" cbrt(x) as  sign(x) * pow(abs(x), 1.0/3)  -- maybe 
that
helps some further optimizations?

> but we can safely go the
> other way pow(x,1.0/3.0) => cbrt(x).


Segher

Re: Question on valid transformations for cbrt

[Robert Dewar]

Segher Boessenkool wrote:

>> The problem with cbrt, unlike sqrt, is that its is more expressive than
>> pow.  i.e. cbrt(-29.7) = -3.1 but pow(-29.7,1.0/3.0) => EDOM.  Hence
>> we can't normalize cbrt(x) as pow(x,1.0/3.0),
> 
> 
> You can "normalize" cbrt(x) as  sign(x) * pow(abs(x), 1.0/3)  -- maybe that
> helps some further optimizations?

Of course both these transformations are numerically horrible. I trust 
that this is understood.

>> but we can safely go the
>> other way pow(x,1.0/3.0) => cbrt(x).

Well I don't like transformations like this which change the computation
so radically and give completely different results. This is not real
arithmetic, and the compiler really has no business making 
substituations that are not meaning preserving.

Re: Question on valid transformations for cbrt

[Geoff Keating]

Roger Sayle <roger@eyesopen.com> writes:

> i.e. cbrt(-29.7) = -3.1 but pow(-29.7,1.0/3.0) => EDOM.

one reason for this is because 1.0 / 3.0, as a double, gets rounded to
6004799503160661 / 2 ^ 54, and so the result of the pow() is imaginary
and not representable as a 'double'.  (If we'd used base-3 arithmetic,
pow() could always provide a result with negative inputs.)

(This also means the same transformations with sqrt() will usually be
safe.)

-- 
- Geoffrey Keating <geoffk@geoffk.org>