[ https://issues.apache.org/jira/browse/MATH1325?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=15270843#comment15270843
]
Eric Barnhill commented on MATH1325:

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 commonsmath 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: MATH1325
> URL: https://issues.apache.org/jira/browse/MATH1325
> 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 13 to include support for multivariate finite differences.

This message was sent by Atlassian JIRA
(v6.3.4#6332)
