Motion P1788/M0009.01_ExactDotProduct YES
My vote is YES
*********
I noticed too late that the discussion period was about to end. However,
the current set of motions address substance and not form, as we don't yet
have a standard text to vote on literally -- so I think these comments
are still appropriate, as they would not modify the substance of the
motion.
(1) In my opinion the title of the motion does not capture the essence
thereof, which I believe to be support for complete arithmetic, and not
the exact dot product as such -- though a cancellation-proof dot product
is probably the primary application of the proposed primitives.
As I mentioned in an earlier post, a "complete" format in some form is
needed to permit large dot products to be computed piecemeal (serially
or in parallel) and yet remain 100% cancellation-proof.
(2) The exact form of the complete format is needed only for an
interchange format. Internally a software implementation could use
a list of standard floating-point numbers in monotonic exponent order,
possibly with large gaps in the exponent sequence, for example. It
could even use exponent-wrap markers, as the total exponent range has
to match that of the complete format (more than twice that of the base
format itself).
(3) Given that fact that the parameters <m,d> of the complete format
are not fixed (only lower bounds are given in the motion), and that the
storage format is relatively large anyway, I would recommend that the
interchange format include the parameters, say as 16-bit integers. In
fact, I believe a third parameter -- call it j -- should be used to
denote a number of implementation-dependent bits that would sit between
the standard header and the integer part (which in turn is followed by
the fraction part). This would permit encapsulating hardware formats
without the need to reformat (in many cases at least), except possibly
to copy the sign and status bits to their standard place in case of a
mismatch between internal and external representation.
One practical use for implementation-dependent bits is high-water marks
(and low-water), so that not all bits need be defined all the time.
Such implementation-dependent bits are undefined in the exchange format
and would have to be reconstructed on input (and logically-zero bits
would have to be cleared on output).
(4) In almost all contexts (possibly excluding functional languages),
complete-format operands are going to be passed by reference. I would
like to see this addressed explicitly, by specifying the operations in
the following form (possibly allowing a standard-conforming implementation
to offer one or the other interfaces -- unless we write the standard in a
form that makes the two forms formally equivalent):
(I use the abbreviations sF and cF for "scalarFormat" and "completeFormat",
and each may stand for a variety of formats of different precisions, though
necessarily of the same radix in this context.)
sF scalarFormatOf_ConvertFromComplete(cF *source) target := round(source)
void ConvertToComplete(cF *target, sF source) target := source
void ConvertToComplete(cF *target, cF *source) target := source
void CompleteAccumulate(cF *target, cF *source) target += source
void CompleteMultiplyAccumulate(cF *target, sF mop1, sF mop2)
target += mop1*mop2
(Yes, I know that introducing C syntax may be a bad idea -- but the
point remains that in many environments passing complete formats by
value will not make sense.)
Now that I think of it, the conversions to a narrower format should
have an explicit rounding direction argument -- or they should return
an Interval!
My "Accumulate" proposal precludes adding two different complete
formats to generate a third complete format different from both --
but that is not an issue because addition to a wider format is
always exact in the absence of overflow, and complete-format usage
demands that one stay away from overflow boundaries, i.e. overflow
exceptions should really be *exceptions*.
Michel.
---Sent: 2009-10-30 20:50:12 UTC