|Re: [eigen] about JacobiSVD's options|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] about JacobiSVD's options
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Thu, 17 Sep 2009 09:51:03 +0200
- 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; bh=zeM/I4R0WlLHzl+sORowq8IzUVsUp2kLnzDHet1BXRs=; b=iKGyuVojtGDqtr9GxIlESU0JjsmnD4O9/KlUYG3VzsGumeZBeU5MTTIdKR0N1mn10n dQ1xgKAuY9XDxATeD34mBnyxv/zo9AIgEXqO6PlJrRsGMrC8b5lvl9p1QubADIMyuyVX 8QHNNBigZj9PNoySrpXP1HBocT8Di/m5WcZJw=
- 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; b=b6vEINk13ix1m9b5Qv2aP2y31uPD11xJqQlbd8RGRiP97JfXum9kkHuCZ3tErYdxmb VAXWkGhdOP/uEHllUgwY3J0NkxMO1+XL2ybCQpqmRDGHyKNJqBl6womv/v2lUMlpkZp8 tb9wlVbKAionqrlt9GclOWe6++qNNoQ+whFpE=
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)
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 ?
>> 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
>>> 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 :)
>>> 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
>>>> === 23:53:27 ~$ nm --print-size --size-sort --demangle a_square | grep
>>>> Eigen | tee symbols_a_square | wc -l
>>>> see new attached files !