Dear Prof. Kulisch, Dear P1788,
after a long consideration I will write some of my thoughts about
this topic...
History has shown that not every required feature of a standard
receives the same attention by (hard- and software) vendors.
E.g. directed rounding toward -oo and +oo is required by IEEE 754
since 1985 and actually it is not implemented in a satisfying
manner
- The most common hardware only supports a global rounding
mode. Hence, operations with rounding toward -oo or +oo suffer
from changing the global state and flushing the pipeline
- IBM Cell supports only round to zero for single precision
- Java (one of the most common programming languages) only
supports round to nearest
- The C++ standard added support of different rounding modes
in 2011. Hence, it took 26 years to include this feature
- ...
And additionally other IEEE 754 features are treated in a
similar manner by the vendors.
Often full IEEE 754 compliance is realized by software...
Finally I can imagine that if we require to much we will
frighten potential implementers and end up with an ignored
standard.
Even if P1788 is accepted by implementers I don't think that we
will see pure fully compliant hardware implementations in the
near future. Furthermore I think we will mainly get software
libraries based on existing hard- and software. And to be
honest, I'm
not sure if someone will benefit from poorly implemented
software routines which are only implemented to achieve a
specific standard.
To sum up, I would be careful with the assumption "If we
require it => we will get it in hardware" and I think we
should concentrate
on a KISS standard with a realistic chance for acceptance ...
Otherwise we will end up in a comparable scenario like this http://xkcd.com/927/
Just my two cents
Marco
On 19.09.2013 05:31, Ulrich Kulisch wrote:
Baker,
an EDP frequently has to be computed for an _expression_ a×b+c×d+e×f
for vectors a, b, c,d, e, f. Think of a defect correction for a
system of equations where you get cancellation in the limit if you
compute it in finite precision. Here the entire _expression_ has to
be computed as one single EDP.
I am sure that we shall get the EDP (motion 50 allows realization
in software or hardware) if we require it. We shall probably not
get it if we just recommend it. My experience tells me that it
needs that litlle push.
Best regards
Ulrich
Am 18.09.2013 15:54, schrieb Ralph Baker Kearfott:
Ulrich,
Please correct me if I am wrong, but, according to my
understanding,
a correctly rounded dot product would also give you 23456, by
definition.
Baker
On 09/18/2013 08:02 AM, Ulrich Kulisch wrote:
Let's assume that we are using decimal
arithmetic. Consider the two vectors
a = (10²ºº, 23456, -10²ºº) and b = (1, 1, 1).
A conventional for loop for the dot product of a and b in any
available
fixed precision gives you 0, while the EDP would give you
23456.
A conventional for loop for the dot product of a by itself
(norm) would
give you an overflow, while the EDP would give you the value
of the
product.23456×23456 with no overflow.
For more details see the poster.
Let me mention that I shall be out of town for a conference
for one week.
Ulrich Kulisch
Am 17.09.2013 23:09, schrieb Richard Fateman:
On 9/17/2013 6:24 AM, Ulrich Kulisch
wrote:
Let me just discuss an explicit
example more closely, computing the
dot product of two vectors with interval components. What
you would
like to have is the least enclosure of the set of all dot
products of
real vectors out of the two interval vectors. Computing
the interval
dot product in conventional interval arithmetic (what we
are going to
standardize in P1788) for each interval product of two
vector
components you round the minimum of all products of the
interval
bounds downwards and the maximum upwards.
There is no requirement that an interval dot product be
computed by a
simple loop
for i:=1 to n sum a[i]*b[i] {where sum and * are
interval
operations}
just as there is no requirement that a dot product of floats
be computed
by that same loop.
If I were computing a dot product of vectors of ordinary
floats I might
consider
extra-precise multiplication (via Split/TwoSum/TwoProd
etc.)
and compensated summation.
For the analogous interval operation, perhaps the
convenient operations
I would need
are already implicit in the standard, which permits
multiple-precision.... For example
multiplication of 2 double-float intervals [a1,a2] *
[b1,b2] to produce
[C,D] where C and D were
quad-float numbers. e.g. C = <e,f> where e + f ,each
a double-float, is
a representation of exactly the product.
This would be available as an appropriately overloaded
interval mul(),
with a quad target precision, e.g.
quad_mul(a,b).
I think that quad_add() would be effective in adding the
minima and the
maxima, vastly decreasing the
possibility of a significant rounding error affecting the
final outcome.
Or perhaps a compensated summation of the collection of
(scalar) values
separately.
While it is possible to add 3 numbers a,b,c via
EDP(<a,b,c>, <1,1,1>)
and multiply two numbers by EDP(<a>,<b>), it
does not seem economical.
RJF
--
o Marco Nehmeier, Lehrstuhl fuer Informatik II
/ \ Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o Tel.: +49 931 / 31 88684
/ \ Uni E-Mail: nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx
o o Wuerzburg
|