[std-interval] More on interval computations as proofs

Sylvain Pion Sylvain.Pion at sophia.inria.fr
Sat Sep 30 15:45:15 PDT 2006


Gabriel Dos Reis a écrit :
> Sylvain Pion <Sylvain.Pion at sophia.inria.fr> writes:
> | An alternative implementation is to have a global flag like errno,
> 
> I would not support that.  Global variables pose significant problems,
> both for users and implementers -- these days errno really is a
> function.  Specially in multi-threaded environment (C++ is seriously
> considering concurency).

Actually, I mentioned errno on purpose because it is thread-safe.

I am not sure about Lawrence's argument about the cost of "side-effect".
The side-effect here would be well delimited, to one global
(thread-local) variable.  Can't compilers notice this particular case ?

An implementation could simply be:

   inline
   interval operator/(interval i, interval j)
   { return internal_division(i, j, &global_flag); }

in which case the compiler has a vision of the code which is very
close to Juergen's proposal.  The difference is that we pass
the address of a global variable, instead of one which might
live on the stack.  What kind of optimizations are prevented
by this?


Moreover, functions on floating-point types like std::sqrt()
already use errno, so, should we be more picky about performance
for intervals ?  Consistency with floating-point functions might
be desirable here.  The speed impact would be less for intervals
than for floating-point anyway (since there's more to do for
intervals).  Functions needing top-efficiency ( + - * ) don't
need it anyway.  Division is already relatively slower, it
would not change it much.


Now, for users, what would be more comfortable ?
I personally never needed this feature, so I can't really tell.
It seems to me that having to pass an additional flag to each
function call, and not forgetting one, is risky, painful to do,
and produces code which is not easily readable.

If we really need 2 different functions for efficiency reasons, we
can keep the same names but put them in different namespaces (and/or
use a concept_map to remap them), while still using a global flag
for the version which cares.

I think the proposal would be nicely simplified if we had this
flag stuff supported by default in all functions that care.


(side note : actually, if we had concepts with contexts, I think
              the problem would be solved nicely, but it's not part
              of the current concept proposals :(
)

> Another alternative design could throw an exception.

I fear it might be too costly.  Throwing an exception with GCC costs
20,000 cycles (Sun does better, although my measurements date back
from several years).  For some codes, it can be an important efficiency
problem.  This is one of the main reasons for introducing bool_set
instead of throwing, and I fear it is the same issue here (?).

-- 
Sylvain


More information about the Std-interval mailing list