[std-interval] C++ interval std

[Sylvain Pion]

George Corliss wrote:
> FYI:
> 
> Wednesday, March 29, Sun Microsystems
> Ned Nedialkov and I (George Corliss)  with quite a few Sun people.
> Here is my visit report:

Thanks for the report.

> C++ compiler developers:
> Steve Clamage <Stephen.Clamage at Sun.com>
> Lawrence Crowl <Lawrence.Crowl at Sun.com>
> 
> Steve and Lawrence are both members of the C++ Committee (J16),
> representing Sun. Steve is the chair of J16.  It was Lawrence
> who wrote the comment to the this group in early March about
> passing by value.

Note that I am attending the ISO C++ meeting this week in Berlin,
so I will have the opportunity to present the status (briefly, as
I don't think we are ready to show a concrete update adressing all
the comments), and discuss with Lawrence and Steve.

> The discussion was quite wide ranging, but here are some points.
> 
> The standards committee is also considering user-defined literals.
> If they adopt something there, we can probably use whatever is
> adopted for our problems of literals in an interval context.
> 
> Sun has an open source release of its interval elementary functions,
> so the barrier to entry is low.  That means we CAN require math.h
> functions be provided in an interval standard.

There are also other open source implementations available.
However, at the presentation in Mont-Tremblant, the committee was
a bit reluctant to add more "complicated numeric functions" to
the standard, because there was other proposals with such a common
theme.  So the question might boild down to whether we prefer to
have nothing or an incomplete library.

I however agree that this would make the proposal attractive to more
users, and that the more complete implementation based on existing
codes is probably not that hard.

> Lawrence feels strongly that the standard should be to pass by
> value.  Intervals are small data structures; by value allows them
> to be passed in registers for speed.  That is how the current Sun
> C++ compiler works.  There is no reason to follow the C++ complex
> standard.  The library is often taken as an example by coders, and
> there is no good reason to follow the tradition of C from 20 years
> ago that structures should be passed by reference.

I don't have any strong opinion on this.
I only did a very local experiment on some code of mine on x86, and
changing to pass-by-value slowed the code down a bit.
I am ready to follow any recommendation from the commitee on this.
I tend to think that there should be a general policy for the standard
library, otherwise I fear that the library might become inconsistent
in that respect.


> Infinities, etc.  Define mathematically what you must contain, and
> permit as much implementation creativity as you can.
> 
> At this point, correctness is MUCH more important than speed.  When
> people start demanding intervals be fast, we'll know we've won.
> Having tests in each operation is not a problem.

Well, if we're arguing that passsing-by-value is fundamentally important
for speed, and that adding a few more tests is not because speed is less
important... ;)

It's important to get the semantics that most people want first,
I agree.

> Uninitialized.  The convention in C/C++ is to initialize to zero,
> but we agree that is not correct for intervals.  Whole is probably
> the best we can do.

I'm not convinced.  Initilization to [0,0] seems nice to me for
intervals because of homogeneity reasons with floating-point.
I could even imagine that the empty interval would make as much
sense as whole.

What makes you think that [0,0] is "not correct", and why 'whole'
would be better than 'empty' ?

 >  Aside: The next day, we visited Berkeley and
> talked with Jim Demmel and Bill Kahan.  Among other things, Kahan
> wants user-defined data types to be tagged.  If we have the
> Kahan-suggested tag, we can tag intervals as Uninitialized.

Could you elaborate on this tag ?  What would it do ?
Would this be a run-time feature of the objects telling if
they are initialized or not ?  Can't this be left to some
"debug mode" ?

> The 1999 C standard provides for access to IEEE hardware.  The
> next version of the C++ standard will also address features new
> in the 1999 C standard to be included in C++.
> 
> The current C++ standard does not discuss or acknowledge threads.
> They are working on the next revision of the standard, which will
> have something to say about threads in the language proper and in
> the standard library.  Probably the interval standard should say,
> "Intervals will be implemented in a thread-safe manner."

I guess this will have to be true for the whole standard library,
or almost all, so I don't think we should worry specifically about
this at the interval level, other than stating this requirement.

> What it really takes to sell intervals to the standard committee
> is evidence of users, together with broad agreement from the
> domain experts.  I'll contact Siegfried to see what he knows about
> numbers of users of his packages.  At some point, an open letter
> to the standards committee with 100 signatures from the interval
> community would help.

The web-survey we are conducting has already been able to collect
some informations for this purpose.  I hope Herve will be able to
produce a summary soon.

> A freely available reference implementation is necessary.

We have already a preliminary one, but it should be improved
and updated.  We (Herve, Guillaume and myself) are lacking time
for this, so we should organize a bit more with other volunteers.

> Evidence of widespread teaching of intervals will help.

> 
> 
> IEEE 754R
> David Hough <David.Hough at Sun.com>
> 
> IEEE 754R is nearly over.  It is likely to include
>    Decimal formats for floating point
>        (Should C++ IA standard permit decimal intervals?)

We have explicitly asked this question (at the Mont-Tremblant meeting)
to the IBM representant supporting the decimal floating-point proposal.
He agreed that, at least currently, there is no need for this
compatibility as the corresponding user communities targetted are
a priori separate.

>    Quad precision
>        (Should C++ IA standard quad intervals?)

I would say that it depends if quads appear in the C++ language
(or is this supposed to be the already existing "long double" ?).
But if they appear, probably support for interval<quads> should
be added, yes.

>    Fused Multiply and Add
>        (I assume with directed rounding?
>         Great for interval linear algebra, too)

I guess it also depends if there appears a function for doing fma
on floating-point types in C++, in which case a natural overload
for intervals would be nice and natural.

>    min/max
>        (I wonder how they handle NaN, infinity, etc.)
>    expression evaluation
>        (Don't remember what that means)
> 
> As far as David is concerned, ISVs (Independent Software Vendors)
> drive the market.

More generally, since IEEE754R will most probably be released before
C++0x, it would be nice if C++0x would take it into account.

-- 
Sylvain