[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: [Stds-754] Comments on draft 1.1.5 (Aug15) for Aug17 style review
We're bogging down trying to impose a particular formatting scheme on the
external character sequences. What's important is that the external
character sequence format be able to represent up to \mu significant digits
and have enough exponent range to represent the result of converting any
internal format value to external character sequence with up to \mu
significant digits. The exact minimal exponent range depends on the
formatting scheme (X.X...XeSYYY, 0.X...DeSYYY, XX...XESYYY), but is
straightforward to determine, given the formatting scheme (though, as Michel
points out, it's devilish in general). Note the \eta isn't used in the
specification other than to name sufficient exponent range.
For example, say binary32 is the widest internal format, \mu = 12, and the
formatting scheme is X.XX...XeSYYY. The extreme values (rounded to nearest,
though that clearly doesn't matter in this case) are
3.40282346639e+38
1.40129846432e-45
so the exponent range must be at least [-45, 38].
With this approach, we could say:
"The conversion parameter m is specified below according to the widest
internal format supported in a radix. For each supported radix, an
implementation shall define an integer \mu >= (m+3) and shall provide
conversion between all interchange and non-interchange formats in the radix
and at least one external character sequence format that represents all
decimal numbers with up to \mu significant digits and that has sufficient
exponent range to represent the result of converting any internal format
value to external character sequence with up to \mu significant digits."
If we want to mandate the exponent range to be of the form [-(10^\eta - 1),
10^\eta - 1], then we could specify that directly: "... and that has
sufficient exponent range [-(10^\eta - 1), 10^\eta - 1] to represent ...."
-Jim
"Michel Hack (1-914-784-7648)" wrote:
...
Page 42, 7.12.3, external decimal.... line 4 of 1st paragraph:
...all integers of the form M*10**N where integer
|{bold m}| <= 10**\mu-1 and integer |{bold n}| <= \eta.
This is old nonsense which I should have noticed months
ago, but now made worse by confusions between several
different letters M, introduced when Dave James started
repairing font issues. The fonts were consistent (but
perhaps unusual) in 5.13.3 on page 82 of draft D0.18.8
of 26 June 2006.
The original nonsense is easy to fix: "all decimal integers
of the form" should be "all decimal numbers of the form".
Actually, that's not enough: another fix is needed when
\mu is very large, because that shifts the relevant range
for the exponent N relative to \eta.
The bold m and n should be the capital M and N here, and it
is indeed M and N that should be integers.
Bold m and n are what used to be script capitals.
Here is a corrected first paragraph, using *c* to denote
character c in bold font:
Conversion parameters *m* and *n* are specified below
according to the widest internal format supported in
a radix. For each supported radix, an implementation
shall define integer \mu >= (*m* + 3) and integer
\eta >= *n*, and shall provide conversions between all
interchange and non-interchange formats and at least
one external character sequence format that represents
all decimal numbers of the form M*10**N where integer
M is such that |M| <= 10**\mu-1 and integer N is such
that 3 + *m* - \eta <= N + \mu <= 3 + *m* + \eta.
It might be easier to state the intent: values in the range
10**-\eta to 10**+\eta with up to \mu digits should be
representable -- or is it 10**-\eta to 10**(\eta + *m* + 3)?
You see, the effective exponent depends on both an explicitly
given exponent (as in 1.2e-3) and the position of the decimal
point (as in 0.0012). The exponent due to the decimal point
can vary enormously, bounded only by the size of the address
space holding the string -- even when \mu is small, because
leading and trailing zeros do not contribute to the number of
significant digits.
I can demonstrate that the original text that introduced \eta
is inconsistent. Suppose the widest implemented format has
an emax of 9999, then \eta could be as small as 9999. Then,
regardless of \mu, small normal numbers with a minimal
exponent could be restricted to one significant digit and
still satisfy the the bounds on N. So all this gibberish
with nested logarithms is a waste of fine print!
I'm not entirely sure what to do about this. The standard
formats are ok (after my correction), because their exponent
ranges are not close to powers of ten. But IBM Fortran has an
extended-exponent range base-16 format whose decimal exponent
range is -9865 to +9861, awfully close to 9999; luckily the
precision is only 35 digits. If it were 135 digits there would
be trouble!
I suppose it would take a motion to reword this in a way that exhibits
the original intent (which I'll have to guess, since that text was
present long before I joined the committee), so for now let's just
fix the obvious problems.