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

True, but are 15+ digit *exact* decimals really a frequent requirement?

On the other hand, my suggested 'rat' solution is incorrect.
 rat(.33333...) is (correctly) 1/3, not 33333/10^5.  But a round-to-decimal
function isn't hard to write.

On the other hand, your bfloat comment makes me thing the following: when
reading bfloats, why shouldn't Maxima use *all* digits, even if there are
more than fpprec? This would slow down arithmetic on these non-fpprec
bfloats slightly because the bfloat package first rounds to the current
fpprec before doing arithmetic.

Fateman, you probably have a thought-through opinion on this....

            -s

On Wed, Nov 30, 2011 at 23:19, Raymond Toy <toy.raymond at gmail.com> wrote:

> On 11/30/11 9:21 AM, Stavros Macrakis wrote:
> > How about rat(12.345678)?  Of course, ratepsilon should be 2e-15 or so
> > (which we agreed on in February 2005, but it's still 1e-8!) and you
> > probably want to turn off ratprint.
>
> Just remembered there's one problem with using rat.  The number is
> converted to a floating-point number before rat gets it.  So you get FP
> roundoff.  With r notation, it truly is exact and you can have way more
> than 15 significant digits.  Using bfloats is a workaround, which only
> works if fpprec is bigger than the number of digits you've entered.
>
> Ray
>