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

On Wed, Nov 30, 2011 at 6:33 AM, Stavros Macrakis <macrakis at alum.mit.edu>wrote:

> This seems to add complexity where in fact simplicity is needed.
>
> The naive user who is confused by the trailing digits in 12.3*70.95 is
> hardly likely to write 12.3r0*70.95r0.  And the sophisticated user
> shouldn't find it too hard to write 123*10^-1 (3 extra keystrokes), and has
> a variety of ways of controlling the form of the output.
>

I agree about the naive user.   I, however, would find 12.345678r0 to be
quite handy because I invariably get the power of ten wrong.  And it
doesn't bother me that a rational is printed out.  That's what "r" was
intended to mean.

>
> Then there's the complication of output.  Do users who enter the fraction
> 2/5 really want to see 4.0r-1 on output?  I doubt it.  But users who enter
> 0.4r1 presumably don't want to see 2/5, either.  So then do we need to keep
> track of the *origin* of each rat?  Do we want 2/5*3 to print as 6/5, but
> 2/5*3r0 to print as 1.2r0?  Yuck yuck yuck.
>

Agreed.  It should just be a rational.

>
> This seems like a lot of complexity for a very simple problem.  The vast
> majority of cases are, I suspect, handled satisfactorily by simply making
> fpprintprec:14 by default.
>

I kind of disagree with that.  Floating point should be printed out to full
precision;  changing fpprintprec merely hides the problem which the naive
user should learn about and not be naive anymore.  The experienced user can
set fpprintprec appropriately.

Ray