RoundedOperations
FWIW, I would also vote yes for the language Michel proposes. Particularly
to broaden scope to sqrt, conversions, different radix, etc.
However, I make the following note:
IEEE 1788 would only require the operations to be provided in explict form
for rounding modes up and down. Some future version of IEEE 754 could
require providing the other rounding modes, of course. But IEEE 1788 doesn't
need all rounding modes treated equal, as might otherwise be desireable for
such a hypothetical IEEE 754.
As to where in the standard such language might go, IMHO the main text just
needs to introduce the operations and mention they shall be provided, as
Ulrich and Michel have suggested. A comment or non-normative note could
clarify the point that implementers may choose the naming taxonomy and
nature of the implementation.
Nate
----- Original Message -----
From: "John Pryce" <prycejd1@xxxxxxxxxxxxx>
To: "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, May 17, 2011 8:09 AM
Subject: I vote NO on Motion P1788/M0024.02:RoundedOperations
Dear P1788
Putting something on the lines of Prof Kulisch's motion would, I think,
please our "upline" Bob Davis in view of his 2007 letter (attached) that was
seminal in getting this effort underway. And, I support the aims of the
motion. But I also agree with Dan Zuras:
On 15 May 2011, at 18:57, Dan Zuras Intervals wrote:
Don't get me wrong: I think what Prof Kulisch has
in mind is a good idea. The last machine I worked
on before I retired had opcodes for this. It is
just not something that we have the right to demand
(shall) or even ask (should) of our implementers.
So I vote no.
Personally I prefer Michel Hack's simpler wording below. Maybe he and Prof
Kulisch can produce a revised motion on these line.
Early during the discussion I had proposed a much shorter description
that gets to the essence of the proposal; Hossam Fahmy referred to it,
so let me repeat it here: (The complete post was dated April 18)
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.
However we must bear in mind
On 16 May 2011, at 12:34, Vincent Lefevre wrote:
And more importantly, implementations of floating-point operations
belong to IEEE 754, not P1788.
So, where and how would the requirement expressed by Ulrich's words, or
Michel's words, fit into the P1788 document? It's not about interval
operations as such, but about how to implement them. I can see it going into
any of
- A "desirable things" section, either in the introductory material or in an
annex.
- Level 3, which is about the internal structure of intervals, and how
interval operations are implemented in terms of FP operations on their
internal fields. Here the standard might include implementations of the
interval operations at a pseudo-code level in terms of Ulrich's operations,
e.g. Matlab-style
function z = plus(x,y) %overloads +
z.inf = x.inf +< y.inf
z.sup = x.sup +> y.sup;
end
That requires a keen volunteer! We can only say these operations SHOULD be
implemented by a system, whether hardware or a hardware-software mix --
SHALL is not our business, as Dan & Vincent say.
- A Language Level. In essence we already decided P1788 shall have such a
thing, holding material about allowed expression rearrangements, on the
lines of IEEE754-2008's Clause 10. We could add to it that P1788 compliant
language implementations SHOULD include operations with an explicit rounding
direction. I don't see how we can make it a SHALL.
It seems clear to me WHAT is being asked, but not WHO (systems or people)
are being asked to do it. So I vote no to the current motion and hope for a
clearer statement. Or maybe I am just confused.
John Pryce