Re: about emp (was: Motion 42: NO)
On 2013-02-19 17:40:00 +0100, Guillaume Melquiond wrote:
> Le mardi 19 février 2013 à 16:18 +0100, Vincent Lefevre a écrit :
>
> > > Now let us move to more practical considerations. Let us assume that the
> > > text of the standard ends up giving a clear way to infer an expression
> > > from the user program. How, as a library implementer, should I implement
> > > it in practice? For instance, in C++, I could go the following way for
> > > multiplication:
> > >
> > > interval operator*(interval const &x, interval const &y) {
> > > if (&x == &y) return square_of(x);
> > > else return product_of(x, y);
> > > }
> >
> > If square_of(x) and product_of(x, y) do exactly the same thing, the
> > code is OK. But if they don't, why would a user write wrong code like
> > that?
>
> You missed the point of my email. This is not the code from a user.
Perhaps I should have used the word "programmer" ou "author".
> As
> you know, I am the maintainer of a C++ library for interval arithmetic.
> And my concern is: is it possible to write a C++ library such that, if
> the user evaluates the C++ code "sqrt(-x*x-1)" with x being the interval
> [-1,1], the empty interval is returned?
The empty interval would be incorrect. Why would you want to return
the empty interval?
Note that this was one of my comments about the example in §8.8.3.
I said I disagreed with it.
> > > So, let me state it clearly: I am convinced it is impossible to
> > > write a library that follows your meaning of expressions,
> > > whatever the programming language. Now, it would be possible to
> > > achieve it by modifying compilers, but you have to wonder
> > > whether a feature (from a non-language standard) that requires
> > > modifying compilers is actually useful.
> >
> > No, a library can just ignore any allowed "optimization" related to
> > variables and expressions.
>
> Again, it is much worse than that. Not only can they ignore these
> optimizations, as you call them, but they actually will have to, because
> it is impossible to implement them! So, again, one has to wonder what is
> the point of a standard feature that cannot be implemented.
No, this is not impossible. Of course, this can only be done at the
language level[*] (e.g. by the compiler). Said otherwise, it would
be impossible for libraries, but the standard is not just for
libraries.
[*] By that, I mean where expressions are controlled and can be
analyzed.
> The fact that constructors have one or two inputs is irrelevant. Indeed,
> interval(0.1,0.1) has just the same issue; yet nobody expects it to
> return an interval enclosing one tenth in most programming languages.
I've never disagreed with that (though the current nums2interval
text from the non-public Draft 7.0 contains non-sense, IMHO).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)