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: Johan Råde (rade_at_[hidden])
Date: 2008-12-08 15:27:05

Robert Kawulak wrote:
>> From: Thorsten Ottosen
>> Neal Becker skrev:
>>> Robert Kawulak wrote:
>>>
>>>>> From: Robert Kawulak
>>>>> 2008/12/5 Neal Becker <ndbecker2_at_[hidden]>:
>>>>>> How about, floating point is allowed, but the results may
>>>>> sometimes be surprising?
>>>>>
>>>>> If the surprise consists of breaking the invariant, I'm not
>>>>> convinced...
>>>> Moreover, isn't your proposition actually similar to the 
>> current state?
>>>> Technically, there are no limitations in the library to 
>> prevent you from
>>>> defining bounded<float> ("floating point is allowed"). But 
>> the advice in
>>>> the documentation ("don't use built-in floating point 
>> types with this
>>>> library (until you really know what you're doing)") can be 
>> interpreted as
>>>> "the results may sometimes be surprising".
>>>>
>>> Yes.  I don't suggest changing anything. 
>> I totally disagree. People have to deal with floats anyway. That is a 
>> seperate issue. The advic should be removed IMO, and 
>> bounded_float provided.
> 
> It should be provided, but Boost should first include some set of mechanisms to
> deal with the FP issues. They are too general to be implemented within this
> library and they are not tightly coupled with the concept of constrained types.
> I see this as an analogy to arithmetic overflows prevention, which is also too
> general and too orthogonal to this library.
> 
> Best regards,
> Robert

A pragmatic solution might be to provide constrained floating point values,
and implement them the naive way, as if this issue did not exist.

Then an application developer, who is using the library, has two options:

1. He can say, I don't care, the probability that something unexpected happens
is probably less than the probability of being hit by a meteor while driving to work.

2. He may say, I do care, I want 100% correctness. Then he can probably find some
compiler flags that ensure that this problem will not happen.

--Johan Råde