> From: Stavros Macrakis
>
> Standard Maxima semantics are that operations on exact numbers are
> exact except with numer=true, so gamma(1+1/2*%i) should not return
> a float. Floats and bfloats are inexact.
>
> Currently, Maxima does not have the notion of an inexact complex in
> the same way, so though sin(1.0) returns a float, sin(1.0+2.0*%i) does not.
>
> It seems reasonable to define inexact+%i*exact and exact+%i*inexact as
> inexact, so that sin(1+2.0*%i), gamma(1+0.5*%i), and gamma(1.0+%i) return
> floats.
>
> -s
That seems reasonable to me. I agree with Ray's suggestion to modify
complex-number-p to do the right thing, although perhaps we need a function
called inexact-complex-number-p (or similar). That is:
- a predicate to detect maxima complex numbers
- another predicate to check when complex numbers should be evaluated numerically.
I didn't want to do this without discussion.
I had another issue with complex arguments. I'll use airy_ai() as an example,
but other functions I tried showed the same issue. Let z be an exact complex
number, eq z:1+%i/2.
Both "airy_ai(z), numer;" and "float(airy_ai(z));" give a numeric value
but "airy_ai(%i), numer;" is numeric while "float(airy_ai(%i));" is
returned unevaluated.
The simplification routine tests $numer to see if exact complex numbers should
be evaluate numerically. This isn't set while evaulating float(airy_ai(%i)).
Is there another variable set while eavaluating within float(), or should float
set $numer?.
David
NOTICE
This e-mail and any attachments are private and confidential and may contain privileged information. If you are not an authorised recipient, the copying or distribution of this e-mail and any attachments is prohibited and you must not read, print or act in reliance on this e-mail or attachments.
This notice should not be removed.