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

Re: On some reverse-mode functions



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.
>