Re: Discussion period extended? Re: Motion 11.01 Basic Reverse Interval Operations
P1788
Here is my two-pennyworth on George's "mild argument against reverse operations".
As a matter of overall strategy for the standard, I think we should be ready to admit, into the draft, _some_ material that is important to _some_ serious interval people but not all. Thus the initial draft of the whole standard is likely to be rather too long. There shall then be a Global Revision process, part of whose brief is to prioritise material, and then to decide
(1) Keep as normative text; (2) Keep as informative text; (3) Cut.
This may be painful as people will have conflicting priorities. I think our democratic process will make clear in most cases what stays and what goes. There may be borderline cases where an editorial decision must be taken. I think that's part of the Technical Editor's job and I'm content to do it.
Now to Motion 11. Serious interval people do use reverse ops. (Proof: George admits doing so. The Vienna text includes them.) So I think we should include them now. They _may_ end up on the cutting floor.
HOWEVER. George must be right: ours is a hardware-like standard, so simplicity is critical. Marco, I think your motion 11 operation tables are FAR too complicated. I suggest you make them smaller on the lines suggested by Prof Kulisch. Also, I think the following are true (notation as Vienna 3.11)
timesInv(bb,cc) = { Entire, if 0 in bb and 0 in cc
{ the usual interval cc/bb, otherwise.
divInv1(bb,cc,xx) = { Empty, if bb is singleton [0]
{ the usual interval (bb*cc) intersect xx, otherwise.
(I was unable to produce a similar simple description of divInv2.) Marco, _if_ I have got these right they show the overhead of adding these particular operations, on top of a _hardware_ implementation of the forward operations, is negligible. So they seem worth putting in your document.
Also I entirely agree with Frédéric Goualard's view:
On 16 Feb 2010, at 07:16, Frédéric Goualard wrote:
> I believe with George Corliss that we should keep the standard as simple
> as possible... However, supporting reverse operators adds operators to the
> standard, not complexity. Supporting decorated intervals, that is
> something that added complexity.
>
> ... I am therefore in
> favor of having Marco Nehmeier withdraw his motion for the time being,
> and resubmit a new extended motion that presents all reverse operators,
> together with a document presenting convincing rationales in favor of
> their introduction into the standard...
I will probably vote against motion 11 in its present form, but will almost certainly vote for a motion on the lines Frédéric suggests.
Regards
John
John Pryce
46 Ponting Street
Swindon SN1 2BW
j.d.pryce@xxxxxxxxxxxx
On 21 Feb 2010, at 13:51, wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> P1788
>
> I think the reverse operations cannot be calculated by the other
> functions or operations, hence I think they should be included...
>
> regards
> Juergen
>
>>> From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>>> Date: Tue, 16 Feb 2010 01:50:48 +0000
>>>
>>> I'd like to offer a mild argument AGAINST Motion 11.
>>> I prefer a standard as simple as possible, but that
>>> still provided intervals.
>>>
>>> I agree that reverse interval operations are useful;
>>> I have programmed and used them, too.
>>>
>>> If this were a programming language standard, I would
>>> accept reverse interval operations.
>>>
>>> However, P1788 is intended as primarily a hardware
>>> (or hardware-like) standard. Vendors are more likely
>>> to implement our standard if there is a clear market.
>>> The fewer features we write into the standard, the
>>> easier it is to implement...