Some random thoughts on future features



[C Y <smustudent1@yahoo.com>, Wed, 17 Nov 2004 09:38:27 -0800 (PST)]:
> --- Richard Fateman <fateman@cs.berkeley.edu> wrote:
> > 2. It is not so clear how to combine stuff.  For example,
> > bigfloats of different precision.  Rational + float could be
> > made into a rational.  It could be made into a float unless it
> > overflows.
> 
> Presumably the least precise bigfloat would win, wouldn't it?  As for
> rational plus float, wouldn't it be better to have it remain a rational
> unless someone uses the float() or numer() commands on it?  

IIRC (no access to an installation right now), Mathematica evaluates
both of

    Pi + 1 * 0. 

and 

    Pi + 0 * 1.

to 3.14159.  For the former, this seems correct if one thinks of 0. as
an approximate zero, as is the Mathematica point of view (and there
are many problems with the approach).  At any rathe, the latter seems
completely undesirable in a CAS as an exact zero times something known
to be finite should definitely remain an exact zero.

It seems that by using CL's contagion rules one would also end up with
this problem: (* 0 0.d0) evaluates to 0.0d0 rather than to 0, and for
good reason.

This may be naive, but I can see only the following clean
possibilities:

- Always do a symbolic simplification before evaluating anything that
  has to do with both exact quantities and floats of any kind.  This
  is likely to be very costly, and probably the reason why Mathematica
  does not do this.

- Always keep potentially exact quantities and floats separate unless
  explicitly asked not to (NUMER etc.).

- Consider floats and bigfloats as essentially exact, which is
  basically what is done now in at least some circumstances:

  ,----
  | (%i4) 3/5 + 1.;
  | 
  |                                        8
  | (%o4)                                  -
  |                                        5
  `----

  but that would mandate the *most* precise bigfloat to win.

Just my EUR 0.02,

Albert.