Re: [eigen] Enhanced AlignedBox

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/1/15 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Wed, Dec 23, 2009 at 7:47 PM, Manuel Yguel <manuel.yguel@xxxxxxxxx> wrote:
>> On Tue, Dec 22, 2009 at 2:48 PM, Gael Guennebaud
>>> * Why did you template the functions taking another aligned box.
>>> (e.g., contains(), extend(), clamp(), etc.). I mean, both the
>>> dimension and the scalar type have to be exactly the same, so no need
>>> to template them.
>> Why? I agree for the dimension, but not necessary for the scalar type.
>> One can want float for hardware reason and double for precision in an
>> other part of the application.
>
> Actually, this is mainly because we cannot rely on automatic type
> conversion when enabling vectorization. Therefore, throughout Eigen we
> enforce that both operand of a binary operations have the same scalar
> type. Consequently, even if you allow contains() to accept different
> scalar types, the code wont compile. To mix different scalar type you
> have to explicitly do a cast. So two options:
>
> 1 - contains() only accepts the same scalar type, and the user have to
> cast one of the operand
> 2 - contains() accepts different scalar types and the implementation
> of contains() have to be updated to ensure consistent types that is
> quite complicated because you have to determine whether casting
> *this's members or the argument.
>
> For the latter reason, and to be consistent with the rest of Eigen,
> and to not hide any implicit conversions, I really vote for option 1.

I vote for 1. too.

Manuel: note that the user can do cast<double>() wherever he wants to,
and that has no cost other than the casting itself, so we're not
limiting the power of eigen here, we're just forcing casts to be
explicit rather than implicit.

>> Do you think it is the eigen way to add some fields and/or static
>> methods to NumTraits in order to provide the equivalent following
>> informations?
>
> so far we used global functions.
>
>> In the std::numeric_limits they give also minimum positive number,
>> precision, codes for NAN, +INF etc...
>> I saw that you define dummy_precision as a template function, should
>> it not be a static method part of the NumTraits such that someone can
>> easily change the default behaviour by defining its own NumTraits ?
>
> why not. At least why you propose allow to centralize everything in a
> single place.
>
> Benoit, what do you think ?

Initially I too considered putting everything in NumTraits. The reason
why I didn't stick with that, was just the heaviness of the notation.
But thinking about it, for dummy_precision(), it's not too bad, and we
don't use it frequently anyway. So yes why not! Same for epsilon(). As
long as ei_exp() and such remain global functions, I'm happy.

>
>>
>> If you agree with that I would make the changes adding the static functions:
>> highest()
>> lowest()
>> dummy_precision()
>> adding the value for -INF also etc...
>>
>> and after we can mimic std::numeric_limits
>> epsilon()
>> has_infinity()
>> has_quiet_NaN()
>> has_signaling_NaN()
>> etc ...
>
> Then why not simply make NumTraits<Foo> inherits std::numeric_limits<Foo>?

Good idea! (AFAICS)

Benoit