From: Adam W. <li...@co...> - 2004-12-04 04:21:38
|
Hi all, This appears to affect all implementations derived from CMUCL's FORMAT. 22.3.3.1 of the HyperSpec for Tilde F states: Exactly w characters will be output. First, leading copies of the character padchar (which defaults to a space) are printed, if necessary, to pad the field on the left. If the arg is negative, then a minus sign is printed; if the arg is not negative, then a plus sign is printed if and only if the @ modifier was supplied. (format nil "~@F" 1.23) returns 1.23 instead of +1.23 CLISP returns the correct string. Regards, Adam |
From: Raymond T. <ray...@er...> - 2004-12-06 13:08:37
|
>>>>> "Adam" == Adam Warner <li...@co...> writes: Adam> Hi all, Adam> This appears to affect all implementations derived from CMUCL's FORMAT. Adam> 22.3.3.1 of the HyperSpec for Tilde F states: Adam> Exactly w characters will be output. First, leading copies of the Adam> character padchar (which defaults to a space) are printed, if Adam> necessary, to pad the field on the left. If the arg is negative, then a Adam> minus sign is printed; if the arg is not negative, then a plus sign is Adam> printed if and only if the @ modifier was supplied. Adam> (format nil "~@F" 1.23) returns 1.23 instead of +1.23 Adam> CLISP returns the correct string. The November snapshot produces "+1.23". Ray |
From: Paul F. D. <di...@dl...> - 2004-12-06 13:25:01
|
Adam Warner wrote: > This appears to affect all implementations derived from CMUCL's FORMAT. gcl ansi-tests has been adding lots of FORMAT tests over the last few months, so many FORMAT bugs may be fixed in later snapshots or in cvs HEAD. Paul |
From: Christophe R. <cs...@ca...> - 2005-01-28 17:00:03
|
"Paul F. Dietz" <di...@dl...> writes: > Adam Warner wrote: > >> This appears to affect all implementations derived from CMUCL's FORMAT. > > gcl ansi-tests has been adding lots of FORMAT tests over the last few > months, so many FORMAT bugs may be fixed in later snapshots or in cvs HEAD. Paul, you're probably aware of this, bug FORMAT coverage of floating point printing is very patchy -- ~E, ~G and ~$ aren't tested at all, even for equivalence between FORMAT and FORMATTER. Cheers, Christophe |
From: Adam W. <li...@co...> - 2004-12-06 23:56:40
|
Hi Paul F. Dietz, > Adam Warner wrote: > >> This appears to affect all implementations derived from CMUCL's FORMAT. > > gcl ansi-tests has been adding lots of FORMAT tests over the last few > months, so many FORMAT bugs may be fixed in later snapshots or in cvs HEAD. I only belatedly discovered that GCL CVS also printed the float correctly and now I know why :-) I overlooked that CMUCL has also fixed this because the Debian packages aren't usually updated between CMUCL releases (unlike the SBCL and GCL CVS packages which are updated very frequently). Regards, Adam |
From: Edi W. <ed...@ag...> - 2004-12-07 07:22:34
|
On Tue, 07 Dec 2004 12:56:34 +1300, Adam Warner <li...@co...> wrote: > I overlooked that CMUCL has also fixed this because the Debian > packages aren't usually updated between CMUCL releases (unlike the > SBCL and GCL CVS packages which are updated very frequently). The CMUCL package has been updated at least eight times since 19a was released, it includes all official patches for this release: <http://packages.debian.org/changelogs/pool/main/c/cmucl/cmucl_19a-release-20040728-9/changelog> No snapshots, though. Edi. |
From: Christophe R. <cs...@ca...> - 2005-01-28 16:55:24
|
Adam Warner <li...@co...> writes: > (format nil "~@F" 1.23) returns 1.23 instead of +1.23 This should be fixed in sbcl-0.8.19.3. Thanks for the report. (And please check that the fix hasn't broken anything else!) Cheers, Christophe |