Re: [eigen] New Levenberg Marquardt stuff |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
- Subject: Re: [eigen] New Levenberg Marquardt stuff
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 7 Dec 2012 20:47:18 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=YuTW8nZCZCyRSfniZ0N2XUbgVa4Qzedei/otGQ1drZg=; b=nBUfJmXALsl1oIOcBtSjlO/nh5PzqL5H/vg1kY3PrGiRnwib5DwYYGQ1/32sap5/mW wlJDXtdgrIW25m9Qot2otPvo55Eyy6u9jK/gF2OjSHocZNEgIo1ImIuedqjjcqvhy3ZK 59k8tEza3Oj24V1ou/msHDaticLpaLHEJUVx90bfn8ZPiyqln4oTa+oPF1RzlMuChDGw Yvp3IUURl4uLl1znMDjgpdIxT1NLtMvRERxysAgc45dqQSIWlZCXrQDEpiQm8kBQNPMs z88Kv0B8VPIu1Tl8/VyAFl2t0AmBHRIQ76XSavCizOzC4lgS6/eAyQ7/BPH8/ZnIwt48 MNGQ==
Hi,
sorry my brain is overflowing these days. Clearly we've been too fast on that move. Let's look at the bright side first:
- support for sparse Jacobian in LM
- clear goal to make the LM solver officially part of Eigen.
To complete these goals it is clear to me that we need 1) significant API changes because the current API does not really match the rest of Eigen, and 2) as much as code simplification as possible.
Regarding the API, don't take it the wrong way, we definitely want to heard about you, and I'll come with a proposal soon.
Regarding code simplification this means removing the "memory efficient" path which represent a lot of redundant code and sounds less important on todays computer especially since we support sparse Jacobian: if a dense Jacobian is too large to fit in todays computer memory, I have a bad feeling about the time the solver will take to converge. In any case, if you think the opposite, this feature should be implemented in another class since the associated functor API is different.
Right now, to "fix" the current bad state of the repo I propose the following actions:
- Revert the name changes in NonLinearOptimisation module. There is actually no need to rename the original class.
- Fix licence headers
- Move the new module into unsupported until we agreed on the API
Regarding the module granularity, "NonLinearOptimisation" is way too large. The proposed LevenbergMarquart is perhaps too narrow and I'm just thinking about "NonLinearLeastSquares" for which, as far as know, there is not many standard methods.
gael