|Re: [eigen] Array as the Scalar type|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Array as the Scalar type
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sat, 8 May 2010 09:16:26 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=QNMtXpAOfYFWQnrlQ9a4D1F1PJP/GK2hRm7khMJM4j0=; b=V3EGe3tv/S5PVhnpMUCXv2vYymScAaSsb8+7dUbZoOCQL01JhuHepWQog1Rxq+aGkG VErrgaWq52QzNTEmSJB0iUy5Tb/abmgKN6Is28PSXVkJ7Vaju8zReq1VN9cN5kczJ3oa u1A73OXW/fngfJycqokLGvVxoZPXS1pmdMUE0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=x+RMSRlb558tgl7K/jfgj4uxahGwxs9k58YWpvryAEkRUA1F3OXY3JPHBM2ow2oP+z E6LDR/YH8HicOB39cVIE/bEAqlLn/TjJl4Ghc2ybadR+zHrpRZUg4BevFQ4A1Gxh+g5g rUe+y07cvs0ZzyTfnWV7ejIlaMFXpicyegn3M=
2010/5/8 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> well if you think this can be supported without adding too much complexity,
> then let's go for it. Note that ideally we should also be able to do the
> same for any scalar types supporting expr. templates (e.g., autodiff types,
> multi-precision types, etc.).
Yes, I agree, that's why in the MathFunctions I made sure that it was
extensible to arbitrary types. Let me explain what the biggest problem
was. Expression templates type typically derive from an "expression
base" class. You want to write specializations for the "expression
base" class, but at the same time in practice the user calls your
functions on the derived objects. So I offered the possibility for the
user to define a typedef
in his "expression base" class, which is a typedef to itself, so that
all this derived classes have that typedef; and then I use SFINAE to
detect the presence of that typedef and use it when it's present. See
ei_global_math_functions_filtering_base in MathFunctions.h. For the
only example of that currently in Eigen, see ArrayBase.h:58.
> It seems to me that this would require to adjust the functors to export a
> proper scalar type, and a new mechanism to get the "eval scalar type".
Yes. But there's a bit more to do. Currently our expressions export a
Scalar typedef which is the plain-scalar type, no expression
templates. I guess this should remain this unchanged. However we need
to add a new typedef for the type that the coeff() method actually
returns. Actually we already have CoeffReturnType in DenseBase. So
let's extend this concept to all classes, in ei_traits I guess.
I agree it should be done, it's clearly worth it. I was wondering if
you had a plan since sometimes (often) you have.
> Btw, now I remember that a very very long time ago, I managed to get
> matrix<matrix<> > working with expr template, but it was on a alpha version
> of eigen 2, and I lost that piece of code (HD death) :(
By the way, Matrix-as-scalar type is still quite interesting to have,
it would allow us to claim we do have tensors :)
Supreme refinement would be Matrix<Matrix<Matrix<... if we do all that
correctly, that should work, and give us arbitrary tensors...
> On Fri, May 7, 2010 at 10:18 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
>> Mostly a question to Gael:
>> We wanted to enable support for Array as the scalar type, i.e.
>> Matrix<ArrayType, ...>.
>> But all our design is based on the assumption that it's OK to return
>> Scalars by value. E.g. the coeff() const methods in rvalue expressions
>> all return a Scalar by value.
>> So? Are we saying that using Array as Scalar type only is efficient
>> when the Array is small enough to fit entirely in registers? Should we
>> then discourage using large Array types as Scalar ? Note that would be
>> a bit disappointing as it would be the end of our "horizontal
>> vectorization" dreams.
>> Or do you want us to refactor Eigen so that we support expression
>> templates for the Scalar type?
>> In my rework of MathFunctions.h i have made sure to allow supporting
>> expression templates for the Scalar type, and have implemented that
>> for Array expressions, but if it's the only part of Eigen that does
>> that, it makes no sense! Should I drop xpr template Scalar support,
>> which would simplify MathFunctions.h quite a bit (e.g. no need for
>> SFINAE anymore).