Re: about emp (was: Motion 42: NO)
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. 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?
My point was: while the code above would do the trick, it is in fact
incorrect. And more generally, it is impossible to write such a library,
whatever the language. But I would be interested in being proved wrong.
> > 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.
> > Note that this issue also occurs with constant constructors. For
> > instance, nobody on this mailing-list expects interval(0.1) to return an
> > enclosure of one tenth for languages that do not support decimal
> > arithmetic. We all know that the compiler will have replaced it by the
> > binary floating-point number the closest to one tenth beforehand. As a
> > consequence, we would all suggest to write it interval("0.1") instead.
> > That process perfectly matches what a quotation is.
>
> Constructors with only one input number, such as interval(0.1),
> have already been rejected.
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.
Best regards,
Guillaume