Re: [eigen] numerical differentiation

[Trevor Irons <trevorirons@xxxxxxxxx>]

Thomas/Benoit:

I reiterate that my comments do not carry much/any weight. I think
that it will be a struggle to provide a robust numerical difference
interface, but that is not my problem. Thomas, please know that my
comments, carry no weight here, and that I am working on similar
problems; it is good to hear about options. Do not let me discourage
you. If you are interested in providing a robust solution I would be
willing to contribute. I am working on 3D EM problems. I would like to
see the indirect solver interface improved, personally. Especially for
the complex case. The netlib template library seems like a great place
to start. How this fits into Eigen is perhaps a secondary discussion.
Is there any desire for this?

-Trevor


   O__  ---- Trevor Irons, PhD Candidate
  c/ /'_ --- Dept. of Geophysics
 (*) \(*) -- Colorado School of Mines
~~~~~~~~~~~  Ph:  (+01) 720.635.8218
~~~~~~~~~~~  (tirons@xxxxxxxxx)



2009/9/27 Rohit Garg <rpg.314@xxxxxxxxx>:
> Trevor does have some good points here. A better idea for what is
> being attempted would be perhaps to provide backends, like it was done
> for FFT. Though in that case, we have a basic FFT code in eigen's core
> as well.
>
> Instead of throwing the kitchen sink into eigen, let's provide
> external interfaces to top notch libraries that exist for that
> purpose. This way, we can expose the need of users and avoid
> maintaining the code as well. If a feature gets used often, even if it
> is unsupported, it will end up core developer's brain cycles.
>
> On Mon, Sep 28, 2009 at 9:04 AM, Trevor Irons <trevorirons@xxxxxxxxx> wrote:
>> Thomas:
>>
>> I am not much of an authority regarding Eigen, but I'll put in my two
>> cents. Please don't construe this comment as a general Eigen comment.
>> I've implemented second order, first and second differential operators
>> for a 3D finite difference electromagnetic code on something sort of
>> looking like a Yee grid. The problem is that these operators can
>> easily become problem dependent and delivering a general differential
>> operator seems, to me at least, impossible. The boundary conditions
>> and dimensionality considerations should not be addressed at this
>> level. Blitz++ has attempted to do this:
>> http://www.oonumerics.org/blitz/manual/blitz04.html with 'stencils'
>> but these assume 1D situations which are not general. Personally, I
>> abandoned Blitz for this, and other reasons.
>>
>> I see Eigen as more of a pure math library. I see this as a strength,
>> and I mean this in the most positive way. Implementing specific
>> difference operators should be problem specific and honestly not too
>> difficult. For most problems I imagine you will be working with Gael's
>> Sparse implementation.  Although this is considered a 'beta' part of
>> Eigen I consider it a huge strength. It is beautiful and natural
>> compared to the alternatives IMO.
>>
>> So I will reiterate. I consider the 'math' focused bent of Eigen a
>> plus. Eigen should remain a ' lightweight C++ template library
>> for linear algebra.' This is a beautiful place to stand. Trying to
>> support every finite element/finite difference scheme that comes your
>> way will obfuscate the goal of the project.
>>
>> Please correct me if I am wrong in my assumptions. By the way I have a
>> Hankel transform algorithm that I would be willing to contribute if
>> anyone is interested.
>>
>> -Trevor
>>
>>   O__  ---- Trevor Irons, PhD Candidate
>>  c/ /'_ --- Dept. of Geophysics
>>  (*) \(*) -- Colorado School of Mines
>> ~~~~~~~~~~~  Ph:  (+01) 720.635.8218
>> ~~~~~~~~~~~  (tirons@xxxxxxxxx)
>>
>>
>>
>> 2009/9/27 Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>:
>>>
>>>
>>> Well, anyway, i've put one in unsupported/NumericalDiff on my eigen fork, it
>>> provides Forward and Central, with (quite basic) unit tests :
>>>
>>> http://bitbucket.org/orzel/eigen2-
>>> cminpack/src/tip/unsupported/Eigen/src/NumericalDiff/NumericalDiff.h
>>> http://bitbucket.org/orzel/eigen2-
>>> cminpack/src/tip/unsupported/test/NumericalDiff.cpp
>>>
>>> I use a template parameter 'mode' to select which one is used... and i have
>>> two questions related to this:
>>>
>>> * in the code i use a switch(mode), in the hope that the compiler will
>>> optimize this and only the relevant code will be compiled-in, and no test will
>>> be made at run-time for the switch... can you confirm ?
>>>
>>> * i'm afraid that the enum for the mode is cluttering the namespace.. how
>>> could i do better ?
>>>
>>> best regards,
>>> Thomas
>>>
>>>
>>> In data lunedì 28 settembre 2009 01:50:15, Thomas Capricelli ha scritto:
>>>> Hello,
>>>>
>>>> Is anybody working on providing 'numerical differenciation' for eigen ?
>>>> (http://en.wikipedia.org/wiki/Numerical_differentiation).
>>>>
>>>> libmv has something approaching (they use eigen) here:
>>>> http://code.google.com/p/libmv/source/browse/trunk/src/libmv/numeric/functi
>>>> on_derivative.h
>>>>
>>>> but i'm not sure how general it can be made.
>>>>
>>>> Ideally, there would be NumericalDifferenciation using forward difference,
>>>> central difference, and some higher order formula
>>>>
>>>> Thomas
>>>>
>>>
>>> --
>>> Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>
>>> http://www.freehackers.org/thomas
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Rohit Garg
>
> http://rpg-314.blogspot.com/
>
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology
> Bombay
>
>
>