| Re: [eigen] Unifying decomposition interfaces |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Unifying decomposition interfaces
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 22 May 2009 03:30:41 +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 :content-transfer-encoding; bh=Lz86ITNNoBcauVG7WGTlzbhT+AyvSosrUpQ53iIM6uE=; b=osCkTEPiqt8E8ByZWb8wvGL4pFTLEYr/4ovJDn/zcgOFZrV+z2IHoKZ3npiJsXe3Zd 3kyqRn51DUdKquj+GaqonNE4ltKne+EFXtCeAzJDtERy4VpxeeR2uYmyE02IpwP2nXiT eRQU1Bo8cADZ6Jv3iyq/A9ADwi+O/HRdwvkeE=
- 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:content-transfer-encoding; b=SP2kp3Vb1zcjmKiGB7YeCwHDwQ2IUo2omCk+g59IfGIq2yiQFKrBxs3YbblZ4Y+9tg S29wodqllVI6m7pqmlp21kp11bVTbUZIeB6RWJIVEsWnTpGrXX9aI3JKMjuUwjP5AFLv PRIppZv98xs3MTi7OF8Ur0fAmbiOu1pOY78yc=
2009/5/21 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Thu, May 21, 2009 at 5:42 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> So there's no way around adding bool m_initialized in general. On
>> second thought, this also makes code easier to read.
> Done ...
Thanks!
>
>> (Side note: our unit tests for lu and qr currently only test
>> dynamic-size, that's bad)
> I just added fixed size tests - at least for the assert verifications.
Good, that's a starting point...
>> Another small remark is that the default constructors you added need
>> to have some (even very short) documentation. It's just scary for the
>> user when an item is undocumented.
> Done ...
Thanks.
>
> A final comment. I did not touch the SelfAdjointEigenSolver - it
> already has several undocumented ctors and I am not sure about the use
> cases for them.
OK
> You can take a look at the final patches over here:
> http://bitbucket.org/hauke/decomposition-unification/src/
>
> I tried out the patch queues - IMHO, they rock. Only patches will be
> versioned in a patch queue - i.e. you are actually working on shallow
> copy of the Eigen repository. Each patch in a patch series can be
> pushed/poped and modified until you like them. Even now, in case you
> have some remarks left, the patches can be easily changed.
I've yet to read your link below and understand how patch queues are
better than simply examining the diff between eigen2 and a clone...
> Once I get the go, the I will apply the patches
Yes, please go ahead! Assuming that the unit-tests pass (didn't check).
> - my assumption is
> that it will result in four individual commits which I consider
> reasonable given the number of changes. If you want a single commit
> for the changes just let me know.
Do as you think makes for the most meaningful commit history. We don't
have rules for that.
Cheers,
Benoit
> p.s. When I have time, I can write a how-to for the patch queues
> though the introduction given here is very good
> http://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org