Simplification of products and the number 0

Agreed entirely that * should be associative and commutative, so 0*0.0 =
0.0*0 etc.

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.

Thoughts?

           -s

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
>
> and
>
> 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
> testsuite:
>
> (%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
> value:
>
> (%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
> http://www.math.utexas.edu/mailman/listinfo/maxima
>