March 21, 2007 Re: handling T.min the right way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | 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 |
March 21, 2007 Re: handling T.min the right way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | 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.
|
March 21, 2007 Re: handling T.min the right way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | 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"). And what about carrying over that const mess from C++? If const as a keyword is to stay - just let it mean constant - nothing else. > 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." !<>= is in use in Tango as it seems to what is actually happening when looking for NaN :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango |
March 21, 2007 Re: handling T.min the right way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | Andrei Alexandrescu (See Website For Email) wrote:
> It's odd to have the smorgasbord of floating-point operators that D has (how often did _you_ use !<>=?) yet
Since you ask...
With a quick grep through 2 directories I found three uses, with <>= being used 12 times.
But I'm not normal. <g>.
|
March 21, 2007 Re: handling T.min the right way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> It's odd to have the smorgasbord of floating-point operators that D has (how often did _you_ use !<>=?) yet
> Since you ask...
> With a quick grep through 2 directories I found three uses, with <>= being used 12 times.
> But I'm not normal. <g>.
Ok, now search for !>=. :o)
Andrei
|
March 21, 2007 Re: handling T.min the right way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> It's odd to have the smorgasbord of floating-point operators that D has (how often did _you_ use !<>=?) yet
> Since you ask...
> With a quick grep through 2 directories I found three uses, with <>= being used 12 times.
> But I'm not normal. <g>.
That's why your opinion on fp issues carries a lot of weight here - you're a professional numerics programmer, and those are unusual.
|
March 21, 2007 Re: handling T.min the right way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | Don Clugston wrote:
> 0ffh wrote:
>> [...]
>> Of course if you have a *very* big number, that might mean it's the same.... sometimes I do faster typing than thinking... :)
> Exactly -- that's the trap.
Faster typing than thinking? Sure! :-))))
(Sorry, couldn't resist!)
Greetz, Frank
|
Copyright © 1999-2021 by the D Language Foundation