[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Corrections to 7.12.2, external character conversions
We're bogging down trying to impose a particular formatting scheme on
the external character sequences.
I don't think so -- nobody imposes a format of a big integer times a
power of ten, which is what M * 10**N is. That representation was
simply a way to relate \mu (max digits of M) and \eta (max |N|) to
the required minima *m* and *n* (previously script capitals). The
trouble is that the value range is typically symmetrical, so the
bounds on N should take the number of digits of M into account.
When that number is small relative to \eta, it doesn't matter much,
but when \mu is unbounded (effectively, the size of the address space)
this is not so anymore.
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.
In full agreement.
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
The trouble is, it is not clear what "exponent range" means in this
context. Exponent range of the *value* is well defined: this is
slightly asymmetrical because of subnormals, and requiring that the
supported range at least include "round" bounds expressed in decimal
seems a good idea... or does it? Given that the actual ranges of
the standard formats are far from powers of ten, this is easy to
achieve, but the formula for non-basic formats breaks down when this
is not the case. We could require that the range be at least twice
as large as the actual value range, but that's awkward for Decimal128
whose actual range is around 6000 -- far enough from 9999, but 99999
might be silly.
The motivation behind a "round" bound is however based on allowing a
restriction on the number of digits for an explicit exponent, as in
scientific notation with exactly one digit before the decimal point.
I claim that this restriction is bogus, because usually input formats
permit an arbitrary number of leading or trailing zeros, which are
simply counted, and whose number can easily exceed the "exponent bound".
The situation used to be a bit more complicated. In June 2005 there was
still a definition of trapped overflow handling, with a scale factor to
be delivered to the trap handler. Ron Smith interpreted this in the
sense that any value from 10**-9999 to 10**+9999, with up to \mu digits,
had to be rounded correctly to a value in the range [1,2) for BFP, with
a binary scale factor of up to 33220 in case of trapped overflow or
underflow. The exponent bounds were therefore critical: four-digit
exponents were doable, but five-digit exponents would have required
unreasonably large tables (or excessively expensive conversion) for an
operation nobody cared about.
sufficient exponent range to represent the result of converting any
internal format value to external character sequence with up to \mu
significant digits."
I think that's good enough. It is weaker than what we have now (with
my correction from <= to >=): does that mean we need a motion, or do
we need a motion only if somebody objects in these pages?
Trouble starts when one tries to define "exponent range" in any sense
other than the value range; the phrasing above does not use the term,
which is fine. That's why we should shy away from the following:
If we want to mandate the exponent range to be of the form ...
If there is a desire to restrict bounds on the explicitly given exponent
in scientific notation, then \eta might be fine, and if a format is such
that a subnormal might require e-10009, then the number could still be
given as 0.000000000012345e-9999 to get around an unfortunate exponent
bound. But this should then be stated explicitly, and perhaps should be
stated in terms of the number of digits of explicit exponent that must
be supported.
If the notion of scaled conversion ever resurfaces, we must make sure
that there are reasonable bounds on the exponent range of the value,
regardless of how that exponent is presented.
Michel.
Sent: 2006-08-19 01:03:21 UTC