handling T.min the right way

[Don Clugston]

Andrei Alexandrescu (See Website For Email) wrote:
> Don Clugston wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Don Clugston wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>> A while ago, C++ did the mistake of defining 
>>>>> std::numeric_limits<T>::min() with a different semantics for 
>>>>> floating-point types than for integral types. That hurt generic 
>>>>> numeric code a lot.
>>>>>
>>>>> D has taken over the same mistake: T.min means the smallest value 
>>>>> of the type, except for floating-point types, where it means the 
>>>>> smallest positive value.
>>>>>
>>>>> The right way is to have T.min always return the minimum value 
>>>>> (duh) and define a separate property T.min_positive.
>>>>>
>>>>> The question is, would a lot of code be hurt by such a change?
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>> It probably wouldn't break a huge amount of D code, but I don't 
>>>> think there would be many cases where T.min for a floating point 
>>>> type would be useful. More significant is the problems involved in 
>>>> converting from C or Fortran code to D.
>>>
>>> I'm not even discussing the utility of min_positive. All I'm saying 
>>> is that if you say "min", you should return "min", particularly when 
>>> others do exactly that.
>>>
>>>> On a more profound level...
>>>> I'm not aware of many cases where it's possible to treat integer and 
>>>> floating-points generically. People often try, but usually the code 
>>>> is incorrect for the floating point types, since the semantics are 
>>>> completely different. (For example, I don't know why x++ is legal 
>>>> for floating point types; I think it's just a newbie trap; you have 
>>>> no guarantee that x++ is different to x).
>>>>
>>>> What type of generic numeric code did you have in mind? What are the 
>>>> benefits which would come by such a change?
>>>
>>> Trivially simple: the min and max functions. For min, the code picks 
>>> the type with the smallest .min. For max, the code picks the type 
>>> with the largest .max.
>>
>> Obviously, but are there many other functions like that? Also, you 
>> really should treat floating point as a special case, anyway, because 
>> of the possibility of a NaN.
> 
> There was another example (computing the minimum of a nonempty 
> collection). But to me the issue is a tad different: (1) the name is 
> clearly misused; (2) it's easy to fix; (3) not fixing it sends the wrong 
> message ("we carried over whatever was in C++ on numerics"). D takes
> pride in taking care of minutiae. It's odd to have the smorgasbord of 
> floating-point operators that D has (how often did _you_ use !<>=?) yet 
> at the same time say, "oh, min? that's not really min. I was kidding.

Point taken. I'd support this if at the same time, the bizarre out-by-1 
error in min_exp and max_exp was fixed. My code contains quite a few 
instances of (real.min_exp/2) because I actually wanted the genuine 
minimum exponent.
Then we could say that all normalised numbers x satisfy
pow(2, real.min_exp) <= x < pow(2, real.max_exp+1).

Possibly even rename the current real.min to be real.min_normal, since 
it isn't even the smallest representable value > 0.