Re: As simple as it is now, I am still against motion 24.03...
Vincent wrote:
> Note that if x is a real, then [x,x] is a valid interval.
At level 1 perhaps, but then we get into all that trouble about "exact"
interval arithmetic that we discussed at length ove two years ago.
Later Vincent himself mentioned the trouble with that approach:
> BTW, providing point -> interval functions may be a bit dangerous, as
> a user could write f_interval(1.0/3.0) and this would be incorrect.
But we were discussing the need for support of explicit directed rounding
arithmetic operations as per Motion 24.03.
The trouble is really with the difficulty of expressing the programmer's
intent in higher-level languages. Some operations are well-defined, are
well-supported on some (but not all) platforms, but are inaccessible in
a portable manner, so circumlocutions have to be used. If optimizing
compilers were up to snuff this might not be an issue, but I'm still
waiting after 40 years... So yes, it is a performance issue and not a
functional issue. From preceding discussions (especially the Vienna
proposal) we can expect an IA environment to support interval operations
and bound-extraction primitives, so clearly the functionality is there.
But will the compiler discard not only the dead code leading to the unused
bound, but also the allocation of the intermediate interval variable?
Actually, 754-2008 shows the way, but I have yet to see support, or even
talk about support, of it: application of static rounding directives to
"blocks" that could be as small as a single expression, e.g. in C:
{ #pragma RoundTowardsPositive x = a + b; }
But that's 754 -- and we were not going to tie 1788 to 754. Yet 1788 is
the context in which this issue is most relevant.
As for examples of situations where different rounding directions are
applied to different expressions (as opposed to two directions for one
expression, i.e. plain interval evaluation), I'll remind you again that
there are TWO rather differnet application domains of IA -- and I'm often
thinking about the one that represents ranges (e.g. constraint propagation)
instead of uncertain values (the more common interpretation).
Michel.
---Sent: 2011-06-14 15:23:46 UTC