|Re: [eigen] New Levenberg Marquardt stuff|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] New Levenberg Marquardt stuff
- From: "Radu B. Rusu" <radu.b.rusu@xxxxxxxxx>
- Date: Fri, 07 Dec 2012 18:57:00 -0800
- Cc: Sameer Agarwal <sameeragarwal@xxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ey62AW492iigNJOkRnlkOw+w7Ah8T13cV7itiAly4zw=; b=klTIPFCNWE5F3gZA4J8VMGdLufz7dbpvkharJYdqjBFp+xDnVwevVv9Ek/F9FXeVmI ojMc5+Sz96SA2mIe0F6D+JUj321GBWv1ZhhK+GYvTwNlbXFcsO4jKoyy+BsPFsn0/X9e sahgOJU+R1iL0DQM5sBxB1ITbFwHT/sDHTpV3f/Nt4LquA8Q+TIGAMcr1vxR/IF11iwj /MCkkMlwHkg/BozH3i3svCMHQkRtDTvVusUTzb4oneV4PXz3c7U30ScLLuqmGfmPqjRT iHm6MtDeAb5f3LRlEvpn9P5KrVRaM3EiCUj+mUT2JwEdC40Sw3RD08cTF32rgMFUHACo Xt3A==
Is there a particular reason why you'd like to remove the current LM implementation that Eigen has from the library? We
have been using it for a long time, and are quite happy with it. There might be other implementations which are better,
but there are use cases where the number of dependencies has to be very low, and one of our applications fits perfectly
in this scenario. Eigen has a proven track record of being cross compilable on all the architectures that I can think
of, with excellent unit tests, documentation, and really a fantastic user support, while other libraries are/do not. I'm
bowing my hat every time I have a chance to the Eigen team, as they are an inspiration for other open source movements
such as ours.
I think we can all agree that what Eigen did in the past few years changed the game completely for us C++-ers, as they
made us move away from that ugly C code that we were using in the past while dealing with matrix operations /
decompositions. That being said, I'd be more happy to see more solvers available in Eigen, either as part of the core or
maybe the Eigen maintainers/developers can start adding additional modules ("libraries") alongside the core that deal
with non-linear LS solvers. If there is code in CERES that is generally purpose and fits in the Eigen paradigm, it would
be great to have it included it there. Why not have "libeigen-core", "libeigen-nonlinear", etc if adding more to the
existing Eigen library is a problem?
Generally speaking, I think the libraries with the best support win in the long run. Our group has contributed and
co-developed G2O at Willow Garage with Freiburg University, and we have also made contributions to GTSAM recently.
However, even though the code in these graph optimizers might be excellent, the user support is orders of magnitude
poorer than Eigen's, and it's most likely going to stay this way. The main programmers are PhD students and they simply
do not have the time to build such comprehensive software packages as the Eigen community did or spend time with user
support -- though one could argue that would be good for their careers in the long run ;)
So +1 to keep the existing LM code, and potentially improve it and/or add additional similar solvers to perhaps an extra
Eigen module if people feel that Eigen is "growing too big". (I disagree that it does.)
On 12/07/2012 03:07 PM, Sameer Agarwal wrote:
I think that discussion about releasing ceres is best had elsewhere rather than the eigen mailinglist.
Have you considered punting on the LM library entirely?
Ceres is almost uniformly better than what's there now, is heavily battle
tested in production both large (Street View) and small (Android, in every
Nexus 4), is BSD licensed, uses Eigen internally, has extensive sparse
Well, it might use Eigen internally, but ceres' interface dealing a lot with double-pointers is far away from the
clearity of Eigen ...
It's not clear that Eigen dev's time is best spent working on LM when Ceres
As mentioned already by others, Eigen's LM module existed way longer than Ceres, and there existed a bunch of LM
implementations before that.
Furthermore, I agree with opinions raised by others that including a generic non-linear LS solver into Eigen
might/should not be the goal of Eigen, which IMHO should basically be a *linear* algebra package.
As long as no further dependencies are introduced (neither for compiling nor for licensing), I don't mind if some
small extensions are added, though (clearly not the case for ceres having 2--5 more dependencies).
Keir and I are arguing exactly that, please do not add more stuff into eigen which has nothing to do with linear
algebra. We are not arguing for adding Ceres to eigen, but to remove nonlinear optimization code from eigen.
Dipl.-Inf. Christoph Hertzberg
Tel: +49 (421) 218-64252 <tel:%2B49%20%28421%29%20218-64252>