I think that unless you actually do the arithmetic in decimal, or you
look at the display in binary/octal/hex,
you will find these minor anomalies because of binary to decimal
conversion. As it happens, bigfloat
computation can be done entirely in decimal if this mimicking of naive
modeling of floating point arithmetic
is really important. Of course this makes arithmetic slower, and from a
more sophisticated perspective it
adds nothing to accuracy.
Maple big nums and bigfloats are (or at least at one time were)
represented as packed decimals, I think.
e.g. 1000 represented in 10 bits (1024). wastes 2.4%.
If speed were paramount, then maxima bigfloats could be made much faster
by importing MPFR into Lisp.
Raymond Toy wrote:
> Volker van Nek wrote:
>
>> Ray, in your example just take fpprec 26, which I believe is correct,
>> because you want 26 valid digits.
>>
>> (%i1) fpprec:26$
>> (%i2) 1b0+1b-25;
>> (%o2) 1.0000000000000000000000001b0
>>
>>
> Heh. Ok. Change the example to x : 1b0+10b0^(-fpprec). For the few
> cases I tried, maxima prints 1b0, but x-1b0 is non-zero.
>
>
>
>> Remembering the PI computations I did some time ago I found that time that
>> fpprec is very precise. E.g. the following shows that a correct rounding was
>> made at the 30. valid digit.
>>
>> (%i4) fpprec:30$
>> (%i5) bfloat(%pi);
>> (%o5) 3.14159265358979323846264338328b0
>> (%i6) slength(string(%));
>> (%o6) 33
>> (%i7) fpprec:32$
>> (%i8) bfloat(%pi);
>> (%o8) 3.1415926535897932384626433832795b0
>>
> Isn't this because bfloat(%pi) calls fppi1 which calls comppi with 12
> extra bits of precision and then rounds the result to the desired precision?
>
> Ray
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>