[Maxima] Simplification of products and the number 0
macrakis at alum.mit.edu
Mon Sep 27 08:57:16 CDT 2010
Agreed entirely that * should be associative and commutative, so 0*0.0 =
However, there are two possible reasonable results for 0*0.0: 0 or 0.0.
Here are the arguments in favor of each:
0 -- 0 represents an exact zero; 0.0 represents some unknown number very
near zero. Therefore 0*0.0 is always exactly 0.
0.0 -- a) calculating with 0.0 implies that we want an approximate result
b) we want type(a*b) to be a function of type(a) and type(b),
independently of their values (especially important for compilation)
c) multiplying by integer 0 is a very special case -- do we really
want to handle it differently from other integers?
I started writing this email thinking that 0 was the 'correct' solution --
and I think it is, in fact, logically correct -- however, it looks as though
0.0 is the pragmatic solution.
On Sat, Sep 25, 2010 at 13:37, Dieter Kaiser <drdieterkaiser at web.de> wrote:
> We get the following if we multiply zeros:
> 0 * 0.0 -> 0
> 0.0 * 0 -> 0.0
> If we reverse the order of the arguments the type is preserved. But if
> we take any other numbers we always get a zero as a result:
> 0 * 1.0 -> 0
> 1.0 * 0 -> 0
> simptimes has code to return always 0, if we have the number 0 as a
> factor. The case 0.0 * 0 is the only exception I have found.
> This behavior has only small, but subtle effects. E.g. the following
> examples show a different behavior for a complex number:
> (%i22) realpart(0.0*%i);
> (%o22) 0.0
> (%i23) realpart(1.0*%i);
> (%o23) 0
> It is possible to implement a consistent simplification which preserve
> the type, we will get
> 0 * 1.0 -> 0.0
> 1.0 * 0 -> 0.0
> 0 * 0.0 -> 0.0
> 0.0 * 0 -> 0.0
> 0 * 1.0 * a -> 0.0
> a * 1.0 * 0 -> 0.0
> realpart(1.0*%i) -> 0.0
> By the way: All examples show the same behavior for bigfloat numbers.
> I have got only one problem with the testsuite and no problem with the
> share_testsuite. The following new result causes the failure in the
> (%i57) abs((float(%pi)*%i-%pi*%i));
> (%o57) 3.141592653589793 - %pi
> The new code does not simplify the above example to zero. But this is
> inconsistent too, because we always have for a constant with a numeric
> (%i58) float(%pi)-%pi;
> (%o58) 3.141592653589793 - %pi
> (%i59) abs(%);
> (%o59) 0
> This behavior might be arguable too. It is caused by the fact that
> simpabs looks for the sign of its argument and gets
> sign(3.141592653589793 - %pi) -> ZERO.
> So the question is, is it the desired and expected behavior to preserve
> the type of an expression, when we multiply zeros. But it is clear that
> this might cause subtle changes and problems at other places of the
> code, which are not recognized by the testsuite or share_testsuite.
> Dieter Kaiser
> Maxima mailing list
> Maxima at math.utexas.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Maxima