bug in rational arithmetic ?



The numbers I wrote down  for (correct) conversion are what is provided by commercial Macsyma.

In lisp, there are 2 different built-in functions, rational and rationalize.

(rational 2.1) gives 21/10.
(rationalize 2.1) gives 4404019/2097152  which is more accurate. even though you might not think so if you misunderstand the role played by binary numbers.
allegro common lisp gives ...  (* 1.0d0 (rational 2.1)) -->2.0999999046325684d0
The lisp underneath commercial macsyma gives  2.0999994277954d0

The lisp under wxmaxima gives the wrong answer for
(* 1.0d0 (rational 2.1d0))   which should be 2.1d0.

The lisp under wxmaxima also gives a different answer for (rationalize 2.1),  perhaps erroneously.
I don't know if this matters to maxima.


RJF

----- Original Message -----
From: Robert Dodier <robert.dodier at gmail.com>
Date: Sunday, August 5, 2007 7:28 pm
Subject: Re: [Maxima] bug in rational arithmetic ?

> 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
>