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

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