|Re: [eigen] a few more points...|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] a few more points...
- From: "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
- Date: Sat, 3 Jan 2009 01:20:51 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=AivQzgJh8VzRLQnomkvbV8cIgUm84tVxea2T0yXjMXY=; b=ebRWCh0EPUYh2qXXQFkYIA0/6vH4mMB9QYN57NyIcGw1QTvjGoS25yfsZEJ40EWkga IIFJBZDGRQQmBe6bwTTrYN+hjF+AHgAk1uOVRcAQ7Zxbl+A+4W/dwqsfO0emlEaPMDBL 3grP/o4YpRW4JgKqsjLSnD6VxAqGEnip6iQVQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vNCHNdylStfzbdQXkmi6Dw6i5gh9Y8LcWQygMoLwTl3l7rrx0pjR1VPUOTunlF2zzZ F/21vdvFltzgYh9DYceIFyKdv55XT9NRLpHkjzOfICashPKMthR/c/AOvRgvf6kvIllB J9tjPI8tUxWbMhxsW+rTvEDyjBgSRk/OmxigU=
2009/1/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Fri, Jan 2, 2009 at 10:28 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> Hi List,
>> 1) Should we rename Eigen/Regression to Eigen/LeastSquares?
>> after all, regression analysis is only one of the things that one can
>> do with least squares, currently this module is essentially providing
>> raw least squares, no fancy (non-linear) regression analysis; moreover
>> other modules like LU are named after the basic algo not after the
>> common use case -- so naming that module Regression is a bit like
>> calling the LU module "Solving" and the QR module "Spectral" etc... We
>> could keep Regression as a trivial, deprecated header for now until 2.0...
> I'm ok with that.
>> 2) Is it a bug that ei_traits<Block>::Flags doesn't set the AlignedBit
>> even if the ForceAligned option is used?
>> I have a local change like this:
>> - Flags = (MatrixType::Flags & (HereditaryBits |
>> MaskPacketAccessBit | DirectAccessBit)) | FlagsLinearAccessBit,
>> + Flags = (MatrixType::Flags & (HereditaryBits |
>> MaskPacketAccessBit | DirectAccessBit)) | FlagsLinearAccessBit
>> + | (int(PacketAccess)==ForceAligned ? AlignedBit : 0),
>> Is this OK with you?
> hm... actually ForceAligned is used when we can guarantee that the
> read/write accesses to the data will be aligned even though the first
> element is not aligned (e.g., m.block(...) += ... ;).
I see. in my situation i have a Matrix4d, so it is aligned, and i
decompose it as 2x2 2x2 blocks, so i can really guarantee that the
accesses will be aligned. So I can use ForceAligned. But when I tried,
Eigen (Assign.h) didn't use the vectorized paths because SrcIsAligned
was false. So I had to do this change to the flags of Block, in order
to make Assign.h choose a vectorized path.
> means that the first element is aligned. So they are 2 different
Ah ok, i understand.
> and I don't think that's safe to add AlignedBit if we have
> ForceAligned, eg:
> Matrix4d m1;
> m1.block<2,2>(1,0) *= 2;
> will take the "LinearVectorization with CompleteUnrolling" path and crash.
The block expression here doesn't have the LinearAccessBit because it
isn't a vector. So this assignment shouldn't take the
> But I see your point, ForceAligned is currently only useful for
> relatively large matrices for which there is no unrolling. Perhaps,
> what you would like is a way to tell Block that our sub matrix
> expression preserve alignment ?
Actually your ForceAligned as you explained it sounds like exactly
what I want. What I need now is a way to tell Assign.h to use a
vectorized path -- currently it doesn't because SrcIsAligned is 0 in
ei_assign_traits because my block expression doesn't have the
>> 3) I'm adding a StorageOrder enum in Matrix, to fix wrong code in LU.h
>> that passed Flags as 4th templ param of Matrix. One more little thing
>> to change when/if you do the change with the Compact option.
> I won't have time to code till Monday evening....
OK I think I'll do it.
>> 4) I think we need a detailed wiki page explaining what we guarantee
>> API stability for and what we don't -- indeed it's nontrivial to
>> separate public from private stuff in a template lib. I think we
>> should plainly exclude asDiagonal() from the API stability guarantee
>> in 2.0 to leave us as much wiggling space as possible.
> Yes, good idea, again no time to help till Monday evening...
OK I was planning to do it myself.
PS just in case you wondered, 2009 = 7^2 * 41