Re: Motion 52: final "Expressions" text for vote
Bill,
> For a system of real, not extended real intervals,
> the domain of div(x,y) and recip(x) can be R^2 and R, respectively.
> See Table 9.1 on page 21.
The table 9.1 gives domain of a POINT function.
It is flavour-dependent what is how interval extension is derived from
definition of the point function.
The interval-extension in the set-based flavour is interval hull of the range of the function.
recip([0,0])=[Empty].
I guess that the interval-extension in the containment-set flavour is interval hull of limits of the function.
recip([0,0])=[-inf,+inf].
This freedom is allowed because there is no common evaluation recip([0,0])=[a,b].
If common evaluation exists recip([1,2])=[1/2,1], then operation in all flavours must return it.
> The ranges of asin, acos, atan, and atan2 functions are unnecessarily narrow.
I don't understand.
What should be interval extension of asin in containment-set flavour ?
> Therefore Section 9 makes it impossible for alternative interval systems
> to be standard conforming flavors.
The Section 9 just defines point operation. It doesn't prescribe how these definitions
are transformed to definitions of interval operation.
> There are many more, including the ability to replace code for a given
> expression or set of expressions with different code as long as the new
> code always returns an enclosure of the containment set defined by the
> original code. Of course, this requires the containment set of any
> existing code to be defined, which has yet to be done; where the
> containment set is just the smallest set of values that must be included
> in the result of any interval computation.
This is more serious restriction. Really, Section 6.1 says
<<<<
Here it is assumed that evaluation of any of these forms is, by definition, done using the
operations exactly as written. E.g., one does not replace an occurrence of x − x by 0, since that
creates a different expression.
[snip]
When evaluated in interval mode, multiple instances of the same variable can lead to excessive
widening of the final result: e.g., evaluating x − x with an interval input x gives, not [0, 0], but an
interval twice the width of x. Thus the question, when it is valid to manipulate expressions—e.g.,
to replace x − x by 0—is of especial importance for interval computation because of its potential
to tighten enclosures. This is the dependency issue, covered in Annex ??.
>>>
The expression is defined in Section 6.1.
It is not defined yet, but
it is straight-forward to define the result of point-evaluation for any of three forms of expression in 6.1 .
<<<<
The evaluation will traverse the code-list and assign values for each input and operation.
When traversal enters an operation "v_r",
v_r = phi_r(u_{r,1},...,u_{r,k_r})
all its inputs u_{r,j} already have assigned values.
If these values are out of the domain of point function, the traversal stops and the expression has no value.
If these values are in the domain, the value of the point function is assigned to the operation "v_r".
If traversal of the codelist finishes successfully, the value of the expression is the value assigned to "v_m".
>>>
How will you define the containment set of a code-list ?
-Dima
----- Исходное сообщение -----
От: bill@xxxxxxxxxxx
Кому: dmitry.nadezhin@xxxxxxxxxx, stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Воскресенье, 24 Ноябрь 2013 г 22:59:26 GMT +04:00 Абу-Даби, Маскат
Тема: Re: Motion 52: final "Expressions" text for vote
Yes.
For a system of real, not extended real intervals, the domain of
div(x,y) and recip(x) can be R^2 and R, respectively. See Table 9.1 on
page 21.
The ranges of asin, acos, atan, and atan2 functions are unnecessarily
narrow.
These are just two examples.
There are many more, including the ability to replace code for a given
expression or set of expressions with different code as long as the new
code always returns an enclosure of the containment set defined by the
original code. Of course, this requires the containment set of any
existing code to be defined, which has yet to be done; where the
containment set is just the smallest set of values that must be included
in the result of any interval computation.
Therefore Section 9 makes it impossible for alternative interval systems
to be standard conforming flavors.
My fundamental problem with the draft standard is that I believe it will
accomplish the opposite of what the authors intended it to accomplish.
That is, rather than increasing acceptance of computing with intervals,
I believe in anything like its present form, the draft standard will
decrease the acceptance of computing with intervals. Its complexity
exposes the fact that the mathematical foundation remains incomplete.
Cheers,
Bill
On 11/23/13 8:28 PM, Dmitry Nadezhin wrote:
>
> Are there some more issues there that may prevent developing
> containment-set flavour or other flavour you are developing in future ?