Re: Motion 11
I'm still working on it. I will send my new version of the motion tomorrow.
My intention to write a motion about the basic operations only was to have an analog process as with motion 5 and 10.
And I'm still thinking it is the best way to have a motion about basic reverse operations first and then working on a second motion about
reverse functions.
Best regards
Marco
Am 04.02.2010 um 19:27 schrieb John Pryce:
> Dear Marco
>
> As far as I can see I have not received an answer to my suggestion of 25 Jan, copied below, which Baker also agreed with. Could you please respond to it? I will probably submit an amendment to motion 11, moving that this idea be adopted, in the next day or two -- unless you persuade me otherwise!
>
> John
>
> On 25 Jan 2010, at 14:48, John Pryce wrote:
>> Frédéric Goualard, Marco Nehmeier & P1788
>>
>> On 24 Jan 2010, at 21:00, Frédéric Goualard wrote:
>>> Thank you very much for taking the time to write Motion 11 and submit it
>>> to P1788. I believe that what you call "Reverse Interval Operations" are
>>> very important and should find their place in the upcoming interval
>>> standard.
>>>
>>> I have, however, one regret and one remark:
>>> The regret is that your motion only concerns itself with basic
>>> operations, which is not reflected by its title. Why not consider
>>> reverse cosine, reverse sine, ... ? Constraint programming, for example,
>>> cannot make do with reverse multiplication and reverse division only.
>>
>> Marco, I also am glad you have submitted this motion, but I agree with Frédéric. Arnold Neumaier in the Vienna document proposes -= if I count correctly - 14 functions/operations to be provided in reverse mode. Anyone who agrees with the general concept of "reverse operation" is probably happy to vote for the whole of Arnold's list (give or take one or two, to be argued case by case). As a friendly amendment I suggest: include all 14 (or whatever) in your motion, and phrase it on the lines of Juergen's motion 10.
>>
>> I feel your document could be clearer on what the motion *is*, i.e. what are we voting for? At present this is hidden within the two Definitions, which say "
>> should
>> ". State the motion separately, and say "shall", not "should".