Re: [eigen] numerical differentiation

[ Thread Index | Date Index | More Archives ]

Ahh, I forgot that you were working on the minpack porting project; or
I didn't make the connection between the numerical differentiation and
that project. I totally agree that the minimization algorithms belong
in eigen. If I understand now, your need for numerical differentiation
is for things like steepest descent?  In this case, sure, you need
this and it belongs in eigen. I don't know if I would call it a naive
implementation, so much as a specific one. I just read your first
email and was concerned that this could blow up into something huge,
and that you were not aware of this. Sounds like you have no intention
to let this happen.

No, I don't know of any 'backends' for this sort of thing (numerical
differentiation), or none that are not embedded in some large Finite
Element / Difference library. It is much more natural to do this
within eigen. I don't know of any better backends for non linear
minimisation either. I am sure you did an exhaustive search before
embarking on this : ) I am very interested to look into your port.
Thanks for the contribution.

While we are sort of on the subject, does eigen provide an optimised
convolution operator? I could see this as a way to provide numerical
differentiation in a fairly abstract way that would be fast and pretty
general and useful. I'm backpedaling... If we have FFT, convolution
seems natural. Convolution is embarrassingly parallel. Could it be

Is sounds like you are planning on making minpack work with sparse
matrices then? I would be very excited to see this.

I feel your pain with the old FORTRAN code. This Hankel transform I
just finished porting to C++ came from old 66 code rife with
IMPLICITs, assigned GOTO's, EQUIVALENCE, and externals. I don't think
it would be possible to make more confusing code.

I have no issues with the NumerialDiff module given your arguments.


Mail converted by MHonArc 2.6.19+