float to float exponent, was: Problem with plotting function defined condionally

On Sat, Jun 7, 2008 at 8:31 PM, Robert Dodier <robert.dodier at gmail.com> wrote:
>>  croot(x) := if x>0 then x^(0.3333333333333333) else
>>  -(-x)^(0.3333333333333333) $
>
> I'm glad that you found something which works, although it is
> discouraging that you had to resort to such a non-obvious tactic.

Agreed.

> After thinking about this some more, I think this is the origin of the problem:
>
> (<negative literal float>)^(1/3) => <negative literal float>
> (<negative literal float>)^float(1/3) => (<negative literal float>)^.3333333333333333

Yes, this causes the problem, but the *ultimate* cause is that
x^(1/3),numer => x^.333, a transformation which takes a well-defined
expression and converts it to an ill-defined one.

We know that (-1)^(a/b) = (-1)^a when b is odd (in the reals -- this
isn't the principal value in the complexes).  The rational 1/3 has an
odd denominator, but when we convert it to a float, we have a problem:
treated as exact numbers (rationalize), the denominators of *all*
floats are even since they are of the form k*2^i; treated as
approximate numbers or intervals, their denominators' oddness is
undefined.

So perhaps x^(1/3),numer should remain x^(1/3) just as x^3,numer
remains x^3 and does not become x^3.0.

> Maybe there should be a symbolic cube root function, just as there is a symbolic square root function, which would not be susceptible to float?

Maxima does not really have a symbolic square root function -- sqrt(x)
immediately simplifies to x^(1/2). The current simpsqrt does invoke
flonum-eval directly if the argument is a literal float, but that is
problematic.  (To be continued in a separate email, because it's
really a separate topic.)

             -s