infinity, nan, etc redundant, also exact decimal arithmetic

On 9/5/06, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> For example, when you type in 0.4, you would be surprised, and
> probably annoyed, to see 2/5.

I agree that if you type in 0.4, you should see 0.4 back, not 2/5 or 4
x 10^-1 (your proposed internal represenation if I understand
correctly) or 57646075230342349 * 2^-57 (the internal representation
of 0.4b0 with default fpprec).

I also agree that IEEE float is not very intuitive.

> Also, it is possible to associate with numbers "format strings"  so they
> can be printed in some format like common lisp e,f,g directives.

I also agree with this: 0.4 could be represented as say ((rat simp
decimal) 2 5) or ((rat simp decimal 1) 2 5) (where 1 is the number of
significant digits).

> Though whether it is sensible to propagate these formats through
> operations, I haven't decided....
>  At some junctures you have to give up this claim about full precision

Well, yes, that is precisely the issue.  How much accuracy do you
preserve, and how many digits do you display for 1.0+1/3?  I would say
preserve full precision whenever you can (+ - * / ^int).  Display
precision is harder.  Do you really want 1.0+10^-100 to print 100
digits?  Or maybe it would be better to have a convention representing
approximation, e.g. 1.00000~.  But how do you distinguish between
1.0+10^-100 (represented exactly but printed approximately) and
1.0+sqrt(10.0^-201) (represented approximately)?

Just some thoughts....

         -s