exact decimal type, was: 12.3*70.95 a little bit weird

I don't have a strong opinion about whether bfloats should be binary or
decimal.

Interesting idea to use decimal bfloats as the standard floats in Maxima.

Advantages:

* Decimal input would be represented exactly and print/read would always be
idempotent (it's supposed to be today, but isn't).
* Simple calculations (+, -, *) would give exact decimal results (within
given precision).
* User could set whatever precision was appropriate.

Non-advantages (i.e. things it wouldn't either improve or make worse):

* Division of floats would still not be exact in general, so 2.0/3.0*3.0-1
wouldn't necessarily be exactly 0.
* Roots and transcendental functions would still not be exact, so
asin(sin(.3)) might not be exactly .3.
* Given the above two points, users would *still* have to be educated about
the properties of floating-point arithmetic.
* Exact decimal floats do not improve the accuracy of most real-world
calculations.

Disadvantages:

* Numerical calculations in Maxima would be slower
* Some parts of Maxima would have to be rewritten -- in particular, the CRE
representation doesn't allow bigfloat coefficients.
* Interfacing to compiled numeric code would require a translation step
which would add a (small) overhead but more importantly vitiate the
exactness property.

Overall, it seems like a lot of work for very little advantage.

         -s

On Wed, Dec 7, 2011 at 11:14, Richard Fateman <fateman at eecs.berkeley.edu>wrote:

> I've been traveling and so didn't really enter into this thread except to
> send a note to Stavros.
>
> There is a flag *decfp  in the bigfloat package which changes the
> arithmetic to decimal.
> It is used during computation of the (decimal) version of the output.  It
> is not sufficient to
> merely bind *decfp to T  to make bigfloats run in decimal, but it is
> probably close.
>
> So there is likely to be a way to make all bigfloat arithmetic decimal.
>  In fact some early
> version of the package was in decimal -- it is just faster to "round to
> nearest even" if
> the fraction part of the number is in binary.
>
> I think that the handful of locations where *decfp is checked need to be
> examined, and
> also all occurrences of the number 2, where it is explicitly used as a
> base.
>
> All results must be rounded, and fpround  (which check *decfp) does the
> work.
>
> RJF
>
>
>