[std-interval] Revised document available

Dr John Pryce j.d.pryce at ntlworld.com
Fri Sep 15 00:29:03 PDT 2006


Dear std-intervalers,

At 09:16 12/09/06, Sylvain Pion wrote:
>A revised version of the proposal is now available at:
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2067.pdf

I aim to comment on the revised proposal in several separate messages 
addressing various aspects. Here is the first one. The views are my 
own, but mostly shared by the other four members of the ISL project team.

As you will know, ISL favours a cset-based standard. In case readers 
have missed them, please find attached the following.
- The current version of ISL's interval standard proposal, dated 7 June 2006.
   We are working on a revision in the light of [std-interval] discussions.
   In particular we support Lee Winter's arguments in favour of allowing (but
   not mandating) tags.
- The paper by Pryce and Corliss "Interval Arithmetic with Containment
   Sets", accepted for publication in Springer "Computing". This is a
   wide ranging discussion of theoretical and practical issues.

Herve, Guillaume, Sylvain: Your current version improves on the 
previous in many ways. In particular the specifications of arithmetic 
operations are now much cleaner and closer to the mathematics. It is 
now mandatory for I/O to respect inclusion. The C++ code has been 
tidied up, e.g. by removing the "numeric specializations" to float, 
double & long double, which turned out to be unnecessary.

I want to comment first on the use of "undefined". Is it appropriate 
to specify an "undefined" result in so many cases?
E.g. p15-16 #4,10,12,15,... These are functions central to the 
interval system, yet using any of them, even once, makes it 
impossible to assert portability of a program. For a package aimed at 
high-integrity programming this makes no sense.

For instance. At present "interval(NaN)" is mandated to return empty, 
but "interval(NaN, NaN)" need not. What happens if a safety-critical 
program developed on a system where "interval(NaN, NaN)" returns 
empty is ported to one where it returns whole, or some other value, 
or raises an exception?

The vast majority of machines on which interval computation will be used are
- IEEE-conforming;
- used by the general scientific community, for whom portability and
   future-proofing of code is vastly important.

On a non-IEEE machine, if interval computation is used I believe it 
will be for a specialist purpose (e.g. embedded processor in 
avionics). Portability FROM such a machine TO a different platform 
will not be so important.

The standard should respect the needs of both these types of application.

I propose that it leave NOTHING undefined on IEEE platforms, while 
allowing "undefined", "unspecified" or "implementation-defined" on 
non-IEEE platforms. (Maybe the choice between these three options, 
for a platform whose users are not concerned with portability, should 
be left to the house-rules defined by their managers.) Actually, of 
the 10 occurrences of "undefined" in your draft standard text, I 
don't see a reason against changing them all to 
"implementation-defined" for non-IEEE, and giving a specific 
definition for IEEE.

Regards

John Pryce  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpponemodel.pdf
Type: application/pdf
Size: 287752 bytes
Desc: not available
Url : http://compgeom.poly.edu/pipermail/std-interval/attachments/20060914/86ca9033/cpponemodel-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IntvlArithCsets.pdf
Type: application/pdf
Size: 272162 bytes
Desc: not available
Url : http://compgeom.poly.edu/pipermail/std-interval/attachments/20060914/86ca9033/IntvlArithCsets-0001.pdf
-------------- next part --------------
Dr John and Mrs Kate Pryce
142 Kingshill Rd
Swindon, Wiltshire SN1 4LW
UK
Tel (+44)1793-331062


More information about the Std-interval mailing list