I haven't looked at the examples in detail, and I'm not sure this is the
right explanation, but
computing a floating-point value for 123^(1/3) "from the bottom up"
as A= (float(123)) ^ float(1/3) is subtly different from B= (123.0)
^ (1/3)
in particular, A=r^s would be computed as exp(s*log(r)). One value.
B arguably has 3, including exp(s*(log(r)+2*pi*i)) etc.
Once you have converted 1/3 to 0.333333333334d0 I'm not sure we
can justify the 3 values version.
Anyway, I think that's why something like
Q: exp(1/3*(log(2)+2*%pi*%i))
Q,numer
Q,float
Also there seems to be some inhibition to just calling expand or rectform on
numeric items "automatically" because maybe that's not what you want??
On 9/29/2013 8:29 PM, Robert Dodier wrote:
> On 2013-09-29, John Lapeyre <lapeyre.math122a at gmail.com> wrote:
>
>> I have a suggested patch for bfloat() and float().
>> Currently they don't reduce some expressions as
>> far as they could. These expressions involve
>> roots or products of complex numbers.
> That sounds interesting. Where is the patch? I don't see it attached
> to the message or in a link -- perhaps I am missing something.
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima