Re: [eigen] Enhanced AlignedBox

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Sat, Jan 16, 2010 at 5:31 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 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.

yes the math functions must remain global functions. So let's do it.

>
>>
>>>
>>> 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)

ok, good.

gael

>
> Benoit
>
>
>