[jira] Created: (LANG-606) EqualsBuilder causes StackOverflowException

2010-03-13 Thread Oliver Sauder (JIRA)
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.



[jira] Updated: (LANG-606) EqualsBuilder causes StackOverflowException

2010-03-13 Thread Oliver Sauder (JIRA)

 [ 
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] Updated: (MATH-327) Maximal number of iterations (540) exceeded

2010-03-13 Thread Phil Steitz (JIRA)

 [ 
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.init(EigenDecompositionImpl.java:202),
  
 org.apache.commons.math.linear.SingularValueDecompositionImpl.init(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.99107143, 
 1., 1., 1., 1., 0.94450431, 

[jira] Resolved: (MATH-328) Is NoFeasibleSolutionException Bug not Fixed Yet?

2010-03-13 Thread Phil Steitz (JIRA)

 [ 
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  = 
 

[jira] Updated: (MATH-321) Support for Sparse (Thin) SVD

2010-03-13 Thread Phil Steitz (JIRA)

 [ 
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] Updated: (MATH-284) Avoid ArrayStoreException

2010-03-13 Thread Phil Steitz (JIRA)

 [ 
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? extends FieldElement 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-351) SimplexSolver fails to solve feasible problem instance

2010-03-13 Thread Phil Steitz (JIRA)

 [ 
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-345) A new secant solver that does not enforce bracketing

2010-03-13 Thread Phil Steitz (JIRA)

 [ 
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] Closed: (MATH-331) t-distribution, Weibull distribution, and Cauchy distribution: add density-function (through HasDensityDouble-interface)

2010-03-13 Thread Phil Steitz (JIRA)

 [ 
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 HasDensityDouble-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] Created: (LANG-607) StringUtils.containsAny methods incorrectly matches Unicode 2.0+ supplementary characters.

2010-03-13 Thread Gary Gregory (JIRA)
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] Updated: (LANG-607) StringUtils.containsAny methods incorrectly matches Unicode 2.0+ supplementary characters.

2010-03-13 Thread Gary Gregory (JIRA)

 [ 
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] Resolved: (MATH-337) Equals methods rely on catching ClassCastException rather than using instanceof check

2010-03-13 Thread Sebb (JIRA)

 [ 
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=922713view=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] Reopened: (MATH-336) Unnecessary null checks in equals methods

2010-03-13 Thread Sebb (JIRA)

 [ 
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-335) Fraction.hashCode() inconsistent with Fraction.equals()

2010-03-13 Thread Sebb (JIRA)

 [ 
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=922715view=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] Updated: (MATH-257) FastFourierTransformer.MultiDimensionalComplexMatrix.get() not consistent with FastFourierTransformer.MultiDimensionalComplexMatrix.set()

2010-03-13 Thread Sebb (JIRA)

 [ 
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] Created: (DBCP-326) Rollback an uncommited transaction on return

2010-03-13 Thread Adrian Tarau (JIRA)
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] Created: (DAEMON-137) Allow to configure JNI message logging

2010-03-13 Thread Mladen Turk (JIRA)
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: (DAEMON-139) Stdout/Stderr redirection does not work properly

2010-03-13 Thread Mladen Turk (JIRA)
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.