#3301 fpprintprec do not round bfloat correctly(another case)

[Takayuki Homma]

(%i1) display2d:false;
(%o1) false
(%i2) fpprintprec:4;
(%o2) 4
(%i3) 9.9999e0;
(%o3) 10.0 <- correct
(%i4) 9.9999b0;
(%o4) 1.0b0 <- not correct

[Takayuki Homma]

and...

(%i1) display2d:false;
(%o1) false
(%i2) fpprintprec:4;
(%o2) 4
(%i3) string(9.9999e0);
(%o3) "10.0" <- correct
(%i4) string(9.9999b0);
(%o4) "1.0b0" <- not correct
(%i5) printf(false, "~h", 9.9999b0);
(%o5) "1.0" <- not correct

[Takayuki Homma]

cf. https://sourceforge.net/p/maxima/bugs/3213/

[Stavros Macrakis]

Another example:

fpprintprec:6$
0.9999999b0 => 1.0b-1 <<<!!! should be 1.0b0.

In fact, you get this incorrect answer for bfloat(1-10^-i) for i in 4..16 and fpprintprec=i-2 or i-1.

for i:4 thru 16 do
   for fpprintprec:2 thru i-1 do 
      print(i,fpprintprec,bfloat(1-10^-i))

Actually, anything from 1-0.5*10^-i to 1-5*10^-i hits this bug.

Tested on Maxima 5.45.1 SBCL 2.0.0 Windows

[Stavros Macrakis]

Here is some proposed code to fix fpformat.

The existing code was poorly formatted (incorrect indendation) and very messy (reusing the variable name l for several different things). So I reformatted it and changed some variable names to understand it better before applying my patch. It can certainly be cleaned up further, but my main goal was to fix this bug.

Please read and try out the code and let me know what you think.

[Robert Dodier]

It looks like this bug was actually fixed by Ray Toy a while ago (commit d1976ae dated 2021-09-24). I don't see the buggy behavior with a current build.

Version 5.45.1 is dated 2021-06-20 so it doesn't include the bug fix.

I think it's still meaningful to clean up the code and include new test cases, including any specific ones mentioned here.

[Raymond Toy]

Huh. I don't remember doing that at all. And here's a link to the commit [d1976a], just to make it easier to see.

[Robert Dodier]

Closing this ticket as fixed by commit d1976ae. We can continue to work on FPFORMAT but anyway this bug is fixed.