[
https://issues.apache.org/jira/browse/MATH-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15271466#comment-15271466
]
Fran Lattanzio commented on MATH-1325:
--------------------------------------
For (1) this is exactly the bandwidth strategy. In the current framework, you
are basically stuck using a fixed bandwidth, regardless of the point at which
you are evaluating the underlying function and the deriviatve/error order of
the finite difference. The bandwidth functions allow you to choose a different
bandwidth based on all of these things. In addition, there are several
strategies that attempt to automatically calculate a "good" bandwidth for you.
Doing the bandwidth calculation is totally independent of the FD coefficient
generation - much like Savitzky-Golay filters, you can generate the
coefficients themselves without knowing the "x" values; the coefficient
generation step assumes only that the coefficients will be used to generate an
FD approximation around some special x*, with other values x*+h, x*-h, x*+2h,
... etc. where h is the bandwidth used. This actually ties in with #2...
In terms of (2), the bandwidth represents the (equi-distant!) space in the
"stencil" or grid of underlying function values that will be combined with the
FD coefficients to generate the derivative approximation. This has nothing to
do with like the magnitude response of the differentiation estimator - I think
bandwidth was bad terminology. Instead, I should have called it something more
like "StepSizeStrategy". In fact, I think I just convinced myself to make this
change. I will do this tonight.
For (3), I did this because we can be sure this way that the finite difference
coefficients themselves are accurate to machine precision. Basically the FD
coefficients are generated by solving a system of linear equations based on
repeated Taylor expansions. If we solved this system using something like the
double-based SVD decomposition, we could end up in situation where some
coefficient is say 0.000000000001 - since the SVD is solving to some tolerance
- rather than 0. In other words, we could end up in a situation where there is
some round-off error in the coefficients. But all of the error analysis
literature for FDs that I have seen assumes that the coefficients are accurate
to 1 ulp. (The *function* need not be accurate to 1 ulp, but that is another
story!)
> Improve finite differencing infrastructure
> ------------------------------------------
>
> Key: MATH-1325
> URL: https://issues.apache.org/jira/browse/MATH-1325
> Project: Commons Math
> Issue Type: New Feature
> Reporter: Fran Lattanzio
> Priority: Minor
>
> The existing finite difference framework in commons math is a limiting
> because it accepts only fixed bandwidth parameters. Furthermore, the finite
> difference coefficients/descriptions are not exposed to the user in any
> reasonable fashion (e.g. a user doing a numerical ODE solve probably wants to
> just grab suitable coefficients from somewhere).
> Conceptually, I think the work of finite difference can be broadly divided
> into three tasks:
> 1. Generation of finite difference coefficients. Again, one should be able to
> do this and get the results outside of the context of taking an actual
> derivative. Ideally, we could generate coefficients for any flavor (forward,
> central, backward) and order.
> 2. Selection of the bandwidth. This is, to be honest, the trickiest part of
> computing a numerical derivative. There is some "art" to picking a proper
> bandwidth that will generate an accurate numerical derivative - there are two
> competing sources of error (roundoff, due to the finite representation of
> floating points; and truncation, due to the inherent nature of finite
> differences). Ideally, we want to pick a bandwidth that will minimize the
> *total* error.
> 3. Actually computing the finite difference derivative estimate. This is
> really easy once you have 1. and 2.
> 4. Extend 1-3 to include support for multivariate finite differences.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
