Re: [eigen] numerical differentiation

[Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>]

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
> cents.


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 
eigen proper.

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 
c++/eigen.

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.


regards,
Thomas
-- 
Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>
http://www.freehackers.org/thomas