Re: about emp (was: Motion 42: NO)
On 2013-02-19 11:00:39 +0100, Guillaume Melquiond wrote:
> First, what is a "code variable"?
[...]
It would be the implementation to define what is a variable and what
is an expression if it chooses to do something specific with them.
> 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?
Note that for interval extensions, it has been chosen that if
f: (x1,...xn) |-> f(x1,...xn)
is a point function, then its natural extension is defined by:
f(xx1,...,xxn) = { f(x1,...,xn) | (x1,...,xn) in Dom(f) and
x1 in xx1, ..., xn in xxn }
so that x * x and sqr(x) can give different results on intervals.
This is not a problem, because their corresponding point functions
are mathematically *different* (one has 2 arguments, the other one
has only one argument). If you choose something different, you'll
have problems when starting to define pow(x,y) in a consistent way
with sqr(x).
> 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.
I'm not against forbidding all such optimizations, but it should
clearly be said in the text of the decoration system.
> 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.
--
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)