Re: As simple as it is now, I am still against motion 24.03...
Vincent Lefèvre wrote (about the requirement for direct-rounded operations):
> It seems that the only goal of such a requirement is for a particular
> implementation, as said in the introduction: "On the computer the
> lower bound of the result of an interval operation is computed with
> rounding downwards and the upper bound with rounding upwards." But
> from my reading of the document, it doesn't bring anything for the
> user of the standard.
Perhaps that was the only goal prof. Kulisch had in mind, but that's not
at all how I feel.
You have to realise that there are different classes of "users" who can
benefit from a standard:
(1) end-users, who want a predictable environment for doing their work.
(2) library writers, who want a predictable set of primitives in order
to provided the full functionality needed by group (1).
(3) compiler and basic runtime writers, who need to know what primitives
to provide for both (1) and (2).
Those are all on top of hardware vendors, who provide the primitives needed
primarily by group (3), as groups (2) and (1) use them in contexts that are
progressively more removed.
As most of you know my interests lie towards the bottom of this hierarchy,
and the comments I made about using explicit directed operations alongside
interval primitives apply mostly to group (2). Since group (2) is in a
position to implement parts of a conforming IA environment, it does not
need the full complement of standard functions, but it can benefit greatly
from standard versions of those functions it wants to build from.
A standard that only addresses group (1) leaves a lot of uncertainty for
groups (2) and (3), and therefore makes it more difficult to achieve what
is needed by group (1). It comes down to ease of implementation, and we
should pay at least SOME attention to that, notwithstanding the possibility
that changes in the availability of primitives may change the factors that
affect implementability.
Also, not every environment is vertically integrated to the point that one
vendor provides everything from hardware through libraries -- and even if
there is, competition is healthy, and it should be possible to develop
alternatives at layers (3) and (2) (e.g. gcc vs proprietary compilers).
Michel.
---Sent: 2011-06-10 15:14:49 UTC