Re: [eigen] New Levenberg Marquardt stuff

[ Thread Index | Date Index | More Archives ]

Hello all

I think that Eigen should include a good  non-linear support. Why not ???. Better if based in Thomas work based on Mr Moré and colleagues old-and-reliable MINPACK work. Is there a better implementation???

And it is great if Gäel has improved Eigen interface with it. I will update all the code to the latest interface.

Of course I fully support all Thomas and Gäel job. This is a non sense discussion.

Best regards

On Sat, Dec 8, 2012 at 8:00 PM, Radu B. Rusu <radu.b.rusu@xxxxxxxxx> wrote:

On 12/07/2012 11:23 PM, Sameer Agarwal wrote:
On Fri, Dec 7, 2012 at 6:57 PM, Radu B. Rusu <radu.b.rusu@xxxxxxxxx <mailto:radu.b.rusu@xxxxxxxxx>> wrote:

I know Keir's original email mentioned Ceres so this may come across as self serving, but let me say this quite clearly
and I know Keir will agree with me -- this is not about promoting one solver over another, but just addressing the issue
as to what are the boundaries of a linear algebra library. I for one would not like to see more solvers in Eigen. I'd
rather Eigen focus on on providing exceptional support for various advanced linear algebra algorithms.

Please remember that open source projects are quite organic, and it's not users that define their boundaries but developers/contributors and maintainers. I agree with your concern about focus, and I would not want to have all the Eigen developers drop support for the core linear algebra algorithms and jump on something else, but at the same time I would never tell contributors that are willing to submit and maintain additional code such as LM or other solvers that they are not welcome, especially if the maintainers of the project _do agree_ that it falls within the scope of the project.

As users of open source, we are at the mercy of the maintainers/developers of a project. They dedicate massive amounts of their time to provide their user base with _free_ software, so we can disagree with them, but unless we jump in and help, our opinions might matter less. That being said, there's nothing that I can do as an user other than fork the project and add my own little contributions, if the Eigen dev team decides to drop support for a feature that I need in my own work, or doesn't add an additional one because it falls outside Eigen's scope.

However, we have public mailing lists and at the very least we can have discussions such as this, and express our opinions so that the project's dev team at least gets feedback from us, the users, and hopefully continues to support features that the community considers useful.

    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?

Your argument essentially boils down to -- eigen is awesome.  we need X, so lets add X to eigen, and X will be awesome too.

My argument was to _not_ remove the current LM implementation as it is very useful for a lot of people, as others have stated. Since we've already crossed that bridge and added "X" to the library, and the Eigen dev-team seems to think "X" is within the scope of Eigen, improving "X" further makes a lot of sense. Also expanding "X" might make sense too (e.g., additional solvers), though it really comes down to finding developers / contributors that are willing to submit and maintain that addition. All we want is rock stable (robust + fast) features that fall within the scope defined by the project's leaders, and awesome user support.

I personally do not see anything wrong with building additional Eigen modules, though as Gael explained, since Eigen is a header only project, there is no point in really thinking about it in terms of a library, because if you do not include a particular header, that module will never be seen by the compiler. Since the Eigen team already proved to the community that they are extremely serious about this project, adding additional solvers -- if and only if the maintainers agree and there are contributors in the community actually willing to write the code and support it -- seems like a great idea to me! I think discussing file sizes and counting KB is absolutely irrelevant, unless someone can come up with some concrete numbers and a good use case where the extra code that Eigen is adding in newer versions is hurting that particular project.

Finally, I think we're all thankful to see more and more open source initiatives out there, but I would be way more happy to see projects and efforts actually merge in some cases, rather than see fragmentation, because "open source developer time" is a rare and precious flower. ;) If I sound too much like an Eigen advocate, I apologize (and no, Gael and Benoit have not bribed me to say this :) ), but there's only a handful of open source projects out there that are really "awesome", and Eigen is one of them. The rest of us strive to get to that stage.


Mail converted by MHonArc 2.6.19+