[
https://issues.apache.org/jira/browse/MATH-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270843#comment-15270843
]
Eric Barnhill commented on MATH-1325:
-------------------------------------
Hi Fran,
I am just a noob around here, but I would say that your Java code looks very
polished, and very well integrated into the commons-math framework.
I have a few questions about how this library is to be used if you don't mind.
(1) When you posted to the list you suggested that the code gave the user the
ability to carefully specify bandwidth in a FD approximation. But, I don't see
that power here. I only see the user's ability to specify support size and
error. Bandwidth can be returned as a double, but that is different than being
able to specify the bandwidth when the FD approximation is constructed. Is this
possible?
(2) Regarding the double returned as bandwidth. I am not sure what it means.
For example, let's say in Matlab I call "[b,a] = butter(4, 0.4 0.6)". I know
that I have created a 4th order Butterworth with normalized passband frequency
between 0.4 and 0.6 . Does your bandwidth value return a value on the
normalized spectrum like this, presumably a highpass cutoff since the method is
differencing? If not what does it return?
(3) In the documentation you mention (and implement) the use of BigFraction so
that the initial FD derivations are done completely with rational numbers. You
also mention that this is much slower than a decimal approximation. So far
sounds very interesting. However when the method returns coefficients it does
not return the BigFraction, it returns a double[]. What is the relationship of
the double[] to the BigFraction? What is the point of using a BigFraction if
the user only gets a double[] in the end anyway?
Thanks and apologies if these were dumb questions.
> 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)
