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