[std-interval] More on interval computations as proofs

[Sylvain Pion]

Gabriel Dos Reis a écrit :
> Sylvain Pion <Sylvain.Pion at sophia.inria.fr> writes:
> 
> | 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.
> 
> because implementers have taken extra step to make it so.  Furthermore,
> even when each thread has been made to use its own view of errno, it
> still fails the composition test:   Think of
> 
>     c = f(h() + i(), y());

Sorry, I don't see what's the problem with this code.
This smells like sequence-points, which I am clueless about...
Care to give more details?

> Neither, the C, neither the C++ standards say it is thread safe.
> Essentially, one needs thread-local storage -- which none of the
> standard proposes.   You could make the argument that the standard
> library does not need to be written in standard C++, but that would
> start pushing the limit.

I think we all agree.  Threads are not standard C++ yet, so any argument
can go in any direction.  In practice, errno is supposed to be
thread-safe, for a practical definition of thread.  For a future
standard definition of thread, well...  we'll see.

I'm not sure I guess right what you're saying by "proposes", but
threads and thread-local storage are both being worked on for C++
(See Lawrence's N1966 for TLS:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1966.html).
(just in case you missed it)

In a future with standard threads and accompanying TLS, then I don't
see what would be the problem with a global, thread-safe errno,
implemented using TLS.  Exceptions might be better on the paper,
but they are damn slow in practice in some cases (don't ask me why,
maybe it's simply poor compiler implementation and we should not
make decisions based on such observations).


 > I would suggest not to explore the errno route.
> errno is supported only for historical reason.  If it were to be done
> again with hindsight, I suspect it would be done differently.

Well, on the other hand, I have seen no proposal to replace its
functionality by anything else...  like std::sqrt(double, bool &flag)
or exceptions, or whatever.  Are you aware of any work along this line?

If people who use this functionality don't like errno, then what
exactly do they prefer instead?

> | Now, for users, what would be more comfortable ?
> 
> As a user, I would definitely not to have to deal with errno.  It is a
> back hole.  Its proper use requires tests at every stages, i.e. a
> maintenance nightmarre.  Part of the reasons why we got exceptions in
> the first place. 

OK, but then you agree that the proposed extra flag argument also
requires code modifications at every stage (even more so).
And exceptions are slow.
Sounds like the world is not perfect :(
Given this state of affairs, I'd go for simplicity of the interface
(the less functions/variants we have, the better), and consistency
with existing practice (errno or another global variable) to reduce
the learning complexity.

> | (side note : actually, if we had concepts with contexts, I think
> |               the problem would be solved nicely,
> 
> How?

Not that I went far enough in my thoughts on this, unfortunately,
but concept_maps can currently rename functions (provided you are
in a template function and you specify the concept).  If
concepts supported concrete data as "data member", which somehow
you could use in the "redefinitions" of functions in the concept
maps, but which would not appear at the call sites, and which would
be passed invisibly to functions parameterized by these concepts,
then we would be set, since the concrete data would specify which
flag variable to modify (global or not), and the calling syntax
would not mention it.

While at it, I believe concepts would help a lot for specifying
which set of comparison operators one wants for intervals.
Currently, the interval proposal does not mention concepts, and
puts comparison operators in separate namespaces.  But if you
write a template, you can specify the semantic of the comparison
operators as part of the concept.
And you can write concept_maps for the interval class which
map to the corresponding comparison functions.

(NB: With Jeremy Siek's additional paper, we could have several
  concept_maps per concept+type pair, which would be better,
  but still far from the 100% flexibility of my dreams. )

Anyway, I hope I am clear enough.
Of course, there are a lot of ifs and optimism here :)


> | 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).
> 
> yes, it would be interesting to have recent data.

I filed a GCC bug/enhancement report 4 years ago about this issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6588
I just checked with a 2 months old GCC, and it is still as slow.

 > Also, as you said,
> you would essentially have two versions -- one "safe", throwing;
> another one potentially "unsafe", non-checking non-throwing.

I may look as against progress here, but I'm still not convinced
that we need to depart away from an errno-like solution.
(Of course it can be a different variable from errno, if the
point is to avoid mixing all kinds of errors in the same variable.)

-- 
Sylvain