Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: On some reverse-mode functions



Frédéric,

OK.  We'll take your vote as a "yes," and consider
your comments as a friendly amendment, unless
there are objections.

Are there objections to the changes Frédéric mentions?
(If so, it will prompt a re-vote on that issue.)

Best regards,

Baker

On 06/06/2014 04:33 AM, Frédéric Goualard wrote:
-----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-----



--

---------------------------------------------------------------
Ralph Baker Kearfott,   rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------