Opened 12 years ago

Closed 12 years ago

#230 closed defect (fixed)

Format ~F switches to scientific notation too soon

Reported by: danieldickison Owned by: gb
Priority: major Milestone:
Component: ANSI CL Compliance Version:
Keywords: Cc:

Description

ClozureCL seems to switch to scientific notation when doing format ~F before the number becomes too large or small.

Example:

CCL> (format t "~F" 0.0001)
1.0E-4  ;; Expected: 0.0001

From CLHS Section 22.3.3.1:

If w is omitted, then if the magnitude of arg is so large (or, if d is also omitted, so small) that more than 100 digits would have to be printed, then an implementation is free, at its discretion, to print the number using exponential notation instead, as if by the directive ~E (with all parameters to ~E defaulted, not taking their values from the ~F directive).

I read that to mean that if less than 100 digits would be printed, then it's required to use fixed point representation.

MCL 5.0 actually gets this right, so I/we/somebody might be able to merge code from MCL's Lib/format.lisp into CCL's file of the same name.

Attachments (2)

format-f.diff (5.4 KB) - added by danieldickison 12 years ago.
Patch to pull in MCL's format ~f behavior
format-f-condensed.diff (1.5 KB) - added by danieldickison 12 years ago.
Same patch but ignoring indentation changes

Download all attachments as: .zip

Change History (6)

comment:1 Changed 12 years ago by gb

  • Status changed from new to assigned

That section also says

"If both w and d are omitted, then the effect is to print the value using ordinary free-format output"; I'd assume that "ordinary" refers to the float-printing behavior described in 22.1.3.1, and CCL seems to comply with that definition of "ordinary" floating-point printing.

I think that if you want ~F to behave differently from ~S, you have to provide w or d parameters.

If you agree, please close this bug.

comment:2 Changed 12 years ago by danieldickison

Well, the second half of that sentence after the semi-colon is: "prin1 uses this format for any number whose magnitude is either zero or between 10-3 (inclusive) and 107 (exclusive)." I don't think it would have been qualified with the [10-3, 107) range if the intention was to have it behave the same as prin1 for numbers outside of that range.

But this is starting to sound like a debate about the comma in the Second Amendment. A better argument might be that "my" interpretation of the no-parameter ~F is a useful behavior that's not present available any other printing methods (i.e. a non-scientific-notation format that has just enough digits to avoid having trailing zeros). Also, this is how MCL and SBCL do it.

Pulling in the changes from MCL was pretty simple (though the patch is big because it shifts all the indentation). I'll attach it in a second. I understand the spec is ambiguous so feel free to apply the patch or not.

Changed 12 years ago by danieldickison

Patch to pull in MCL's format ~f behavior

Changed 12 years ago by danieldickison

Same patch but ignoring indentation changes

comment:3 Changed 12 years ago by danieldickison

I just noticed today that another argument for the MCL/SBCL interpretation of the spec -- the CLHS clearly distinguishes between "ordinary free-format output" (22.3.3.1) and "ordinary free-format exponential output" (22.3.3.2, describing the ~E format), so I don't think the former refers to the standard printing behavior of 22.1.3.1.

But again, if you'd rather not change this, let me know and I'll be happy to close the bug.

comment:4 Changed 12 years ago by gb

  • Resolution set to fixed
  • Status changed from assigned to closed

Sorry it took so long to commit; it should be fixed in changeset:8236.

Note: See TracTickets for help on using tickets.