Re: smalleset() ( Re: [eigen] Householder.h: ::min() and operator<=)

[Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx>]

> I'd rather stick with std::numeric_limits::min():
I second that.

It is good idea to specialize std::numeric_limits for custom numeric type.
Together with std::swap, which enables std algorithms to work with the
type efficiently.

And probably provide specialization of std::complex for the type.

On Mon, Sep 12, 2016 at 11:23 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> I'd rather stick with std::numeric_limits::min():
>
> std::numeric_limits has to be specialized for custom types anyways (it is
> one of the rare cases where users are welcomed to enter in the std
> namespace), and I don't see reason for exposing a different value for
> std::numeric_limits::min() and NumTraits::smallest()? The only advantage I
> see could be a clearer name (not sure smallest is really clearer though).
>
> I know that we already have some aliases in NumTraits, but retrospectively I
> think this was a bad idea, it just make everything more confusing.
>
> gael
>
> On Mon, Sep 12, 2016 at 11:08 AM, Peter <list@xxxxxxxxxxxxxxxxx> wrote:
>>
>> Dear Christoph,
>>
>>
>> Am 12.09.2016 um 10:57 schrieb Christoph Hertzberg:
>>
>>> If nobody objects against that, I'll patch this into the dev-branch.
>>> Especially, are there objections against or alternative suggestions for the
>>> naming? `lowest()` probably would be a bad choice, since this is what std
>>> calls what
>>> we call `min()`.
>>>
>>
>> The problem with std::min() is, that it has to be understood historically.
>> The name is a bad choice,
>> since the behaviour is different for integer and floating point values .
>>
>> > N.B.: The 1 must be T(1) here (in case T is not implicitly constructible
>> > from int). And perhaps we should document it as "lowest non-denormalized
>> > positive value".
>>
>> Which would suggest lowest() as a name, which is however already used.
>>
>> Best regards,
>> Peter
>>
>>
>