Re: [eigen] numerical differentiation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] numerical differentiation
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Mon, 28 Sep 2009 00:05:25 -0400
- 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=YlL6IJ39AWfF4XMRIRWAfX8guZTzRYrZmt8nsB/7lGs=; b=dIYUk8u2+XQtzpodrba6GutNeBrJiOeDLWKywXsVwkxvHRY0rclvf1gVv1l3S8zh8e PUUPLjyCaaWcO9c9MejApjTeTcWeNC3tGlIJAWhjbIpCoSMPOkw3I2+EXkwz8IoxliUu 6WWJTzHm3ZBUBcSEdrpCgfycPAp4TtjOOcq40=
- 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=Cwlb7x67kHCcqIzkW27/AwcuVpw82eJs2khTxwXDxueGnKJbfFalBH4w9KsLTC0jbH dGov+kDEVmRNVQIeupTPIAxWhJpK6OARMXXPZQytuWP8Mg9nWddoiljpz97EMdLOugG8 OqZ6ICVtP3B+ODVOJoUK14ZvSFNBkE4a5fj+0=
2009/9/27 Trevor Irons <trevorirons@xxxxxxxxx>:
> 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.
I am totally ignorant about numerical differenciation and what Thomas
is doing there, so I can only speak about the general direction of the
Eigen project.
Being a pure template library means that we can freely provide extra,
separate modules, without making the whole thing any heavier.
This is a great advantage of C++ template libraries and it would be
too bad not to draw the benefits from it.
But on the other hand, you are of course right that we shouldn't try
to provide everything on earth.
So far, from my point of view, the process is this:
1) If someone is motivated enough to write a decent module, and it
looks reasonable and relates to Eigen, we can at least put that in the
unsupported/ directory. Here, unsupported means that we make no
promises and keep ourselves the freedom to remove it at any later
date.
2) If / when
- The module is confirmed to have a tight connection with Eigen (a
good reason to sit in eigen rather than somewhere else)
- The code is in really good shape
- Its usefulness is proven (either because many people are asking
for it, or because we've been convinced)
- Its maintainance is guaranteed (either because the author is known
to be serious, or because we're OK to maintain the code)
Then it can move to Eigen/ as a new supported module.
You are right that we could get rid of all these discussions by saying
that we want to stay a pure linear algebra library. But there are
arguments on the other side:
- from the very beginning of Eigen, we weren't a pure linear algebra
library: already in Eigen 1, we had geometric features for use in
OpenGL apps. Eigen has always been about addressing the need of
real-world applications. That's been one of the best decisions i've
ever taken. The tough question of course is how to draw the limit.
- it's not a priori clear what the limits of a linear algebra library
should be. Better let practical experience speak here, than draw an
abstract limit beforehand and stick to it ever after.
- it's good to attract more people to code with us here, that
enriches our developer community. What happens in my FOSS experience
is that people who come first to contribute an external feature end up
contributing more and more central improvements. It's even starting to
get confirmed in Eigen.
- it also expands our user base ( "hey, this library provides this
and this useful feature" ) which never hurts.
Whee, I should make that a wiki page!
Benoit
>
> 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
>>
>>
>>
>
>
>