Re: Information
Ian McIntosh wrote:
> For intervals, shouldn't EDP be implemented as returning an interval
> - the smallest interval enclosing the exact result?
That's a different requirement: a tightest interval dot product.
The correctly-rounded dot product passed by Motion 45 can be used as
a primitive for that, and Quality-of-Implementation issues might lead
vendors to provide an interval version that is faster, or uses fewer
internal resources, than a pair of correctly-rounded dot products
followed by numsToInterval().
You could of course offer a motion that requires a tightest interval
dot product, for at least one interval type. We have to be careful
not to define it as a required operation, because that would require
support for all otherwise-supported interval types, and that might
be too much.
To get back to the Exact Dot Product: I continue to maintain that,
without support for a reasonable set of operations on the format used
to represent an EDP result, this would be pretty useless. As I said
before, the representation used may not have to be exposed, i.e. it
could exploit Kulisch accumulators, lists of scaled FP numbers, or
whatever else might be suitable. It would have to support at a
minimum the ability perform correctly-rounded conversions to any other
floating-point type, and exact sums. Scalar products would also be
nice, but products of two complete types might be too much (though
unlike Kulisch accumulators, lists of scaled FP numbers could support
arbitrary products).
Michel.
---Sent: 2013-09-06 17:09:52 UTC