[
https://issues.apache.org/jira/browse/MATH-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fran Lattanzio updated MATH-1325:
---------------------------------
Description:
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.
was:
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!
> 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)
