Re: On some reverse-mode functions
John, Frédéric, P1788,
OK. Unless there are objections, we will interpret
Frédéric's friendly amendment to mean (d), that is,
remove divRev1(), divRev2() and recipRev().
Please post any objections to this alteration to the
text as a friendly amendment before the end of the
voting period. (Such objections would cause us
to re-vote the issue.)
Baker
On 06/07/2014 05:47 AM, Joy's MacBook admin wrote:
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.
--
---------------------------------------------------------------
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
---------------------------------------------------------------