[jira] [Commented] (MATH-1057) BOBYQAOptimizerTest has two failing tests
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876442#comment-13876442
]
Sean Owen commented on MATH-1057:
-
Yeah I see the point but the artifact is now called 'math3' as it was not
backwards compatible with 2.x and was sometimes necessary to deploy together.
So it really is math3 3.2.
> BOBYQAOptimizerTest has two failing tests
> -
>
> Key: MATH-1057
> URL: https://issues.apache.org/jira/browse/MATH-1057
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
> 3.1.1
>Reporter: Sean Owen
>Priority: Minor
> Fix For: 3.3
>
> Attachments: MATH-1057.patch
>
>
> I see two test failures, in both the copies of BOBYQAOptimizerTest:
> {code}
> Failed tests:
> BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0>
> but was:<1.047765607609108E-8>
> BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0>
> but was:<1.047765607609108E-8>
> Tests in error:
> BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
> TooManyEvaluations
> BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
> TooManyEvaluations
> {code}
> (This predated the patches I've worked on so I don't think it's me!)
> I tried on Mac OS X and Linux and see the same, so don't think it is an
> environment issue. I'll see if a little digging can uncover the issue from a
> recent commit.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (MATH-1057) BOBYQAOptimizerTest has two failing tests
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876268#comment-13876268
]
Sean Owen commented on MATH-1057:
-
Yes, but you show you are working with 3.2. Look at what you downloaded.
> BOBYQAOptimizerTest has two failing tests
> -
>
> Key: MATH-1057
> URL: https://issues.apache.org/jira/browse/MATH-1057
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
> 3.1.1
>Reporter: Sean Owen
>Priority: Minor
> Fix For: 3.3
>
> Attachments: MATH-1057.patch
>
>
> I see two test failures, in both the copies of BOBYQAOptimizerTest:
> {code}
> Failed tests:
> BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0>
> but was:<1.047765607609108E-8>
> BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0>
> but was:<1.047765607609108E-8>
> Tests in error:
> BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
> TooManyEvaluations
> BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
> TooManyEvaluations
> {code}
> (This predated the patches I've worked on so I don't think it's me!)
> I tried on Mac OS X and Linux and see the same, so don't think it is an
> environment issue. I'll see if a little digging can uncover the issue from a
> recent commit.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (MATH-1057) BOBYQAOptimizerTest has two failing tests
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876261#comment-13876261
]
Sean Owen commented on MATH-1057:
-
The error is indeed reported against 3.2 and fixed for 3.3. Are you saying you
see this in HEAD?
> BOBYQAOptimizerTest has two failing tests
> -
>
> Key: MATH-1057
> URL: https://issues.apache.org/jira/browse/MATH-1057
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
> 3.1.1
>Reporter: Sean Owen
>Priority: Minor
> Fix For: 3.3
>
> Attachments: MATH-1057.patch
>
>
> I see two test failures, in both the copies of BOBYQAOptimizerTest:
> {code}
> Failed tests:
> BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0>
> but was:<1.047765607609108E-8>
> BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0>
> but was:<1.047765607609108E-8>
> Tests in error:
> BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
> TooManyEvaluations
> BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
> TooManyEvaluations
> {code}
> (This predated the patches I've worked on so I don't think it's me!)
> I tried on Mac OS X and Linux and see the same, so don't think it is an
> environment issue. I'll see if a little digging can uncover the issue from a
> recent commit.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (MATH-1053) QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices
[ https://issues.apache.org/jira/browse/MATH-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813240#comment-13813240 ] Sean Owen commented on MATH-1053: - As a more conservative change for now, it could merely reject a tall matrix with an exception, and document this. That would probably be nicer than the current DimesnionMismatchException. > QRDecomposition.getSolver() should be able to find pseudo-inverse of > non-square matrices > > > Key: MATH-1053 > URL: https://issues.apache.org/jira/browse/MATH-1053 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Attachments: MATH-1053.patch > > > I don't have a complete solution to this, so don't commit this as-is, but > posting in case someone can get it over the line. > If you process a tall m x n matrix (non-square, m>n) with QRDecomposition and > then call getSolver().getInverse(), you will get DimensionMismatchException. > There's not a good reason the QR decomposition can't compute the > least-squares solution here. > The issue is that it tries to invert A by solving AX = I. The dimension of I > has to match the row dimension of A, or m. However it's using the length of > the diagonal of R, which is min(m,n), which is n when m>n. > That patch is simple and is part of the attached patch. It also includes a > test case for a tall matrix. > However it doesn't work for a fat matrix (m too. It returns an n x m value but the rows for i >= m are 0 and are not > computed. I'm not sure enough about the shape of the computation to be able > to fix it, but it is where it's solving the triangular system Rx = y. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1058) Beta, LogNormalDistribution, WeibullDistribution give slightly wrong answer for extremely small args due to log/exp inaccuracy
[ https://issues.apache.org/jira/browse/MATH-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1058: Attachment: MATH-1058.patch > Beta, LogNormalDistribution, WeibullDistribution give slightly wrong answer > for extremely small args due to log/exp inaccuracy > -- > > Key: MATH-1058 > URL: https://issues.apache.org/jira/browse/MATH-1058 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: exp, expm1, log, log1p > Attachments: MATH-1058.patch > > > Background for those who aren't familiar: math libs like Math and FastMath > have two mysterious methods, log1p and expm1. log1p(x) = log(1+x) and > expm1(x) = exp(x)-1 mathetmatically, but can return a correct answer even > when x was small, where floating-point error due to the addition/subtraction > introduces a relatively large error. > There are three instances in the code that can employ these specialized > methods and gain a measurable improvement in accuracy. See patch and tests > for an example -- try the tests without the code change to see the error. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1058) Beta, LogNormalDistribution, WeibullDistribution give slightly wrong answer for extremely small args due to log/exp inaccuracy
Sean Owen created MATH-1058: --- Summary: Beta, LogNormalDistribution, WeibullDistribution give slightly wrong answer for extremely small args due to log/exp inaccuracy Key: MATH-1058 URL: https://issues.apache.org/jira/browse/MATH-1058 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Background for those who aren't familiar: math libs like Math and FastMath have two mysterious methods, log1p and expm1. log1p(x) = log(1+x) and expm1(x) = exp(x)-1 mathetmatically, but can return a correct answer even when x was small, where floating-point error due to the addition/subtraction introduces a relatively large error. There are three instances in the code that can employ these specialized methods and gain a measurable improvement in accuracy. See patch and tests for an example -- try the tests without the code change to see the error. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1057) BOBYQAOptimizerTest has two failing tests
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812502#comment-13812502
]
Sean Owen commented on MATH-1057:
-
For the record, my java versions:
OS X:
{code}
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
{code}
Linux:
{code}
java version "1.7.0_45"
OpenJDK Runtime Environment (amzn-2.4.3.2.32.amzn1-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
{code}
> BOBYQAOptimizerTest has two failing tests
> -
>
> Key: MATH-1057
> URL: https://issues.apache.org/jira/browse/MATH-1057
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
> 3.1.1
>Reporter: Sean Owen
>Priority: Minor
> Attachments: MATH-1057.patch
>
>
> I see two test failures, in both the copies of BOBYQAOptimizerTest:
> {code}
> Failed tests:
> BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0>
> but was:<1.047765607609108E-8>
> BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0>
> but was:<1.047765607609108E-8>
> Tests in error:
> BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
> TooManyEvaluations
> BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
> TooManyEvaluations
> {code}
> (This predated the patches I've worked on so I don't think it's me!)
> I tried on Mac OS X and Linux and see the same, so don't think it is an
> environment issue. I'll see if a little digging can uncover the issue from a
> recent commit.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1057) BOBYQAOptimizerTest has two failing tests
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812492#comment-13812492
]
Sean Owen commented on MATH-1057:
-
Oh I see -- see above, Java 7 on OS X 10.9 and on Linux.
> BOBYQAOptimizerTest has two failing tests
> -
>
> Key: MATH-1057
> URL: https://issues.apache.org/jira/browse/MATH-1057
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
> 3.1.1
>Reporter: Sean Owen
>Priority: Minor
> Attachments: MATH-1057.patch
>
>
> I see two test failures, in both the copies of BOBYQAOptimizerTest:
> {code}
> Failed tests:
> BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0>
> but was:<1.047765607609108E-8>
> BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0>
> but was:<1.047765607609108E-8>
> Tests in error:
> BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
> TooManyEvaluations
> BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
> TooManyEvaluations
> {code}
> (This predated the patches I've worked on so I don't think it's me!)
> I tried on Mac OS X and Linux and see the same, so don't think it is an
> environment issue. I'll see if a little digging can uncover the issue from a
> recent commit.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1057) BOBYQAOptimizerTest has two failing tests
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen updated MATH-1057:
Attachment: MATH-1057.patch
Here's a patch implementing your change. Yes it fixes the failure for
testDiffPow for me too and sounds like a good change. Not sure about the other.
Maybe the tolerance needs to be loosened?
> BOBYQAOptimizerTest has two failing tests
> -
>
> Key: MATH-1057
> URL: https://issues.apache.org/jira/browse/MATH-1057
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
> 3.1.1
>Reporter: Sean Owen
>Priority: Minor
> Attachments: MATH-1057.patch
>
>
> I see two test failures, in both the copies of BOBYQAOptimizerTest:
> {code}
> Failed tests:
> BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0>
> but was:<1.047765607609108E-8>
> BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0>
> but was:<1.047765607609108E-8>
> Tests in error:
> BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
> TooManyEvaluations
> BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
> TooManyEvaluations
> {code}
> (This predated the patches I've worked on so I don't think it's me!)
> I tried on Mac OS X and Linux and see the same, so don't think it is an
> environment issue. I'll see if a little digging can uncover the issue from a
> recent commit.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1057) BOBYQAOptimizerTest has two failing tests
[
https://issues.apache.org/jira/browse/MATH-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812453#comment-13812453
]
Sean Owen commented on MATH-1057:
-
Hmm, I show that this fails even from the first time the test was added in
r1420684. Anyone else seeing the same? if not, what platform I wonder?
> BOBYQAOptimizerTest has two failing tests
> -
>
> Key: MATH-1057
> URL: https://issues.apache.org/jira/browse/MATH-1057
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
> 3.1.1
>Reporter: Sean Owen
>Priority: Minor
>
> I see two test failures, in both the copies of BOBYQAOptimizerTest:
> {code}
> Failed tests:
> BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0>
> but was:<1.047765607609108E-8>
> BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0>
> but was:<1.047765607609108E-8>
> Tests in error:
> BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
> TooManyEvaluations
> BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
> TooManyEvaluations
> {code}
> (This predated the patches I've worked on so I don't think it's me!)
> I tried on Mac OS X and Linux and see the same, so don't think it is an
> environment issue. I'll see if a little digging can uncover the issue from a
> recent commit.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (MATH-1057) BOBYQAOptimizerTest has two failing tests
Sean Owen created MATH-1057:
---
Summary: BOBYQAOptimizerTest has two failing tests
Key: MATH-1057
URL: https://issues.apache.org/jira/browse/MATH-1057
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.2
Environment: Mac OS X 10.9 and also Linux 3.4 kernel; Java 7; Maven
3.1.1
Reporter: Sean Owen
Priority: Minor
I see two test failures, in both the copies of BOBYQAOptimizerTest:
{code}
Failed tests:
BOBYQAOptimizerTest.testAckley:209->doTest:282->doTest:338 expected:<0.0> but
was:<1.047765607609108E-8>
BOBYQAOptimizerTest.testAckley:208->doTest:281->doTest:336 expected:<0.0> but
was:<1.047765607609108E-8>
Tests in error:
BOBYQAOptimizerTest.testDiffPow:187->doTest:282->doTest:322 »
TooManyEvaluations
BOBYQAOptimizerTest.testDiffPow:186->doTest:281->doTest:326 »
TooManyEvaluations
{code}
(This predated the patches I've worked on so I don't think it's me!)
I tried on Mac OS X and Linux and see the same, so don't think it is an
environment issue. I'll see if a little digging can uncover the issue from a
recent commit.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1056) Small error in PoissonDistribution.nextPoisson() algorithm
[
https://issues.apache.org/jira/browse/MATH-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen updated MATH-1056:
Description:
Here's a tiny bug I noticed via static inspection, since it flagged the integer
division. PoissonDistribution.java:325 says:
{code:java}
final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / 8 *
lambda);
{code}
The "1 / 8 * lambda" is evidently incorrect, since this will always evaluate to
0. I rechecked the original algorithm
(http://luc.devroye.org/devroye-poisson.pdf) and it should instead be:
{code:java}
final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / (8 *
lambda));
{code}
(lambda is a double so there is no int division issue.) This matches a later
expression.
I'm not sure how to evaluate the effect of the bug. Better to be correct of
course; it may never have made much practical difference.
was:
Here's a tiny bug I noticed via static inspection, since it flagged the integer
division. PoissonDistribution.java:325 says:
{code:java}
final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / 8 *
lambda);
{code}
The "1 / 8 * lambda)" is evidently incorrect, since this will always evaluate
to 0. I rechecked the original algorithm
(http://luc.devroye.org/devroye-poisson.pdf) and it should instead be:
{code:java}
final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / (8 *
lambda));
{code}
(lambda is a double so there is no int division issue.) This matches a later
expression.
I'm not sure how to evaluate the effect of the bug. Better to be correct of
course; it may never have made much practical difference.
> Small error in PoissonDistribution.nextPoisson() algorithm
> --
>
> Key: MATH-1056
> URL: https://issues.apache.org/jira/browse/MATH-1056
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Sean Owen
>Priority: Minor
> Attachments: MATH-1056.patch
>
>
> Here's a tiny bug I noticed via static inspection, since it flagged the
> integer division. PoissonDistribution.java:325 says:
> {code:java}
> final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / 8 *
> lambda);
> {code}
> The "1 / 8 * lambda" is evidently incorrect, since this will always evaluate
> to 0. I rechecked the original algorithm
> (http://luc.devroye.org/devroye-poisson.pdf) and it should instead be:
> {code:java}
> final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / (8 *
> lambda));
> {code}
> (lambda is a double so there is no int division issue.) This matches a later
> expression.
> I'm not sure how to evaluate the effect of the bug. Better to be correct of
> course; it may never have made much practical difference.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (MATH-1056) Small error in PoissonDistribution.nextPoisson() algorithm
Sean Owen created MATH-1056:
---
Summary: Small error in PoissonDistribution.nextPoisson() algorithm
Key: MATH-1056
URL: https://issues.apache.org/jira/browse/MATH-1056
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.2
Reporter: Sean Owen
Priority: Minor
Attachments: MATH-1056.patch
Here's a tiny bug I noticed via static inspection, since it flagged the integer
division. PoissonDistribution.java:325 says:
{code:java}
final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / 8 *
lambda);
{code}
The "1 / 8 * lambda)" is evidently incorrect, since this will always evaluate
to 0. I rechecked the original algorithm
(http://luc.devroye.org/devroye-poisson.pdf) and it should instead be:
{code:java}
final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / (8 *
lambda));
{code}
(lambda is a double so there is no int division issue.) This matches a later
expression.
I'm not sure how to evaluate the effect of the bug. Better to be correct of
course; it may never have made much practical difference.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1056) Small error in PoissonDistribution.nextPoisson() algorithm
[
https://issues.apache.org/jira/browse/MATH-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen updated MATH-1056:
Attachment: MATH-1056.patch
> Small error in PoissonDistribution.nextPoisson() algorithm
> --
>
> Key: MATH-1056
> URL: https://issues.apache.org/jira/browse/MATH-1056
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Sean Owen
>Priority: Minor
> Attachments: MATH-1056.patch
>
>
> Here's a tiny bug I noticed via static inspection, since it flagged the
> integer division. PoissonDistribution.java:325 says:
> {code:java}
> final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / 8 *
> lambda);
> {code}
> The "1 / 8 * lambda)" is evidently incorrect, since this will always evaluate
> to 0. I rechecked the original algorithm
> (http://luc.devroye.org/devroye-poisson.pdf) and it should instead be:
> {code:java}
> final double a1 = FastMath.sqrt(FastMath.PI * twolpd) * FastMath.exp(1 / (8 *
> lambda));
> {code}
> (lambda is a double so there is no int division issue.) This matches a later
> expression.
> I'm not sure how to evaluate the effect of the bug. Better to be correct of
> course; it may never have made much practical difference.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1055) Fix some javadoc errors; add @Deprecated annotations to @deprecated methods
[ https://issues.apache.org/jira/browse/MATH-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812327#comment-13812327 ] Sean Owen commented on MATH-1055: - Actually I changed a @link to @code in this case. The target was a method in a test class that is not visible to the non-test code. It is helpful as javadoc, but can't be @link. And if it's just written for humans, "." is the more natural notation. Yes '#' is correct in general -- I actually didn't think you could use '.' if you wanted to. > Fix some javadoc errors; add @Deprecated annotations to @deprecated methods > --- > > Key: MATH-1055 > URL: https://issues.apache.org/jira/browse/MATH-1055 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Trivial > Attachments: MATH-1055.patch > > > And here is another patch touching up some javadoc problems -- missing or > outdated references, and along the way, adding @Deprecated annotations to > methods javadoc'ed as @deprecated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1054) Standardize "x = x op y" to "x op= y"
[ https://issues.apache.org/jira/browse/MATH-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1054: Attachment: (was: MATH-1054.patch) > Standardize "x = x op y" to "x op= y" > - > > Key: MATH-1054 > URL: https://issues.apache.org/jira/browse/MATH-1054 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Attachments: MATH-1054.patch > > > Here's one of a series of proposed small simplification/optimizations across > the code base. This can be rejected. > The change is to standardize expressions like: > x[i] = x[i] + b; > to: > x[i] += b; > ... for any operation that has an 'op=' version. The resulting byte code is > very marginally faster since the target is evaluated once; this might matter > in a tight loop manipulating a 2D array cell. > There's a minor argument that it is simpler code. Since both styles appear in > the code now, this would also represent a tiny standardization. > The counter-argument is that "x += foo" might risk being misread more readily > as "x = foo" -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1054) Standardize "x = x op y" to "x op= y"
[ https://issues.apache.org/jira/browse/MATH-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1054: Attachment: MATH-1054.patch This patch should remove all those parentheses. > Standardize "x = x op y" to "x op= y" > - > > Key: MATH-1054 > URL: https://issues.apache.org/jira/browse/MATH-1054 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Attachments: MATH-1054.patch > > > Here's one of a series of proposed small simplification/optimizations across > the code base. This can be rejected. > The change is to standardize expressions like: > x[i] = x[i] + b; > to: > x[i] += b; > ... for any operation that has an 'op=' version. The resulting byte code is > very marginally faster since the target is evaluated once; this might matter > in a tight loop manipulating a 2D array cell. > There's a minor argument that it is simpler code. Since both styles appear in > the code now, this would also represent a tiny standardization. > The counter-argument is that "x += foo" might risk being misread more readily > as "x = foo" -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1055) Fix some javadoc errors; add @Deprecated annotations to @deprecated methods
[ https://issues.apache.org/jira/browse/MATH-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1055: Attachment: MATH-1055.patch > Fix some javadoc errors; add @Deprecated annotations to @deprecated methods > --- > > Key: MATH-1055 > URL: https://issues.apache.org/jira/browse/MATH-1055 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Trivial > Attachments: MATH-1055.patch > > > And here is another patch touching up some javadoc problems -- missing or > outdated references, and along the way, adding @Deprecated annotations to > methods javadoc'ed as @deprecated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1055) Fix some javadoc errors; add @Deprecated annotations to @deprecated methods
Sean Owen created MATH-1055: --- Summary: Fix some javadoc errors; add @Deprecated annotations to @deprecated methods Key: MATH-1055 URL: https://issues.apache.org/jira/browse/MATH-1055 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Trivial Attachments: MATH-1055.patch And here is another patch touching up some javadoc problems -- missing or outdated references, and along the way, adding @Deprecated annotations to methods javadoc'ed as @deprecated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1054) Standardize "x = x op y" to "x op= y"
[ https://issues.apache.org/jira/browse/MATH-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1054: Attachment: MATH-1054.patch > Standardize "x = x op y" to "x op= y" > - > > Key: MATH-1054 > URL: https://issues.apache.org/jira/browse/MATH-1054 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Attachments: MATH-1054.patch > > > Here's one of a series of proposed small simplification/optimizations across > the code base. This can be rejected. > The change is to standardize expressions like: > x[i] = x[i] + b; > to: > x[i] += b; > ... for any operation that has an 'op=' version. The resulting byte code is > very marginally faster since the target is evaluated once; this might matter > in a tight loop manipulating a 2D array cell. > There's a minor argument that it is simpler code. Since both styles appear in > the code now, this would also represent a tiny standardization. > The counter-argument is that "x += foo" might risk being misread more readily > as "x = foo" -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1054) Standardize "x = x op y" to "x op= y"
Sean Owen created MATH-1054: --- Summary: Standardize "x = x op y" to "x op= y" Key: MATH-1054 URL: https://issues.apache.org/jira/browse/MATH-1054 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Here's one of a series of proposed small simplification/optimizations across the code base. This can be rejected. The change is to standardize expressions like: x[i] = x[i] + b; to: x[i] += b; ... for any operation that has an 'op=' version. The resulting byte code is very marginally faster since the target is evaluated once; this might matter in a tight loop manipulating a 2D array cell. There's a minor argument that it is simpler code. Since both styles appear in the code now, this would also represent a tiny standardization. The counter-argument is that "x += foo" might risk being misread more readily as "x = foo" -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1053) QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices
[ https://issues.apache.org/jira/browse/MATH-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1053: Attachment: MATH-1053.patch > QRDecomposition.getSolver() should be able to find pseudo-inverse of > non-square matrices > > > Key: MATH-1053 > URL: https://issues.apache.org/jira/browse/MATH-1053 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Attachments: MATH-1053.patch > > > I don't have a complete solution to this, so don't commit this as-is, but > posting in case someone can get it over the line. > If you process a tall m x n matrix (non-square, m>n) with QRDecomposition and > then call getSolver().getInverse(), you will get DimensionMismatchException. > There's not a good reason the QR decomposition can't compute the > least-squares solution here. > The issue is that it tries to invert A by solving AX = I. The dimension of I > has to match the row dimension of A, or m. However it's using the length of > the diagonal of R, which is min(m,n), which is n when m>n. > That patch is simple and is part of the attached patch. It also includes a > test case for a tall matrix. > However it doesn't work for a fat matrix (m too. It returns an n x m value but the rows for i >= m are 0 and are not > computed. I'm not sure enough about the shape of the computation to be able > to fix it, but it is where it's solving the triangular system Rx = y. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1053) QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices
Sean Owen created MATH-1053: --- Summary: QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices Key: MATH-1053 URL: https://issues.apache.org/jira/browse/MATH-1053 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Attachments: MATH-1053.patch I don't have a complete solution to this, so don't commit this as-is, but posting in case someone can get it over the line. If you process a tall m x n matrix (non-square, m>n) with QRDecomposition and then call getSolver().getInverse(), you will get DimensionMismatchException. There's not a good reason the QR decomposition can't compute the least-squares solution here. The issue is that it tries to invert A by solving AX = I. The dimension of I has to match the row dimension of A, or m. However it's using the length of the diagonal of R, which is min(m,n), which is n when m>n. That patch is simple and is part of the attached patch. It also includes a test case for a tall matrix. However it doesn't work for a fat matrix (m= m are 0 and are not computed. I'm not sure enough about the shape of the computation to be able to fix it, but it is where it's solving the triangular system Rx = y. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[
https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810261#comment-13810261
]
Sean Owen commented on MATH-1045:
-
This is a separate issue, but so minor not sure if it merits another JIRA.
While looking at this code I noticed this loop at EigenDecomposition:945 that
does nothing:
// Vectors of isolated roots
for (int i = 0; i < n; i++) {
if (i < 0 | i > n - 1) {
for (int j = i; j < n; j++) {
matrixP[i][j] = matrixT[i][j];
}
}
}
The 'if' can never be true. (Not to mention non-short-circuit boolean op there.)
> EigenDecomposition.Solver should consider tiny values 0 for purposes of
> determining singularity
> ---
>
> Key: MATH-1045
> URL: https://issues.apache.org/jira/browse/MATH-1045
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Sean Owen
>Priority: Minor
> Labels: eigenvalue, singular
> Fix For: 3.3
>
> Attachments: MATH-1045.patch, MATH-1045.patch, MATH-1045_2.patch
>
>
> EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0
> for exact equality. Elsewhere in the class and in the code, of course, very
> small values are considered 0. This causes the solver to consider some
> singular matrices as non-singular.
> The patch here includes a test as well showing the behavior -- the matrix is
> clearly singular but isn't considered as such since one eigenvalue are ~1e-14
> rather than exactly 0.
> (What I am not sure of is whether we should really be evaluating the *norm*
> of the imaginary eigenvalues rather than real/imag components separately. But
> the javadoc says the solver only supports real eigenvalues anyhow, so it's
> kind of moot since imag=0 for all eigenvalues.)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: MATH-1045_2.patch Ah right, I should have said that these show out-of-order eigenvalues but that's not what we need to check. We need one that puts a very small eigenvalue first. That's easy to generate as something like [ d 0 ] [ 1 1 ] for tiny d. Patch attached. > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Fix For: 3.3 > > Attachments: MATH-1045_2.patch, MATH-1045.patch, MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809009#comment-13809009 ] Sean Owen commented on MATH-1045: - Yes, this is a good point. It's safest to find the largest eigenvalue (by absolute value) with a loop I think. The final matrix in testUnsymmetric(), which is unsymmetric, shows this. The symmetric matrix in testSquareRootNonPositiveDefinite() also shows this -- the last eigenvalue is the most negative, but is the largest in absolute value. > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Fix For: 3.3 > > Attachments: MATH-1045.patch, MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804016#comment-13804016 ] Sean Owen commented on MATH-1045: - These are good points, as well as the comments from the thread on commons-dev -- Ted in particular notes that you can use the threshold in the decomposition itself to simply stop computing eigenvalues when they get small. Now, these more advanced changes are near the limit of my ability and I am not sure I feel confident making them. I propose these additional changes be considered in another issue: (maybe) moving a threshold parameter, maybe modifying the decomposition. The patch here does I think represent a small, distinct positive change, in that it employs a reasonable test for singularity after the fact. > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Attachments: MATH-1045.patch, MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: MATH-1045.patch On a little more research, it seems the thing to do is look at the ratio with the largest eigenvalue. Attached is a new patch where your new test and my (2) new tests all pass. Comments welcome from linear algebra experts but I think this is at least as principled as the existing code. We could also let the user specify the zero threshold as in the QRDecomposition class. > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Attachments: MATH-1045.patch, MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801910#comment-13801910 ] Sean Owen commented on MATH-1045: - That's a good point. If you make the example matrix non-singular, but then divide elements by 1e12, it will report it as singular. This seems wrong. On the other hand it seems a bit undesirable to return an 'inverse' in this case -- it's dominated by the inverse of that tiny eigenvalue, which is huge, and the result is pretty unreliable. I'm a bit out of my depth here but I wonder if it's more reasonable to examine the eigenvalues in sorted order and examine ratio of one to the next. When that ratio is below epsilon it makes more sense to declare it "0". I could also see this being a case of "caller beware". That's the more conservative thing here. > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Attachments: MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: (was: MATH-1045.patch) > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Attachments: MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: MATH-1045.patch > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Attachments: MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: MATH-1044.patch Now with LaTeX > Clarify and fix javadoc of DecompositionSolver.getInverse() and > implementations > --- > > Key: MATH-1044 > URL: https://issues.apache.org/jira/browse/MATH-1044 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: decomposition, inverse, singular, solver > Attachments: MATH-1044.patch > > > As suggested by Phil on the mailing list, I'm providing a patch to the > javadoc of DecompositionSolver.getInverse() to clarify what it does. It also > correctly moves the "@throws SingularMatrixException" to implementations that > do throw this exception; not all do. > Tests already cover most of the behavior asserted by the documentation. I > added one to show that the SVD does not reject singular matrices. There > should be a test for EigenDecomposition here too, but in the course of adding > it I found another apparent small bug in its behavior with singular matrices. > So I will provide that separately (it actually involves no doc changes, and > docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: (was: MATH-1044.patch) > Clarify and fix javadoc of DecompositionSolver.getInverse() and > implementations > --- > > Key: MATH-1044 > URL: https://issues.apache.org/jira/browse/MATH-1044 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: decomposition, inverse, singular, solver > Attachments: MATH-1044.patch > > > As suggested by Phil on the mailing list, I'm providing a patch to the > javadoc of DecompositionSolver.getInverse() to clarify what it does. It also > correctly moves the "@throws SingularMatrixException" to implementations that > do throw this exception; not all do. > Tests already cover most of the behavior asserted by the documentation. I > added one to show that the SVD does not reject singular matrices. There > should be a test for EigenDecomposition here too, but in the course of adding > it I found another apparent small bug in its behavior with singular matrices. > So I will provide that separately (it actually involves no doc changes, and > docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: (was: MATH-1045.patch) > Clarify and fix javadoc of DecompositionSolver.getInverse() and > implementations > --- > > Key: MATH-1044 > URL: https://issues.apache.org/jira/browse/MATH-1044 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: decomposition, inverse, singular, solver > Attachments: MATH-1044.patch > > > As suggested by Phil on the mailing list, I'm providing a patch to the > javadoc of DecompositionSolver.getInverse() to clarify what it does. It also > correctly moves the "@throws SingularMatrixException" to implementations that > do throw this exception; not all do. > Tests already cover most of the behavior asserted by the documentation. I > added one to show that the SVD does not reject singular matrices. There > should be a test for EigenDecomposition here too, but in the course of adding > it I found another apparent small bug in its behavior with singular matrices. > So I will provide that separately (it actually involves no doc changes, and > docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: MATH-1045.patch > Clarify and fix javadoc of DecompositionSolver.getInverse() and > implementations > --- > > Key: MATH-1044 > URL: https://issues.apache.org/jira/browse/MATH-1044 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: decomposition, inverse, singular, solver > Attachments: MATH-1044.patch > > > As suggested by Phil on the mailing list, I'm providing a patch to the > javadoc of DecompositionSolver.getInverse() to clarify what it does. It also > correctly moves the "@throws SingularMatrixException" to implementations that > do throw this exception; not all do. > Tests already cover most of the behavior asserted by the documentation. I > added one to show that the SVD does not reject singular matrices. There > should be a test for EigenDecomposition here too, but in the course of adding > it I found another apparent small bug in its behavior with singular matrices. > So I will provide that separately (it actually involves no doc changes, and > docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: MATH-1045.patch > EigenDecomposition.Solver should consider tiny values 0 for purposes of > determining singularity > --- > > Key: MATH-1045 > URL: https://issues.apache.org/jira/browse/MATH-1045 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: eigenvalue, singular > Attachments: MATH-1045.patch > > > EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 > for exact equality. Elsewhere in the class and in the code, of course, very > small values are considered 0. This causes the solver to consider some > singular matrices as non-singular. > The patch here includes a test as well showing the behavior -- the matrix is > clearly singular but isn't considered as such since one eigenvalue are ~1e-14 > rather than exactly 0. > (What I am not sure of is whether we should really be evaluating the *norm* > of the imaginary eigenvalues rather than real/imag components separately. But > the javadoc says the solver only supports real eigenvalues anyhow, so it's > kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
Sean Owen created MATH-1045: --- Summary: EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: MATH-1044.patch > Clarify and fix javadoc of DecompositionSolver.getInverse() and > implementations > --- > > Key: MATH-1044 > URL: https://issues.apache.org/jira/browse/MATH-1044 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: decomposition, inverse, singular, solver > Attachments: MATH-1044.patch > > > As suggested by Phil on the mailing list, I'm providing a patch to the > javadoc of DecompositionSolver.getInverse() to clarify what it does. It also > correctly moves the "@throws SingularMatrixException" to implementations that > do throw this exception; not all do. > Tests already cover most of the behavior asserted by the documentation. I > added one to show that the SVD does not reject singular matrices. There > should be a test for EigenDecomposition here too, but in the course of adding > it I found another apparent small bug in its behavior with singular matrices. > So I will provide that separately (it actually involves no doc changes, and > docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
Sean Owen created MATH-1044: --- Summary: Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations Key: MATH-1044 URL: https://issues.apache.org/jira/browse/MATH-1044 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor As suggested by Phil on the mailing list, I'm providing a patch to the javadoc of DecompositionSolver.getInverse() to clarify what it does. It also correctly moves the "@throws SingularMatrixException" to implementations that do throw this exception; not all do. Tests already cover most of the behavior asserted by the documentation. I added one to show that the SVD does not reject singular matrices. There should be a test for EigenDecomposition here too, but in the course of adding it I found another apparent small bug in its behavior with singular matrices. So I will provide that separately (it actually involves no doc changes, and docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041_Comparator.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_MathArrays.patch, > MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041_MathArrays.patch MATH-1041_Comparator.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_MathArrays.patch, > MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796667#comment-13796667 ] Sean Owen commented on MATH-1041: - I will prepare one more patch with the naming changes and javadoc. From there you should feel free to edit further before you commit. Separately, on of() vs create(), I would also note that the Pair in Apache Crunch, and 4 Pair classes in the JDK, have an "of()" method. It does seem more natural to me as well. But I'm not going to make that change in this patch. There is an internal usage of a Pair Comparator already. It seems not such a big thing to simply expose that. I will attach an additional patch showing how it can replace the existing other Comparator, but this is of course entirely optional. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796597#comment-13796597 ] Sean Owen commented on MATH-1041: - OK. This had felt like so minor as to be one issue to me, but I can see breaking it into two. But here I meant that within one issue you had me invite discussion to iterate on the patch but had twice committed part of it before those changes completed. Truly no big deal, but I figured it would just save you trouble to converge on the right patch and then commit. (I still have some extra tests outstanding on the 'patch' side FWIW.) You are welcome to commit any variation on the proposed changed here that you see fit. Thanks Gilles, don't let me burn any more of your cycles. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041_Pair.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796581#comment-13796581 ] Sean Owen commented on MATH-1041: - Ah I see you have committed part of the patch again. One more update coming. Let's do all-or-nothing for the remainder to keep this simple. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041_Pair.patch MATH-1041_Comparator.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041_Comparator.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041_Pair.patch MATH-1041_Comparator.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796576#comment-13796576 ] Sean Owen commented on MATH-1041: - Done. Yes I saw that and had updated the patch already. It's broken down into two now as well. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041_Comparator.patch, MATH-1041_Pair.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Description: I use Commons Math heavily, and have adopted its Pair class for the cases where I need, well, a pair of things. The attached patch adds three small improvements to the Pair class: - toString() method - factory method ".create()" to avoid duplicating generic types on instance creation - a Comparator Tests are included. I won't feel offended if this is rejected or modified but just wanted to supply the suggestion. was: I use Commons Math heavily, and have adopted its Pair class for the cases where I need, well, a pair of things. The attached patch adds three small improvements to the Pair class: - toString() method - factory method ".of()" to avoid duplicating generic types on instance creation - a Comparator Tests are included. I won't feel offended if this is rejected or modified but just wanted to supply the suggestion. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".create()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041.patch Updated patch per Phil's comments on the mailing list. > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: (was: MATH-1041.patch) > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1041) Add Pair factory method, toString(), Comparator
[ https://issues.apache.org/jira/browse/MATH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1041: Attachment: MATH-1041.patch > Add Pair factory method, toString(), Comparator > > > Key: MATH-1041 > URL: https://issues.apache.org/jira/browse/MATH-1041 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Labels: comparator, pair > Attachments: MATH-1041.patch > > > I use Commons Math heavily, and have adopted its Pair class for the cases > where I need, well, a pair of things. > The attached patch adds three small improvements to the Pair class: > - toString() method > - factory method ".of()" to avoid duplicating generic types on instance > creation > - a Comparator > Tests are included. I won't feel offended if this is rejected or modified but > just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1041) Add Pair factory method, toString(), Comparator
Sean Owen created MATH-1041: --- Summary: Add Pair factory method, toString(), Comparator Key: MATH-1041 URL: https://issues.apache.org/jira/browse/MATH-1041 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor I use Commons Math heavily, and have adopted its Pair class for the cases where I need, well, a pair of things. The attached patch adds three small improvements to the Pair class: - toString() method - factory method ".of()" to avoid duplicating generic types on instance creation - a Comparator Tests are included. I won't feel offended if this is rejected or modified but just wanted to supply the suggestion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-931) Speed up UnitSphereRandomVectorGenerator for high dimensions
[ https://issues.apache.org/jira/browse/MATH-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567097#comment-13567097 ] Sean Owen commented on MATH-931: You can omit that test, of the two. The original motivation here was that the method could take minutes or hours to run when dimensions got to high tens. That just asserted that it ran in 10 seconds -- should be like a nanosecond now. > Speed up UnitSphereRandomVectorGenerator for high dimensions > > > Key: MATH-931 > URL: https://issues.apache.org/jira/browse/MATH-931 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.1.1 >Reporter: Sean Owen >Priority: Minor > Attachments: MATH-931.patch > > > I have a small proposal to improve the speed of > UnitSphereRandomVectorGenerator. This class picks a random point on the unit > n-sphere -- a unit vector, chosen uniformly from all possible directions. > It does so using a rejection process -- generates a random point in the unit > n-cube (well, with side lengths 2) and rejects any points outside the unit > n-sphere, then normalizes the length. This is correct and works well at low > dimension. However the volume of the unit n-sphere compared to the unit > n-cube drops exponentially. This method eventually takes an extraordinary > amount of time when dimensions get past about 20, since virtually no samples > are usable. > For example, here is the time in milliseconds taken to make pick 10 points as > a function of dimension up to 20: > 1 : 11 > 2 : 1 > 3 : 0 > 4 : 1 > 5 : 0 > 6 : 1 > 7 : 1 > 8 : 17 > 9 : 4 > 10 : 3 > 11 : 13 > 12 : 32 > 13 : 15 > 14 : 41 > 15 : 220 > 16 : 897 > 17 : 1770 > 18 : 7426 > 19 : 48457 > 20 : 122647 > ... > It's equally correct, and much faster, to generate these points by picking n > standard Gaussians and normalizing. This method takes negligible time even > into thousands of dimensions. > Patch coming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-931) Speed up UnitSphereRandomVectorGenerator for high dimensions
[ https://issues.apache.org/jira/browse/MATH-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-931: --- Attachment: MATH-931.patch > Speed up UnitSphereRandomVectorGenerator for high dimensions > > > Key: MATH-931 > URL: https://issues.apache.org/jira/browse/MATH-931 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.1.1 >Reporter: Sean Owen >Priority: Minor > Attachments: MATH-931.patch > > > I have a small proposal to improve the speed of > UnitSphereRandomVectorGenerator. This class picks a random point on the unit > n-sphere -- a unit vector, chosen uniformly from all possible directions. > It does so using a rejection process -- generates a random point in the unit > n-cube (well, with side lengths 2) and rejects any points outside the unit > n-sphere, then normalizes the length. This is correct and works well at low > dimension. However the volume of the unit n-sphere compared to the unit > n-cube drops exponentially. This method eventually takes an extraordinary > amount of time when dimensions get past about 20, since virtually no samples > are usable. > For example, here is the time in milliseconds taken to make pick 10 points as > a function of dimension up to 20: > 1 : 11 > 2 : 1 > 3 : 0 > 4 : 1 > 5 : 0 > 6 : 1 > 7 : 1 > 8 : 17 > 9 : 4 > 10 : 3 > 11 : 13 > 12 : 32 > 13 : 15 > 14 : 41 > 15 : 220 > 16 : 897 > 17 : 1770 > 18 : 7426 > 19 : 48457 > 20 : 122647 > ... > It's equally correct, and much faster, to generate these points by picking n > standard Gaussians and normalizing. This method takes negligible time even > into thousands of dimensions. > Patch coming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-931) Speed up UnitSphereRandomVectorGenerator for high dimensions
Sean Owen created MATH-931: -- Summary: Speed up UnitSphereRandomVectorGenerator for high dimensions Key: MATH-931 URL: https://issues.apache.org/jira/browse/MATH-931 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1.1 Reporter: Sean Owen Priority: Minor Attachments: MATH-931.patch I have a small proposal to improve the speed of UnitSphereRandomVectorGenerator. This class picks a random point on the unit n-sphere -- a unit vector, chosen uniformly from all possible directions. It does so using a rejection process -- generates a random point in the unit n-cube (well, with side lengths 2) and rejects any points outside the unit n-sphere, then normalizes the length. This is correct and works well at low dimension. However the volume of the unit n-sphere compared to the unit n-cube drops exponentially. This method eventually takes an extraordinary amount of time when dimensions get past about 20, since virtually no samples are usable. For example, here is the time in milliseconds taken to make pick 10 points as a function of dimension up to 20: 1 : 11 2 : 1 3 : 0 4 : 1 5 : 0 6 : 1 7 : 1 8 : 17 9 : 4 10 : 3 11 : 13 12 : 32 13 : 15 14 : 41 15 : 220 16 : 897 17 : 1770 18 : 7426 19 : 48457 20 : 122647 ... It's equally correct, and much faster, to generate these points by picking n standard Gaussians and normalizing. This method takes negligible time even into thousands of dimensions. Patch coming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-293) Should FTPSClient set "PBSZ 0" and "PROT P" for FTPS connections
Should FTPSClient set "PBSZ 0" and "PROT P" for FTPS connections Key: NET-293 URL: https://issues.apache.org/jira/browse/NET-293 Project: Commons Net Issue Type: Improvement Affects Versions: 2.0 Reporter: Sean Owen Priority: Minor I don't know enough about the FTPS spec to know whether this is a bug or not -- somehow thinking not. But I spent some time debugging a connection to an FTPS server and in the end discovered that it would only work if the following commands were sent after login: PBSZ 0 PROT P Otherwise it would fail with "426 Transfer Aborted" after the file transfer began. I note that another FTPS desktop client I have did specify these and succeeded, which is the only thing that prompted me to wonder whether this should be set by default by FTPSClient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
