Boost logo

Boost :

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-12-08 07:39:33

Robert Kawulak skrev:
>> From: Thorsten Ottosen
>> I guess p. 34 (Intervals) provides some hints to how we write such a
>> careful predicate. If I understand this correctly, then we should at
>> least use bounds that are exactly representable in the type involved.
> I'm afraid the bounds are not enough, the values would also have to have exact
> representation. But the section indeed provides a hint -- maybe the problem
> could be somehow solved if we have a function float exact(float) that, given a
> floating point value (that may have greater precision because of caching in a
> register), returns a value that is truncated (has exactly the precision of
> float, not greater). Does it sound sensible?


> Anyway, I think the solution to reliable FP arithmetic is too general to make it
> a part of this library. This should be addressed by a dedicated library, and
> then Constrained Value library could make a use of it.

I've been thinking about my use-cases, and I think I most want it in the
interface and rarely internally in the representation of classes. For
example, I might say

typedef bounded_float<double,0x?????,0x?????> Cost;

Cost& Foo::cost();
Cost Foo::cost() const;

Now, it might also be useful to be able to specify that numbers that are
"close" (defined by the user) to the bounds should be rounded to the
bounds, but I think that was already possible in your library. Right?

So I think my conclusion is the following: The fact that floating point
calculations are not easily portable is not an argument against having
constrained values of floats; if anything, it is an agument for having
them because the library makes it easier to detect/respond to such
portability problems.


Boost list run by bdawes at, gregod at, cpdaniel at, john at