|Re: [eigen] numerical differentiation|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] numerical differentiation
- From: Rohit Garg <rpg.314@xxxxxxxxx>
- Date: Mon, 28 Sep 2009 10:07:45 +0530
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=tvJVklBauFiyY2dOQ8NdbfNSZGnPv+VA3pcwU+lK4wI=; b=jNQz31IpG0GhdUDcFOCrXh6bG1+w6DbwsphJBB9ASYISBVQq2pfyx+vGXXcUzRXkdB M7z6LBi6W3cb5xqjZwzooH7V/RcbWza/J7x0eJ77yTVIMMK4CEM49muT8tMTAigSvtjF yWNPJkn436f3UjbOnbdtk6GHvDFDfISxsu93M=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=iDV3uaqKIGf2j3aTpmiZCjEKdmJuD4A78HVdXF4pXOdE6kydsb2hdUzTJCciiL1gGf mKj7CB6jVRvgqTN00kKhOaI4hYtnaraLoJbFzzugxWgGtstHWgsGJQirhNgpg/ocq7tw Va431ww1sr4tQ+l5qKns58395f82nJgc0/ifw=
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
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:
> 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.
> 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 :
>> 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,
>> In data lunedì 28 settembre 2009 01:50:15, Thomas Capricelli ha scritto:
>>> Is anybody working on providing 'numerical differenciation' for eigen ?
>>> libmv has something approaching (they use eigen) here:
>>> 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 Capricelli <orzel@xxxxxxxxxxxxxxx>
Department of Physics
Indian Institute of Technology