handling T.min the right way
Don Clugston
dac at nospam.com.au
Wed Mar 21 05:49:14 PDT 2007
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.
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);
-- which is a little strange.
More information about the Digitalmars-d
mailing list