Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today

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?

Maybe.

> 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.

-Thorsten