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

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

On Sat, Jan 3, 2009 at 1:20 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 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.

right, so it will take the "InnerVectorization with CompleteUnrolling"
and still crash.

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

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

---