Re: [eigen] about JacobiSVD's options

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Wed, Sep 16, 2009 at 2:57 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/9/16 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> ok ok, but I still think it is a bit unfortunate to clutter the API
>> for compilation time only.
>>
>> Actually, note that if the advanced user really want to speed up his
>> compilation time, the best is to explicitly instantiate the few
>> operations he need in a separate file (e.g., JacobiSVD<MatrixXd>), and
>> then the compilation of JacobiSVD<MatrixXd> will take 0sec. I agree
>> this is a little more work than just adding ",Square", but this
>> solution works for all classes and global functions and it brings much
>> more speed !
>
> But it doesn't address the issue of code size...

well, that depends, because if someone use both non square and square
then the code size increase (+4k per instantiation of JacobiSVD)

> Does it really clutter the API to have an optional template parameter here?
> It's optional, meaning that the user who doesn't care can just do
>
> JacobiSVD<MatrixXf> svd(m);
>
> Would you prefer this being split in a separate class,
> SquareJacobiSVD? Or would you prefer it being a separate
> constructor/compute() method, like this,
>
> JacobiSVD<MatrixXf> svd(m); // don't assume square, compile QR
> JacobiSVD<MatrixXf> svd(m, IsSquare); // assume square. this ctor
> takes a IsSquare_t argument
>
> Or would it be more acceptable if we had just Square and discarded the
> AtLeastAsManyRowsAsCols which I agree isn't very useful?

yes the AtLeastAsMany*As* are definitely useless and they can only
increase the code size.

One problem is that the SkipU/SkipV options are mixed with the
Square/NonSquare one, and so if someone use SkipU then he loses the
automatic computation of Square/NonSquare for fixed sizes, and so he
would have to duplicate that piece of code... So if you really really
want to keep Square, then it should be a separate template parameter.

oh! I've just got an idea: what about making the Square/NonSquare
option a true feature ? The idea is to template JacobiSVD by a
preconditioner type which would allow the user to choose between:

- Identity (for square matrix)
- FullPivotingHouseholderQR
- ColPivotingHouseholderQR
- etc.

Currently there is no big advantage of using ColPivotingHouseholderQR,
but once we'll have a blocked version of it, performance wise, it will
be very relevant to offer that feature. What do you think ?

gael.

> Benoit
>
>
>>
>> gael.
>>
>> On Wed, Sep 16, 2009 at 2:11 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> ok, last email.
>>>
>>> The symbol tables look fine, really it seems that it's just that
>>> Householder QR is inherently more complicated code than square jacobi
>>> SVD.
>>> After all, the latter is just a 2x2 kernel and the code to apply
>>> Jacobi rotations, that's about it.
>>> This would confirm my theory that it's important to give the user an
>>> option to specify "square" at compile time :)
>>>
>>> Benoit
>>>
>>> 2009/9/16 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>>>> 2009/9/16 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>>>>> See attached files, if you can make sense of that... i'm puzzled.
>>>>> The matrix-vector product symbol itself takes 4 kilobytes, so it's not
>>>>> explaining all the difference.
>>>>
>>>> Wow, i just found out about nm --demangle...
>>>>
>>>> === 23:53:05 ~$ nm --print-size --size-sort --demangle a | grep Eigen
>>>> | tee symbols_a | wc -l
>>>> 118
>>>> === 23:53:27 ~$ nm --print-size --size-sort --demangle a_square | grep
>>>> Eigen | tee symbols_a_square | wc -l
>>>> 38
>>>>
>>>> see new attached files !
>>>>
>>>> Benoit
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>