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

Re: Draft: P1788.1 Standard for Interval Arithmetic (Simplified)



Ned and all

On 27 Jul 2015, at 14:28, Ned Nedialkov <nedialk@xxxxxxxxxxx> wrote:
> I have attached a draft of the basic standard. IEEE did not like “Basic Standard” 
> so it is "(Simplified)”. 
> I would like to invite everybody for comments and suggestions. 

Here are some comments.

Oliver Heimlich thinks "simplified" in the name of the standard might be misleading. I think when implementations become common, it sounds better to say one is using "the simplified 1788" than "the reduced 1788" or "the essential 1788", and I can't presently think of any better word. 

I feel the abstract makes clear what "simplified" means, but to make it even clearer how about recasting the abstract (2nd, un-numbered, page) thus:

  This standard is a simplified version and a subset of the IEEE Std 1788TM-2015 
  for Interval Arithmetic and includes those operations and features of the latter 
  that in the the editors’ view are most commonly used in practice. 
  It specifies interval arithmetic operations based on intervals whose endpoints 
  are IEEE 754 binary64 floating-point numbers and a decoration system for 
  exception-free computations and propagation of properties of the computed results.

  A program built on top of an implementation of IEEE P1788.1 should compile and 
  run, and give identical output within round off, using an implementation of IEEE 
  Std 1788TM-2015, or any superset of the former. 

  Compared to IEEE Std 1788TM-2015, this standard aims to be minimalistic, yet to 
  cover much of the functionality needed for interval computations. As such, it 
  is more accessible and will be much easier to implement, and thus will speed up
  production of implementations.

Similar changes on p2/3-15, Scope and Purpose.

I like Vladik's idea to present a "list of things which are present in the full standard but not here".

p6/1. Remove colon noted by Vladik (not IEEE style)

Vladik's "pp. 20, 21... to avoid confusion of dash with minus...". I think IEEE style requires a dash. Might an em-dash be clearer than the present en-dash?

p20 there is a "rounded toward +oo", shouldn't this be "rounded toward positive"?

Oliver H. comments on p24/17 “NOTE—If ..., this standard becomes a flavor of the full standard.” I think he is correct. It *would* be useful to know for certain just what extra features need adding to make it become a flavor. This is not quite trivial work but not massive. If someone is willing to do it, it would be great (not me, just now). Otherwise it might be best to just delete this Note.