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

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

> It's a pity that the CLHS is underspecified here.  But I suspect that this
> only matters in very rare cases, namely when the binary representation is
> *exactly* equal to a decimal number with 5000... after the last digit.
>  So we'd have cases like
>
>     print(2342342342342345.0),fpprintprec:14;
>
> which might print as
>
>     2.34234234234235E+15
> or
>     2.34234234234234E+15
>
> on different implementations.
>
> I really find it hard to believe that *any *user, especially a naive
> user, will ever notice that numbers like this print differently in the last
> digit in some implementations.  They are more likely to be confused
> when 10000000000000005.0 prints out as 1.0000000000000004E+16 (because ...5
> is not representable).
>

I would notice.  But only because I'm looking for it in some specialized
case.  Otherwise. no, I wouldn't notice in general.

>
> As for naive users wondering why comparing two floats returns false even
> though they look equal, yes, I suppose that will be a FAQ, just like why
> sqrt(2.0)^2-2 isn't equal to 0.  Anyway, we already seem to have the "look
> equal" problem.  On Maxima 5.25.1 GCL 2.6.8, sqrt(2.0)^2 prints as 2.0, but
> sqrt(2.0)^2-2 => 4.4e-16.
>
>
Hmm.  sqrt(2.0)^2 also prints as 2.0 with cmucl.  But if you examine the
actual answer, maxima/cmucl prints out 2.0000...04.  I am now reminded that
there were some messy things done in maxima's float printer to accomodate
some things which I no longer remember.  I'll have to look at the code to
see what's going on (again).

So maybe fpprintprec:14 is ok, since we're already not really printing all
bits. :-)

Ray