Any action? Re: Prospective Motion --, Kaucher Arithmetic
P-1788,
Does someone wish to take action on this motion?
I certainly did not mean to quash it, but I hoped
to have its underlying intent be clear and
precise. Does someone wish to present formally
how the specified set of operations should be considered
(required, optional but as stated if implemented, or
recommended as stated)?
Baker
=============================================================
OK. However, I'd like the eventual motion to state clearly
what will be required, what will be specified but optional,
and what will be recommended. We need unambiguous guidance
at this point for the actual standard, to avoid controversy
at the last minute, since we are approaching a deadline
for submitting it for IEEE review.
Baker
On 09/26/2012 01:34 PM, Michel Hack wrote:
I take Ulrich's paper to be the basis for developing an actual
motion, after we have discussed the ideas presented therein.
An actual motion to be voted on (as a position paper, at
this point) would state what requirements or recommendations
(Baker's (a) and (b)) should be included in P1788, and (if
that motion passes) there would be a later text motion for
John's "Chapter 3" mentioned in Ulrich's reply to Baker.
The rules being proposed in Ulrich's document are incomplete at
this point. As he himself points out, divisors containing zero,
and overflow during outward rounding, need special treatment --
and this is not covered in the motion proper as it now stands.
In the rationale leading up to the motion, Ulrich
addresses these two issues as follows:
(1) Division by an interval containing zero produces
two unbounded results.
(2) Overflow is not acceptable and the computation
must be stopped at that point.
This leads to a third issue: the given rules only cover inputs
in I*R -- but division by zero will lead (without overflow) to
elements of (I*R)bar.
For overflow Ulrich recommends that a computation be redone with
scaled operands. For division with two results I assume a program
would bifurcate. I would know how to handle that at the assembly
language level (a condition code would indicate that two results
were produced, and a single-threaded program would set one aside
and continue with the other, later handling the second path). I
can even imagine hardware that automatically spawns another tread
and (depending on compute resources) allocates the various threads
among available processing elements. What I don't know is how this
notion would fit generically into higher-level programming languages.
The redo-scaled-after-oveflow could be handled by decorations, thus
avoiding the need for exceptions, or for explicit tests after every
operation, but the bifurcation needs to happen at the point where
it occurs -- unless decorations are used to restart a compound
operation after an argument-splitting step that avoids intervals
containing zero.
So there are a number of ways to deal with these issues -- and this
is one reason why some of us feel that standardization of Kaucher
intervals might be premature.
Michel.
P.S. Would it be possible to get a plain-text version (e.g. the TeX
source) of the motion? Trying to extract text from a .pdf does
not work too well and requires a very large amount of manual
repair to get useful results.
---Sent: 2012-09-26 19:08:02 UTC
--
---------------------------------------------------------------
Ralph Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------