[jira] [Updated] (MATH-1325) Improve finite differencing infrastructure
[ 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)
[jira] [Comment Edited] (MATH-1325) Improve finite differencing infrastructure
[ https://issues.apache.org/jira/browse/MATH-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149787#comment-15149787 ] Fran Lattanzio edited comment on MATH-1325 at 2/17/16 3:36 AM: --- Here is a pull request with the infrastructure to do everything for the univariate case. https://github.com/apache/commons-math/pull/24 was (Author: flattanzio): Here is a pull request that contains some new code for doing everything above: https://github.com/apache/commons-math/compare/master...syenkoc:master?expand=1 > 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! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1325) Improve finite differencing infrastructure
[ https://issues.apache.org/jira/browse/MATH-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149787#comment-15149787 ] Fran Lattanzio commented on MATH-1325: -- Here is a pull request that contains some new code for doing everything above: https://github.com/apache/commons-math/compare/master...syenkoc:master?expand=1 > 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! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1325) Improve finite differencing infrastructure
Fran Lattanzio created MATH-1325: Summary: 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! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-173) Update CSVRecord Constructor
[ https://issues.apache.org/jira/browse/CSV-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149517#comment-15149517 ] Mike Foody commented on CSV-173: Adding a record interface would also allow Mockito and other mocking tools to easily mock records. Given the choice though I'd go all the way and create the factory as well. I'd rather not mock a simple class like CSVRecord if I can avoid it. > Update CSVRecord Constructor > > > Key: CSV-173 > URL: https://issues.apache.org/jira/browse/CSV-173 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.2 >Reporter: Mike Foody >Priority: Minor > > Thanks for the solid library. This is a simple change but the fact that > CSVRecord is final and doesn't have a public constructor means you end up > having to write more code than seems necessary just to instantiate instances > for test cases. If it was made non final then most mocking frameworks would > happily mock it or if it had a public constructor it could just be > instantiated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-173) Update CSVRecord Constructor
[
https://issues.apache.org/jira/browse/CSV-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149515#comment-15149515
]
Gary Gregory commented on CSV-173:
--
I like final because it allows the JVM to optimize best and gives us the
freedom to fiddle with the class.
I wonder if adding a record factory class would be best here?
{code:java}
CSVRecordFactory.getDefault().newRecord(...)
{code}
Would your code be OK to call a factory method. This would give us the most
flexibility moving forward.
Hm... but we do not have a record interface, I would probably want to add one
of those as well...
> Update CSVRecord Constructor
>
>
> Key: CSV-173
> URL: https://issues.apache.org/jira/browse/CSV-173
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.2
>Reporter: Mike Foody
>Priority: Minor
>
> Thanks for the solid library. This is a simple change but the fact that
> CSVRecord is final and doesn't have a public constructor means you end up
> having to write more code than seems necessary just to instantiate instances
> for test cases. If it was made non final then most mocking frameworks would
> happily mock it or if it had a public constructor it could just be
> instantiated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CSV-173) Update CSVRecord Constructor
Mike Foody created CSV-173: -- Summary: Update CSVRecord Constructor Key: CSV-173 URL: https://issues.apache.org/jira/browse/CSV-173 Project: Commons CSV Issue Type: Improvement Components: Parser Affects Versions: 1.2 Reporter: Mike Foody Priority: Minor Thanks for the solid library. This is a simple change but the fact that CSVRecord is final and doesn't have a public constructor means you end up having to write more code than seems necessary just to instantiate instances for test cases. If it was made non final then most mocking frameworks would happily mock it or if it had a public constructor it could just be instantiated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IO-499) FilenameUtils.directoryContains(String, String) gives false positive when two directories exist with equal prefixes
Federico Bonelli created IO-499:
---
Summary: FilenameUtils.directoryContains(String, String) gives
false positive when two directories exist with equal prefixes
Key: IO-499
URL: https://issues.apache.org/jira/browse/IO-499
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.4
Reporter: Federico Bonelli
Priority: Minor
In a folder layout as such:
{code}
/foo/a.txt
/foo2/b.txt
{code}
The result of invoking directoryContains is wrong:
{code}
FilenameUtils.directoryContains("/foo", "/foo2/b.txt"); // returns true
{code}
even if "/foo" and "/foo2/b.txt" are the canonical paths, they start with the
same characters, and the current implementation of the method fails.
As workaround we are currently appending a path separator '/' to the first
argument.
It is noteworthy that the current implementation of
FileUtils.directoryContains() reveals this issue because it uses the
File.getCanonicalPath() to obtain the String paths of "/foo" and "/foo2/b.txt".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-479) An Order Statistic Tree
[ https://issues.apache.org/jira/browse/COLLECTIONS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148762#comment-15148762 ] Rodion Efremov commented on COLLECTIONS-479: I am more or less done with a Set-implementation that provides methods get(int index) and indexOf(T element); both run in O(log N). See here: https://github.com/coderodde/OrderStatisticTree However, if a Map is required, please tell me, should not take much time to refactor. Best, rodde > An Order Statistic Tree > --- > > Key: COLLECTIONS-479 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-479 > Project: Commons Collections > Issue Type: New Feature >Reporter: Ajo Fod >Priority: Minor > Fix For: 4.x > > Attachments: COLLECTIONS-479.patch, NodeExistsException.java, > RedBlackBST.java > > > An order statistic tree http://en.wikipedia.org/wiki/Order_statistic_tree > provides two useful properties. The ability to rank arbitrary keys relative > to keys existing in the tree AND the ability to retrieve elements from the > tree with the given rank. > This can be used to find the percentile rank of a key for example. > This functionality is not yet provided yet by any of the major libraries > AFAIK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
