[Maxima-bugs] [ maxima-Bugs-697476 ] formating doubles / really minor

[SourceForge.net <no...@so...>]

Bugs item #697476, was opened at 2003-03-04 13:06
Message generated for change (Comment added) made by robert_dodier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Lisp Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Barton Willis (willisb)
Assigned to: Nobody/Anonymous (nobody)
Summary: formating doubles / really minor

Initial Comment:
fpprec has an undocumented feature; its value
determines the number of decimal digits that 
are displayed for a double.

(C1) fpprec : 8;
(D1) 				       8
(C2) sin(0.1d0);
(D2) 				   0.099833
(C3) fpprec : 30;
(D3) 				      30
(C4) sin(0.1d0);
(D4) 			      
0.09983341664682816
(C5) fpprec : 16;
(D5) 				      16
(C6) sin(0.1d0);
(D6) 			       
0.09983341664683
(C7) 

I was  surprised by this; the setting of  fpprec changes 
the formatting of doubles, but nothing else about them.  
For bfloat numbers,  the setting of fpprec changes the 
formating and the number of bits in the fractional part.  

The documentation for fpprec is unclear and
misleading

- Variable: FPPREC
     default: [16] - Floating Point PRECision.  Can be set 
to an intger representing the desired precision.

Maybe Maxima has too many globals already, but 
I might suggest that the formating of doubles
be controlled by something other than fpprec.
(An option for scientific notation, etc might
be nice.)


Maxima version: 5.9.0.rc4
Maxima build date: 12:4 1/30/2003
host type: i686-pc-mingw32
lisp-implementation-type: Kyoto Common Lisp
lisp-implementation-version: GCL-2-5.0

Barton


----------------------------------------------------------------------

>Comment By: Robert Dodier (robert_dodier)
Date: 2006-07-04 00:14

Message:
Logged In: YES 
user_id=501686

EXPLODEN (src/commac.lisp) has been revised to observe
$FPPRINTPREC instead of $FPPREC to determined the number of
digits to print. ($FPPRINTPREC is the existing global
variable which governs formatting for bigfloats.)

It may well be that float formatting can be further
improved, but the confusion of $FPPREC (bigfloat
computational precision) with number formatting has been
resolved.

Closing this report as fixed.

----------------------------------------------------------------------

Comment By: Stavros Macrakis (macrakis)
Date: 2004-02-23 15:17

Message:
Logged In: YES 
user_id=588346

for fpprec:1 thru 6 do
  print(fpprec,"  ",
        1.0e-3/3,"      ",
        1.0e-2/3,"      ",
        1.0e-1/3,"       ",
        1.0e+0/3,"       ",
        1.0e+1/3,"      ",
        1.0e+2/3,"  ",
        1.0e+6/3,"  ",
        1.0e+10/3);


1  3.E-4       .0      .0      .0      3.      30.     300000. 3.E+9   
2  3.3E-4      0.0     0.0     0.3     3.3     33.     330000. 
3.3E+9  
3  3.33E-4     0.0     0.03    0.3     3.33    33.3    333000. 
3.33E+9 
4  3.333E-4    0.003   0.03    0.33    3.333   33.33   333300. 
3.333E+9        
5  3.3333E-4   0.003   0.033   0.333   3.3333  33.333  
333330. 3.3333E+9       
6  3.33333E-4  0.0033  0.0333  0.3333  3.33333 33.3333 
333333. 3.33333E+9

There are several problems here.

First of all, in all but the .003, 0.03, and 0.3 cases, fpprec 
refers to the number of significant digits, not the number of 
printed digits.  Those cases should read:

1  0.003       0.03       0.3
2  0.0033      0.033      0.33           
3  0.00333     0.0333     0.333          
4  0.003333    0.03333    0.3333   
5  0.0033333   0.033333   0.33333  
6  0.00333333  0.0333333  0.333333 

Secondly, 3. and 30. in Maxima read in as integers, not floats, 
so should presumably be output in a consistent way.

Finally, it is confusing (though arguably consistent) that 
333333.0 prints as 300000. with fpprec=1.  Non-significant 
zeroes can be avoided by using scientific form, as C does with 
%g format.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933