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

It does round before it does arithmetic, but if you write
round_to_decimal(343453453.45345345345b0), there will be no rounding
involved.

One of the strange things is that there doesn't seem to be any standard
programmatic way to extract the inherent precision of a bfloat in Maxima.
 The cheat: ?caddar(bfloat) gives you the precision in binary digits.

           -s

On Thu, Dec 1, 2011 at 12:23, Raymond Toy <toy.raymond at gmail.com> wrote:

>
>
> On Thu, Dec 1, 2011 at 4:53 AM, Stavros Macrakis <macrakis at alum.mit.edu>wrote:
>
>> 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.
>>
>
> 15+ digits aren't common.  I was just pointing out that rat would not be a
> good general solution.  Your example is a better reason of why rat is not
> the right solution either. :-)  Maybe round_to_decimal(".333333....") is
> the best general solution.
>
>>
>> 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.
>>
>>
> I was assuming bfloats wouldn't use all the digits; I will have to check
> to be sure.  But if it rounds before doing arithmetic, then it doesn't
> really matter too much because you can't do anything with these
> extra-precision bfloats except read them and, maybe, print them.
>
> Ray
>
>