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)



John and all,

> On Jul 28, 2015, at 9:31 AM, John Pryce <PryceJD1@xxxxxxxxxxxxx> wrote:
> 
> 
> 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 agree. 

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

Will change. 

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

Yes, it will be useful. Perhaps it should be an Appendix, not a Clause? 

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

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

I think it is fine without dashes. 
> 
> p20 there is a "rounded toward +oo", shouldn't this be "rounded toward positive”?

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

Yes, it is non-trivial work. As time allows, I will try to do this. 

Ned