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:04:25 -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=rSuydA4khJxkLefE+e6+qK0DaZBdjC17NuzwcJZdPJs=; b=wv7SJAl2iR6Vn0UedgnesdzVoia/CCsCZVlyPLtDfUYYSTn7DKl45zpN7uKBnD76dI tljb6duceYuAutP0Kln1W/8qLLubWPRKj6BMOIQMJTGA504+olaYVyP4cogG6EcrX0eS AE82Zd1zH/extNzfAOb46RPYThmzRhv0awkkU=
- 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=WfJ6gwGrXDFYBW2GJPTPKtEdYeOCQgFV2Gy6EX5vzcjC5+I2usTo5gSllaYfuVIMH+ ZTPU4YMr/PaOPMSZHgieJe8BI2L/OvhrmxRmUUisL9puTxtTymEUTteUY7eIGnLBkczC dkrI3c2a4dxK00Qx/uBFy4YU2msnyxKR6XY/g=
2010/1/3 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 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.
Argh, I forgot about the variant taking the int as a template
parameter: it takes void argument. So that's not possible.
> 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
>