Dear colleagues,
I vote NO on motion 24.02:RoundedOperations due to the reasons given
by Michel Hack.
I would vote YES after changing the text according to the
suggestions mentioned below.
Best regards,
Andreas
Am 16.05.2011 17:49, schrieb Michel Hack:
I vote NO because the wording is both too specific and not inclusive enough.
I do support the underlying ideas (as do many others here who voted NO), and
would vote YES if the text were changed along the lines I have suggested
before. I'll repeat this, with some elaboration on "essential":
Every (essential) IEEE-754 arithmetic operation shall be provided
in a form with an explicit rounding direction, in addition to the
usual forms that respect a static global rounding direction. All
rounding modes provided for a given radix shall also be supported
in this manner.
The essential operations are addition, subtraction, multiplication,
division, square root, and type conversions (different precision or
different radix). (Question: what about fma?)
I'll note that IEEE 745-2008 already supports this for conversions to and
from integers or strings (but not for plain type or "cast" conversions).
Cast conversions are of course a language issue, and explicit rounding is
not really applicable here unless the rounding were associated with a type
(which no language I know of supports today). I'm therefore talking about
explicit conversions, which could for example be modelled after 754's
integer conversions, e.g.:
formatOf-convertFormatTowardPositive(source)
Now, what do I object to in the current Motion 24.02?
It is (still) too specific: "...by distinct operation codes"
and "...SHALL be callable as a single instruction".
Perhaps the use of "operation code" and "instruction" is a bit
inflammatory. Why is it not sufficient to say "shall provide
the 8 operations"?
It is also not inclusive enough, unless confined to a context
with a single floating-point type. Whether square root and/or
fma should be covered might be open to debate, but including them
would provide a clearer picture in the context of 754-2008 at least.
Of course, the downside of my proposal is that it ties 1788 to 754,
something we have not committed ourselves to, I think. Perhaps some
less inflammatory text than the current M24.02 could be used, followed
by the above as an interpretation in a 754 context.
(As an aside, I'm not sure I understand why Fortran's "x .addup. y" is
worse than using functional notation such as "addp(x,y)" -- it seems to
me that Fortran comes closer to the notion of "+>" as an infix operator.)
Michel.
P.S. When it comes to applying this notion to transcendental functions
we'll run into some difficulties, even when requiring no more than
reasonably-tight inclusion: what to do for functions like arctan()
where the mathematical endpoint may not be representable, and the
required outward rounding would lead to a range trespass?
(I'm well aware that we far from having to discuss this issue...)
---Sent: 2011-05-16 16:24:34 UTC
--
Dr.-Ing. Andreas Rauh
Chair of Mechatronics
University of Rostock
Justus-von-Liebig-Weg 6
D-18059 Rostock, GERMANY
Tel: +49 (0)381 498-9216
Fax: +49 (0)381 498-9092
e-Mail: andreas.rauh@xxxxxxxxxxxxxx
|