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

[ Thread Index | Date Index | More Archives ]

On 2016-09-12 16:37, Pavel Holoborodko wrote:
I'd rather stick with std::numeric_limits::min():
I second that.

I'm fine with either way.
Of course we should then update our documentation on how to provide custom types (i.e., explicitly say that one should specialize std::numeric_limits and inherit NumTraits<...> from GenericNumTraits<...>). Probably the historic reason for introducing the aliases into NumTraits was to avoid the confusion with min() for integers vs min() for floating point types)
A small advantage of having aliases in NumTraits would be that we could
  typedef NumTraits<Scalar> NT;
locally, in case we need multiple attributes of it.

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.

Some time ago I actually tried to make unit tests for everything with a minimal-example generic type (i.e., just encapsulating a float and forwarding all operators and std-functions). One of the main obstacles was that we often do things like
  Scalar(1) or Scalar(0)
which does not work, if Scalar=std::complex<CustomType> and CustomType does not have an implicit constructor from int (and writing Scalar(RealScalar(0)) everywhere would be annoying). How should a user best specialize std::complex to avoid that (without copying the whole std::complex implementation, and just adding another constructor)? Unfortunately, one can't do
namespace std {
class complex<MyType> : public ::std::complex<MyType>
{/* add stuff here */};

Could/should we maybe make our own internal Eigen::complex type (which inherits from std::complex, but adds the additional constructors)? This would also make it easier to provide fixed abs() implementations for compilers where it is broken (I briefly remember some issues with that).


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.


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,

 Dipl. Inf., Dipl. Math. Christoph Hertzberg

 Universität Bremen
 FB 3 - Mathematik und Informatik
 AG Robotik
 Robert-Hooke-Straße 1
 28359 Bremen, Germany

 Zentrale: +49 421 178 45-6611

 Besuchsadresse der Nebengeschäftsstelle:
 Robert-Hooke-Straße 5
 28359 Bremen, Germany

 Tel.:    +49 421 178 45-4021
 Empfang: +49 421 178 45-6600
 Fax:     +49 421 178 45-4150
 E-Mail:  chtz@xxxxxxxxxxxxxxxxxxxxxxxx

 Weitere Informationen:

Mail converted by MHonArc 2.6.19+