Comments on "Draft P1788" (29 Sep 2008, Kearfott, Pryce & Revol)
I realise this comes a bit late, but somehow this document had slipped
to the bottom of my pile of 1788-related stuff. Sorry.
Now, perhaps I'm simply way out-of-date, and there is a newer version
available. If so, where?
I am aware of the fact that this document is an early attempt to use
a P754 draft as a starting point, and turn it into a P1788 proposal.
(This is especially obvious to me, as I was part of the P754 process.)
There are a few things that did not translate easily from P754 to P1788
however, most notably some subtleties of DFP (Decimal FP).
1.2 Purpose: "The results ... will be identical". This ended up having
a few caveats relative to exception handling, but basically held
up for P754 primitive operations.
It *may* hold up for P1788 primitives, but only if the Interval
implementation type is fully standardized. From an IA point of
view however that may be too strong a constraint, and what is
probably more important is COMPATIBLE results, i.e. interval
results on different implementations must never be disjoint,
and must individually satisfy relevant containment properties.
For example, one implementation may only offer one implementation
type, and the other offer a different type. For P754 those would
not be comparable, but for P1788 they would be.
2.1.2 and 2.1.3: In the case of improper intervals the description in
terms of value order is incompatible with the description in
terms of first element and second element in Clause 3.
Since this document explicitly defines Division to be capable
of returning an improper interval as an encoding of a gap, this
matters. (3) States "The first element is the lower bound..."
Perhaps section 2.1 needs to introduce Proper and Improper
intervals, and then restrict 2.1.2 and 2.1.3 to proper intervals.
3: Ok, two versions are proposed, one of which requires an interval
for every supported floating-point type, the other one permitting
a subset, possibly only one -- but requiring "at least" Binary64.
That should add "if binary formats are supported". After all,
a DFP-only implementation should be capable of conforming too.
4.2: "Exceptions are not signalled until ... both bounds...". I
was under the impression that IA did not (per se) trigger any
exceptions. Some of the conversions into intervals may trigger
a validity exception, but if that is a trap, it should suppress
the operation and not complete it. Non-trap exceptions simply
set flags, and the issue should not arise. Visibility of flags
in the case of asynchronous interruptions is not covered by P754.
4.3, 1st para: Is there a reason that comparisons and lattice operations
are "should" and not "shall"?
I note that LessEqual comparison is of the "possibly" type, and
not the "definitely" type. Fortan seems to make that distinction
(or was supposed to, in Baker Kearfott's 1996 proposal).
intervalElementOf(point, interval) needs to define the result
when "point" is Inf or NaN, in which case the stated definition
does not apply. I assume the answer is simply FALSE.
intervalIntersection() needs to state the result Empty when
either operand is Empty, as the stated definition does not apply.
All interval functions in 4.3 need to define how improper
intervals are handled. Arnold Neumaier steps around this by
defining Division to return two intervals, the containment
and the gap, neither of which is improper. The gap may be
Empty; if not, the containment would be Entire.
Perhaps there should be a Gap() function that turns an improper
interval into a proper interval by exchanging the bounds (it
should transform Empty and proper intervals to Empty however).
The rest of the document (Clauses 5 through 8) appears to be concerned
only with "complete arithmetic". Nothing is said (so far) about
conversions between intervals of different types, or between intervals
and other types (including floats, integers, character sequences...).
Now, Complete Arithmetic is an interesting concept, and its application
domain overlaps that of Interval Arithmetic -- but nothing of the sort
is mentioned in the PAR for P1788.
Nevertheless, I'll proceed to comment on it, since I am in fact familiar
with the Kulisch Accumulator that was implemented in "hardware" (well,
microcode) in IBM's S/370 twenty years ago (the "High Accuracy Arithmetic"
feature, standard on IBM's 9377 for example). Please note that I am not
in the least interested in any compatibility with this old and by now
thoroughly obsolete HFP-based format, but good ideas should not be lost.
5.2: "The values of extra overflow bits ... not used for arithmetic
results shall be zero". This precludes using room in the format
for implementation-specific information that does not affect the
results, but could be exploited for performance. For example,
the S/370 implementation had lookaside for the offset of the
most and least significant bytes, so that all-zero leading or
trailing bytes did not have to be inspected unnecessrily.
The format SHOULD specify the offset of the first arithmetic bit,
or equivalently the value of "x", the implementation-defined
number of non-arithmetic bits. (They are not really overflow
bits unless an implementation decides to keep a sticky overflow
bit in there.)
On the other hand, the official status flags should include a
bit to distinguish SNaN from QNaN so that this test can be done
by software in a format-independent manner. As I will point out
below, the "most significant bit of the integer part" may not be
easy to identify. (I shall elaborate on this later.)
Complete Decimal (DFP) formats require more discussion, and it
is not clear that it makes sense to dictate the format here.
The DPD encoding, with three digits per 10 bits, is a possibility,
but the BID encoding simply does not fit, or would be monumentally
impractical (a 26,000-bit binary integer expressing the value in
terms of a unit of 10**(-12354) should be fun to work with!).
But since the format will be much wider than a natural storage
unit anyway, it might be better to use raw BCD, even it takes up
20% more room.
6: Since the complete operations are specified as formatOf, with
all combinations of source and target precision allowed, all
operations are subject to rounding. In the case of overflow
this holds even when the source and target complete types are
the same, as when adding to a complete value that is just below
the overflow threshold.
7.2.2 "Conversion from a floating-point format to a complete format
is always exact" is true only for same-radix conversions. For
binary->decimal conversions the range of exact conversions is
much wider than for float->float conversion, and the following
conversions are exact (but others are generally not):
Binary32 -> CompleteDecimal64
Binary32 -> CompleteDecimal128
Binary64 -> CompleteDecimal128
What is the difference between exactFormatOf-convert() and
regular FormatOf-convert() with a complete-format target?
The latter already includes all supported complete target
formats (1st para of 7.2.2).
7.2.3 -- what about completeDFP to/from decimal strings, and
for that matter completeBFP to/from decimal strings?
Surely the former must be provided (if a decimal complete
fomat is provided); the latter may be optional. If the
latter is provided, the quantity M of 754-2008 clause
5.12.2 needs to be stated. (5.12.2 does provide a formula
for binary precisions exceeding 128, but that is not
directly applicable to this fixed-point type; indeed,
something should be said whether exponent-based decimal
notation is appropriate, as supposed to a notation that
reflects the integral part exactly and possibly only
approximates the fraction.)
7.4: Comparisons "for operands in all supported complete formats
available for arithmetic": does this include mixed-radix
comparisons? P754 did define those at one point (they were
optional, but if provided they had to be correct), but in
the end chose NOT to support them.
I note the "even if the data have different complete formats"
clarification at the end!
8.1 Aha, a brief mention of interval formats again -- but intervals
don't have NaNs (they *might* have NaIs, but so far those have
not been mentioned, never mind defined) nor Inf, and arithmetic
for Inf bounds might NOT match the P754 rules.
8.3, 4th para, top. Typo: converesion
8.3, 4th para, middle. Since exactFusedMultiplyAdd is new, the exception
granted to fusedMultiplyAdd with respect to the Invalid exception
need not be transferred to the new operation. Let's clean up.
(See also 8.4 below.)
8.3, 4th para, bottom: There has been no mention of conversions to
a format not supporting NaN (such as Integers).
8.4 Complete NaNs. This is a new concept, and so need not suffer
from the compatibility concerns that prevented P754 from
clarifying the definition of BFP NaN. (Note that there is
no "trailing field" here.)
Like DFP, there should be an explicit SNaN flag among the status
bits, and the payload should be defined to be the integral part,
possibly beheaded (i.e. low-order bits or digits preserved during
conversions). Like DFP, a 1-bit should denote Signalling; for
BFP the 0-bit was recommended because of the possible confusion
with Infinity during conversion to QNaN.
Now, there is an interesting issue with respect to NaN conversion
between complete BFP NaN and regular binary floating-point format.
If anything, this would suggest that the LEAST-significand bit of
the I field should be the SNaN/QNaN bit. This would simplify the
conversion, and avoid the need for bit-reversal when transferring
the payload between completeBFP and plainBFP types, which will be
more common than conversion between DFP and BFP. I still think
that the SNaN/QNaN distinction should be carried in the status
field; the low-order integer-field bit could then be left in an
implementation-defined state reflecting the machine type (i.e.
SNaN flag for HP-PA, QNaN flag for most others).
It may even be possible to support both forms: if the fraction
is zero, the payload is carried in the I field, and conversion
between I-payload and F-payload is by bit-reversal.
The point of all this is to make payloads expressed as small
integers convertible exactly and reversibly between all formats.
Then NaN payloads might actually become useful!
8.5: Remove the exception for exactFusedMultiplyAdd
Typo: exceptionw
8.5 c) I saw no complete->integer conversion, but I suppose those could
be defined pretty much like P754. However, the out-of-range
error when the conversion target is a complete format should be
Overflow, not Invalid, or this would conflict with 7.2.2.
8.7 Again, suppressing Underflow for complete formats would
conflict with clause 6. When the target has fewer fraction
bits than the source, underflow is certainly possible.
Back to 5.2, description of the layout of complete formats.
I think we should take advantage of the fact that this is a new format,
not constrained by current machine formats (I said already that there
is no need to cater to the old S/370 format). In particular, there
should be more than two status bits. I already mentioned that the
SNaN bit belongs there. Especially in the context of Intervals we
should probably also have explicit Overflow and Underflow indicators,
so that genuine Inf and Zero could be distinguished from Overflow and
Underflow. An explicit isZero bit would probably be very useful too.
So we get, besides Sign (which btw. might come first, not behind
the status bits, again for certain quick format-neutral tests,
especially since the significand is NOT in base-complement form),
the following flags:
isNaN
isSignalling
isInfinite
isZero
isOverflowed
isUnderflowed
isInexact
Together with Sign that's eight bits, a nice number (these days).
Some precedence should be defined so as to avoid having to deal
with conflicting flags (which would then simply be non-canonical).
The significand would be undefined if Inf, Zero, Over or Under
are indicated, and conceivably Over/Under could be combined and
interpreted in the context of Inf/Zero, but I think clean separate
flags would be most convenient. Canonical forms could require
that the irrelevant bits be zero, but that could get expensive for
the significand in operations like Max or Min that are supposed to
canonicalize, but often would be happy just to copy.
Michel.
Sent: 2008-11-17 23:36:08 UTC