[jira] Created: (DAEMON-139) Stdout/Stderr redirection does not work properly
Stdout/Stderr redirection does not work properly Key: DAEMON-139 URL: https://issues.apache.org/jira/browse/DAEMON-139 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.2 Reporter: Mladen Turk Assignee: Mladen Turk Fix For: 1.0.2 Fix the console redirection. Currently the redirection doesn't work and process stderr/stdout messages are never recorded. Since services does not have console, AllocConsole must be called before duplicating stdout/stderr to file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAEMON-138) Create pidfile for storing the process id.
Create pidfile for storing the process id. -- Key: DAEMON-138 URL: https://issues.apache.org/jira/browse/DAEMON-138 Project: Commons Daemon Issue Type: New Feature Components: Procrun Reporter: Mladen Turk Assignee: Mladen Turk Fix For: 1.0.2 Currently there is no way to easily determine the process id of the service file. Add --PidFile configuration option that will store the process id in file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAEMON-137) Allow to configure JNI message logging
Allow to configure JNI message logging -- Key: DAEMON-137 URL: https://issues.apache.org/jira/browse/DAEMON-137 Project: Commons Daemon Issue Type: New Feature Components: Procrun Affects Versions: 1.0.2 Reporter: Mladen Turk Assignee: Mladen Turk Fix For: 1.0.2 Currently procrun always uses vprintf callback. Add --LogJniMessages configuration option that would allow to bypass that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DBCP-326) Rollback an uncommited transaction on return
Rollback an uncommited transaction on return Key: DBCP-326 URL: https://issues.apache.org/jira/browse/DBCP-326 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.4, 1.3 Environment: Any Reporter: Adrian Tarau Priority: Critical DBCP should perform a rollback(should be configurable but by default activated) when the datasource has auto-commit=false. The reason behind is to avoid passing a partial transaction to the next client. Rolling back a transaction(in case it wasn't committed of course) adds a guarantee to the validity of a connection borrowed from the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-257) FastFourierTransformer.MultiDimensionalComplexMatrix.get() not consistent with FastFourierTransformer.MultiDimensionalComplexMatrix.set()
[ https://issues.apache.org/jira/browse/MATH-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-257: -- Fix Version/s: 2.0 > FastFourierTransformer.MultiDimensionalComplexMatrix.get() not consistent > with FastFourierTransformer.MultiDimensionalComplexMatrix.set() > - > > Key: MATH-257 > URL: https://issues.apache.org/jira/browse/MATH-257 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb >Assignee: Luc Maisonobe > Fix For: 2.0 > > > FastFourierTransformer.MultiDimensionalComplexMatrix.get() is not consistent > with FastFourierTransformer.MultiDimensionalComplexMatrix.set(). > The set() method does not allow a null parameter to get past the first check. > The get() method allows a null parameter provided dimensionSize.length <= 1. > This seems wrong, both because it is inconsistent and because it may allow an > NPE later if dimensionSize.length == 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-335) Fraction.hashCode() inconsistent with Fraction.equals()
[ https://issues.apache.org/jira/browse/MATH-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved MATH-335. --- Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=922715&view=rev Log: MATH-335 Fraction.hashCode() inconsistent with Fraction.equals() Change hashCode() to use fields directly > Fraction.hashCode() inconsistent with Fraction.equals() > --- > > Key: MATH-335 > URL: https://issues.apache.org/jira/browse/MATH-335 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Fix For: 2.1 > > > Fraction.hashCode() is inconsistent with Fraction.equals(). > hashCode() uses getNumerator() (which is not final) rather than directly > accessing the field. > Seems to me that hashCode() has no reason to use the getters - or if it does, > then equals should do so too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-336) Unnecessary null checks in equals methods
[
https://issues.apache.org/jira/browse/MATH-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved MATH-336.
---
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=922714&view=rev
Log:
MATH-336 Unnecessary null checks in equals methods
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/polynomials/PolynomialFunction.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/OpenMapRealVector.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/SparseFieldVector.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/stat/descriptive/moment/VectorialCovariance.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/stat/descriptive/moment/VectorialMean.java
> Unnecessary null checks in equals methods
> -
>
> Key: MATH-336
> URL: https://issues.apache.org/jira/browse/MATH-336
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> Many of the equals() methods have code like the following:
> {code}
> if (obj == null) {
> return false;
> }
> if (!(obj instanceof OpenMapRealVector)) {
> return false;
> }
> {code}
> The null check is redundant, as null would cause the instanceof check to fail
> anyway, so the null check could just be removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-336) Unnecessary null checks in equals methods
[
https://issues.apache.org/jira/browse/MATH-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved MATH-336.
---
Resolution: Fixed
Fixed as part of MATH-337
> Unnecessary null checks in equals methods
> -
>
> Key: MATH-336
> URL: https://issues.apache.org/jira/browse/MATH-336
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> Many of the equals() methods have code like the following:
> {code}
> if (obj == null) {
> return false;
> }
> if (!(obj instanceof OpenMapRealVector)) {
> return false;
> }
> {code}
> The null check is redundant, as null would cause the instanceof check to fail
> anyway, so the null check could just be removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MATH-336) Unnecessary null checks in equals methods
[
https://issues.apache.org/jira/browse/MATH-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb reopened MATH-336:
---
Oops - only some of the instances were fixed as part of MATH-337
> Unnecessary null checks in equals methods
> -
>
> Key: MATH-336
> URL: https://issues.apache.org/jira/browse/MATH-336
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> Many of the equals() methods have code like the following:
> {code}
> if (obj == null) {
> return false;
> }
> if (!(obj instanceof OpenMapRealVector)) {
> return false;
> }
> {code}
> The null check is redundant, as null would cause the instanceof check to fail
> anyway, so the null check could just be removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-337) Equals methods rely on catching ClassCastException rather than using instanceof check
[
https://issues.apache.org/jira/browse/MATH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved MATH-337.
---
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=922713&view=rev
Log:
MATH-337 Equals methods rely on catching ClassCastException rather than using
instanceof check
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/complex/Complex.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/fraction/Fraction.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/geometry/Vector3D.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/linear/LinearConstraint.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/linear/LinearObjectiveFunction.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/linear/SimplexTableau.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/BigReal.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/TransformerMap.java
> Equals methods rely on catching ClassCastException rather than using
> instanceof check
> -
>
> Key: MATH-337
> URL: https://issues.apache.org/jira/browse/MATH-337
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> Several of the equals methods rely on catching ClassCastException rather than
> using an instanceof check.
> For example:
> {code}
> SimplexTableau.equals(Object){
> if (this == other) {
> return true;
> }
> if (other == null) {
> return false;
> }
> try {
> SimplexTableau rhs = (SimplexTableau) other;
> etc.
> } catch (ClassCastException ex) {
> return false;
> }
> }
> {code}
> This is likely to be significantly slower if the cast fails. It would be
> cheaper to do the following:
> {code}
> SimplexTableau.equals(Object){
> if (this == other) {
> return true;
> }
> if (!(other instanceof SimplexTableau)) {
> return false;
> }
> SimplexTableau rhs = (SimplexTableau) other;
> etc.
> }
> {code}
> Note that the null check is no longer needed; it is replaced by the
> instanceof check.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-607) StringUtils.containsAny methods incorrectly matches Unicode 2.0+ supplementary characters.
[ https://issues.apache.org/jira/browse/LANG-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-607: -- Attachment: LANG-607.diff Attaching patch for the record. > StringUtils.containsAny methods incorrectly matches Unicode 2.0+ > supplementary characters. > -- > > Key: LANG-607 > URL: https://issues.apache.org/jira/browse/LANG-607 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.5 > Environment: java version "1.6.0_16" > Java(TM) SE Runtime Environment (build 1.6.0_16-b01) > Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) > Microsoft Windows [Version 6.0.6002] > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_16 > Java home: C:\Program Files\Java\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Minor > Fix For: 3.0 > > Attachments: LANG-607.diff > > > StringUtils.containsAny methods incorrectly matches Unicode 2.0+ > supplementary characters. > For example, define a test fixture to be the Unicode character U+2 where > U+2 is written in Java source as "\uD840\uDC00" > private static final String CharU2 = "\uD840\uDC00"; > private static final String CharU20001 = "\uD840\uDC01"; > You can see Unicode supplementary characters correctly implemented in the JRE > call: > assertEquals(-1, CharU2.indexOf(CharU20001)); > But this is broken: > assertEquals(false, StringUtils.containsAny(CharU2, CharU20001)); > assertEquals(false, StringUtils.containsAny(CharU20001, CharU2)); > This is fine: > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU2)); > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU20001)); > assertEquals(true, StringUtils.contains(CharU2, CharU2)); > assertEquals(false, StringUtils.contains(CharU2, CharU20001)); > because the method calls the JRE to perform the match. > More than you want to know: > - http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-607) StringUtils.containsAny methods incorrectly matches Unicode 2.0+ supplementary characters.
StringUtils.containsAny methods incorrectly matches Unicode 2.0+ supplementary characters. -- Key: LANG-607 URL: https://issues.apache.org/jira/browse/LANG-607 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 2.5 Environment: java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) Microsoft Windows [Version 6.0.6002] Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) Java version: 1.6.0_16 Java home: C:\Program Files\Java\jdk1.6.0_16\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" Reporter: Gary Gregory Assignee: Gary Gregory Priority: Minor Fix For: 3.0 StringUtils.containsAny methods incorrectly matches Unicode 2.0+ supplementary characters. For example, define a test fixture to be the Unicode character U+2 where U+2 is written in Java source as "\uD840\uDC00" private static final String CharU2 = "\uD840\uDC00"; private static final String CharU20001 = "\uD840\uDC01"; You can see Unicode supplementary characters correctly implemented in the JRE call: assertEquals(-1, CharU2.indexOf(CharU20001)); But this is broken: assertEquals(false, StringUtils.containsAny(CharU2, CharU20001)); assertEquals(false, StringUtils.containsAny(CharU20001, CharU2)); This is fine: assertEquals(true, StringUtils.contains(CharU2 + CharU20001, CharU2)); assertEquals(true, StringUtils.contains(CharU2 + CharU20001, CharU20001)); assertEquals(true, StringUtils.contains(CharU2, CharU2)); assertEquals(false, StringUtils.contains(CharU2, CharU20001)); because the method calls the JRE to perform the match. More than you want to know: - http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-410) Include forceReload or refresh method in AbstractFileConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844961#action_12844961 ] Oliver Heger commented on CONFIGURATION-410: Thanks for your patch. I had a look and understand how the feature is implemented. Some comments below: * At least in minor releases we have to keep backwards compatibility to avoid breaking existing code. So we must not change the signature of public or protected methods or reduce method visibility. * Was there a special reason why in the catch(Exception) block the if-statement was dropped? * Is there any chance that you can provide a JUnit test? We usually only add new features if a unit test exists. If not, I can write a test myself. > Include forceReload or refresh method in AbstractFileConfiguration > --- > > Key: CONFIGURATION-410 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-410 > Project: Commons Configuration > Issue Type: Improvement > Components: File reloading >Reporter: Bhanu Vanteru >Priority: Minor > Attachments: AbstractFileConfiguration.diff, > AbstractFileConfiguration.java > > > Consider an enhancement to AbstractFileConfiguration, where in a new method > called forceReload() or refresh(), which is similar to the existing reload() > method, except that strategy.reloadingRequired() is ignored and so a clear() > and load() always occur when this new method is called. I will upload changes > to AbstractFileConfiguration with this new method in a bit, for your review. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MATH-331) t-distribution, Weibull distribution, and Cauchy distribution: add density-function (through HasDensity-interface)
[ https://issues.apache.org/jira/browse/MATH-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed MATH-331. Resolution: Duplicate Superceded by MATH-332 > t-distribution, Weibull distribution, and Cauchy distribution: add > density-function (through HasDensity-interface) > -- > > Key: MATH-331 > URL: https://issues.apache.org/jira/browse/MATH-331 > Project: Commons Math > Issue Type: Improvement >Reporter: Mikkel Meyer Andersen >Priority: Minor > Attachments: patch-rest > > Original Estimate: 3h > Remaining Estimate: 3h > > I've added the density function for the mentioned distributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MATH-330) F-distribution: add density-function (through HasDensity-interface)
[ https://issues.apache.org/jira/browse/MATH-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed MATH-330. Resolution: Duplicate Superceded by MATH-332 > F-distribution: add density-function (through HasDensity-interface) > --- > > Key: MATH-330 > URL: https://issues.apache.org/jira/browse/MATH-330 > Project: Commons Math > Issue Type: Improvement >Reporter: Mikkel Meyer Andersen >Priority: Minor > Attachments: patchfile > > Original Estimate: 1h > Remaining Estimate: 1h > > I've added the density function for the F-distribution. > Tested from R with: > > df(1, 1, 1) > [1] 0.1591549 > > df(1, 5, 2) > [1] 0.3080008 > > df(1, 100, 1) > [1] 0.2407659 > > df(1, 50, 200) > [1] 1.777891 > The result with this new density-function: > FDistributionImpl F1 = new FDistributionImpl(1, 1); > FDistributionImpl F2 = new FDistributionImpl(5, 2); > FDistributionImpl F3 = new FDistributionImpl(100, 1); > FDistributionImpl F4 = new FDistributionImpl(50, 200); > F1.density(1.0); // gives 0.1591549430918953 > F2.density(1.0); // gives 0.308000821694066 > F3.density(1.0); // gives 0.2407658969285279 > F4.density(1.0); // gives 1.7778909151036544 > Some numeric instability may occur because it's the log density that's > calculated, and then the result is the exponential function applied to this > result. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-310) Supply nextSample for all distributions with inverse cdf using inverse transform sampling approach
[ https://issues.apache.org/jira/browse/MATH-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-310: - Fix Version/s: 2.2 > Supply nextSample for all distributions with inverse cdf using inverse > transform sampling approach > -- > > Key: MATH-310 > URL: https://issues.apache.org/jira/browse/MATH-310 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Mikkel Meyer Andersen >Priority: Minor > Fix For: 2.2 > > Attachments: patch_proposal > > Original Estimate: 3h > Remaining Estimate: 3h > > To be able to generate samples from the supported probability distributions, > a generic function nextSample is implemented in > AbstractContinuousDistribution and AbstractIntegerDistribution. This also > gives the possibility to override the method if better algorithms are > available for specific distributions as shown in the small example with the > exponential distribution. > Because the nextExponential is used several places: in nextPoisson it can be > replaces by an instance if the ExponentialDistribution and in ValueServer it > can as well, although maybe not in as natural maner as the other. > This problem with the Exponential is a special problem. In general the > nextSample-approaches immediately gives the possibility the sample from all > the distributions with inverse cdf instead just only a couple. > Only AbstractContinuousDistribution and AbstractIntegerDistribution extends > AbstractDistribution, and both AbstractIntegerDistribution and > AbstractContinuousDistribution has an inverseCumulativeProbability-function. > But in AbstractContinuousDistribution the inverse cdf returns a double, and > at AbstractIntegerDistribution it - naturally - returns an integer. Therefor > the nextSample is not put on AbstractDistribution, but on each extension with > different return types. > RandomGenerator as parameter instead of getting a RNG inside the nextSample, > because one typically wants to use the same RNG because often several random > samples are wanted. Another option is to have a RNG as a field in the class, > but that would be more ugly and also result in several RNGs at runtime. > The nextPoisson etc. ought to be moved as well, if the enhancement is > accepted, but it should be a quick fix. > Tests has to be written for this change as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-345) A new secant solver that does not enforce bracketing
[ https://issues.apache.org/jira/browse/MATH-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-345: - Fix Version/s: 2.2 > A new secant solver that does not enforce bracketing > > > Key: MATH-345 > URL: https://issues.apache.org/jira/browse/MATH-345 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Volkan Aktas >Priority: Minor > Fix For: 2.2 > > > Existing SecantSolver is only able to find a root in the specified bracket. > Non-bracketing versions exist and adding one to the suite would be useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-337) Equals methods rely on catching ClassCastException rather than using instanceof check
[
https://issues.apache.org/jira/browse/MATH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-337:
-
Fix Version/s: 2.1
> Equals methods rely on catching ClassCastException rather than using
> instanceof check
> -
>
> Key: MATH-337
> URL: https://issues.apache.org/jira/browse/MATH-337
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> Several of the equals methods rely on catching ClassCastException rather than
> using an instanceof check.
> For example:
> {code}
> SimplexTableau.equals(Object){
> if (this == other) {
> return true;
> }
> if (other == null) {
> return false;
> }
> try {
> SimplexTableau rhs = (SimplexTableau) other;
> etc.
> } catch (ClassCastException ex) {
> return false;
> }
> }
> {code}
> This is likely to be significantly slower if the cast fails. It would be
> cheaper to do the following:
> {code}
> SimplexTableau.equals(Object){
> if (this == other) {
> return true;
> }
> if (!(other instanceof SimplexTableau)) {
> return false;
> }
> SimplexTableau rhs = (SimplexTableau) other;
> etc.
> }
> {code}
> Note that the null check is no longer needed; it is replaced by the
> instanceof check.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-335) Fraction.hashCode() inconsistent with Fraction.equals()
[ https://issues.apache.org/jira/browse/MATH-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-335: - Fix Version/s: 2.1 > Fraction.hashCode() inconsistent with Fraction.equals() > --- > > Key: MATH-335 > URL: https://issues.apache.org/jira/browse/MATH-335 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Fix For: 2.1 > > > Fraction.hashCode() is inconsistent with Fraction.equals(). > hashCode() uses getNumerator() (which is not final) rather than directly > accessing the field. > Seems to me that hashCode() has no reason to use the getters - or if it does, > then equals should do so too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-351) SimplexSolver fails to solve feasible problem instance
[ https://issues.apache.org/jira/browse/MATH-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-351: - Fix Version/s: 2.1 > SimplexSolver fails to solve feasible problem instance > --- > > Key: MATH-351 > URL: https://issues.apache.org/jira/browse/MATH-351 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows Vista Home Premium Version 6.0 Service Pack 1, > Build 6001 >Reporter: Mark Thomas > Fix For: 2.1 > > Attachments: SimplexFail.xlsx, TestSimplexFail.java > > > SimplexSolver throws an UnboundedSolutionException on a problem instance I > can optimally solve with Excel's Solver. I've kept the parameters between the > two programs the same as far as I can tell (i.e. both have a > precision/epsilon value of 1e-6 and a maxIterations value of 1000). I will > attach a JUnit test with an example problem on which SimplexSolver fails. I > will also attach an Excel spreadsheet wtih the same data and successful > Solver setup in place. > I don't know a whole lot about linear programming or Simplex, but the problem > I'm attempting to solve does appear to have a fairly sparse coefficient > matrix, which may be part of the problem. > It's surprisingly difficult to find a Java-based linear programming library, > so I was ecstatic when I found this. Let me know how I can help! > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-336) Unnecessary null checks in equals methods
[
https://issues.apache.org/jira/browse/MATH-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-336:
-
Fix Version/s: 2.1
> Unnecessary null checks in equals methods
> -
>
> Key: MATH-336
> URL: https://issues.apache.org/jira/browse/MATH-336
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> Many of the equals() methods have code like the following:
> {code}
> if (obj == null) {
> return false;
> }
> if (!(obj instanceof OpenMapRealVector)) {
> return false;
> }
> {code}
> The null check is redundant, as null would cause the instanceof check to fail
> anyway, so the null check could just be removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-284) Avoid ArrayStoreException
[
https://issues.apache.org/jira/browse/MATH-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-284:
-
Fix Version/s: 3.0
> Avoid ArrayStoreException
> -
>
> Key: MATH-284
> URL: https://issues.apache.org/jira/browse/MATH-284
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Klaus Hartlage
>Priority: Minor
> Fix For: 3.0
>
> Attachments: math-284.patch
>
>
> Add a new method
> org.apache.commons.math,Field#getRuntimeClass():
> ...
> /**
> * Returns the runtime class of the FieldElement.
> *
> * @return The {...@code Class} object that represents the runtime
> * class of this object.
> */
> Class getRuntimeClass();
> ...
> and replace all occurrences of
> Array.newInstance(field.getZero().getClass(),)
> with
> Array.newInstance(field.getRuntimeClass(),)
> to avoid the throwing of ArrayStoreException in the case you have a type
> hierachy of Fields with a common interface
> and the array should have the interface type at runtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-332) Replacement of the HasDensity-interface with a "double density(double x)"-method on the AbstractContinuousDistribution
[ https://issues.apache.org/jira/browse/MATH-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-332: - Fix Version/s: 2.1 > Replacement of the HasDensity-interface with a "double density(double > x)"-method on the AbstractContinuousDistribution > - > > Key: MATH-332 > URL: https://issues.apache.org/jira/browse/MATH-332 > Project: Commons Math > Issue Type: Improvement >Reporter: Mikkel Meyer Andersen > Fix For: 2.1 > > Attachments: patch-all > > Original Estimate: 3h > Remaining Estimate: 3h > > Removed the HasDensity-interface and replaced it with a "public double > density(double x)"-method on the AbstractContinuousDistribution-class (it > throws an exception as default if the classes don't override the method). > Implemented density-functions for the F-distribution, t-distribution, Weibull > distribution, and Cauchy distribution (the only continuous ones without a > density implemented). > A side-effect is that ChiSquaredDistributionImpl now uses an internal > GammaDistributionImpl instead of a GammaDistribution. This is the only > "major" change. > This improvement replaces https://issues.apache.org/jira/browse/MATH-330 > (density implementation for the F-distribution) and > https://issues.apache.org/jira/browse/MATH-331 (density implementation for > the other three distributions). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-321) Support for Sparse (Thin) SVD
[ https://issues.apache.org/jira/browse/MATH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-321: - Fix Version/s: 2.1 > Support for Sparse (Thin) SVD > - > > Key: MATH-321 > URL: https://issues.apache.org/jira/browse/MATH-321 > Project: Commons Math > Issue Type: New Feature >Reporter: David Jurgens > Fix For: 2.1 > > > Current the SingularValueDecomposition implementation computes the full SVD. > However, for some applications, e.g. LSA, vision applications, only the most > significant singular values are needed. For these applications, the full > decomposition is impractical, and for large matrices, computationally > infeasible. The sparse SVD avoids computing the unnecessary data, and more > importantly, has significantly lower computational complexity, which allows > it to scale to larger matrices. > Other linear algebra implementation have support for the sparse svd. Both > Matlab and Octave have the svds function. C has SVDLIBC. SVDPACK is also > available in Fortran and C. However, after extensive searching, I do not > believe there is any existing Java-based sparse SVD implementation. This > added functionality would be widely used for any pure Java application that > requires a sparse SVD, as the only current solution is to call out to a > library in another language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-328) Is "NoFeasibleSolutionException" Bug not Fixed Yet?
[
https://issues.apache.org/jira/browse/MATH-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved MATH-328.
--
Resolution: Incomplete
> Is "NoFeasibleSolutionException" Bug not Fixed Yet?
> ---
>
> Key: MATH-328
> URL: https://issues.apache.org/jira/browse/MATH-328
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP commons Math 2.0 jre 1.6
>Reporter: son ki sup
>Priority: Critical
> Attachments: error_data.txt
>
>
> I received a e-mail which introduces URL
> "https://svn.apache.org/repos/asf/commons/proper/math/trunk";.
> I downloaded Source Files in Package
> "org\apache\commons\math\optimization\linear"
> and compiled these files(make a new commons-math-2.?.jar = Simplex Patch
> Version)
> Lastly I tested a fixed Simplex module, But didn't get a feasible solution.
> Exception Message is as follow
> ---
> org.apache.commons.math.optimization.linear.NoFeasibleSolutionException: no
> feasible solution
> at
> org.apache.commons.math.optimization.linear.SimplexSolver.solvePhase1(SimplexSolver.java:166)
> at
> org.apache.commons.math.optimization.linear.SimplexSolver.doOptimize(SimplexSolver.java:176)
> at
> org.apache.commons.math.optimization.linear.AbstractLinearOptimizer.optimize(AbstractLinearOptimizer.java:106)
> at SimplexSolverTest.test111(SimplexSolverTest.java:711)
> at SimplexSolverTest.main(SimplexSolverTest.java:730
> ---
> Test Data is as follow
> ---
> double[] ob =
> {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1000,0,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,0};
> double[] c1 =
> {115239312,65417490,111006072,63657738,26800758,120283110,137807244,90077436,25759098,20452338,40821822,136261944,54779832,42682500,138210804,27299808,144635238,105106248,46103364,142549164,94178844,129443166,127867176,152840844,104050710,122083578,25506900,110386026,79515846,149110056,98889318,87030882,128243016,112193730,109948500,134574300,72316818,174011850,139884606,170461962,178817040,45444960,119593602,82012374,155913894,19837854,135737676,77510844,168166152,63235476,-1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> double[] c2 =
> {115239312,65417490,111006072,63657738,26800758,120283110,137807244,90077436,25759098,20452338,40821822,136261944,54779832,42682500,138210804,27299808,144635238,105106248,46103364,142549164,94178844,129443166,127867176,152840844,104050710,122083578,25506900,110386026,79515846,149110056,98889318,87030882,128243016,112193730,109948500,134574300,72316818,174011850,139884606,170461962,178817040,45444960,119593602,82012374,155913894,19837854,135737676,77510844,168166152,63235476,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> double[] c3 =
> {8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,11.1,14.4,7.5,4.5,3.6,9.3,12.6,5.4,1.2,6.6,8.1,9.6,8.1,8.1,13.8,0.6,14.1,6.6,15,10.2,7.2,6,1.2,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> double[] c4 =
> {8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,8.4,11.1,14.4,7.5,4.5,3.6,9.3,12.6,5.4,1.2,6.6,8.1,9.6,8.1,8.1,13.8,0.6,14.1,6.6,15,10.2,7.2,6,1.2,0,0,0,-1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> double[] c5 =
> {-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-48.9,-45.6,-52.5,-55.5,-56.4,-50.7,-47.4,-54.6,-58.8,-53.4,-51.9,-50.4,-51.9,-51.9,-46.2,-59.4,-45.9,-53.4,-45,-49.8,-52.8,-54,-58.8,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> double[] c6 =
> {-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-51.6,-48.9,-45.6,-52.5,-55.5,-56.4,-50.7,-47.4,-54.6,-58.8,-53.4,-51.9,-50.4,-51.9,-51.9,-46.2,-59.4,-45.9,-53.4,-45,-49.8,-52.8,-54,-58.8,0,0,0,0,0,-1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> double[] c7 =
> {-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6,-6
[jira] Updated: (MATH-327) Maximal number of iterations (540) exceeded
[ https://issues.apache.org/jira/browse/MATH-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-327: - Fix Version/s: 2.2 > Maximal number of iterations (540) exceeded > > > Key: MATH-327 > URL: https://issues.apache.org/jira/browse/MATH-327 > Project: Commons Math > Issue Type: Bug > Environment: Windows 7 (32-bit) JDK 1.6_16 >Reporter: Mansoor Ahmed Khan >Priority: Critical > Fix For: 2.2 > > > I have a matrix of size 49x19 and when I apply SVD on this matrix it raises > the following exception. The problem which I am facing is that SVD works for > some matrix and doesn't work for others. I have no clue what is the possible > reason. > Exception:: > CorrespondenceAnalysis: > org.apache.commons.math.MaxIterationsExceededException: Maximal number of > iterations (540) exceeded > [org.apache.commons.math.linear.EigenDecompositionImpl.processGeneralBlock(EigenDecompositionImpl.java:881), > > org.apache.commons.math.linear.EigenDecompositionImpl.findEigenvalues(EigenDecompositionImpl.java:651), > > org.apache.commons.math.linear.EigenDecompositionImpl.decompose(EigenDecompositionImpl.java:243), > > org.apache.commons.math.linear.EigenDecompositionImpl.(EigenDecompositionImpl.java:202), > > org.apache.commons.math.linear.SingularValueDecompositionImpl.(SingularValueDecompositionImpl.java:114), > RealMatrix m = [[1., 1., 1., 1., 1., > 1., 0.99107143, 1., 1., 1., 1., > 0.94450431, 1., 1., 0.99107143, 0.95238096, 1., > 1., 0.96428573],[1., 1., 1., 1., > 1., 1., 0.99107143, 1., 1., 1., > 1., 0.94450431, 1., 1., 0.99107143, 0.95238096, > 1., 1., 0.96428573],[1., 1., 1., > 1., 1., 1., 0.99107143, 1., 1., > 1., 1., 0.94450431, 1., 1., 0.99107143, > 0.95238096, 1., 1., 0.96428573],[1., 1., > 1., 1., 1., 1., 0.99107143, 1., > 1., 1., 1., 0.94450431, 1., 1., > 0.99107143, 0.95238096, 1., 1., 0.96428573],[1., > 1., 0.9499, 0.9581, 1., 1., 0.99107143, > 0.9458, 1., 0.9500, 0.9833, 0.92106681, 0.97368419, > 1., 0.95357142, 0.95238096, 1., 0.9334, > 0.96428573],[1., 1., 0.9499, 0.9581, 1., > 1., 0.99107143, 0.9458, 1., 0.9500, 0.9833, > 0.92106681, 0.97368419, 1., 0.95357142, 0.95238096, 1., > 0.9334, 0.96428573],[1., 1., 1., 1., > 1., 1., 0.99107143, 1., 1., 1., > 1., 0.94450431, 1., 1., 0.99107143, 0.95238096, > 1., 1., 0.96428573],[1., 1., 1., > 1., 1., 1., 0.99107143, 1., 1., > 1., 1., 0.94450431, 1., 1., 0.99107143, > 0.95238096, 1., 1., 0.96428573],[1., 1., > 1., 1., 1., 1., 0.99107143, 1., > 1., 1., 1., 0.94450431, 1., 1., > 0.99107143, 0.95238096, 1., 1., 0.96428573],[1., > 1., 0.9499, 0.9581, 1., 1., 0.99107143, > 0.9458, 1., 0.9500, 0.9833, 0.92106681, 0.97368419, > 1., 0.95357142, 0.95238096, 1., 0.9334, > 0.96428573],[1., 1., 1., 1., 1., > 1., 0.99107143, 1., 1., 1., 1., > 0.94450431, 1., 1., 0.99107143, 0.95238096, 1., > 1., 0.96428573],[1., 1., 1., 1., > 1., 1., 0.99107143, 1., 1., 1., > 1., 0.94450431, 1., 1., 0.99107143, 0.95238096, > 1., 1., 0.96428573],[1., 1., 0.9499, > 0.9581, 1., 1., 0.99107143, 0.9458, 1., > 0.9500, 0.9833, 0.92106681, 0.97368419, 1., 0.95357142, > 0.95238096, 1., 0.9334, 0.96428573],[1., 1., > 1., 1., 1., 1., 0.99107143, 1., > 1., 1., 1., 0.94450431, 1., 1., > 0.99107143, 0.95238096, 1., 1., 0.96428573],[1., > 1., 1., 1., 1., 1., 0.9910714
[jira] Updated: (LANG-606) EqualsBuilder causes StackOverflowException
[
https://issues.apache.org/jira/browse/LANG-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Sauder updated LANG-606:
---
Attachment: EqualsBuilderCyclicalObjectReferences.patch
Attached patch should solve the issue.
I've used the same attempt used in HashCodeBuilder solving the cyclical
reference issue.
Only difference is that a registry with objects pairs is used. When checking if
two objects have already be compared resp. registered those two objects need to
be swapped as the cyclical reference takes place when "the other object" is the
"this object".
> EqualsBuilder causes StackOverflowException
> ---
>
> Key: LANG-606
> URL: https://issues.apache.org/jira/browse/LANG-606
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 2.5
>Reporter: Oliver Sauder
>Priority: Minor
> Attachments: EqualsBuilderCyclicalObjectReferences.patch
>
>
> EqualsBuilder causes StackOverflowException when comparing objects with
> cyclical object references.
> e,g.
> static class TestObjectReference {
> @SuppressWarnings("unused")
> private TestObjectReference reference;
> @SuppressWarnings("unused")
> private TestObject one;
>
> public TestObjectReference(int one) {
> this.one = new TestObject(one);
> }
>
> public void setObjectReference(
> TestObjectReference reference) {
> this.reference = reference;
> }
> @Override
> public boolean equals(Object obj) {
> return EqualsBuilder.reflectionEquals(this, obj);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-606) EqualsBuilder causes StackOverflowException
EqualsBuilder causes StackOverflowException
---
Key: LANG-606
URL: https://issues.apache.org/jira/browse/LANG-606
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Affects Versions: 2.5
Reporter: Oliver Sauder
Priority: Minor
EqualsBuilder causes StackOverflowException when comparing objects with
cyclical object references.
e,g.
static class TestObjectReference {
@SuppressWarnings("unused")
private TestObjectReference reference;
@SuppressWarnings("unused")
private TestObject one;
public TestObjectReference(int one) {
this.one = new TestObject(one);
}
public void setObjectReference(
TestObjectReference reference) {
this.reference = reference;
}
@Override
public boolean equals(Object obj) {
return EqualsBuilder.reflectionEquals(this, obj);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
