Re: On some reverse-mode functions

[Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I agree
Jürgen

Am 07.06.2014 12:47, schrieb Joy's MacBook admin:

Baker, Frédéric, P1788

I see four reasonable options:
(a) Leave reverse-mode functions as they are.
(b) Keep divRev1(), divRev2() and recipRev() in existence, but change their definition to be equivalent to the corresponding multiplication as Frédéric suggests.
(c) As (b), and demote them to recommended.
(d) Remove them.

I don't like (b) for the reason I said before: 1788 uses the standard set-theory definition of a function, which this ad-hoc change contradicts.
I think (c) is no better.
I rather prefer (d). First, for the sake of K.I.S.S.; second, because a programmer who wants these functions can define them in terms of mulRev(). In C, I think, they can be inline definitions that incur no performance penalty?
Also, if constraint programming is usually implemented by some sort of compiler or source interpreter, there is no cost in changing X/Y=Z to X=YZ.

John Pryce

On 6 Jun 2014, at 12:45, Ralph Baker Kearfott wrote:

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.