Re: [eigen] Areas of eigen3 variation and using eigen2/3 in generic code? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Areas of eigen3 variation and using eigen2/3 in generic code?
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sun, 3 Jan 2010 14:02:43 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=RxCLtrFCutitN5s/+O0WF9yLY+NXuQ2nGAAmCo6YGj4=; b=Vb3STAdXTsHdAiB4JtgfD2BbxDd7c269zSANEkH1r4AeN5OpWPN29Mu+WKYlSXPLpV BKuyxkBuzJjLX+dMuKzgJ66w5d9JGB5ECagKUkeZs1FP8TyUDVwZxh6kktHShCXR3njT 7fDAxYPksjRLUVvmaPeIL/XBWadx1z4igs3PY=
- 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:content-transfer-encoding; b=Ou563U/0SABEOGJ24EnA7gyh7tgr70geyjF6HbjGi7dUIdOPANN0aQ1uJUVXvwhzZc iFBusxc48nzajYOtMxlMKD8nM2FadVdZV11CPfZDVzeQj7NVhnlQZMRx1Htlt3Xlrrs7 vybIDZ2Ro7QnREFGlQDnat2gFTBwzXGOvZLAQ=
2010/1/3 Jesse Perla <jesseperla@xxxxxxxxx>:
> On Sun, Jan 3, 2010 at 12:03 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> Yes, there would be few changes.
>> The basic linear algebra operations syntax doesn't change. The thing
>> closest to this that will change, is coefficient-wise operations with
>> cwise().
>
> Greats. Any hints on how to best future proof cwise()?
First, we should provide a Eigen2Support file providing cwise(). Then,
for what you are doing, you will only have a few lines to change, and
that should be easy. The same functionality will be here, only with a
different syntax. We'll write doc pages about the syntax changes.
> Another question I couldn't immediately figure out from the docs/source. Is
> the vector a (roughly) STD compliant container?
No, not even roughly.
> Or any way to return a
> random access iterator for begin() and end() that I could use with
> std::transform, etc? The "start" and "end" seem different than normal
> iterators
Indeed, we do not have any iterators in Eigen for dense matrices and
vectors. Do you have a use case for that? So far, index-based access
has been all we have needed, as we were 100% focused on linear
algebra.
Gael: with your fork bringing a general-purpose Array class, do you
think we should allow/provide iterators?
Name-wise, if all that's needed is begin() and end() methods, that's
possible: we only have end(int), we don't have end(void), so we could
overload. Or if you think that's ugly, and if iterators are very
important, we could rename end(int) to tail(int), for example... I
need to hear opinions, as so far i'm focused on dense linear algebra
that doesn't need iterators.
> Also: is there a good reference file in the source that captures a lot of
> the traits I might use for metaprogramming?
Not completely sure what traits means here, but:
- most of the methods that you want to wrap are declared in Core/MatrixBase.h
- most of the generic metaprogramming stuff is declated in Core/util/Meta.h
>
>>
>> > 3. I am interested in writing a lot of routines that would have the
>> > option
>> > of using the boost numeric bindings traits
>> >
>> > (see https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/traits/ and http://lists.boost.org/MailArchives/ublas/2009/11/3854.php ;).I
>> > haven't heard of that, but at first glance, this seems perfectly possible.
>
> At some point I will check in the the numeric bindings guys and see if they
> have done anything will eigen. I will report back to this list conditional
> on success.
Great, keep us informed!
Cheers,
Benoit