Re: On some reverse-mode functions
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Baker,
On 06/06/2014 02:27, Ralph Baker Kearfott wrote:
> Frédéric,
>
> So...
>
> Do you vote "no" and would you change your vote to "yes" if the
> changes you pointed out were made?
Sorry for not following the format agreed upon for the voting period.
This mail was meant as a follow-up to previous ones sent *before* the
voting period, and I was more expecting new comments or
counter-examples to my arguments.
As I see it, the danger is more about mandating functions that will
never be used than about incorrectness issues. If nobody voices
strongly against my proposal, maybe we could stretch the definition a
bit and consider it as a friendly amendment?
Otherwise, even though I am not happy with the way the section on
reverse-mode functions is written now, I think I could live with it.
Consequently, I would not vote against the current document if it
means delaying further the acceptance process.
Best regards,
F.
>
> Baker
>
> On 06/05/2014 04:37 PM, Frédéric Goualard wrote: Dear all,
>
> Some time ago I voiced my opposition to having the functions
> divRev1(), divRev2()---and, I guess, recipRev() too---included in
> the standard (see Table 10.1 in D9.2). I would like to clarify here
> what are my concerns about these functions:
>
> As Michel Hack pointed out, divRev1() and divRev2() are useful to
> narrow the domains of X and Y in the relation:
>
> X/Y=Z
>
> Dmitri Nadezhin added that the relations X/Y=Z and X=ZY are not
> equivalent since the tuple (X=0, Y=0, Z=1) belongs to the second
> one but not to the first.
>
> Obviously, they are both right. And yet, in the context of
> constraint programming---the precise setting for the benefit of
> which these operators are introduced---I believe the relations
> X/Y=Z and X=ZY SHOULD be equivalent to prevent most users from
> nasty bitings when modeling their problem.
>
> Consider the following Prolog IV program:
>
> ohmslaw(E,R,I):- E = R .*. I.
>
> which enforces the relation E=RI (Ohm's law). With E\in[0,10],
> R=0, and I\in[1,2], we may narrow the domains as such:
>
>>>>>> E=cc(0,10), R=0, I=cc(1,2), ohmslaw(E,R,I).
>
> The answer will be:
>
> U = 0, R = 0, I ~ [1,2].
>
> If the resistance between two nodes is null, the potential
> difference is also null. All fine and dandy.
>
> Now, the user could have written Ohm's law as:
>
> ohmslaw(E,R,I):- I = E ./. R.
>
> For most users, the two models should behave equivalently (that is
> what is written in most EE textbooks anyway).
>
> And yet, the above request will now yield a different outcome:
>
>>>>>> E=cc(0,10), R=0, I=cc(1,2), ohmslaw(E,R,I).
>
> false.
>
> Since the denominator shall not be equal to 0 as per P1788's
> definition of the interval division, there is now no solution.
>
> Evidently, all these results are correct if we consider the
> definitions given in the standard, and the difference between the
> two request should be expected. Nevertheless, this would be not at
> all obvious to most users.
>
> Cleary's paper (Logical Arithmetic. John G. Cleary. Future
> Computing Systems 2(2), pp. 125--149, 1987), which introduces the
> use of interval arithmetic in Prolog to obtain a more logical
> arithmetic and to solve constraints, never considers the division
> relation per se, and it seems clear from the text that such a
> relation should be stated through multiplication (hence, X/Y=Z is
> equivalent to X=YZ).
>
> We can forgo the X/Y=Z relation (and then divRev1(), divRev2() and
> recipRev()), and use the X=ZY relation in its place. In theory,
> the price to pay would be less narrowing of the variable domains
> for some applications; on the other hand, allowing the X/Y=Z
> relation means a loss of solutions whenever it is misused, and it
> is very easy to misuse.
>
> I have yet to see models that would benefit from the X/Y=Z
> relation. Some systems have offered it in the past (most
> prominently Prolog IV) but I believe it was more for symmetry and
> completeness than for anything else.
>
> If anyone knows a problem model that positively requires the X/Y=Z
> relation, please share it with us now. Otherwise, let us not
> clutter the standard with unused functions. There are already so
> many to implement.
>
>
> FG.
>>
>
>
- --
Frédéric Goualard LINA - UMR CNRS 6241
Tel.: +33 2 76 64 50 12 Univ. of Nantes - Ecole des Mines de Nantes
2, rue de la Houssinière - BP 92208
http://frederic.goualard.net/ F-44322 NANTES CEDEX 3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTkYroAAoJEIyjRWvAvCeC1+wH/RylaCjJeq9cT7c2R6DXdwCG
Pm9anQsqODAnClxWkZv6FiziKxdx9fIAUv78acDNvYP5xFgYpcNG1PqdemxmJ7gj
a9L9GLT+10N+OTzM815F7+Dp2KWoKIeDQyY/on7dkfo35D7sqywgn/NtSWx2u5we
6fipbxY45rVSZ7uMzJkznkxR34a4uZi5Z2ZtRHEeh1UZqt9bw8epN3kRi9jjwiUd
TUrvR/6Cd1SzTvJJ4A4F2GWKtka1Oedw3hpkwhkR1Q04rm+vfmNXEP9wLlX+Riwu
XEMKU7wKrsRuxB7DQ4x8NL06t2R122ZFI1UQXP58sWlXP0xdS+LbWvJAjiG3xDk=
=xekT
-----END PGP SIGNATURE-----