| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788,
Motion 8 Exception Handling PASSES
Yes - 37; No - 4; Needed for quorum: 35 (one Voter moved to Observer)
The motion is listed in the attachment to this message.
George Corliss, P1788 Voting Tabulator
Here are comments received. I gather them all here for ease of reference,
especially by the Technical Editor, in case these comments can assist
further progress.
------ Forwarded Message
From: George Corliss <George.Corliss@xxxxxxxxxxxxx>
Date: Thu, 19 Nov 2009 14:31:44 -0600
Subject: M0008.02_Exception_Handling YES
YES to M0008.02 Exception_Handling
Discussions at Dagstuhl this week have convinced me that I do not care much
for the concept of decorations - they are too complicated - but I like much
LESS any alternative I have yet heard.
As the motion promises, I expect further clarifying discussions. I hope we
can simplify what is described so far.
------ Forwarded Message
From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
Date: Thu, 19 Nov 2009 16:16:37 -0600
Subject: Re: M0008.02_Exception_Handling YES
My vote is "YES"
I agree with George that more is work is needed to get
solid standard verbiage. However, discussions
at Dagstuhl have led to my understanding "decorations" more,
and, although there is a down side, they're not so bad.
We do need SOME kind of exception handling, and there is
more than one exception we need. Something like a "decoration"
naturally follows from that.
------ Forwarded Message
From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
Date: Thu, 19 Nov 2009 17:14:16 -0600
Subject: Re: M0008.02_Exception_Handling YES
FWIW:
I believe it should be possible. As it stands, the rules for decorations are
overly-generalized. THis was intentional, since we don't yet know what is
the required list of trits, and various trits might potentially have
competing requirements. So the generality seemed appropriate at this stage.
If we are able to weed out certain trits and/or competing requirements, I
believe many simplifications can be made.
Nate
P.S. When trying to decide how to vote, people might want to remember at
this point we are not yet voting on language for the standard; just general
directions we want the standard to go.
------ Forwarded Message
From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
Date: Sat, 21 Nov 2009 03:13:45 -0600
Subject: M0008.02_Exception_Handling YES
YES to M0008.02 Exception_Handling
Like George, I think that for handling interval exceptions, the
decoration approach is the best so far offered. My yes vote should be
interpreted as "I support what we have so far. But it needs a LOT
more work, especially in the Level 2 semantics of exceptions and how
these should be specified within the standard. Let's do that work."
------ Forwarded Message
From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 22 Nov 2009 03:13:14 -0600
Subject: M0008.02_Exception_Handling YES
Dear 1788 group,
I vote Yes on our current general scheme to use decoration for exception
handling and hope that we will finalize the details as time passes.
------ Forwarded Message
From: Michel Hack <hack@xxxxxxxxxxxxxx>
Date: Sun, 22 Nov 2009 11:43:10 -0600
Subject: M0008.02_Exception_Handling YES
My vote is YES.
Having just re-read the motion, I am impressed with the care it takes
to circumscribe its scope, and to mention which aspects need refinement
through further motions -- so I can offer an unqualified YES here.
A comment on form: it was (as usual) rather painful to extract the text
of the motion from the .pdf file (which happened to have font problems
on my PC, making it almost unprintable). Yet it looks like the original
was in fact a plain-text document before it got mutilated by Acrobat.
The .pdf (even though compressed) was also MUCH larger than the plaintext.
It's a shame that (after PC-DOS) PCs lost the ability to handle plaintext
files well (e.g. print generically on LPT1, edit, grep, etc.). Luckily
our listserv environment is still plaintext, though frightfully many email
systems seem to switch to HTML-only -- and rather gaudy HTML at that. The
MSword .doc format is somewhat better at permitting text to be extracted,
but I'd love to find some general way to convert from plaintext to a
PC-friendly format (needed by most users) and back...
Minor comment on substance: Motion 8 section 3.3 paragraph 3 states that
one cannot extract an interval from a bare decoration. This is generally
true, but SOME decorations should map properly to either bare Empty or
bare Entire. It is however made clear that this level of discussion is
beyond the scope of the motion at hand.
Michel Hack, IBM Research.
(I find it useful to present complete affiliation detail on Votes.)
------ Forwarded Message
From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
Date: Mon, 23 Nov 2009 09:05:57 -0600
To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
Subject: Re: M0008.02_Exception_Handling NO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I vote NO on Motion 8.02 on the following grounds:
Decorations as proposed by Motion 8.02 have the potential to greatly
enhance the usefulness of interval arithmetic libraries. I have no doubt
about that.
On the other hand, I believe that the standardization process should
sanction techniques and practices that stood the test of time. I am not
aware of any interval arithmetic library that already implements such
decorated intervals. What if, once the standard is passed, decorations
are never used because the way they were defined makes them inconvenient
to use? Are we sure that the decorations defined are the only ones of
importance to all users of interval arithmetic? Will the propagation
rules chosen prove sound for all applications of interval arithmetic?
As I understand it, nobody has any experience whatsoever with
programming with decorated intervals. With work, we may be able to
introduce in the standard a carefully chosen set of decorations with
sound propagation rules. Are we sure all of them will be worth the
trouble *in practice*?
Moreover, the whole machinery of decorations adds complexity to the
standard and raises the bar for potential implementors.
Besides, this is not as if introducing and standardizing decorations was
a necessity now: as said previously on the list, interval arithmetic
libraries have already proved their power and usefulness. And they have
done so without decorations being widely available.
More broadly, I am in favor of standardizing only what is already known
to work and to be useful. Let us add powerful additions like decorations
in the next version of the standard, once the first simple one is widely
accepted and implemented.
FG.
- --
Frédéric Goualard LINA - UMR CNRS 6241
Tel.: +33 2 51 12 58 38 Univ. of Nantes - Ecole des Mines de Nantes
Fax.: +33 2 51 12 58 12 2, rue de la Houssinière - BP 92208
http://goualard.frederic.free.fr/ F-44322 NANTES CEDEX 3
------ Forwarded Message
From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
Date: Mon, 23 Nov 2009 10:28:12 -0600
To: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
Subject: Re: M0008.02_Exception_Handling NO
Frédéric Goualard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I vote NO on Motion 8.02 on the following grounds:
>
> Decorations as proposed by Motion 8.02 have the potential to greatly
> enhance the usefulness of interval arithmetic libraries. I have no doubt
> about that.
>
> On the other hand, I believe that the standardization process should
> sanction techniques and practices that stood the test of time.
[...]
> More broadly, I am in favor of standardizing only what is already known
> to work and to be useful. Let us add powerful additions like decorations
> in the next version of the standard, once the first simple one is widely
> accepted and implemented.
Note the the IEEE754 standard also introduced directed rounding and
NaN's, for which there was no previous experience.
------ End of Forwarded Message
------ Forwarded Message
From: Frédéric GOUALARD <Frederic.Goualard@xxxxxxxxxxxxxx>
Date: Mon, 23 Nov 2009 11:51:19 -0600
To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
Cc: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
Subject: Re: M0008.02_Exception_Handling NO
> Frédéric Goualard wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I vote NO on Motion 8.02 on the following grounds:
>>
>> Decorations as proposed by Motion 8.02 have the potential to greatly
>> enhance the usefulness of interval arithmetic libraries. I have no doubt
>> about that.
>>
>> On the other hand, I believe that the standardization process should
>> sanction techniques and practices that stood the test of time.
> [...]
>> More broadly, I am in favor of standardizing only what is already known
>> to work and to be useful. Let us add powerful additions like decorations
>> in the next version of the standard, once the first simple one is widely
>> accepted and implemented.
>
> Note the the IEEE754 standard also introduced directed rounding and
> NaN's, for which there was no previous experience.
Or did it? My understanding was that Intel already had a conforming chip
(i8087?) before the standard was even voted thanks to Kahan's early work.
------ End of Forwarded Message
------ Forwarded Message
From: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>
Date: Mon, 23 Nov 2009 12:31:59 -0600
To: Frédéric GOUALARD <Frederic.Goualard@xxxxxxxxxxxxxx>, stds-1788
<stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: M0008.02_Exception_Handling NO
Frédéric,
I'm not sure about the actual timing, but I always knew the
8087 as the "IEEE chip." It is not uncommon for vendors to
implement the standard before it is actually official. They
run the risk of the standard being changed a little, but
they have the advantage of a conforming product right away.
Does anyone care to try out the "decorated intervals" proposal?
(For instance, it might be built on top of INTLAB.)
Best regards,
Baker
------ Forwarded Message
From: Michel Hack <hack@xxxxxxxxxxxxxx>
Date: Mon, 23 Nov 2009 13:24:35 -0600
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: IEEE 754-1985 and Intel 8087
(Let's not misuse a "Subject:" reserved for voting!)
The Intel chip did come out before the standard, and indeed there were
several deviations, some of which got corrected in later versions.
One of the issues that got settled late was the decision to support
only one kind of infinity, signed affine infinity, and to drop the
unsigned projective infinity. There were also changes with respect
to NaNs and so-called "pseudo-subnormal" entities (if I can trust my
memory; my "8087 book" is at home and I'm not).
The whole thrust of the Kahan-initiated effort was however to enshrine a
complete set of floating-point primitives, not just common practice which
at the time was a scattered set of incompatible formats and features.
Here I want to stress "complete" -- precisely to avoid that missing but
needed features would be implemented in diverging and incompatible ways.
It is true that some things were overspecified and thus never fully
supported, such as the exception model (which may have been adequate
in its time but is problematic in today's multicore world), and others
were underspecified and thus led to incompatibilities which 754-2008
had to carry along -- but on the whole I think it was rather successful.
To get back to Motion 8: this is 1788's attempt at laying the proper
foundations for exception support. SOMETHING is needed, and so the
issue CANNOT be deferred to a "revised 1788" -- otherwise we will end
up with grossly-incompatible disjoint "solutions".
Michel.
------ Forwarded Message
From: Bob Davis <bob@xxxxxxxx>
Date: Mon, 23 Nov 2009 14:29:48 -0600
To: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>
Cc: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>,
"stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
Subject: Re: Standardizing existing practice or not?
Baker,
New techniques and libraries for Interval Artitmatic are or will be
developed and written over the next decade, of generation, by the
members of this committee or by their students as an ongoing process.
The operations will be carried out on devices that we are surely not
aware of yet in bits or Qubits, or on organic problem solvers.
Speed of computing the answer to an operation is always brought forward
to boost a particular algorithm/method over another. The rate of change
of the processing power continues to increase making those arguments
relatively less important. As I recall, subject to a better memory, in
the floating point math, much, much less than 1% of the computational
time was actually spent on actual FP operations, except in one or two
concocted cases, while the remainder was just handling the data. I
suspect the same will hold for IA. The usefulness of IA is probably not
computationally speed driven.
IEEE 754 served the industry well by making sure that users got the SAME
answer for a given operation with the same input regardless of the
technique, hardware or software used to get the answer. P1788 could
strive for a similar success story.
The SAME answer is not necessarily always the most correct answer, which
may be arguable, but is more useful. Reproducible results of IA
operations, defined independently of specific library, or algorithm,
should foster the use of IA.
My $0.02 on this.
Respectfully,
Bob Davis
------ Forwarded Message
From: Sylvain Pion <Sylvain.Pion@xxxxxxxxxxxxxxx>
Date: Tue, 24 Nov 2009 11:12:49 -0600
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: M0008.02_Exception_Handling NO
I vote NO for motion M0008.02.
It's obviously important to know about discontinuities and
other exceptional events in interval computations, but I would
prefer to see this addressed in the standard by introducing
variants of functions which return some additional information
separately, and leave the propagation rules outside of the
standard completely.
The motion text is too imprecise for me at this stage to agree
on the particular direction it proposes. For example, not
specifying which properties are considered can change the
deal : some properties could be altered by an addition
operation, while some others can only be altered by more
complex operations. And if costly operations (say,
division, sqrt, or worse) are the only ones concerned, then we
could consider that the cost of a separate treatment/propagation
of the additional information is amortized, and so
folding this task inside the main decorated-interval
operation would not be needed.
My goal here is to make it *easy* for hardware vendors
to support the critical interval operations. That is,
it should be a relative no-brainer to extend an existing
SIMD unit to support the interval functions of this standard.
Concretely, what I would propose instead would be to have
functions like sqrt(x) which return an interval y, together
with the "exceptional" information in a separate (integer) register i.
This should vectorize without problem, with an accompanying
integer vector-register.
Then if you need to propagate or combine the information
one way or another, you do it by considering the information
registers.
Of course, at the programming language level, one can
encapsulate all the propagation rules the way the motion says
(or rather, says a later motion would specify).
But I think that this part should not be specified in this standard.
This is more a topic for the -er subgroup anyway.
Some other remarks on the motion :
- "trit" is not a very good name to me for {true, false, possibly}
since it does not carry a relation to ternary logic specifically.
tribool might be better (as in boost::tribool for those who know
about this class). Maybe 4 values might find more use and still
fit in 2 bits. The C++ interval proposal comes with a bool_set class
representing {true, false, true_or_false, neither_true_nor_false}.
(I don't claim this name is better, for the 4th value can be useful)
- I can't make sense of the rationale paragraph for limiting
the trits to 5 since it only considers bare decorations.
- In my experience using IA for controlling rounding error propagation,
I never needed those exceptions. However, there is one place where
I use C++ exceptions, which is when comparing intervals. Strangely,
this does not seem to be covered by the motion, although the text
is fuzzy enough that we could interpret it as if it did (?).
Note : the C++ interval proposal makes the comparison operators return
a bool_set object mentioned above.
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/
------ Forwarded Message
From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
Date: Tue, 24 Nov 2009 11:29:05 -0600
To: Sylvain Pion <Sylvain.Pion@xxxxxxxxxxxxxxx>, stds-1788
<stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Vectorizing motion 8
Sylvain Pion wrote:
> My goal here is to make it *easy* for hardware vendors
> to support the critical interval operations. That is,
> it should be a relative no-brainer to extend an existing
> SIMD unit to support the interval functions of this standard.
>
> Concretely, what I would propose instead would be to have
> functions like sqrt(x) which return an interval y, together
> with the "exceptional" information in a separate (integer) register i.
> This should vectorize without problem, with an accompanying
> integer vector-register.
> Then if you need to propagate or combine the information
> one way or another, you do it by considering the information
> registers.
I also agree with all of this, although IMHO what you describe is a concrete
implementation of a decorated interval. So it is an example of a (would-be)
conforming implementation.
For example, if the values in the integer registers are not propogated, then
this can be viewed as a "forgetful" operation.
> Of course, at the programming language level, one can
> encapsulate all the propagation rules the way the motion says
> (or rather, says a later motion would specify).
> But I think that this part should not be specified in this standard.
I agree.
This was by design.
Sincerely,
Nate
------ Forwarded Message
From: Jean-Pierre Merlet <Jean-Pierre.Merlet@xxxxxxxxxxxxxxx>
Reply-To: "Jean-Pierre.Merlet@xxxxxxxxxxxxxxx"
<Jean-Pierre.Merlet@xxxxxxxxxxxxxxx>
Date: Thu, 26 Nov 2009 06:48:22 -0600
To: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: M0008.02_Exception_Handling YES
My vote is reluctantly YES. I feel that exception handling at the
interval level will not be sufficient and that treatment at the
expression level will be necessary. But what is proposed may be
sufficient to handle relatively simple cases
------ Forwarded Message
From: Gilles Chabert <gilles.chabert@xxxxxx>
Date: Thu, 26 Nov 2009 10:22:34 -0600
To: "owner-stds-1788@xxxxxxxxxxxxxxxxx" <owner-stds-1788@xxxxxxxxxxxxxxxxx>
Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: M0008.02_Exception_Handling NO
I vote NO, following Sylvain Pion's arguments
------ End of Forwarded Message
------ Forwarded Message
From: Vincent Lefevre <vincent@xxxxxxxxxx>
Date: Fri, 27 Nov 2009 10:54:04 -0600
To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
Subject: M0008.02_Exception_Handling YES
My vote is YES.
Note: I haven't had the time to read all the discussions yet. But
the end of 3.4 (about a possible hardware representation of bare
decorations by a pair of FP numbers, one or two of which being a
NaN) is a bit surprising. This representation is fine (though more
or less a hack) if the goal is to have a common type allowing to
represent a bare interval and a bare decoration at the same time,
but this doesn't seem to be really useful: if one wants to deal
with decorated intervals without much restriction, one would then
need a tuple of 4 FP numbers, which would be inefficient...
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Attachment:
Motion8.02.pdf
Description: Motion8.02.pdf