|Re: [eigen] numerical differentiation|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
In data lunedì 28 settembre 2009 05:34:11, Trevor Irons ha scritto:
> I am not much of an authority regarding Eigen, but I'll put in my two
Hi Trevor. Thanks for your feedback. Don't worry about our reaction : mailing
lists are here for this kind of brainstorming. I'll try to address every point
raised in the thread.
First, i'm totally convinced that eigen should not do everything. Especially
regarding things like finite elements or numerical differentiation, or any
heavy numerical algorithm. I think there's plenty of room for independent
libraries doing this (based on eigen, of course!).
Here, my purpose is to 'port' minpack to eigen. I think this makes sense
because it will perform much better/faster than if we just do a wrapper around
it. And moreover, it will be a lot more general (we can make it work with
sparse matrices for example). It is already more general than minpack because
it can work with any scalar type.
Though, i want to do that 'cleanly' and minpack provides an algorithm that
uses numerical differentiation. So i thought about moving this part in its own
module. That could be used as a quick&dirty numerical differentiation. I'm ok
to add some big fat warning : "CAREFUL this is a naive differentiation
method". I only did that for minpack completeness. I dont even need that for
my projects (I do need Levenberg Marquadt though).
Providing this naive implementation also allows the user to have some code to
start from for his (domain-)specific implementation.
I think that those two algorithms than minpack provide (Levenberg Marquadt and
non-linear system solving) really belong to eigen. They are basically loops of
heavy linear stuff, the code is short, and more importantly i think those are
very close to be the best LGPL-compatible implementation overthere (please!
dont hesitate to point me to other ones). Several people have already asked
for it, and some projects using eigen already implement those (though in a
less robust form, imho). This would benefit all those people to have it in
Lot of people speak about backends. I guess you were speaking about numerical
differentiation. Because for minpack algorithms, i still have to find
'backends' that could be used here. I see different backends for FFT or sparse
LU or some other stuff. But for those two problems, i have yet to find other
good implementations available. I'll wait for this to add the complexity of
backend handling. Show me "top-notch backends" for those algorithms!
Having backends for numerical differentiation is a good idea.. but do we
really need it in eigen ? I'm not sure... and i'm not interested in doing
this, i know nothing about it and have no need. (but if someone is, please do
Concerning maintainance, the minpack code have not been touched for decades
(this is fortran by the way). Cminpack is maintained, but there has been
almost no need to change anything for years. Those code are very hard to
read/understand (either fortran, or automatically ported code from fortran to
c, i dont know which one is worse), so i'd better maintain some code in
As Benoit pointed out, thanks to the templating nature of eigen, you can
either include or not those files, which means that you have a ZERO cost in
compilation time if you do not need the feature. This is totally optional.
So, as a conclusion : i only provided this minimalist numerical
differentiation because i needed it to be on-par with minpack features set. I
really want people porting from minpack to eigen to 'feel at home' and have
everything that was available. This is one of my main design goal. If the
NumericalDiff module makes a problem, i can embed it in the minpack module,
i'm ok with that.
Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>