|
Boost : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-09-03 13:52:35
On Tuesday 03 September 2002 01:54 pm, Herve Bronnimann wrote:
> > [General comments]
> Concept documentation is used to document requirements, mostly for
> template parameters (e.g. ForwardIterator). It is appropriate for the
> base number type, and the Function parameter of compare_full. But it is
> not really appropriate for classes and functions.
Agreed 100%.
> > * rounded_transc_dummy seems very dangerous, because it will allow
> > meaningless code to compile. I think Jeff Garland already brought this
> > up, but a call to sin(interval<T>) should not compile if it isn't going
> > to do anything useful.
>
> This is the other route. Our choice is correct (i.e. returns a valid
> interval) and but it is true that the danger is that the user is
> unaware of why he/she is getting strange intervals.
Is there a case where the current behavior is clearly better than the behavior
that Jeff & I expected/proposed? I ask because most libraries strive to find
errors as soon as possible (e.g., via compile-time or run-time assertions),
so I'm trying to understand why signalling an error is not desired.
> > [Code comments]
> > * interval.hpp: Should the compare, checking, and rounding typedefs be
> > exported as part of the public interface (probably with the names
> > compare_type, checking_type, and rounding_type, respectively)?
>
> I wouldn't mind but the traits_type provides those already (with one
> more level of indirection).
Okay, fine by me.
> Symbolic expressions such as boost::rational and other types that
> fundamentally represent numbers could be (and should probably have been)
> tested, if we had had more time, but I do not see a major problem why
> they shouldn't work. Indeed, they have worked in other (closely related)
> interval libraries. Other than that, I am not sure what other symbolic
> types you envision. Perhaps you can elaborate.
I'm interested in non-numeric types, e.g., expressions like 'x + y' or 'x^2 +
3x^4'. In my application, we have some set of symbols and an interval
associated with each symbol. The interval bounds are expressions that can
contain arbitrary mathematical expressions involving the symbols themselves,
for instance we might have:
x in the interval [0, y]
y in the interval [2, 2*z]
z in the interval [w, 2*w + w^2]
w in the interval [1, 10]
My particular application is in the area of static analysis. Given this
system, we might try to analyze the code:
int x;
// ...
if (x > 0) {
// do something...
}
else {
// do something else
}
We might use interval comparison to determine if x > 0 (indeterminate) and
then intersection to compute the values of x within the 'if' and 'else'
branches based on the condition. Within the 'if' branch, the value of x is
the intersection of x with [1, +Infinity] and within the "else" branch the
value of x is the intersection of x with [-Infinity, 0].
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk