[jira] [Commented] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206430#comment-13206430
]
Sébastien Brisard commented on MATH-743:
In {{r1243263}}, introduced {{DctNormalization}} to specify the normalization
of discrete cosine transforms (standard, orthogonal).
Use enums in package transform
--
Key: MATH-743
URL: https://issues.apache.org/jira/browse/MATH-743
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: api-change, enum, transform
As discussed on the mailing-list, enums could be used in the package
{{transform}}
# An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
inverse transform is to be computed. This will replace the pair
{{transform}}/{{inverseTransform}}
# An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
in each transform class, in order to specify the normalization that should be
used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-299) getPrefixLength returns null if filename has leading slashes
[
https://issues.apache.org/jira/browse/IO-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206439#comment-13206439
]
Thilina Dampahala commented on IO-299:
--
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix: //I don't want to become null!
In Windows: \\I don't want to become null!
Any ideas on this?
getPrefixLength returns null if filename has leading slashes
Key: IO-299
URL: https://issues.apache.org/jira/browse/IO-299
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.0.1, 2.1
Reporter: Rick Latrine
Original Estimate: 2h
Remaining Estimate: 2h
Situation:
FilenameUtils.getPrefixLength is used in FilenameUtils.doNormalize.
FilenameUtils.normalize(I don't want to become null!) returns null.
Problem:
Expected was: I don't want to become null!
The method FilenameUtils.getPrefixLength returns -1 for the mentioned string.
The root problem is found in following lines of code:
{code:title=FilenameUtils.getPrefixLength}
...
int posUnix = filename.indexOf(UNIX_SEPARATOR, 2);
int posWin = filename.indexOf(WINDOWS_SEPARATOR, 2);
if ((posUnix == -1 posWin == -1) || posUnix == 2 || posWin
== 2) {
return -1;
}
...
{code}
Solution:
All leading slashes should be ignored at all, but considering the rest of the
string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-299) getPrefixLength returns null if filename has leading slashes
[
https://issues.apache.org/jira/browse/IO-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206439#comment-13206439
]
Thilina Dampahala edited comment on IO-299 at 2/12/12 4:07 PM:
---
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\I don't want to become null!
Any ideas on this?
was (Author: thdamp):
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix: //I don't want to become null!
In Windows: \\I don't want to become null!
Any ideas on this?
getPrefixLength returns null if filename has leading slashes
Key: IO-299
URL: https://issues.apache.org/jira/browse/IO-299
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.0.1, 2.1
Reporter: Rick Latrine
Original Estimate: 2h
Remaining Estimate: 2h
Situation:
FilenameUtils.getPrefixLength is used in FilenameUtils.doNormalize.
FilenameUtils.normalize(I don't want to become null!) returns null.
Problem:
Expected was: I don't want to become null!
The method FilenameUtils.getPrefixLength returns -1 for the mentioned string.
The root problem is found in following lines of code:
{code:title=FilenameUtils.getPrefixLength}
...
int posUnix = filename.indexOf(UNIX_SEPARATOR, 2);
int posWin = filename.indexOf(WINDOWS_SEPARATOR, 2);
if ((posUnix == -1 posWin == -1) || posUnix == 2 || posWin
== 2) {
return -1;
}
...
{code}
Solution:
All leading slashes should be ignored at all, but considering the rest of the
string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-299) getPrefixLength returns null if filename has leading slashes
[
https://issues.apache.org/jira/browse/IO-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206439#comment-13206439
]
Thilina Dampahala edited comment on IO-299 at 2/12/12 4:08 PM:
---
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
I don't want to become null!
Any ideas on this?
was (Author: thdamp):
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\I don't want to become null!
Any ideas on this?
getPrefixLength returns null if filename has leading slashes
Key: IO-299
URL: https://issues.apache.org/jira/browse/IO-299
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.0.1, 2.1
Reporter: Rick Latrine
Original Estimate: 2h
Remaining Estimate: 2h
Situation:
FilenameUtils.getPrefixLength is used in FilenameUtils.doNormalize.
FilenameUtils.normalize(I don't want to become null!) returns null.
Problem:
Expected was: I don't want to become null!
The method FilenameUtils.getPrefixLength returns -1 for the mentioned string.
The root problem is found in following lines of code:
{code:title=FilenameUtils.getPrefixLength}
...
int posUnix = filename.indexOf(UNIX_SEPARATOR, 2);
int posWin = filename.indexOf(WINDOWS_SEPARATOR, 2);
if ((posUnix == -1 posWin == -1) || posUnix == 2 || posWin
== 2) {
return -1;
}
...
{code}
Solution:
All leading slashes should be ignored at all, but considering the rest of the
string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-299) getPrefixLength returns null if filename has leading slashes
[
https://issues.apache.org/jira/browse/IO-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206439#comment-13206439
]
Thilina Dampahala edited comment on IO-299 at 2/12/12 4:08 PM:
---
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\\I don't want to become null!
Any ideas on this?
was (Author: thdamp):
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
I don't want to become null!
Any ideas on this?
getPrefixLength returns null if filename has leading slashes
Key: IO-299
URL: https://issues.apache.org/jira/browse/IO-299
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.0.1, 2.1
Reporter: Rick Latrine
Original Estimate: 2h
Remaining Estimate: 2h
Situation:
FilenameUtils.getPrefixLength is used in FilenameUtils.doNormalize.
FilenameUtils.normalize(I don't want to become null!) returns null.
Problem:
Expected was: I don't want to become null!
The method FilenameUtils.getPrefixLength returns -1 for the mentioned string.
The root problem is found in following lines of code:
{code:title=FilenameUtils.getPrefixLength}
...
int posUnix = filename.indexOf(UNIX_SEPARATOR, 2);
int posWin = filename.indexOf(WINDOWS_SEPARATOR, 2);
if ((posUnix == -1 posWin == -1) || posUnix == 2 || posWin
== 2) {
return -1;
}
...
{code}
Solution:
All leading slashes should be ignored at all, but considering the rest of the
string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-299) getPrefixLength returns null if filename has leading slashes
[
https://issues.apache.org/jira/browse/IO-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206439#comment-13206439
]
Thilina Dampahala edited comment on IO-299 at 2/12/12 4:09 PM:
---
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\I don't want to become null!
Any ideas on this?
was (Author: thdamp):
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\\I don't want to become null!
Any ideas on this?
getPrefixLength returns null if filename has leading slashes
Key: IO-299
URL: https://issues.apache.org/jira/browse/IO-299
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.0.1, 2.1
Reporter: Rick Latrine
Original Estimate: 2h
Remaining Estimate: 2h
Situation:
FilenameUtils.getPrefixLength is used in FilenameUtils.doNormalize.
FilenameUtils.normalize(I don't want to become null!) returns null.
Problem:
Expected was: I don't want to become null!
The method FilenameUtils.getPrefixLength returns -1 for the mentioned string.
The root problem is found in following lines of code:
{code:title=FilenameUtils.getPrefixLength}
...
int posUnix = filename.indexOf(UNIX_SEPARATOR, 2);
int posWin = filename.indexOf(WINDOWS_SEPARATOR, 2);
if ((posUnix == -1 posWin == -1) || posUnix == 2 || posWin
== 2) {
return -1;
}
...
{code}
Solution:
All leading slashes should be ignored at all, but considering the rest of the
string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-299) getPrefixLength returns null if filename has leading slashes
[
https://issues.apache.org/jira/browse/IO-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206439#comment-13206439
]
Thilina Dampahala edited comment on IO-299 at 2/12/12 4:09 PM:
---
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\I don't want to become null!
Any ideas on this?
was (Author: thdamp):
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\I don't want to become null!
Any ideas on this?
getPrefixLength returns null if filename has leading slashes
Key: IO-299
URL: https://issues.apache.org/jira/browse/IO-299
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.0.1, 2.1
Reporter: Rick Latrine
Original Estimate: 2h
Remaining Estimate: 2h
Situation:
FilenameUtils.getPrefixLength is used in FilenameUtils.doNormalize.
FilenameUtils.normalize(I don't want to become null!) returns null.
Problem:
Expected was: I don't want to become null!
The method FilenameUtils.getPrefixLength returns -1 for the mentioned string.
The root problem is found in following lines of code:
{code:title=FilenameUtils.getPrefixLength}
...
int posUnix = filename.indexOf(UNIX_SEPARATOR, 2);
int posWin = filename.indexOf(WINDOWS_SEPARATOR, 2);
if ((posUnix == -1 posWin == -1) || posUnix == 2 || posWin
== 2) {
return -1;
}
...
{code}
Solution:
All leading slashes should be ignored at all, but considering the rest of the
string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: site.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-299) getPrefixLength returns null if filename has leading slashes
[
https://issues.apache.org/jira/browse/IO-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206439#comment-13206439
]
Thilina Dampahala edited comment on IO-299 at 2/12/12 4:11 PM:
---
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
Same with the other slash
Any ideas on this?
was (Author: thdamp):
In this case for your input I don't want to become null!, I think the
expected output should be
In Unix:
//I don't want to become null!
In Windows:
\\I don't want to become null!
Any ideas on this?
getPrefixLength returns null if filename has leading slashes
Key: IO-299
URL: https://issues.apache.org/jira/browse/IO-299
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.0.1, 2.1
Reporter: Rick Latrine
Original Estimate: 2h
Remaining Estimate: 2h
Situation:
FilenameUtils.getPrefixLength is used in FilenameUtils.doNormalize.
FilenameUtils.normalize(I don't want to become null!) returns null.
Problem:
Expected was: I don't want to become null!
The method FilenameUtils.getPrefixLength returns -1 for the mentioned string.
The root problem is found in following lines of code:
{code:title=FilenameUtils.getPrefixLength}
...
int posUnix = filename.indexOf(UNIX_SEPARATOR, 2);
int posWin = filename.indexOf(WINDOWS_SEPARATOR, 2);
if ((posUnix == -1 posWin == -1) || posUnix == 2 || posWin
== 2) {
return -1;
}
...
{code}
Solution:
All leading slashes should be ignored at all, but considering the rest of the
string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thundre updated MATH-744: - Attachment: site.patch Patch file for the fraction package. BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: site.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-739) Merge interface and implementation for statistical test classes in stat.inference package
[ https://issues.apache.org/jira/browse/MATH-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206463#comment-13206463 ] Thomas Neidhart commented on MATH-739: -- Merged ChiSquareTest in r1243286. Merge interface and implementation for statistical test classes in stat.inference package - Key: MATH-739 URL: https://issues.apache.org/jira/browse/MATH-739 Project: Commons Math Issue Type: Improvement Reporter: Thomas Neidhart Assignee: Thomas Neidhart Priority: Minor Fix For: 3.0 Original Estimate: 2h Remaining Estimate: 2h Generally, there is only one implementation of the respective interfaces in this package, so I am proposing that we eliminate the interface and rename the corresponding xxxTestImpl to xxxTest. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-488) Deprecate MathException in MATH_2_X and remove it in trunk
[
https://issues.apache.org/jira/browse/MATH-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206464#comment-13206464
]
Thomas Neidhart commented on MATH-488:
--
Cleanup of ChiSquareTest in r1243286.
Deprecate MathException in MATH_2_X and remove it in trunk
Key: MATH-488
URL: https://issues.apache.org/jira/browse/MATH-488
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Priority: Minor
Fix For: 2.2, 3.0
In trunk, all instances of {{MathException}} should be replaced by a more
specific object from the new {{exception}} package.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206491#comment-13206491 ] Gilles commented on MATH-744: - Thanks for fixing this. Would you mind adding a unit test that demonstrates the fix? BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: site.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-739) Merge interface and implementation for statistical test classes in stat.inference package
[ https://issues.apache.org/jira/browse/MATH-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-739. -- Resolution: Fixed Merged TTest in r1243304. This resolves this issuem though there are some inconsistencies wrt the check of array lengths in the stat package. Sometimes a DimensionMismatchException is thrown and sometimes NumberIsTooSmallException. Needs tbd. Merge interface and implementation for statistical test classes in stat.inference package - Key: MATH-739 URL: https://issues.apache.org/jira/browse/MATH-739 Project: Commons Math Issue Type: Improvement Reporter: Thomas Neidhart Assignee: Thomas Neidhart Priority: Minor Fix For: 3.0 Original Estimate: 2h Remaining Estimate: 2h Generally, there is only one implementation of the respective interfaces in this package, so I am proposing that we eliminate the interface and rename the corresponding xxxTestImpl to xxxTest. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-488) Deprecate MathException in MATH_2_X and remove it in trunk
[
https://issues.apache.org/jira/browse/MATH-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206495#comment-13206495
]
Thomas Neidhart commented on MATH-488:
--
The last use of MathException has been removed in r1243304 (TTest in
stat.inference).
There still exists an obsolete unit test, so I think this issue can be resolved
after removal of this test + MathException itself.
Deprecate MathException in MATH_2_X and remove it in trunk
Key: MATH-488
URL: https://issues.apache.org/jira/browse/MATH-488
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Priority: Minor
Fix For: 2.2, 3.0
In trunk, all instances of {{MathException}} should be replaced by a more
specific object from the new {{exception}} package.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[
https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206514#comment-13206514
]
Thundre commented on MATH-744:
--
I don't have the test classes working in Eclipse, so I can't do it there.
Here's a main method that demonstrates. (10^401+1)/(10^400) is just a smidgen
more than 10.
public static void main(String args[]) {
double x = new BigFraction(BigInteger.TEN.pow(401).add(BigInteger.ONE),
BigInteger.TEN.pow(400)).doubleValue();
System.out.println(x);
System.exit(0);
}
BigFraction.doubleValue() returns Double.NaN for large numerators or
denominators
-
Key: MATH-744
URL: https://issues.apache.org/jira/browse/MATH-744
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Reporter: Thundre
Attachments: site.patch
The current implementation of doubleValue() divides numerator.doubleValue() /
denominator.doubleValue(). BigInteger.doubleValue() fails for any number
greater than Double.MAX_VALUE. So if the user has 308-digit numerator or
denominator, the resulting quotient fails, even in cases where the result
would be well inside Double's range.
I have a patch to fix it, if I can figure out how to attach it here I will.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thundre updated MATH-744: - Attachment: test.patch I figured out my problem with junit. Here's a test case. BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: site.patch, test.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[
https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thundre updated MATH-744:
-
Comment: was deleted
(was: I don't have the test classes working in Eclipse, so I can't do it there.
Here's a main method that demonstrates. (10^401+1)/(10^400) is just a smidgen
more than 10.
public static void main(String args[]) {
double x = new BigFraction(BigInteger.TEN.pow(401).add(BigInteger.ONE),
BigInteger.TEN.pow(400)).doubleValue();
System.out.println(x);
System.exit(0);
})
BigFraction.doubleValue() returns Double.NaN for large numerators or
denominators
-
Key: MATH-744
URL: https://issues.apache.org/jira/browse/MATH-744
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Reporter: Thundre
Attachments: site.patch, test.patch
The current implementation of doubleValue() divides numerator.doubleValue() /
denominator.doubleValue(). BigInteger.doubleValue() fails for any number
greater than Double.MAX_VALUE. So if the user has 308-digit numerator or
denominator, the resulting quotient fails, even in cases where the result
would be well inside Double's range.
I have a patch to fix it, if I can figure out how to attach it here I will.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206520#comment-13206520 ] Thundre commented on MATH-744: -- I noticed that floatValue() has the same bug. Stand by for more patches. BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: site.patch, test.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thundre updated MATH-744: - Attachment: src.patch Patch for fixes to BigFraction.doubleValue() and floatValue(), and junit tests. BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: site.patch, src.patch, test.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thundre updated MATH-744: - Attachment: (was: site.patch) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: src.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thundre updated MATH-744: - Attachment: (was: test.patch) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: src.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-107) number of connections created has crossed more than maxActive
[ https://issues.apache.org/jira/browse/POOL-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206526#comment-13206526 ] Mark Thomas commented on POOL-107: -- I've spent some time looking at this and I am struggling to see how the described behavior could occur. The configuration provided looks like a JNDI resource definition from a container environment. You do not say which container or which version. Neither do you say which version of DBCP you are using. Further, there is no configuration that suggests that it isn't the container that is providing the connection pool. Neither is a stack trace provided of the initial errors that occur which would be very enlightening. Making a whole rash of assumptions (Tomcat is the container, the container provides the pool, latest Tomcat version) then if MySQL is not running, the connection pool will not be created when an attempt is made to obtain a connection. This will continue until the database is started at which point a connection pool will be created. In this scenario, the previous failures will have no effect on the pool that is created. Without sufficient detail to reproduce this issue, the assumption is going to be that the problem is somewhere (container code, application code) rather then POOL or DBCP. number of connections created has crossed more than maxActive -- Key: POOL-107 URL: https://issues.apache.org/jira/browse/POOL-107 Project: Commons Pool Issue Type: Bug Affects Versions: 1.3 Environment: OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 2) uname:Linux 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 vm_info: Java HotSpot(TM) Server VM (1.4.2_13-b06) for linux-x86, built on Oct 18 2006 09:55:11 by unknown with unknown compiler Reporter: Bhaskar NA Fix For: 1.5 I found that when the minIdle is configured then during loads, common pool creates more number of connections it will be greater than maxActive. When I had following settings: maxActive = 50 maxIdle = 30 minIdle=30 factory=org.apache.commons.dbcp.BasicDataSourceFactory maxWait=1 timeBetweenEvictionRunsMillis=90 numTestsPerEvictionRun=50 minEvictableIdleTimeMillis=180 testWhileIdle=true testOnBorrow = true validationQuery='select 1 from dual' Number of connections in the pool went upto 121. (found thru netstat) When I changed minIdle to 15 and did my load test connecitons in the pool went upto 66 Looks like maxActive is getting bypassed with minIdle. When I changed minIdle to 10 and maxActive to 30 and maxIdle to 30 then number of connections went upto 40. Can someone please throw light on what is going on here? I am using DBCP 1.2.1 and common pool 1.3. Bhaskar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-744) BigFraction.doubleValue() returns Double.NaN for large numerators or denominators
[ https://issues.apache.org/jira/browse/MATH-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206532#comment-13206532 ] Gilles commented on MATH-744: - Sorry to be picky, but it is better to avoid clumping many tests in the same test function, especially if they check different things. In this case, you could create a new test method, e.g. testDoubleValueForLargeNumeratorAndDenominator. Also, in addition to checking that the result is not NaN, you should check that the result is the expected value. Thanks for your contribution. BigFraction.doubleValue() returns Double.NaN for large numerators or denominators - Key: MATH-744 URL: https://issues.apache.org/jira/browse/MATH-744 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Thundre Attachments: src.patch The current implementation of doubleValue() divides numerator.doubleValue() / denominator.doubleValue(). BigInteger.doubleValue() fails for any number greater than Double.MAX_VALUE. So if the user has 308-digit numerator or denominator, the resulting quotient fails, even in cases where the result would be well inside Double's range. I have a patch to fix it, if I can figure out how to attach it here I will. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206566#comment-13206566
]
Gilles commented on MATH-707:
-
Done as of revision 1243370.
Instead of removing {{RealPointValuePair}} and {{VectorialPointValuePair}},
I've just renamed them {{PointValuePair}} and {{PointVectorValuePair}}
(according to the convention agreed on here) and made them subclasses of
{{Pair}}. This is needed in order to be able to keep the old semantics of
getPoint and getValue which returned copies of the stored data; by using
the {{Pair}} directly, we can only return a reference to the key and value.
Personally, I think that it shouldn't be a problem in this context (the pair is
just used to check convergence, and probably discarded afterwards: the
optimizer will instantiates another pair in the next iteration...).
So, proceeding with a semantic change (getKey would replace getPointRef and
getValue would replace getValueRef; the current getPoint and getValue,
returning copies, would disappear)?
Naming confusion
Key: MATH-707
URL: https://issues.apache.org/jira/browse/MATH-707
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Labels: api-change
Fix For: 3.0
This issue was raised in [this
thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the dev ML.
It proposes to consistently name classes/interfaces that refer to number
types (e.g. Real, Complex, ...) and structure (e.g. Scalar,
Vectorial, ...), with Real and Scalar components in names being assumed
(thus, not to be included in the name).
For example, for the Univariate... interfaces (in package analysis), the
proposal is to operate the following renaming:
* {{UnivariateRealFunction}} - {{UnivariateFunction}}
* {{UnivariateRealVectorialFunction}} - {{UnivariateVectorFunction}}
* {{UnivariateMatrixFunction}} - {{UnivariateMatrixFunction}}
Similar changes are in order in the package optimization (where Real is
sometimes included in the name and sometimes not, or used instead of
Scalar).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206605#comment-13206605
]
Elijah Zupancic commented on CHAIN-58:
--
@Simo
The patch looks good. I was unable to patch the latest checkout or the version
the patch was created from, so I had to look at all of the changes in patch
file format. The changes are in agreement with all of the work that I had been
doing. Please check them in. After this, shall I try to tackle the
documentation so that we can release an actual 2.0?
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: CHAIN-58-working-context-generics.patch,
chain-58-improved-context-generic.diff, chain-58-with-context-generic.diff,
chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-745) up to 5x Performance Improvement on FasFourierTransformer.java by using a recursive iterative sumation Approach
up to 5x Performance Improvement on FasFourierTransformer.java by using a recursive iterative sumation Approach --- Key: MATH-745 URL: https://issues.apache.org/jira/browse/MATH-745 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Leandro Ariel Pezzente By swithinch form a loop iterative approach to a recursive iterative approach on fastFourierTransformer.java a Perfomance Improvement of up to 5x is gained. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-745) up to 5x Performance Improvement on FasFourierTransformer.java by using a recursive iterative sumation Approach
[ https://issues.apache.org/jira/browse/MATH-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leandro Ariel Pezzente updated MATH-745: Attachment: FastFourierTransformer.patch.txt patch uploadad up to 5x Performance Improvement on FasFourierTransformer.java by using a recursive iterative sumation Approach --- Key: MATH-745 URL: https://issues.apache.org/jira/browse/MATH-745 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Leandro Ariel Pezzente Labels: FFT, Fast, Fourier, Transform Attachments: FastFourierTransformer.patch.txt By swithinch form a loop iterative approach to a recursive iterative approach on fastFourierTransformer.java a Perfomance Improvement of up to 5x is gained. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VALIDATOR-304) Support for additional Discovery Bins in the CreditCardValidator
Support for additional Discovery Bins in the CreditCardValidator Key: VALIDATOR-304 URL: https://issues.apache.org/jira/browse/VALIDATOR-304 Project: Commons Validator Issue Type: Improvement Components: Framework Affects Versions: 1.3.1 Release, 1.4 Environment: Software Platforms using the CreditCardValidator. Reporter: Harrhy Saladagu Priority: Critical Fix For: 1.4 Currently, The CreditCardValidator considers only cards having BINS 6011 as Discovery Card. This limits the usage of newly supported BINs by Discovery like 644 and 65. So, we need to support the newly added BINs by Discovery in CreditCardValidator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VALIDATOR-304) Support for additional Discovery Bins in the CreditCardValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harrhy Saladagu updated VALIDATOR-304: -- Environment: All (was: Software Platforms using the CreditCardValidator.) Support for additional Discovery Bins in the CreditCardValidator Key: VALIDATOR-304 URL: https://issues.apache.org/jira/browse/VALIDATOR-304 Project: Commons Validator Issue Type: Improvement Components: Framework Affects Versions: 1.3.1 Release, 1.4 Environment: All Reporter: Harrhy Saladagu Priority: Critical Labels: patch Fix For: 1.4 Currently, The CreditCardValidator considers only cards having BINS 6011 as Discovery Card. This limits the usage of newly supported BINs by Discovery like 644 and 65. So, we need to support the newly added BINs by Discovery in CreditCardValidator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
