Re: Motion 11
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Nate and all,
Nate Hayes wrote:
> [ some part of the message snipped]
>>> A=[0,2]
>>> B=[-1,1]
>>> C=[1,1]
>>>
>>> with \circ=\times
>>>
>>> and compute \times_1^-(B,C,A) = hull({x\in[0,2]\mid\exists
>>> b\in[-1,1], x\times b\in[1,1]})
>>>
>>> Can you obtain [1, 2] as a result? The n+1-ary reverse division will.
>>
>> Ah, yes. We have discussed this before.
>>
>> Still, I believe that the answer is that such a result
>> CAN be obtained with the proper inverse of B. But I'll
>> let Nate describe the details.
>>
>> Nate?
>>
>
> In this example, my observation is reverse mode appears to be the same as
> the normal interval expression
>
> ([1,1]/[-1,1]) \intersect [0,2].
>
> Kaucher/modal arithmetic is an unrelated topic, I believe.
>
> IMO, the only tricky issue of Frederic's example appears to be how to deal
> with the fact division by [-1,1] bifurcates the problem into two disjoint
> interval results.
>
> On the one hand, reverse mode gives [1,2] in a single operation. On the
> other hand, bisecting B=[-1,1] into B_1=[-1,0] and B_2=[0,1] at the
> branch-cut and then processing each side with normal interval operations
> yields
>
> branch1: ([1,1]/[-1,0]) \intersect [0,2] = empty
> branch2: ([1,1]/[0,1]) \intersect [0,2] = [1,2].
>
> This gives the same result [1,2] obtained by the reverse mode operator.
>
> So the question in my mind is: does a dedicated reverse-mode operation in
> hardware provide benefit over using the normal interval operations? My
> feeling is a deeply pipelined interval processor will compute the normal
> interval operations very quickly. A more scientific analysis might be
> helpful. :)
>
> The same applies if A=[-2,2], however in this case it seems clear to me the
> normal interval operations are more desireable, i.e.,
>
> branch1: ([1,1]/[-1,0]) \intersect [-2,2] = [-2,-1]
> branch2: ([1,1]/[0,1]) \intersect [-2,2] = [1,2]
>
I agree with you, Nate, that what you propose is indeed an easy means to
achieve by branching the same result as reverse division. Other reverse
operators (say, reverse arccosine) are not so easily dealt with, though.
In particular, reverse trigonometric operators would require some
support from the standard for interval-based argument reduction
available to the user if we do not want him/her to have to perform
correctly rounded floating-point operations (him/her)self.
So the whole question boils down to this: should reverse operators be
first-class citizens (meaning: implemented as efficiently as the other
operations) or second-class citizens (meaning: implementable by
developers with some low-level support from the standard) in the
standard? Only the interval community at large can decide on this issue.
F.
- --
Frédéric Goualard LINA - UMR CNRS 6241
Tel.: +33 2 51 12 58 38 Univ. of Nantes - Ecole des Mines de Nantes
Fax.: +33 2 51 12 58 12 2, rue de la Houssinière - BP 92208
http://goualard.frederic.free.fr/ F-44322 NANTES CEDEX 3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLe+mpEJvxJgN8HkgRAgVwAJ9QfUQEdJSgGWj1rYav7u9baUHthQCgrO93
rMZ1DxpksarsNBRH0Yh5UE8=
=MtIs
-----END PGP SIGNATURE-----