On 8/5/07, Richard Fateman <fateman at eecs.berkeley.edu> wrote:
> I think the confusion here is that someone has changed the
> semantics of bigfloats to make it "work" on some simple examples,
> and ignored the fact that this change is illusory and the change
> has broken it, in general.
If that's the case then the change happened a long time ago.
I get the same behavior with Maxima 5.9.1 (Sept 2004) as
with current CVS code. Maybe someone can try it with still
older versions.
> In particular the single-float number 2.1
> when converted to 100 bits, and printed in decimal again is
>
> 2.09999942779541015625b0
I'm confused. Is 2.09999942779541015625b0 the expected
correct output or is it what you observe?
At any rate, here's what I get in 5.9.1 and 5.12.0cvs.
I've guessed fpprec and fpprintprec to match what you wrote above.
Maybe there is some other global that needs to be assigned too.
(%i1) fpprec : 32;
(%i2) fpprintprec : 22;
(%i3) bfloat (2.1);
Warning: Float to bigfloat conversion of 2.1
(%o3) 2.1B0
(%i4) :lisp $%
((BIGFLOAT SIMP 109) 340744481341348063122313821605069 2)
> And bfloat(2.1)-21/10 should be about 5.722b-7
5.9.1 and 5.12.0cvs both yield 0.0b0. The result is the same for
the values of fpprec and fpprintprec which I tried.
> bfloat(2.1d0) should be
>
> 2.100000000000000088817841970012523233890533447265625b0
5.9.1 and 5.12.0cvs both yield 2.1b0, for various values of
fpprec and fpprintprec.
> I suspect that someone introduced a gratuitous rounding in
> bigfloat conversion. The only way one can justify this is if one
> assumes that it is OK for Maxima to randomly perturb binary
> floating-point numbers to a nearby decimal number before
> converting to a binary number.
>
> I suggest this be changed back.
It's far from clear to me what needs to be changed. Probably
the best way to make progress here is for you to review
src/float.lisp and recommend some patches. Or explain in
more detail how it's supposed to work so someone else can fix it.
FWIW
Robert Dodier