[GitHub] commons-lang pull request #:
Github user kinow commented on the pull request: https://github.com/apache/commons-lang/commit/dfecbe970917754511a081f8b86efac211e624f6#commitcomment-21810221 +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (NUMBERS-21) Target Java 7
Raymond DeCampo created NUMBERS-21: -- Summary: Target Java 7 Key: NUMBERS-21 URL: https://issues.apache.org/jira/browse/NUMBERS-21 Project: Commons Numbers Issue Type: Task Reporter: Raymond DeCampo Priority: Minor Numbers is being populated with code from [math], which targets Java 7. Currently Java 6 is targeted in the pom.xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973556#comment-15973556 ] Emmanuel Bourg commented on CONFIGURATION-656: -- We could have both: an uber jar (commons-configuration2) and smaller modules (commons-configuration2-core, commons-configuration2-json, commons-configuration2-yaml, etc). > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #:
Github user PascalSchumacher commented on the pull request: https://github.com/apache/commons-lang/commit/dfecbe970917754511a081f8b86efac211e624f6#commitcomment-21808707 nice refactorings :+1: --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973517#comment-15973517 ] Gary Gregory commented on CONFIGURATION-656: In an ideal world, I want to tell my users to write their config in XML, JSON, or YAML and let me program consume it all. It's a little more of a pain if I have to include all possible modules but not too bad. Having an uber-jar helps in that case too. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973495#comment-15973495 ] Emmanuel Bourg commented on CONFIGURATION-656: -- Using an external library is fine I think. We could probably consider moving the extra configuration formats into their own modules to avoid overloading the main module with rarely used dependencies. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1351) New sampler API for "MultivariateRealDistribution"
[
https://issues.apache.org/jira/browse/MATH-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973377#comment-15973377
]
Rob Tompkins commented on MATH-1351:
Sounds good. We'll leave it here for now.
> New sampler API for "MultivariateRealDistribution"
> --
>
> Key: MATH-1351
> URL: https://issues.apache.org/jira/browse/MATH-1351
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, deprecation
> Fix For: 4.X
>
>
> Make changes similar to those {{RealDistribution}} and
> {{IntegerDistribution}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1351) New sampler API for "MultivariateRealDistribution"
[
https://issues.apache.org/jira/browse/MATH-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973334#comment-15973334
]
Gilles commented on MATH-1351:
--
bq. If we'd go for a new "Commons Distributions" standalone component,
FTR: It was my initial intention to create such a component, and have it
contain what is now in the {{o.a.c.rng.sampling.distribution}} package of the
{{commons-rng-sampling}} module of "Commons RNG".
It was a logical separation of concern since the sampling from non-uniform
distributions is _based_ on uniform sampling that is _provided_ by an RNG
algorithm such as implemented in module {{commons-rng-core}} of "Commons RNG".
> New sampler API for "MultivariateRealDistribution"
> --
>
> Key: MATH-1351
> URL: https://issues.apache.org/jira/browse/MATH-1351
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, deprecation
> Fix For: 4.X
>
>
> Make changes similar to those {{RealDistribution}} and
> {{IntegerDistribution}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1351) New sampler API for "MultivariateRealDistribution"
[
https://issues.apache.org/jira/browse/MATH-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973321#comment-15973321
]
Gilles commented on MATH-1351:
--
No; this is about *multivariate* sampling, "Commons RNG" does not deal with
that.
If we'd go for a new "Commons Distributions" standalone component, it would
depend on the {{commons-rng-sampling}} module of "Commons RNG" (for the
univariate Gaussian sampling) and on another new "Commons Linear Algebra"
component (that would be derived from the contents of the package
{{o.a.c.m.linear}}).
> New sampler API for "MultivariateRealDistribution"
> --
>
> Key: MATH-1351
> URL: https://issues.apache.org/jira/browse/MATH-1351
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, deprecation
> Fix For: 4.X
>
>
> Make changes similar to those {{RealDistribution}} and
> {{IntegerDistribution}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973285#comment-15973285 ] The Alchemist commented on CONFIGURATION-656: - Turns out that jackson's YAML support uses snakeyaml (https://github.com/FasterXML/jackson-dataformats-text/tree/master/yaml), so I'm just gonna use that. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973104#comment-15973104 ] Oliver Heger commented on CONFIGURATION-656: Just wanted to bring this in as an additional option. I would indeed prefer this variant because new dependencies have always some potential to cause problems (e.g. version mismatchs when integrating Commons Configuration in client applications) - provided we manage to come to a fast and reliable solution on our own. But it would also be okay to start with a version that uses an external library and later aim for an optimization. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973097#comment-15973097 ] The Alchemist commented on CONFIGURATION-656: - @[~oliver.he...@t-online.de]: Are you saying you would reject a patch that uses Jackson for YAML, or that creating a parser is a long-term goal after an implementation that uses Jackson/whatever is used? > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973090#comment-15973090 ] Oliver Heger commented on CONFIGURATION-656: Ideally, we would have no additional dependencies. For PList configuration formats the way was chosen to use a parser generator to read such files. But this means of course much more effort. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-663) typo at /userguide/upgradeto2_0.html
[
https://issues.apache.org/jira/browse/CONFIGURATION-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973082#comment-15973082
]
Oliver Heger commented on CONFIGURATION-663:
Actually, the class is named {{BaseHierarchicalConfiguration}}. Thanks for
spotting this.
> typo at /userguide/upgradeto2_0.html
>
>
> Key: CONFIGURATION-663
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-663
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: The Alchemist
>
> At
> http://commons.apache.org/proper/commons-configuration/userguide/upgradeto2_0.html:
> "BasieHierarchicalConfiguration" should start with "Basic" instead?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CONFIGURATION-663) typo at /userguide/upgradeto2_0.html
The Alchemist created CONFIGURATION-663: --- Summary: typo at /userguide/upgradeto2_0.html Key: CONFIGURATION-663 URL: https://issues.apache.org/jira/browse/CONFIGURATION-663 Project: Commons Configuration Issue Type: Bug Reporter: The Alchemist At http://commons.apache.org/proper/commons-configuration/userguide/upgradeto2_0.html: "BasieHierarchicalConfiguration" should start with "Basic" instead? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972975#comment-15972975 ] Gary Gregory commented on CONFIGURATION-656: I know Jackson works well and its license is compatible. Not sure about the others. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972969#comment-15972969 ] The Alchemist commented on CONFIGURATION-656: - I can write this if someone points me in the right direction. There's a few alive YAML libraries are there: * jackson-dataformat-yaml * yamlbeans * snakeyaml Any preference? > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1413) Add generics to Frequency
[
https://issues.apache.org/jira/browse/MATH-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1413:
---
Fix Version/s: 4.0
> Add generics to Frequency
> -
>
> Key: MATH-1413
> URL: https://issues.apache.org/jira/browse/MATH-1413
> Project: Commons Math
> Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Labels: generics
> Fix For: 4.0
>
>
> The Frequency class has no generic types, but creates an internal TreeMap,
> with keys with the type `Comparator`. Then whenever you add or get values
> from the TreeMap, it will throw CCE if you pass a key value with a different
> type from the others stored in the map.
> {code}
> Frequency f = new Frequency();
> // Okay
> f.addValue("Ola");
> // Key 12, type Integer, does not match String type. CCE, wrapped in a Math
> exception
> f.addValue(12);
> {code}
> And even a simpler example without Math classes to help outlining the issue.
> {code}
> TreeMap map = new TreeMap<>();
> int key = 1;
> map.put(key, "One");
> // Okay
> map.get(100);
> // TreeMap will try to call 1.1#compareTo against each Key it contains, which
> can result
> // in a CCE here.
> map.get(1.1);
> {code}
> It is not clear how we could compare the key type to the given v value.
> Checking if the map is not empty, and then checking the type of the first key
> doesn't sound very elegant (and not sure if it would be a valid solution).
> A better solution could be to add generics to the class, breaking the current
> contract (i.e. not allowing three types, boxing to longs, etc), but on the
> bright side, it won't use CCE as a normal workflow, nor need suppress
> warnings annotations any more.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1353) "EmpiricalDistribution" has various shortcomings
[ https://issues.apache.org/jira/browse/MATH-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1353: --- Fix Version/s: (was: 4.0) 4.X > "EmpiricalDistribution" has various shortcomings > > > Key: MATH-1353 > URL: https://issues.apache.org/jira/browse/MATH-1353 > Project: Commons Math > Issue Type: Improvement >Reporter: Gilles >Priority: Minor > Labels: refactoring > Fix For: 4.X > > > * Class uses file IO (CM should not be concerned with data persistence) > * Class uses the "java.net" API (ditto) > I'd think that the core functionality could be provided without supporting > data loading (from a file or a URL). > Data input would be via any of > * Collection > * Iterable > * Stream (Java 8) > A redesign goal should be to make the class immutable. > E.g. data source must be set in the constructor (rather than via a "load" > method); there would thus be a one-to-one correspondence between data source > and distribution instance. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1390) LUDecomposition slow on larger matrices
[ https://issues.apache.org/jira/browse/MATH-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1390: --- Fix Version/s: (was: 3.7) > LUDecomposition slow on larger matrices > --- > > Key: MATH-1390 > URL: https://issues.apache.org/jira/browse/MATH-1390 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 4.0, 3.7 >Reporter: Wilhelm Burger >Priority: Minor > Labels: performance > Fix For: 4.0 > > Original Estimate: 6h > Remaining Estimate: 6h > > Commons-math LUDecomposition runs ca. 10 times slower than the original > (referenced) JAMA implementation for a matrix of size 1600 x 1600, slowdown > is noticable above size 750 x 750, regardless of matrix type. > It is suggested to revert to the proven (and fast) JAMA implementation and > overhaul the LUDecomposition class (and related classes) in the 'linear' > package. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1375) BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
[
https://issues.apache.org/jira/browse/MATH-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1375:
---
Fix Version/s: 4.0
> BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
> -
>
> Key: MATH-1375
> URL: https://issues.apache.org/jira/browse/MATH-1375
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Java 8 JDK, OpenJDK, Ubuntu
>Reporter: Thomas Weise
>Priority: Minor
> Fix For: 4.0
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I am using BOBYQAOptimizer to solve some numerical problems related to
> nonlinear function fitting. BOBYQAOptimizer is provided with close-to-optimal
> solutions which it is supposed to refine. In some cases, BOBYQAOptimizer
> seems to enter an endless loop, or at least an extremely long loop. The
> problem is almost impossible to reproduce as it occurs maybe once every 1000
> runs.
> From what I can see with the debugger, the source of the problem is probably
> method trsbox which is called by bobyqb. In trsbox, some values of a vector
> (sorry, forgot which one) grow extremely large (>=1e250). Either way, I
> noticed that both mentioned methods feature a for(;; ) loop.
> Now that algorithm looks quite mathematical to me and seemingly has been
> translated from FORTRAN or something. I think fixing and finding mathematical
> issues might be complicated (see also the caveats reported in the release
> notes) and overall, the algorithm is working.
> How about you also count the iterations of the for(;; ) loops in bobyqb and
> trsbox and throw an exception if they exceed some limit? In the easiest case,
> instead of for(;; ) you can do something like
> {code}
> for(int maxRemainingSteps=100; (--maxRemainingSteps)>=0;) {
> ...
> }
>throw new MaxCountExceededException(100);
> // or TooManyEvaluationsException(100);
> // or MathIllegalStateException(LocalizedFormats.SIMPLE_MESSAGE, "Huh?");
> {code}
> Since the original for loops are always left via "return", that would already
> do the trick. Or you could use an Incrementor object for this purpose. Either
> way, I think with the very simple fix above, you would prevent endless loops,
> add only a tiny bit of very easy-to-understand code, and would not break the
> algorithm contract, since such exceptions could be thrown sometimes even
> without the fix.
> In summary: BOBYQAOptimizer needs some work. Fixing the issue I observed
> properly (i.e., by fixing the special cases causing it) is probably very
> complex and is probably not feasible. Preventing it, however, seems to be
> rather easy, as I have shown above.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1169) Faster Percentile
[
https://issues.apache.org/jira/browse/MATH-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1169:
---
Fix Version/s: 4.X
> Faster Percentile
> -
>
> Key: MATH-1169
> URL: https://issues.apache.org/jira/browse/MATH-1169
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Adam Stelmaszczyk
>Priority: Minor
> Fix For: 4.X
>
> Attachments: FloydRivest.java, Main.java, PercentileFloydRivest.java
>
>
> Percentile class is now using Hoare selection algorithm (aka
> [Quickselect|http://en.wikipedia.org/wiki/Quickselect]) with median of 3 for
> choosing a pivot and caching pivots. Quickselect expected runtime is about
> 3.4N + O(N).
> The constant can be improved to 1.5N by different pivot strategy involving
> sampling, yielding the [Floyd–Rivest
> algorithm|http://en.wikipedia.org/wiki/Floyd%E2%80%93Rivest_algorithm], which
> has average complexity of 1.5N + O(N) for median, with other position
> statistics even faster.
> For proof of concept I implemented Floyd–Rivest algorithm without caching
> pivots following Wikipedia and benchmarked it with
> [Caliper|https://code.google.com/p/caliper/].
> Array size - runtime for Floyd-Rivest - runtime for current Percentile - %
> faster
> 10 - 6.907 - 7.083 - 2.5%
> [link|https://microbenchmarks.appspot.com/runs/a0d947ee-57fc-4636-b687-b4bc5170f1d7#r:scenario.benchmarkSpec.methodName]
> 100 - 70.3 - 75.4 - 6.8%
> [link|https://microbenchmarks.appspot.com/runs/77291c2e-6dbb-4666-bf37-c174e4b53f2e#r:scenario.benchmarkSpec.methodName]
> 1000 - 708 - 868 - 18.4%
> [link|https://microbenchmarks.appspot.com/runs/c0f65e35-44c0-458e-b6e0-634b4e6fa68b#r:scenario.benchmarkSpec.methodName]
> In attachments:
> {{Main.java}} should be run to repeat experiments, it needs Caliper JAR:
> https://code.google.com/p/caliper/downloads/detail?name=caliper-1.0-beta-1-all.jar
> Every call to evaluate() I'm filling the input double[] array with different
> random numbers.
> {{FloydRivest.java}} contatins implementation of algorithm basing on
> pseudocode from its Wikipedia page.
> {{PercentileFloydRivest.java}} is Percentile.java with modified evaluate(),
> so it calls FloydRivest.select() instead of typical select(). pivotsHeap was
> removed for simplicity (maybe it can improve efficiency even more).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1364) Missing unit tests
[ https://issues.apache.org/jira/browse/MATH-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1364: --- Fix Version/s: (was: 4.0) 4.X > Missing unit tests > -- > > Key: MATH-1364 > URL: https://issues.apache.org/jira/browse/MATH-1364 > Project: Commons Math > Issue Type: Test >Affects Versions: 3.6.1 >Reporter: Gilles >Priority: Minor > Labels: test > Fix For: 4.X > > > Units tests are missing for the following classes: > * o.a.c.m.util.RandomPivotingStrategy > * o.a.c.m.util.MedianOf3PivotingStrategy > * o.a.c.m.util.CentralPivotingStrategy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-943) Markov chains
[
https://issues.apache.org/jira/browse/MATH-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-943:
--
Fix Version/s: 4.X
> Markov chains
> -
>
> Key: MATH-943
> URL: https://issues.apache.org/jira/browse/MATH-943
> Project: Commons Math
> Issue Type: Wish
>Reporter: Piotr Wydrych
>Priority: Minor
> Fix For: 4.X
>
> Attachments: MarkovChain.java, MarkovChainTest.java, package-info.java
>
>
> I'd like to contribute a Markov chain class. I was not sure to which package
> this class should belong. Therefore, I've created a new
> {{org.apache.commons.math3.random.process}} package. I attach class file,
> test file, and package info.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1359) Function object for "expm1(x) / x"
[ https://issues.apache.org/jira/browse/MATH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1359: --- Fix Version/s: (was: 4.X) 4.0 > Function object for "expm1(x) / x" > -- > > Key: MATH-1359 > URL: https://issues.apache.org/jira/browse/MATH-1359 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Assignee: Rob Tompkins >Priority: Minor > Fix For: 4.0 > > > Function object to be created in package o.a.c.m.analysis.function. > Rationale: see MATH-1344. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1397) Complex.ZERO.pow(2.0) is NaN
[
https://issues.apache.org/jira/browse/MATH-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1397:
---
Fix Version/s: 4.0
> Complex.ZERO.pow(2.0) is NaN
>
>
> Key: MATH-1397
> URL: https://issues.apache.org/jira/browse/MATH-1397
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Linux, Java1.7/Java1.8
>Reporter: Mario Wenzel
>Assignee: Eric Barnhill
>Priority: Minor
> Fix For: 4.0
>
>
> ```
> package complextest;
> import org.apache.commons.math3.complex.Complex;
> public class T {
> public static void main(String[] args) {
> System.out.println(Complex.ZERO.pow(2.0));
> }
> }
> ```
> This is the code and the readout is `(NaN, NaN)`. This surely isn't right.
> For one, it should actually be zero
> (https://www.wolframalpha.com/input/?i=(0%2B0i)%5E2) and second of all, the
> documentation doesn't state that anything could go wrong from a Complex
> number that has no NaNs and Infs.
> The other definition states that it doesn't work when the base is Zero, but
> it surely should. This strange corner case destroys any naive implementation
> of stuff wrt the mandelbrot set.
> It would be nice to not have to implement this exception myself.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-667) Representations of the complex numbers
[
https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-667:
--
Fix Version/s: 4.X
> Representations of the complex numbers
> --
>
> Key: MATH-667
> URL: https://issues.apache.org/jira/browse/MATH-667
> Project: Commons Math
> Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
> Labels: features
> Fix For: 4.X
>
>
> Several issues have been raised about the current behaviour of the "Complex"
> class, located in package "o.a.c.m.complex" (e.g. MATH-657, MATH-620).
> The ensuing discussion revealed various, sometimes incompatible, requirements
> with focus on efficiency or consistency or backwards compatibility or
> comparison with other math packages (Octave) or faithfulness to standards
> (C99x).
> It is thus proposed to create several classes, each with a clearly defined
> purpose.
> The consensus seems to be that the first task is to implement a new
> "BasicComplex" class where the computational formulae (for computing real and
> imaginary part of a complex) will be applied directly without worrying about
> limiting cases (NaNs and infinities). Doing so will automatically produce a
> behaviour similar to the Java {{double}} primitive. It is also assumed that
> it will be the most efficient implementation for "normal" use (i.e. not
> involving limiting cases).
> This task would consist in copying most of the code in the existing "Complex"
> class over to "BasicComplex". And similarly with "ComplexTest". Then, in
> "BasicComplex", one would remove all variables that refer to NaNs and
> infinities together with checks and special assignments, and adapt the unit
> tests along the way.
> A new "ExtendedComplex" class would inherit from "BasicComplex". This class
> would aim at representing the compactified space of the complex numbers (one
> point-at-infinity).
> A new "C99Complex" class would inherit from "BasicComplex". This class would
> aim at implementing the C99x standard.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1351) New sampler API for "MultivariateRealDistribution"
[
https://issues.apache.org/jira/browse/MATH-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1351:
---
Fix Version/s: (was: 4.0)
4.X
> New sampler API for "MultivariateRealDistribution"
> --
>
> Key: MATH-1351
> URL: https://issues.apache.org/jira/browse/MATH-1351
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, deprecation
> Fix For: 4.X
>
>
> Make changes similar to those {{RealDistribution}} and
> {{IntegerDistribution}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1351) New sampler API for "MultivariateRealDistribution"
[
https://issues.apache.org/jira/browse/MATH-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972926#comment-15972926
]
Rob Tompkins commented on MATH-1351:
Should this be moved to [rng]?
> New sampler API for "MultivariateRealDistribution"
> --
>
> Key: MATH-1351
> URL: https://issues.apache.org/jira/browse/MATH-1351
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, deprecation
> Fix For: 4.X
>
>
> Make changes similar to those {{RealDistribution}} and
> {{IntegerDistribution}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1411) "LevenbergMarquardtOptimizerTest" is shaky
[ https://issues.apache.org/jira/browse/MATH-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1411: --- Fix Version/s: (was: 4.0) 4.X > "LevenbergMarquardtOptimizerTest" is shaky > -- > > Key: MATH-1411 > URL: https://issues.apache.org/jira/browse/MATH-1411 > Project: Commons Math > Issue Type: Test >Reporter: Gilles >Priority: Minor > Labels: unit-test > Fix For: 4.X > > > Test method "testCircleFitting2" is too sensitive to the seed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1359) Function object for "expm1(x) / x"
[ https://issues.apache.org/jira/browse/MATH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1359: --- Fix Version/s: (was: 4.0) 4.X > Function object for "expm1(x) / x" > -- > > Key: MATH-1359 > URL: https://issues.apache.org/jira/browse/MATH-1359 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Assignee: Rob Tompkins >Priority: Minor > Fix For: 4.X > > > Function object to be created in package o.a.c.m.analysis.function. > Rationale: see MATH-1344. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-966) Native support for upper and lower bound for SimplexSolver
[ https://issues.apache.org/jira/browse/MATH-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-966: -- Fix Version/s: 4.X > Native support for upper and lower bound for SimplexSolver > -- > > Key: MATH-966 > URL: https://issues.apache.org/jira/browse/MATH-966 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.1.1, 4.0 >Reporter: Alexander Sehlström >Priority: Minor > Fix For: 4.X > > Attachments: simplextest.java > > > The SimplexSolver (import > org.apache.commons.math3.optim.linear.SimplexSolver) do not support lower and > upper bounds as input arguments. It would be convenient to have this support > since this would be very helpful when dealing with unconstrained problems (no > Ax = c present) that has bounds on x (x_l <= x <= x_u). > Attached is a piece of code in need for such a feature where a lot of > fiddeling is needed in order to convert the bounds (x_l <= x <= x_u) to > constraints (Ax = c). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1410) "MultiStartMultivariateOptimizerTest" is shaky
[ https://issues.apache.org/jira/browse/MATH-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1410: --- Fix Version/s: (was: 4.0) 4.X > "MultiStartMultivariateOptimizerTest" is shaky > -- > > Key: MATH-1410 > URL: https://issues.apache.org/jira/browse/MATH-1410 > Project: Commons Math > Issue Type: Test >Reporter: Gilles >Priority: Minor > Labels: unit-test > Fix For: 4.X > > > The "testRosenbrock" test method (package "o.a.c.m.optim.nonlinear.scalar") > is too sensitive to the seed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1380) LoessInterpolator can calculate median residual for robustness iterations incorrectly
[ https://issues.apache.org/jira/browse/MATH-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1380: --- Fix Version/s: 4.0 > LoessInterpolator can calculate median residual for robustness iterations > incorrectly > - > > Key: MATH-1380 > URL: https://issues.apache.org/jira/browse/MATH-1380 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Richard Wilkinson >Priority: Minor > Fix For: 4.0 > > Attachments: MATH-1380-loess-residual-median.patch > > > When LoessInterpolator.smooth determines the median residual to use in > weighting points when performing robustness iterations its calculation is > only strictly correct for odd numbers of points. For even numbers it should > take the mean of the central two residuals. While this may not generally make > a large difference it hinders comparison with other implementations (such as > R loess) for testing. > Patch and additional tests available. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-928: -- Fix Version/s: (was: 4.0) 4.X > Alternative approach to matrix implementations > -- > > Key: MATH-928 > URL: https://issues.apache.org/jira/browse/MATH-928 > Project: Commons Math > Issue Type: New Feature >Reporter: Gilles >Priority: Minor > Labels: api > Fix For: 4.X > > Attachments: basic_matrix.tar.gz > > > Old and recent discussions on the "dev" ML bought different, and > incompatible, viewpoints on how to provide matrix and linear algebra features > in Commons Math. > Problems with the current API have been summarized in MATH-765. > Those sometimes contributes to putting the CM matrix implementations into the > category of "bloated" code (too many methods that rebuff would-be > contributors from creating new subclasses that only need specific > functionality). > It also poses the question of "purpose": Which implementations are good for a > given usage? Or which should be avoided. > The Commons Math's development model assumes that the implementations were > created to answer some specific need of the contributor(s). But eventually, > the limitations of the ad-hoc implementations (often) do not make it to the > description (Javadoc, user guide, unit test, use cases); and the new tool > just becomes an additional "low-level" components of the library. > Such building blocks are then reused (as a black box) in another context, > e.g. another par of the library (which is a good thing), sometimes with > unforeseen (and not so good) consequences (cf. MATH-924). > It seems that Commons Math could either provide more building blocks (to try > and cover use cases that need different features), or "restrict" usage of the > classes that were maybe primarily developed for a specific usage. > As I hinted above, the former might be rendered more difficult by imposing a > relatively complex interface. > In this issue, I attempted to explore an alternative approach (which was > briefly mentioned more than a year ago, IIRC) by which matrix functionality > would be built up by mixing and matching simple (and more or less > independent) components. > As an example, I've implemented a new matrix class with a focus on > immutability. Certain uses might benefit from such a feature, while for > others, this will be drawback. > However, my hope would be that "elementary" building blocks could lend > themselves to "combinations" by which some algorithm would convert between > the various matrix implementations so as to use to most appropriate for a > given sequence of operations. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1284) Vector is-not-a Point
[ https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1284: --- Fix Version/s: 4.0 > Vector is-not-a Point > - > > Key: MATH-1284 > URL: https://issues.apache.org/jira/browse/MATH-1284 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Roman Werpachowski >Priority: Minor > Fix For: 4.0 > > > The class hierarchy for geometry claims that Vector is-a Point: > https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html > This is mathematically incorrect, see e.g. > http://math.stackexchange.com/a/645827 > Just because they share the same numerical representation, Point and Vector > shouldn't be crammed into a common class hierarchy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[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 ] Rob Tompkins updated MATH-1325: --- Fix Version/s: 4.X > 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 > Fix For: 4.X > > > 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.15#6346)
[jira] [Updated] (MATH-1409) "UncorrelatedRandomVectorGenerator" is shaky
[ https://issues.apache.org/jira/browse/MATH-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1409: --- Fix Version/s: (was: 4.0) 4.X > "UncorrelatedRandomVectorGenerator" is shaky > > > Key: MATH-1409 > URL: https://issues.apache.org/jira/browse/MATH-1409 > Project: Commons Math > Issue Type: Test >Reporter: Gilles >Priority: Minor > Labels: unit-test > Fix For: 4.X > > > This unit test (package "o.a.c.m.random") is too sensitive to the seed. > Using a fixed seed to make it pass (rather than relaxing the tolerance) gives > a wrong impression about the code's purpose (or potentially hides a bug). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1215) Allow solvers to return "Complex" roots
[
https://issues.apache.org/jira/browse/MATH-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1215:
---
Fix Version/s: (was: 4.0)
4.X
> Allow solvers to return "Complex" roots
> ---
>
> Key: MATH-1215
> URL: https://issues.apache.org/jira/browse/MATH-1215
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Labels: API, design
> Fix For: 4.X
>
>
> Some solvers in {{o.a.c.m.analysis.solvers}} are able to return the set of
> all complex roots of a function (namely "LaguerreSolver").
> However, the functionality does not fit with the overall design of the
> classes in this package which focus of computing one real ("double") root
> within a user-defined interval.
> An idea is to provide a "ComplexSolver" public interface whose "solve" method
> would return a "Complex[]" containing the complex roots.
> Moreover some time ago, we decided to modify the Commons Math API so as to
> provide the "fluent API" idiom.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1281) "Median" should not extend "Percentile"
[
https://issues.apache.org/jira/browse/MATH-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1281:
---
Fix Version/s: (was: 4.0)
4.X
> "Median" should not extend "Percentile"
> ---
>
> Key: MATH-1281
> URL: https://issues.apache.org/jira/browse/MATH-1281
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Gilles
>Priority: Minor
> Fix For: 4.X
>
>
> Class {{Median}} (package {{o.a.c.m.stat.descriptive.rank}} inherits several
> {{evaluate}} methods from {{Percentile}} where one of the arguments is the
> percentile value. That doesn't make sense, and easily allows for user bugs.
> Either those inherited methods should be overridden by methods that throw a
> "forbidden" exception, or perhaps more correctly (but not
> backwards-compatible), the methods with a specific percentile argument should
> be made "static". The latter would also fix the same problem in the
> {{Percentile}} class itself.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-362) Bullet-proof code using try-with-resources statements
[
https://issues.apache.org/jira/browse/COMPRESS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972907#comment-15972907
]
Stefan Bodewig commented on COMPRESS-362:
-
sorry, there are a few more {{finally}}s, but neither of them is a candidate
for try-with-resources.
> Bullet-proof code using try-with-resources statements
> -
>
> Key: COMPRESS-362
> URL: https://issues.apache.org/jira/browse/COMPRESS-362
> Project: Commons Compress
> Issue Type: Improvement
>Affects Versions: 1.12
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.14
>
>
> Bullet-proof code using try-with-resources statements. Some code fragments
> already use try-finally blocks, so for these, the code looks cleaners. For
> other code fragments that do not use try-finally blocks, this is an
> improvement.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (COMPRESS-362) Bullet-proof code using try-with-resources statements
[
https://issues.apache.org/jira/browse/COMPRESS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-362.
-
Resolution: Fixed
grep showed one remaining {{finally}} in {{src/main}} that has been fixed with
commit 674886f
> Bullet-proof code using try-with-resources statements
> -
>
> Key: COMPRESS-362
> URL: https://issues.apache.org/jira/browse/COMPRESS-362
> Project: Commons Compress
> Issue Type: Improvement
>Affects Versions: 1.12
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.14
>
>
> Bullet-proof code using try-with-resources statements. Some code fragments
> already use try-finally blocks, so for these, the code looks cleaners. For
> other code fragments that do not use try-finally blocks, this is an
> improvement.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1395) MathParseException when parsing fractions on Android
[
https://issues.apache.org/jira/browse/MATH-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1395:
---
Fix Version/s: 4.0
> MathParseException when parsing fractions on Android
>
>
> Key: MATH-1395
> URL: https://issues.apache.org/jira/browse/MATH-1395
> Project: Commons Math
> Issue Type: Bug
>Reporter: Brian Zable
> Fix For: 4.0
>
>
> I'm seeing a strange issue when trying to work with the Fraction classes on
> Android. In my tests, which are standard JUnit tests, the following code
> performs flawlessly;
> {code:java}
> String amount = "1 1/2";
> ProperFractionFormat ff = new ProperFractionFormat();
> Fraction f = ff.parse(amount.trim());
> {code}
> However, at run time in an Android application, the same code throws an
> Exception:
> {noformat}
>Caused by:
> org.apache.commons.math3.exception.MathParseException: illegal state: string
> "1 1/2" unparseable (from position 3) as an object of type
> org.apache.commons.math3.fraction.Fraction
> at
> org.apache.commons.math3.fraction.FractionFormat.parse(FractionFormat.java:199)
> {noformat}
> I am testing on a Nexus 5X emulator with API level 23 for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1401) Exception at IntervalUtils.getClopperPearsonInterval
[ https://issues.apache.org/jira/browse/MATH-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1401: --- Fix Version/s: 4.0 > Exception at IntervalUtils.getClopperPearsonInterval > > > Key: MATH-1401 > URL: https://issues.apache.org/jira/browse/MATH-1401 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Art > Fix For: 4.0 > > > IntervalUtils.getClopperPearsonInterval throws an exception when number of > successes equals to zero or number of successes = number of trials. > IntervalUtils.getClopperPearsonInterval(1, 0, 0.95) or > IntervalUtils.getClopperPearsonInterval(1, 1, 0.95) throws > org.apache.commons.math3.exception.NotStrictlyPositiveException despite that > its input parameters are valid. > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1137) BOBYQA incorrect indexing
[ https://issues.apache.org/jira/browse/MATH-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1137: --- Fix Version/s: 4.0 > BOBYQA incorrect indexing > - > > Key: MATH-1137 > URL: https://issues.apache.org/jira/browse/MATH-1137 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Nigel Goodwin > Fix For: 4.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1394) Implementation of DIRECT global optimizer
[ https://issues.apache.org/jira/browse/MATH-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1394: --- Fix Version/s: 4.X > Implementation of DIRECT global optimizer > - > > Key: MATH-1394 > URL: https://issues.apache.org/jira/browse/MATH-1394 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.5, 3.6 >Reporter: Burton Patkau > Fix For: 4.X > > > An open source implementation of the DIRECT global optimizer, described by > Jones, Perttunen and Stuckmann, implementing > math3.optim.nonlinear.scalar.MultivariateOptimizer, is available as > DIRECTOptimizer.java at > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/main/com/wwidesigner/math. > There are also three variants of the algorithm on that page: > DIRECT_L_Optimizer implements DIRECT-L by Gablonsky and Kelley, > DIRECT1Optimizer changes which sides are chosen for dividing, and > DIRECTCOptimizer adds alternative ways to select potentially-optimal > hyperrectangles. > DIRECT is not as fast as BOBYQA, but is better at finding a global minimum in > a field of many local minima. > JUnit tests for all of these, using standard optimizer test functions, are > available in > https://github.com/edwardkort/WWIDesigner/tree/optimizer/WWIDesigner/src/test/com/wwidesigner/math. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1398) Support simple Arithmetic mean without Compute correction factor in second pass?
[
https://issues.apache.org/jira/browse/MATH-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1398:
---
Fix Version/s: 4.X
> Support simple Arithmetic mean without Compute correction factor in second
> pass?
>
>
> Key: MATH-1398
> URL: https://issues.apache.org/jira/browse/MATH-1398
> Project: Commons Math
> Issue Type: Improvement
> Environment: All
>Reporter: Francis Li
> Labels: easyfix
> Fix For: 4.X
>
>
> The mean calculate by this function is different excel. which just sum/n as
> first half of function. can we provide another option to calculate normal
> means?
> org.apache.commons.math3.stat.descriptive.moment.Mean
> public double evaluate(final double[] values,final int begin, final int
> length)
> 163throws MathIllegalArgumentException {
> 164if (test(values, begin, length)) {
> 165Sum sum = new Sum();
> 166double sampleSize = length;
> 167
> 168// Compute initial estimate using definitional formula
> 169double xbar = sum.evaluate(values, begin, length) / sampleSize;
> 170
> 171// Compute correction factor in second pass
> 172double correction = 0;
> 173for (int i = begin; i < begin + length; i++) {
> 174correction += values[i] - xbar;
> 175}
> 176return xbar + (correction/sampleSize);
> 177}
> 178return Double.NaN;
> 179}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1406) official support for compiling on GWT 2.8
[ https://issues.apache.org/jira/browse/MATH-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1406: --- Fix Version/s: 4.0 > official support for compiling on GWT 2.8 > - > > Key: MATH-1406 > URL: https://issues.apache.org/jira/browse/MATH-1406 > Project: Commons Math > Issue Type: Improvement >Reporter: Michael Borcherds > Fix For: 4.0 > > Original Estimate: 168h > Remaining Estimate: 168h > > Context: at the moment Apache Commons Math can't be compiled using GWT (to > allow it to be made into a JavaScript library for example) > http://www.gwtproject.org/ > Is there any interest in allowing Apache Commons Math to be officially > supported on GWT? > With GWT 2.8.0 the changes needed aren't too hard to get most of it to compile > You can see the diff from 3.6.1 here: > https://github.com/murkle/commons-math/issues/1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1282) BOBYQA trsbox infinite loop
[ https://issues.apache.org/jira/browse/MATH-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1282: --- Fix Version/s: 4.0 > BOBYQA trsbox infinite loop > --- > > Key: MATH-1282 > URL: https://issues.apache.org/jira/browse/MATH-1282 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Tillmann Gaida > Fix For: 4.0 > > > Apparently the BOBYQA optimizer can get stuck in the trsbox method. This > happened to us out of the blue after millions of successful optimizations. > Unfortunately our target function has too many dependencies, so I can't > provide a unit test for the full optimization. I have however created a unit > test which isolates the call to trsbox: http://pastebin.com/wYPVS3SC > I took a quick look at the code, but it looks like one can't understand a > thing without having read the original paper. Can someone help? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1371) Provide accelerated kmeans++ implementation
[ https://issues.apache.org/jira/browse/MATH-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1371: --- Fix Version/s: 4.0 > Provide accelerated kmeans++ implementation > --- > > Key: MATH-1371 > URL: https://issues.apache.org/jira/browse/MATH-1371 > Project: Commons Math > Issue Type: Improvement >Reporter: Artem Barger >Assignee: Artem Barger > Fix For: 4.0 > > Attachments: ElkanKmeansPlusPlusClusterer.java, > ElkanKmeansPlusPlusClustererTest.java > > > There is an updated version of kmeans++ algorithm available, which is > published in: Elkan, Charles. "Using the triangle inequality to accelerate > k-means." ICML. Vol. 3. 2003. paper. > The main essence is to boost the kmeans iterations by avoiding computation of > distances between centers and points when there is no need for that. For > example after the update cluster center haven't moved too far from the point > therefore no change in point assignment. The accelerated algorithm avoids > unnecessary distance calculations by applying the triangle inequality in two > different ways, and by keeping track of lower and upper bounds for distances > between points and centers. > Algorithm description is available in the paper. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1216) Add balancing of unsymmetric matrices in EigenDecomposition
[ https://issues.apache.org/jira/browse/MATH-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1216: --- Fix Version/s: 4.X > Add balancing of unsymmetric matrices in EigenDecomposition > --- > > Key: MATH-1216 > URL: https://issues.apache.org/jira/browse/MATH-1216 > Project: Commons Math > Issue Type: Improvement >Reporter: Thomas Neidhart > Fix For: 4.X > > > To improve the speed and accuracy when calculating eigen values, unsymmetric > matrices should be balanced. The default used in LAPACK is the Parlett > Reinsch method. > This page contains information about the various methods and proposes another > one: > http://www.cs.pomona.edu/~tzuyi/Research/Balancing/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-387.
-
Resolution: Fixed
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972866#comment-15972866
]
Stefan Bodewig commented on COMPRESS-387:
-
Strange, I've merged the pull request. Many thanks.
Any idea what's going on here?
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972863#comment-15972863
]
ASF GitHub Bot commented on COMPRESS-387:
-
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/19
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-385) Add detect() to CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972857#comment-15972857
]
Stefan Bodewig commented on COMPRESS-385:
-
I've just seen COMPRESS-387, sorry for the noise
> Add detect() to CompressorStreamFactory
> ---
>
> Key: COMPRESS-385
> URL: https://issues.apache.org/jira/browse/COMPRESS-385
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
> Fix For: 1.14
>
>
> On TIKA-1631, several users have requested that we try to avoid an OOM when a
> corrupted Z file is "detected" by CompressorStreamFactory.
> In Tika, for detection, we're creating the stream via CompressorStreamFactory
> and then "detecting" based on what stream was created. Given that there can
> be some overhead in creating the stream and that there can be an OOM for a
> corrupt Z file, it would be great to add a {{detect(InputStream is)}} option
> in CompressorStreamFactory.
> PR on way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-385) Add detect() to CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972845#comment-15972845
]
Stefan Bodewig commented on COMPRESS-385:
-
Re: test failures, looks as if
https://builds.apache.org/job/Commons-Compress%20SonarQube/81/testReport/
highlighted the exact same tests
> Add detect() to CompressorStreamFactory
> ---
>
> Key: COMPRESS-385
> URL: https://issues.apache.org/jira/browse/COMPRESS-385
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
> Fix For: 1.14
>
>
> On TIKA-1631, several users have requested that we try to avoid an OOM when a
> corrupted Z file is "detected" by CompressorStreamFactory.
> In Tika, for detection, we're creating the stream via CompressorStreamFactory
> and then "detecting" based on what stream was created. Given that there can
> be some overhead in creating the stream and that there can be an OOM for a
> corrupt Z file, it would be great to add a {{detect(InputStream is)}} option
> in CompressorStreamFactory.
> PR on way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-385) Add detect() to CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972830#comment-15972830
]
Stefan Bodewig commented on COMPRESS-385:
-
[~talli...@apache.org] I've tweaked your patch a little, the only real change
is that I now allow 7z to be detected as well - trying to obtain a stream will
still throw an exception, though. I can imagine that Tika would benefit from
detecting a 7z archive as well.
> wouldn't users have gotten a ClassNotFoundException (NoClassDefError?) before
> if they had called the 2 parameter createCompressorInputStream; now they're
> getting a CompressorException.
yes, right, so not only does the message change, the type of exception does as
well.
I'm not sure what to make from the test errors you see,
https://builds.apache.org/job/Commons-Compress-Windows/ seems to be fine. We
probably should try to identify and fix the problem in a different issue.
Many thanks!
> Add detect() to CompressorStreamFactory
> ---
>
> Key: COMPRESS-385
> URL: https://issues.apache.org/jira/browse/COMPRESS-385
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
> Fix For: 1.14
>
>
> On TIKA-1631, several users have requested that we try to avoid an OOM when a
> corrupted Z file is "detected" by CompressorStreamFactory.
> In Tika, for detection, we're creating the stream via CompressorStreamFactory
> and then "detecting" based on what stream was created. Given that there can
> be some overhead in creating the stream and that there can be an OOM for a
> corrupt Z file, it would be great to add a {{detect(InputStream is)}} option
> in CompressorStreamFactory.
> PR on way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-385) Add detect() to CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972812#comment-15972812
]
ASF GitHub Bot commented on COMPRESS-385:
-
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/18
> Add detect() to CompressorStreamFactory
> ---
>
> Key: COMPRESS-385
> URL: https://issues.apache.org/jira/browse/COMPRESS-385
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
> Fix For: 1.14
>
>
> On TIKA-1631, several users have requested that we try to avoid an OOM when a
> corrupted Z file is "detected" by CompressorStreamFactory.
> In Tika, for detection, we're creating the stream via CompressorStreamFactory
> and then "detecting" based on what stream was created. Given that there can
> be some overhead in creating the stream and that there can be an OOM for a
> corrupt Z file, it would be great to add a {{detect(InputStream is)}} option
> in CompressorStreamFactory.
> PR on way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (VFS-633) Memory/reference leak when handling tar.gz-files
[
https://issues.apache.org/jira/browse/VFS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Björn Persson Mattsson closed VFS-633.
--
Resolution: Not A Problem
See previous comment. The problem turned out to be caused by something else.
> Memory/reference leak when handling tar.gz-files
>
>
> Key: VFS-633
> URL: https://issues.apache.org/jira/browse/VFS-633
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows, Red Hat Linux
>Reporter: Björn Persson Mattsson
>
> When using VFS to process a large amount of tar.gz-archives there is a memory
> leak occurring where the references to a lot of TarArchiveEntry and
> TarFileObject objects are never released. This ultimately leads to an
> OutOfMemoryError.
> After using NetBeans profiler to trace where the persistent objects are
> created, it seems like they originate from calls to
> `VFS.getManager().resolveFile("tgz://" + filePath)`. The method traces
> returned from the profiler are shown below:
> org.apache.commons.compress.archivers.tar.TarArchiveEntry
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry
> ()
> org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
> org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
> org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
> (Comparable, org.apache.commons.vfs2.FileSystem)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
> (String, org.apache.commons.vfs2.FileObject,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
> org.apache.commons.vfs2.provider.tar.TarFileObject
> org.apache.commons.vfs2.provider.tar.TarFileSystem.createTarFileObject
> (org.apache.commons.vfs2.provider.AbstractFileName,
> org.apache.commons.compress.archivers.tar.TarArchiveEntry)
> org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
> org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
> org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
> (Comparable, org.apache.commons.vfs2.FileSystem)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
> (String, org.apache.commons.vfs2.FileObject,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
> I have tried to explicitly close the TarFileSystems after the processing is
> done by calling
> `VFS.getManager().closeFileSystem(archiveFileObject.getFileSystem())` but I
> see no difference in the amount of live persistent objects.
> I have also tried calling `((DefaultFileSystemManager)
> VFS.getManager()).freeUnusedResources()` but no difference there either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (VFS-633) Memory/reference leak when handling tar.gz-files
[
https://issues.apache.org/jira/browse/VFS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972653#comment-15972653
]
Björn Persson Mattsson commented on VFS-633:
After more troubleshooting it turned out that the problem was ultimately caused
by readers that were never closed. Closing those readers/inputstreams before
going out of scope allowed for the previously persistent TarFileObject and
TarFileEntry objects to be cleaned up during garbage collection.
Closing this issue.
> Memory/reference leak when handling tar.gz-files
>
>
> Key: VFS-633
> URL: https://issues.apache.org/jira/browse/VFS-633
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows, Red Hat Linux
>Reporter: Björn Persson Mattsson
>
> When using VFS to process a large amount of tar.gz-archives there is a memory
> leak occurring where the references to a lot of TarArchiveEntry and
> TarFileObject objects are never released. This ultimately leads to an
> OutOfMemoryError.
> After using NetBeans profiler to trace where the persistent objects are
> created, it seems like they originate from calls to
> `VFS.getManager().resolveFile("tgz://" + filePath)`. The method traces
> returned from the profiler are shown below:
> org.apache.commons.compress.archivers.tar.TarArchiveEntry
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry
> ()
> org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
> org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
> org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
> (Comparable, org.apache.commons.vfs2.FileSystem)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
> (String, org.apache.commons.vfs2.FileObject,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
> org.apache.commons.vfs2.provider.tar.TarFileObject
> org.apache.commons.vfs2.provider.tar.TarFileSystem.createTarFileObject
> (org.apache.commons.vfs2.provider.AbstractFileName,
> org.apache.commons.compress.archivers.tar.TarArchiveEntry)
> org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
> org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
> org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
> (Comparable, org.apache.commons.vfs2.FileSystem)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
> (String, org.apache.commons.vfs2.FileObject,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String,
> org.apache.commons.vfs2.FileSystemOptions)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
> (org.apache.commons.vfs2.FileObject, String)
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
> I have tried to explicitly close the TarFileSystems after the processing is
> done by calling
> `VFS.getManager().closeFileSystem(archiveFileObject.getFileSystem())` but I
> see no difference in the amount of live persistent objects.
> I have also tried calling `((DefaultFileSystemManager)
> VFS.getManager()).freeUnusedResources()` but no difference there either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IO-531) make it more esay-to-use: org.apache.commons.io.FileUtils.listFiles(File, IOFileFilter, IOFileFilter)
[ https://issues.apache.org/jira/browse/IO-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972422#comment-15972422 ] Sebb commented on IO-531: - The Javadoc [1] says: "dirFilter optional filter to apply when finding subdirectories. If this parameter is null, subdirectories will not be included in the search. Use TrueFileFilter.INSTANCE to match all directories. R" Does FileUtils.listFiles(File, filter, TrueFileFilter.INSTANCE) not work for you? [1] http://commons.apache.org/proper/commons-io/javadocs/api-2.5/org/apache/commons/io/FileUtils.html#listFiles(java.io.File,%20org.apache.commons.io.filefilter.IOFileFilter,%20org.apache.commons.io.filefilter.IOFileFilter) > make it more esay-to-use: org.apache.commons.io.FileUtils.listFiles(File, > IOFileFilter, IOFileFilter) > - > > Key: IO-531 > URL: https://issues.apache.org/jira/browse/IO-531 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.5 >Reporter: Hao Liu > > when I only want to filter the directories, it should be better to allow me > to set the second parameter to null or I have to implement the > org.apache.commons.io.filefilter.IOFileFilter interface with nothing > functionally task to do. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (VFS-633) Memory/reference leak when handling tar.gz-files
Björn Persson Mattsson created VFS-633:
--
Summary: Memory/reference leak when handling tar.gz-files
Key: VFS-633
URL: https://issues.apache.org/jira/browse/VFS-633
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: Windows, Red Hat Linux
Reporter: Björn Persson Mattsson
When using VFS to process a large amount of tar.gz-archives there is a memory
leak occurring where the references to a lot of TarArchiveEntry and
TarFileObject objects are never released. This ultimately leads to an
OutOfMemoryError.
After using NetBeans profiler to trace where the persistent objects are
created, it seems like they originate from calls to
`VFS.getManager().resolveFile("tgz://" + filePath)`. The method traces returned
from the profiler are shown below:
org.apache.commons.compress.archivers.tar.TarArchiveEntry
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry
()
org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
(Comparable, org.apache.commons.vfs2.FileSystem)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
(String, org.apache.commons.vfs2.FileObject,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
org.apache.commons.vfs2.provider.tar.TarFileObject
org.apache.commons.vfs2.provider.tar.TarFileSystem.createTarFileObject
(org.apache.commons.vfs2.provider.AbstractFileName,
org.apache.commons.compress.archivers.tar.TarArchiveEntry)
org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
(Comparable, org.apache.commons.vfs2.FileSystem)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
(String, org.apache.commons.vfs2.FileObject,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
I have tried to explicitly close the TarFileSystems after the processing is
done by calling
`VFS.getManager().closeFileSystem(archiveFileObject.getFileSystem())` but I see
no difference in the amount of live persistent objects.
I have also tried calling `((DefaultFileSystemManager)
VFS.getManager()).freeUnusedResources()` but no difference there either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
