Menu
▾
▴
#287 cf(-sqrt(2)) cf(sqrt(2)/sqrt(5)) cf...fpprec incorrect
cf(-sqrt(2)) => [1,2] NO
cf(-sqrt(2)),cflength=3 => [1,2,2,2] NO
But those are the CF's for sqrt(2).
(I show the results for cflength=1 and =3 to show
repetition pattern.)
cf(sqrt(2)/sqrt(5)) => [0,1,2,13] NO
cf(sqrt(2)/sqrt(5)),length=3 => [0,1,1,1,2,1,2,4,2,3,4] NO
The correct result (as you can see from cf(sqrt(.4))) is
[0,1,1,1,2] (repeat 1,1,2)
Apparently cf computes the *truncated* CF for sqrt(2)
and the *truncated* CF for sqrt(5) and then combines
them.
That is the wrong way to do it. Gosper's algorithm
(1972) as documented in Hakmem 101B
(http://www.inwap.com/pdp10/hbaker/hakmem/cf.html#it
em101b) and even more clearly in
http://www.lix.polytechnique.fr/~ilan/pseudo_code.ps.
The strange thing is that CF uses Gosper's algorithm
correctly for finite-length CFs.
Another (unrelated) bug:
block([fpprec:25],cf(1.0b-25)) ==
cf(1.0b-25),fpprec:25 =>
[0, 10000000000000000189023153, 2]
NO!
as opposed to
fpprec:25;
cf(1.0b-25) => [0, 10000000000000000000000000]
Compare the correct behavior of
block([fpprec:25],1.0b0+1.0b-22-1.0b0);
1.0b0+1.0b-22-1.0b0,fpprec:25;
fpprec:25;
1.0b0+1.0b-22-1.0b0;
=> 1.000113059364895023149213B-22
1.000113059364895023149213B-22
Presumably this has something to do with the weird way
CF is an MFEXPR* to avoid LISTARITH arithmetic....
Logged In: YES
user_id=588346
My "(unrelated) bug" is bogus. Sorry about that. The
problem is that the Bfloats are being *read in* using the value
of fpprec prevailing at the time of the *read*!! And bfloats are
represented internally as binary floating-point, not decimal
floating point. Naturally, setting fpprec during the calculation
doesn't change anything.
To demonstrate the effect:
fix(1.0b25) => 10000000000000000100663296
fpprec:25$
fix(1.0b25) => 10000000000000000000000000
But the other CF problems are still legit. Teaches me to put
two different problems in one bugnote -- now I can't mark the
second problem as "user error" and make it disappear....