unpretty FORMAT ~E printing

[Nikodemus Siivola]

Eric Marsden <email address hidden> via lists.sourceforge.net to sbcl-devel

Hi,

,----
| * (lisp-implementation-version)
| "1.0.50.54-5abf3b4"
| * (FORMAT NIL "~E" 1.0)
| "1.e+0"
| * (FORMAT NIL "~E" 1.0d0)
| "1.d+0"
`----

My reading of CLHS ("If all of w, d, and e are omitted, then the effect
is to print the value using ordinary free-format exponential-notation
output") suggests that those should be "1.0e+0" and "1.0d+0".

 http://www.lispworks.com/documentation/HyperSpec/Body/22_ccb.htm

[Nikodemus Siivola (nikodemus)]

Alexnader Klimov says:

Unless "ordinary" is defined (I cannot find such a definition in the
specification), it is reasonable to understand "ordinary" as the form
without any redundant characters, that is for fixed-format it is "1.0"
(the zero is required since "1." is an integer), but for the
exponential notation "1.e+0" is sufficient (actually, "1.e0" is also
enough, but "+" is explicitly required).

As a hint that "1.e+0" is a better interpretation of Section 22.3.3.2
we can consider

 If the parameter d is omitted, then there is no constraint on the
 number of digits to appear. A value is chosen for d in such a way
 that as many digits as possible may be printed subject to the width
 constraint imposed by the parameter w, the constraint of the scale
 factor k, and the constraint that no trailing zero digits may appear
 in the fraction, except that if the fraction to be printed is zero
 then a single zero digit should appear after the decimal point.

and thus "1.0e+0" would violate the "no trailing zero digits"
requirement.

[Raymond Wiker (rwiker)]

I just came across this issue when I was evaluating st-json for working with JSON-formatted data. I got errors from other systems because 1.e+0 is not a valid representation of 1.0.

The text from the Hyperspec that Nikodemus quoted seems to contradict his conclusion: "except that if the fraction to be printed is zero then a single zero digit should appear after the decimal point."

[Raymond Wiker (rwiker)]

The attached diff seems to be a fix for this.

[Christophe Rhodes (csr21-cantab)]

I think it's reasonable that a trailing 0 for a fractional part of zero should be printed, and I agree that the text suggests this. The patch attached passes our current (fairly weak) regression tests.

[Christophe Rhodes (csr21-cantab)]

I think it's reasonable that a trailing 0 for a fractional part of zero should be printed, and I agree that the text suggests this. The patch attached passes our current (fairly weak) regression tests.

[Christophe Rhodes (csr21-cantab)]

My previous patch broke the case when no w was specified, but d-k+1 equalled zero. Revised patch attached.

[Christophe Rhodes (csr21-cantab)]

I've merged a fix for this. There are still problems with the ~E format directive: the print routine does some inexact scaling, meaning that the last decimal place is fairly often wrong.