I think it is a mistake to set fpprec by default to be sort-of like the
precision of an IEEE double-float.
It is confusing, as this message below suggests. If fpprec were set by
default to about 32 decimal digits,
it would be clear that it is for "big floats". Actually, fpprec can be
set to small numbers and simulate
low precision, but that is not very common.
The other questions here were answered by Ray.
RJF
reyssat wrote:
> Hi,
>
> I have some questions and remarks about precision of floats and bigfloats.
>
> I construct
>
> f(i):=block([u], u:sqrt(10^(2*i)+1)/10^i, print(bfloat(u)),print(float(u)));
>
> then :
> (%i3) f(2);
> 1.000049998750063b0
> 1.000049998750062
>
> **** this is ok, just slightly strange that float gives a better result
> than bfloat (the right answer is 1.000049998750062496..., so should be
> rounded to ...0062 and not ...0063).
> By the way, I cannot find in the documentation (at least in chapter 10,
> floating point) the definition and precision of a float.
>
> (%i4) f(50);
> 1.0b0
> 1.0
>
> **** this rounding is ok.
>
>
> (%i5) f(200);
> 1.0b0
> Maxima encountered a Lisp error:
>
> Error in PROGN [or a callee]: Can't print a non-number.
>
> Automatically continuing.
> To reenable the Lisp debugger set *debugger-hook* to nil.
>
> **** bfloat is ok. But float cannot calculate this since some
> intermediate result is too big (once again, is the limit for the
> exponent given in the documentation ?), although the result itself is a
> perfectly nice number. Would it be possible to improve the float
> algorithm to avoid this problem ?
>
>
> (%i6) f(1000);
> 1.0b0
> 0.0
>
> **** this time, no error message, just a stupid result from float ! is
> it a bug, or just a feature ? bfloat is ok.
>
> Eric Reyssat
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>