handling T.min the right way

[Andrei Alexandrescu (See Website For Email)]

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

> I'd be surprised if the total benefit amounted to more than a few dozen 
> lines of library code.
> 
> There's also the issue of complex types. Currently, this passes:
> 
> static assert(creal.max == real.max+1i*real.max);

Ouch.


Andrei