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

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

No issue here.  In fact, I've never used "double.min" for example - I'm suprised to hear that it's positive.

As much as I'd like to see D embrace camelCase for multi-word things, "foreach_reverse" has pretty much decided that one for us - T.min_positive seems like a good addition to the language as any.  I gather this means that we'll also see a t.max_negative to go along with it?
-- 
- EricAnderton at yahoo

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

PS, the guy you really need to ask is Don.  He seems to be the (if not one of a handful of) math/FP guru around here. ;)

-- 
- EricAnderton at yahoo

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.

???
This statement really surprised me. But it does seems to be what DMD does.

The relevant line of the spec (http://www.digitalmars.com/d/property.html [section on floats]):
---
.min 	smallest representable normalized value that's not 0
---
Does "normalized" imply non-negative?

I guess I could have expected this behavior if I'd paid better attention to this line though, since it's '0' that is explicitly excluded instead of negative infinity. (Also, it uses "smallest" instead of something like "lowest")

> The right way is to have T.min always return the minimum value (duh) and define a separate property T.min_positive.

Obviously.
Since the minimum positive number would be a denormalized value (right?), perhaps a T.min_normalized as well?
(or if "normalized" doesn't imply non-negative, min_normalized_positive, though that's getting a bit long...)

> The question is, would a lot of code be hurt by such a change?

I didn't even know this wasn't already how it worked...

Pragma wrote:
> I gather this means that we'll also see a t.max_negative to go along with it?

I was going to suggest this, but then considered that min_positive could also be defined for integer types, while max_negative has no good definition for the unsigned variants.

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> wrote in message news:45FEE0BC.4000407@erdani.org...
>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.

Isn't this value sometimes also called "epsilon"? I think double.epsilon sounds quite nice :)

L.

Am 19.03.2007, 20:13 Uhr, schrieb Andrei Alexandrescu (See Website For Email) <SeeWebsiteForEmail@erdani.org>:

> The right way is to have T.min always return the minimum value (duh) and define a separate property T.min_positive.

Maybe min could take an enum as parameter:

' T.min(positive);
' T.min(negative);

with a default value so that T.min is still valid. Looks a lot more like D and less like PHP :)

-mike

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Lionello Lunesu wrote:
> Isn't this value sometimes also called "epsilon"? I think double.epsilon sounds quite nice :)

quite charming :)

Luis

Lionello Lunesu wrote:
> "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> wrote in message news:45FEE0BC.4000407@erdani.org...
>> The right way is to have T.min always return the minimum value (duh) and define a separate property T.min_positive.
> 
> Isn't this value sometimes also called "epsilon"? I think double.epsilon sounds quite nice :)

Epsilon is already used for a related concept:
".epsilon -- smallest increment to the value 1" (http://www.digitalmars.com/d/property.html)

Frits van Bommel wrote:
> Lionello Lunesu wrote:
>> "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> wrote in message news:45FEE0BC.4000407@erdani.org...
>>> The right way is to have T.min always return the minimum value (duh) and define a separate property T.min_positive.
>>
>> Isn't this value sometimes also called "epsilon"? I think double.epsilon sounds quite nice :)
> 
> Epsilon is already used for a related concept:
> ".epsilon -- smallest increment to the value 1" (http://www.digitalmars.com/d/property.html)

Huh, I thought it sounded familiar.

So epsilon is such that 1.0+epsilon!=1.0, and the 'min' we're talking about is such that 0.0+min_positive!=0.0 ? I didn't know these were both useful values.... I wonder how they're actually being used.

L.