Sheldon Newhouse wrote:
> Raymond Toy wrote:
>
>> Sheldon Newhouse wrote:
>>
>>
>>> Following the earlier discussion in this thread (thanks fo RJF and
>>> Barton), I wrote the following function which relates fpprec and ?fpprec.
>>>
>>> (%t112) fp_bits(n):=floor(log(bfloat(10)^n)/log(bfloat(2)))+3
>>>
>>>
>>>
>> Why experiment when we have the actual source code? :-)
>>
>> Thus, fpprec is computed from $fpprec via the function fpprec1. (Great
>> function name! No way to figure that out except by reading the code
>> And you can't figure out how to call fpprec1 without reading more code
>> to see how it's used.)
>>
>> Anyway, fpprec1 computes fpprec as (+ 2 (integer-length (expt 10
>> $fpprec))). This is pretty much what Sheldon has, except there's a
>> potential for roundoff in his formula. Probably doesn't occur for
>> sensible values of $fpprec.
>>
>> Ray
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
>>
>>
> OK, so we might as well define the function fp_bits as
>
> :lisp (defun $fp_bits(n)(+ 2 (integer-length (expt 10 n))))
>
> Then, there is no ambiguity.
>
> Thanks,
> -sen
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
> .
>
>
Another comment. Although it is not practical, I found it curious that
the following two functions (which seem to be the same for low values of
n) have the following properties:
(%i65) :lisp (defun $fp_bits(n)(+ 2 (integer-length (expt 10 n))))
$FP_BITS
(%i65) fp_bits_1(n):=
rationalize(floor(n*log(bfloat(10))/log(bfloat(2))) + 3);
n log(bfloat(10))
(%o65) fp_bits_1(n) := rationalize(floor(-----------------) + 3)
log(bfloat(2))
(%i66) fpprec:1000;
(%o66) 1000
(%i67) fp_bits(10^5);
(%o67) 332195
(%i68) fp_bits(10^6);
Maxima encountered a Lisp error:
Error in function KERNEL::INTEXP:
The absolute value of 1000000 exceeds EXTENSIONS:*INTEXP-MAXIMUM-EXPONENT*.
Automatically continuing.
To reenable the Lisp debugger set *debugger-hook* to nil.
(%i69) fp_bits_1(10^5);
(%o69) 332195
(%i70) fp_bits_1(10^6);
(%o70) 3321931
(%i71) fp_bits_1(10^50);
(%o71) 332192809488736234787031942948939017586483139302461
So, the lisp implementation of ?fpprec as a function of fpprec has
fairly low values of fpprec allowed, but the definition using logs and
bfloat can go quite high.
FWIW,
-sen
P.S. I still did not check that round-off errors might change the values
of fp_bits_1 from those of fp_bits when both are defined.