[std-interval] list of functions for intervals
George.Corliss at marquette.edu
Sun Jun 4 21:40:04 PDT 2006
Lee and all,
Excellent. I like your proposal better than mine, but (of course?) I have
some questions for you and the list. I had in mind a minimalist standard;
you are more ambitious. If we can summon support for an ambitious standard,
LET'S DO IT.
Q1, p. 1, par. 2. "Standardization of the interval functions should not
mandate that containment, which is a QoI issue." Do you mean containment in
the sense that the set of interval standard functions should contain the
floating point ones? Or that (shudder) containment of values returned
should not be mandated?
Q2, par. 4. "the result of an interval version of a <cmath> function is the
hull of all of the results ..." is close to the cset definition, except that
csets enclose also results of limits. Several of us are preparing a cset
draft for posting here within a few days. _IF_ csets are accepted, say, for
divide, it would be natural to use them to specify results of cmath
functions, too? I'd have to look more closely for differences in returned
Q3, par. 7. "existence of a type designed to hold multiple instances of
values" Such a type could improve the practicality of our cset proposal,
too. Thank you!
Q4, par. 9. "wrong" and "nacceptably wide"
--> "wrong" and "unacceptably wide"
Q5. isnan() and nan(). I see where you are going with the "Set of interval
functions must contain the set of floating-point functions, and interval
functions on singleton intervals must agree with their floating-point
counterpart" argument. I'm sympathetic.
It is a mistake for a standard to give too detailed an implementation, but
many are concerned that the standard also should not mandate a slow
implementation. I assume we want to represent an <empty> set and probably a
<whole> set. If we use [NaN, NaN] as an internal, opaque implementation of
<empty>, there are very few performance-robbing tests. If an implementation
DOES decide to use NaN to represent <empty>, I guess isnan() does no harm,
and I guess nan() would be the equivalent of <empty>.
interval square( interval X )?
Many interval coders are accustomed to
double mag( interval X ); // or magnitude := max abs(X)
double mig( interval X ); // or mignitude := min abs(X),
where "abs(X)" is the interval abs as I imagine you'd specify it.
Q7. Function forms of operators: Hooray! Then the C++ interval is (nearly)
a C interval library plus a C++ wrapper class? Then I can use it if I am
restricted to C, for some reason. Or is that an empty opportunity?
I appreciate you suggesting that implementations are not too hard. In
addition, we should note there are at least a couple quite good (tight)
implementations of most of the common elementary functions, more evidence
that a vendor's barrier to entry is not high.
My reservation is that by putting more advanced tools (your twin functions)
in the hands of people inexperienced with interval algorithms, you provide
more opportunities for screwing up :-)
(In preparing this response, I have consulted on some, but not all, of these
points with John Pryce, R. Baker Kearfott, Ned Nedialkov, and Spencer
Dr. George Corliss
Electrical and Computer Engineering
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee, WI 53201-1881
George.Corliss at Marquette.edu
414-288-6599 (office); 288-4400 (GasDay);
288-6280 (Dept.); 288-5579 (fax)
Office: Haggerty Engineering 296
On 6/3/06 7:30 PM, "first.i.last at comcast.net" <first.i.last at comcast.net>
> -------------- Original message ----------------------
> From: Sylvain Pion <Sylvain.Pion at sophia.inria.fr>
>> Dear all,
>> We have been thinking about the list of floating-point functions
>> which we could propose an interval version for.
>> More precisely, we have looked at the current list of floating-point
>> functions from the latest draft of C++0x
>> What do you think of these lists ?
>> Is something important excluded ?
>> Is there anything that should be excluded ?
>> Note that existing implementations do not necessarily offer all
>> proposed functions, so any comment on the implementation
>> difficulty (for interval<float>, interval<double> and
>> interval<long double>) would be appreciated.
> Attached is a file containing comments on the issues you raised and suggested
> specifications for many of the functions at issue. Having studied this issue
> in great detail, implemented all of the <cmath> functions, and designed
> implementations of the c99 functions I can assure you that the implementation
> of the interval versions of the <cmath> functions, including disjoint results,
> is quite reasonable.
> Using typical elementary functions as a benchmark (trig, hyperbolics, and
> exponentials) all but two of the c99 functions require similar or lesser
> implementation effort. We are still studying the recalcitrant pair of
> functions, beta() and ellint_1(), with an eye to efficient and robust
> The attached document is a summary aimed at raising issues and identifying
> areas meriting additional discussion rather than a comprehensive specification
> with endless detail but no rationale. Therefore readers who are only
> concerned with concrete suggestions should not read it.
> -- Lee Winter
> Std-interval mailing list
> Std-interval at compgeom.poly.edu
More information about the Std-interval