From: SourceForge.net <noreply@so...>  20030304 19:56:49

Bugs item #697476, was opened at 20030304 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933 Category: None Group: None Status: Open Resolution: None 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: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 22:28:00

Bugs item #697476, was opened at 20030304 15:06 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933 Category: None Group: None Status: Open Resolution: None 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: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040223 17:17 Message: Logged In: YES user_id=588346 for fpprec:1 thru 6 do print(fpprec," ", 1.0e3/3," ", 1.0e2/3," ", 1.0e1/3," ", 1.0e+0/3," ", 1.0e+1/3," ", 1.0e+2/3," ", 1.0e+6/3," ", 1.0e+10/3); 1 3.E4 .0 .0 .0 3. 30. 300000. 3.E+9 2 3.3E4 0.0 0.0 0.3 3.3 33. 330000. 3.3E+9 3 3.33E4 0.0 0.03 0.3 3.33 33.3 333000. 3.33E+9 4 3.333E4 0.003 0.03 0.33 3.333 33.33 333300. 3.333E+9 5 3.3333E4 0.003 0.033 0.333 3.3333 33.333 333330. 3.3333E+9 6 3.33333E4 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. Nonsignificant 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 