For what it is worth, there is an exactly reverse view of
the contagion of numeric types that may be more appropriate
for computer algebra.
There is nothing inexact about 1.0, 10.0 or even 123.5 even though they
are expressed in a form that usually leads to a binary floating-point
representation when read in by a computer program.
Thus adding 0.3 to 10 might just as reasonably result in
3/10+10 = 103/10. (rationalize 0.3) in CL gives 3/10.
If you want to coerce to a float (which is not necessarily
inexact !) you can do so.
If you add a bfloat to a float, who wins? (or 2 bfloats of
different precision...) My suggestion is to convert everything
to global fpprec.
Maybe we could find another word or phrase, like limited-precision
binary fraction...
RJF
Billinghurst, David (CALCRTS) wrote:
>>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.
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima