[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