Re: [eigen] a few more points...

["Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>]

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.

>The AlignedBit
> means that the first element is aligned. So they are 2 different
> things,

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
LinearVectorization path.

>
> 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
AlignedBit.

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

Cheers,
Benoit

PS just in case you wondered, 2009 = 7^2 * 41

---