[Maxima] inconsistency with complex numbers?
macrakis at alum.mit.edu
Sun Apr 22 13:14:12 CDT 2012
The Maxima convention is that numbers with decimal points are approximate
and are represented as floating-point numbers. In general, calculations on
approximate numbers yield approximate numbers.
is(a=b) is *syntactic* equality, comparing the *form* of a and b, not their
value. Thus is((x+1)^2=expand((x+1)^2)) returns false. For value
equality, use is(equal(a,b)), e.g. is(equal((x+1)^2,expand((x+1)^2))). The
integer 0 is not syntactically equal to the float 0.0, but Maxima considers
them to be equal in value. (Though one could argue that floats should never
As for the behavior of "limit", a limit at a float is not useful or
meaningful. Is the value of limit(tan(x),x,float(%pi/2)) 1.6e+16? I
suppose we could have limit give an error for floating-point arguments, but
that doesn't really seem helpful or useful.
On Sun, Apr 22, 2012 at 10:54, Claudio Botarelli <
claudio.botarelli at gmail.com> wrote:
> Dear developers and users of Maxima,
> troubleshooting a program of mine, I have discovered a Maxima's behaviour
> which appears inconsistent to me.
> There is a strange utilization of integer, real and complex numbers.
> Input of the example:
> a: 0.1+%i*0.0;
> b: 0.0+%i*0.0;
> c: 0.0+%i*0.1;
> d: 0.1+%i*0.1;
> output of the example:
> Maxima version: 5.26.0
> Maxima build date: 22:48 1/15/2012
> Host type: i686-pc-mingw32
> Lisp implementation type: GNU Common Lisp (GCL)
> Lisp implementation version: GCL 2.6.8
> Particularly interesting the tests:
> both should produce true rather than false.
> Any idea about?
> Do I improperly/wrongly use Maxima? Is it a Maxima's bug?
> Thanks in advance for your support.
> Kind Regards
> Maxima mailing list
> Maxima at math.utexas.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Maxima