[std-interval] More on interval computations as proofs
Hervé Brönnimann
hbr at poly.edu
Fri Oct 6 08:57:14 PDT 2006
On Oct 6, 2006, at 5:55 AM, Sylvain Pion wrote:
> My personnal opinion here is that the speed gains here are not worth
> duplicating the interface of many functions. So, for the proposal
> right now I would go for a global (thread-local) flag. If the
> committee
> disagrees from a C++ point of view and wishes something else, then
> fine,
> we'll adapt. But we need to write something now.
In light of the whole discussion (which I've been following day-to-
day, even though I kept silent), I do not see a better solution than
a thread-local flag. As Guillaume pointed out, the cost is minimal
(typically even though the flag may be raised more than once in the
code of a function, it'll be raised only once per execution path, so
the extra cost should be a single memory access, which can be
expensive but certainly less than raising an exception).
In the case pointed out initially by John Pryce (the million-element
array processed in parallel, one element of which raises the flag), a
single thread-local flag will not allow to detect the source of the
domain error, so it would take (in a good implementation using binary
search) twenty iterations to find this source. An instance local
flag (per interval, propagated a la NaN) would allow the localization
readily, yet there is a definite overhead which is not reasonable to
assume for a general purpose library. If the cost is bearable by the
user and it is important to her that the flag be per instance and
propagate, it is easy enough to write a simple wrapper around a pair
of interval and bool that ORs the global flag and the argument's
flags into the instance and resets the flag after every operation
(note there are no conditionals involved). In fact, with more
knowledge of the implementation details, it is possible that the user
can apply optimization like using NaN (which we can't rely on in the C
++ standard that does not assume IEC 559) or using a particular
unused bit in a class that holds the interval if that is the
application setup, in order to get rid of the extra bool requirement
(which due to alignment could be expensive). In this respect, the
extra local bool is akin to passing a status variable. Again, this
can be done by the user, and I expect Boost-like libraries to be
circulated around to fill this gap if a "plain" C++ interval is part
of the standard.
So I feel like Sylvain and Guillaume that this thread-local global
flag is a good compromise suitable for a C++ standard. And again, as
Sylvain stated, we are of course flexible to adapt to future
recommendations.
Now about the standardization aspect of this, I'm now quite familiar
how errno is mentioned in the current revision of the C++ standard,
so I looked it up, and it is how I thought: only by reference to
<cerrno> and <errno.h> from the C standard. So phrasing this new
thread-local flag in standardese is not supported in the current
standard unless threading is somewhat introduced, which Lawrence says
it will (and I do hope so). Meanwhile, what should we do for the
current proposal? I would suggest to propose a wording in case
threading is part of C++0x or TR2 (remember that this proposal aims
for TR2 at best, not C++0x), but to leave it in the current proposal
as a suggested QoI feature with a strong recommendation to
implementers. The main focus of this proposal is to get the basics of
intervals (rounding mode, proper inclusion property in all cases)
right, and although flags would be desirable for many applications
discussed in this list, I still see a use for intervals without the
flags (mostly for efficiency and compiler support). So I do not
think it necessary to *tie* this proposal to a global flag.
I expect Sylvain, Guillaume and I to further discuss this issue among
ourselves while we try to amend the text of our proposal, but I
wanted to raise this question to the list to give the opportunity of
feedback (esp. from those familiar with the standardization process).
Regards,
--
Hervé Brönnimann
CIS, Polytechnic University
hbr at poly.edu
More information about the Std-interval
mailing list