|Re: [eigen] numerical differentiation|
[ Thread 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 01:28:10 -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; bh=s3CspMhJKVY3CUknl4zM9fL0KbP2a0wg3FUWcqkuhV0=; b=JSlHZ9lMZYSkPdUML/sV0aPhUVc+Hgms1tdn20N4wVmqq8MiTO3oFKgayJwwOUGIxx UwrRh/oizr0G/Dy604ujIv/MyVyKrzdup72oa8z81ZQ8scB+VmfwV2+dj/iVQAqLHhI0 yEaSs862bMXksmYnSDAuVjGCuqJGPeVB/rc98=
- 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; b=qpQ6phsxPua7F6uHIiQwj5N5/lmMRjq5w30yYtPjoQcSri4MYcMgQnZA3hcet7BJ4Y jXduujb/43LXF3Swfrle+0HcxTUEDU1AqvC52jp0ntIzKSIbxcV9fQDQLkqBlXK9YHF7 dh30qBFwbL8JCq0oFYLCoA/OKa/gCG2GWPI4A=
2009/9/28 Rohit Garg <rpg.314@xxxxxxxxx>:
> Trevor does have some good points here.
Just to be clear: I never said he didn't ;)
I just tend to avoid as long as possible dealing with the specifics of
all proposals that appear on this list: otherwise I get sucked into
studying other people's stuff all the time ;)
Now I had a look at Thomas' code and that seems like pretty reasonable
stuff to me as a minimalistic/naive/lightweight implementation, and
then, Rohit's suggestion of allowing to use backends seems very good
to me! Without allowing backends, indeed I'm afraid that this isn't
going to be very useful: doing robust numeric differentiation is
probably much harder than that (and we probably don't want to enter
into that in Eigen).
Thomas --> one remark: calling resize() on fixed size matrices,
passing the right size, is a NOP, it's perfectly OK and we do that all
> 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
Sounds very reasonable to me!
But again, even so, it's useful to provide a minimalistic
implementation built-in, and Thomas' code is that.
> 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.
Yes, it's true. Thanks for caring about these aspects, it's
appreciated ;) It will end in our brain cycles, if only when we wonder
whether to move that to Eigen/.