You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Axel Kramer (JIRA)" <ji...@apache.org> on 2010/08/05 18:39:18 UTC
[jira] Created: (MATH-402) Complex.ZERO.pow(Complex.ONE) gives NaN
in unit tests
Complex.ZERO.pow(Complex.ONE) gives NaN in unit tests
-----------------------------------------------------
Key: MATH-402
URL: https://issues.apache.org/jira/browse/MATH-402
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Environment: Issue 15 http://code.google.com/p/symja/issues/detail?id=15
Reporter: Axel Kramer
Why does this unit test in ComplexTest.java gives NaN?
I expected to get Complex.ZERO as the result?
{code:java}
public void testPowZero() {
TestUtils.assertSame(Complex.NaN,
Complex.ZERO.pow(Complex.ONE));
...
}
{code}
I would suggest something like this for the Complex#pow() method:
{code:java}
public Complex pow(Complex x) {
if (x == null) {
throw new NullPointerException();
}
if (x.imaginary == 0.0) {
if (real == 0.0 && imaginary == 0.0) {
if (x.real == 0.0){
return Complex.ZERO;
}
}
if (x.real == 1.0) {
return this;
}
}
return this.log().multiply(x).exp();
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-402) Complex.ZERO.pow(Complex.ONE) gives NaN
in unit tests
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz updated MATH-402:
-----------------------------
Fix Version/s: 2.2
Affects Version/s: 2.1
2.0
1.2
(was: 2.2)
> Complex.ZERO.pow(Complex.ONE) gives NaN in unit tests
> -----------------------------------------------------
>
> Key: MATH-402
> URL: https://issues.apache.org/jira/browse/MATH-402
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 1.2, 2.0, 2.1
> Environment: Issue 15 http://code.google.com/p/symja/issues/detail?id=15
> Reporter: Axel Kramer
> Fix For: 2.2
>
>
> Why does this unit test in ComplexTest.java gives NaN?
> I expected to get Complex.ZERO as the result?
> {code:java}
> public void testPowZero() {
> TestUtils.assertSame(Complex.NaN,
> Complex.ZERO.pow(Complex.ONE));
> ...
> }
> {code}
> I would suggest something like this for the Complex#pow() method:
> {code:java}
> public Complex pow(Complex x) {
> if (x == null) {
> throw new NullPointerException();
> }
> if (x.imaginary == 0.0) {
> if (real == 0.0 && imaginary == 0.0) {
> if (x.real == 0.0){
> return Complex.ZERO;
> }
> }
> if (x.real == 1.0) {
> return this;
> }
> }
> return this.log().multiply(x).exp();
> }
> {code}
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-402) Complex.ZERO.pow(Complex.ONE) gives
NaN in unit tests
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896344#action_12896344 ]
Phil Steitz commented on MATH-402:
----------------------------------
Thanks for reporting this. If we do make the suggested change, we need to change the formulas in the javadoc to reflect the changed definition. The value returned is a consequence of how we have defined complex exponentiation, which is spelled out in the javadoc for pow, exp and log. I am open to changing the definition, but we should make sure that the javadoc is modified to reflect whatever change we make. Interested in what others think the definition should be.
> Complex.ZERO.pow(Complex.ONE) gives NaN in unit tests
> -----------------------------------------------------
>
> Key: MATH-402
> URL: https://issues.apache.org/jira/browse/MATH-402
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Issue 15 http://code.google.com/p/symja/issues/detail?id=15
> Reporter: Axel Kramer
>
> Why does this unit test in ComplexTest.java gives NaN?
> I expected to get Complex.ZERO as the result?
> {code:java}
> public void testPowZero() {
> TestUtils.assertSame(Complex.NaN,
> Complex.ZERO.pow(Complex.ONE));
> ...
> }
> {code}
> I would suggest something like this for the Complex#pow() method:
> {code:java}
> public Complex pow(Complex x) {
> if (x == null) {
> throw new NullPointerException();
> }
> if (x.imaginary == 0.0) {
> if (real == 0.0 && imaginary == 0.0) {
> if (x.real == 0.0){
> return Complex.ZERO;
> }
> }
> if (x.real == 1.0) {
> return this;
> }
> }
> return this.log().multiply(x).exp();
> }
> {code}
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-402) Complex.ZERO.pow(Complex.ONE) gives
NaN in unit tests
Posted by "Axel Kramer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896247#action_12896247 ]
Axel Kramer commented on MATH-402:
----------------------------------
Sorry for my stupid suggestion in the first post.
It should be something like this:
{code:java}
public Complex pow(Complex x) {
if (x == null) {
throw new NullPointerException();
}
if (x.real == 0.0 && x.imaginary == 0.0) {
if (real == 0.0 && imaginary == 0.0) {
// 0^0 => NaN
return Complex.NaN;
}
// THIS^0 => 1 for THIS<>0
return Complex.ONE;
}
if (real == 0.0 && imaginary == 0.0) {
// 0^x => 0 for x<>0
return Complex.ZERO;
}
return this.log().multiply(x).exp();
}
{code}
> Complex.ZERO.pow(Complex.ONE) gives NaN in unit tests
> -----------------------------------------------------
>
> Key: MATH-402
> URL: https://issues.apache.org/jira/browse/MATH-402
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Issue 15 http://code.google.com/p/symja/issues/detail?id=15
> Reporter: Axel Kramer
>
> Why does this unit test in ComplexTest.java gives NaN?
> I expected to get Complex.ZERO as the result?
> {code:java}
> public void testPowZero() {
> TestUtils.assertSame(Complex.NaN,
> Complex.ZERO.pow(Complex.ONE));
> ...
> }
> {code}
> I would suggest something like this for the Complex#pow() method:
> {code:java}
> public Complex pow(Complex x) {
> if (x == null) {
> throw new NullPointerException();
> }
> if (x.imaginary == 0.0) {
> if (real == 0.0 && imaginary == 0.0) {
> if (x.real == 0.0){
> return Complex.ZERO;
> }
> }
> if (x.real == 1.0) {
> return this;
> }
> }
> return this.log().multiply(x).exp();
> }
> {code}
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-402) Complex.ZERO.pow(Complex.ONE) gives
NaN in unit tests
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896366#action_12896366 ]
Phil Steitz commented on MATH-402:
----------------------------------
The latest draft ISO C spec appears now to be public and is here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1494.pdf
The complex specifications are in Annex G. Does not look like anything has changed since C99x, though I have not done side-by-side comparisons. It looks to me like what we have in the code now matches the spec; but the spec does not specifically call out (unless I missed it) specialization to real arguments. What is causing the NaN is the singularity in the log function. Colt 1.1 looks like it matches our code. R returns 0 + 0i.
> Complex.ZERO.pow(Complex.ONE) gives NaN in unit tests
> -----------------------------------------------------
>
> Key: MATH-402
> URL: https://issues.apache.org/jira/browse/MATH-402
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Issue 15 http://code.google.com/p/symja/issues/detail?id=15
> Reporter: Axel Kramer
>
> Why does this unit test in ComplexTest.java gives NaN?
> I expected to get Complex.ZERO as the result?
> {code:java}
> public void testPowZero() {
> TestUtils.assertSame(Complex.NaN,
> Complex.ZERO.pow(Complex.ONE));
> ...
> }
> {code}
> I would suggest something like this for the Complex#pow() method:
> {code:java}
> public Complex pow(Complex x) {
> if (x == null) {
> throw new NullPointerException();
> }
> if (x.imaginary == 0.0) {
> if (real == 0.0 && imaginary == 0.0) {
> if (x.real == 0.0){
> return Complex.ZERO;
> }
> }
> if (x.real == 1.0) {
> return this;
> }
> }
> return this.log().multiply(x).exp();
> }
> {code}
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-402) Complex.ZERO.pow(Complex.ONE) gives
NaN in unit tests
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896345#action_12896345 ]
Luc Maisonobe commented on MATH-402:
------------------------------------
I know we do not follow C99 in many aspects, but what does C99 standard say about this specific topic ?
> Complex.ZERO.pow(Complex.ONE) gives NaN in unit tests
> -----------------------------------------------------
>
> Key: MATH-402
> URL: https://issues.apache.org/jira/browse/MATH-402
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Issue 15 http://code.google.com/p/symja/issues/detail?id=15
> Reporter: Axel Kramer
>
> Why does this unit test in ComplexTest.java gives NaN?
> I expected to get Complex.ZERO as the result?
> {code:java}
> public void testPowZero() {
> TestUtils.assertSame(Complex.NaN,
> Complex.ZERO.pow(Complex.ONE));
> ...
> }
> {code}
> I would suggest something like this for the Complex#pow() method:
> {code:java}
> public Complex pow(Complex x) {
> if (x == null) {
> throw new NullPointerException();
> }
> if (x.imaginary == 0.0) {
> if (real == 0.0 && imaginary == 0.0) {
> if (x.real == 0.0){
> return Complex.ZERO;
> }
> }
> if (x.real == 1.0) {
> return this;
> }
> }
> return this.log().multiply(x).exp();
> }
> {code}
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.