[jira] [Resolved] (FUNCTOR-19) [PATCH] Fix checkstyle warnings
[ https://issues.apache.org/jira/browse/FUNCTOR-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved FUNCTOR-19. --- Resolution: Fixed Fix Version/s: 1.0 Patch applied, see r1348547 Thanks once again for contributing, Bruno! [PATCH] Fix checkstyle warnings --- Key: FUNCTOR-19 URL: https://issues.apache.org/jira/browse/FUNCTOR-19 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Assignee: Simone Tripodi Priority: Trivial Fix For: 1.0 Attachments: FUNCTOR-19.patch This patch eliminates some checkstyle errors in [functor] trunk. I double checked for tabs and spaces, hope it is okay. Thank you! -- 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] (LANG-807) RandomStringUtils throws confusing IAE when end = start
Sebb created LANG-807: - Summary: RandomStringUtils throws confusing IAE when end = start Key: LANG-807 URL: https://issues.apache.org/jira/browse/LANG-807 Project: Commons Lang Issue Type: Bug Reporter: Sebb Assignee: Sebb Priority: Minor RandomUtils invokes Random#nextInt(n) where n = end - start. If end = start, then Random throws: java.lang.IllegalArgumentException: n must be positive This is confusing, and does not identify the source of the problem. -- 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] (LANG-807) RandomStringUtils throws confusing IAE when end = start
[ https://issues.apache.org/jira/browse/LANG-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-807: -- Affects Version/s: 2.6 3.1 RandomStringUtils throws confusing IAE when end = start Key: LANG-807 URL: https://issues.apache.org/jira/browse/LANG-807 Project: Commons Lang Issue Type: Bug Affects Versions: 2.6, 3.1 Reporter: Sebb Assignee: Sebb Priority: Minor RandomUtils invokes Random#nextInt(n) where n = end - start. If end = start, then Random throws: java.lang.IllegalArgumentException: n must be positive This is confusing, and does not identify the source of the problem. -- 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] (LANG-807) RandomStringUtils throws confusing IAE when end = start
[ https://issues.apache.org/jira/browse/LANG-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-807. --- Resolution: Fixed Fix Version/s: 2.7 3.2 RandomStringUtils throws confusing IAE when end = start Key: LANG-807 URL: https://issues.apache.org/jira/browse/LANG-807 Project: Commons Lang Issue Type: Bug Affects Versions: 2.6, 3.1 Reporter: Sebb Assignee: Sebb Priority: Minor Fix For: 3.2, 2.7 RandomUtils invokes Random#nextInt(n) where n = end - start. If end = start, then Random throws: java.lang.IllegalArgumentException: n must be positive This is confusing, and does not identify the source of the problem. -- 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-804) Make CurveFitter a generic class
Gilles created MATH-804:
---
Summary: Make CurveFitter a generic class
Key: MATH-804
URL: https://issues.apache.org/jira/browse/MATH-804
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.1
In order to enhance compile-time robustness, it is proposed to parameterize the
CurveFitter class with the type of the function to be used for the fit, i.e.:
{code}
public class CurveFitterT extends ParametricUnivariateFunction {
// ...
public double[] fit(T f, final double[] initialGuess) {
// ...
}
}
{code}
Thus enforcing that instances of subclasses like PolynomialFitter defined as
{code}
public class PolynomialFitter extends
CurveFitterPolynomialFunction.Parametric {
// ...
}
{code}
cannot call the fit method with a different function argument.
--
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] (LANG-806) RandomStringUtils can enter infinite loop if chosen char does not meet letter/digit requirements
[ https://issues.apache.org/jira/browse/LANG-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-806: -- Description: An infinite loop can result if the selection process never returns a char that passes the validation test. This can occur if the subset specified by the start and end characters does not contain any valid characters. For example: RandomStringUtils.random(3, 5, 10, true, true); // 1 RandomStringUtils.random(3, 56192, 56319, false, false); // 2 There's also the case where only surrogates are allowed, but the buffer is not an even number of characters, for example: RandomStringUtils.random(3, 56320, 57343, false, false); // 3 The second example is easy to detect, but in general it does not seem easy to determine in advance if the subset contains any valid characters - except by evaluating all the possible char values. This would be expensive if the subset range is large. One possibility is to count the total number of loops (or retries), and throw an error if it exceeds a given value. Or count the number of consecutive retries. In both cases the threshold value must be set high enough to allow for the cases where the allowable char range contains only a small proportion of valid characters. In the case of digits only, the default allowable range is currently set to digits + letters, so the proportion of valid chars is 10/90 i.e. approx 11%. A minimum proportion of 1% or 0.1% would be necessary to reduce the number of false positives. was: If numbers == true or digits == true, then an infinite loop can result if the selection process never returns a char that passes the validation test. This can occur with RandomStringUtils.random(1, -1, 1, true, true) because the gap is 2, i.e. random.nextInt(gap) + start == 0 This is trivial to fix; the code should check that start =0 and end start (unless start==end==0). It can also occur if the provided char array or array subset does not contain any valid chars. RandomStringUtils can enter infinite loop if chosen char does not meet letter/digit requirements Key: LANG-806 URL: https://issues.apache.org/jira/browse/LANG-806 Project: Commons Lang Issue Type: Bug Affects Versions: 2.6, 3.1 Reporter: Sebb Assignee: Sebb An infinite loop can result if the selection process never returns a char that passes the validation test. This can occur if the subset specified by the start and end characters does not contain any valid characters. For example: RandomStringUtils.random(3, 5, 10, true, true); // 1 RandomStringUtils.random(3, 56192, 56319, false, false); // 2 There's also the case where only surrogates are allowed, but the buffer is not an even number of characters, for example: RandomStringUtils.random(3, 56320, 57343, false, false); // 3 The second example is easy to detect, but in general it does not seem easy to determine in advance if the subset contains any valid characters - except by evaluating all the possible char values. This would be expensive if the subset range is large. One possibility is to count the total number of loops (or retries), and throw an error if it exceeds a given value. Or count the number of consecutive retries. In both cases the threshold value must be set high enough to allow for the cases where the allowable char range contains only a small proportion of valid characters. In the case of digits only, the default allowable range is currently set to digits + letters, so the proportion of valid chars is 10/90 i.e. approx 11%. A minimum proportion of 1% or 0.1% would be necessary to reduce the number of false positives. -- 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] (EMAIL-118) smtpPort setter and getter doesn't works with the same type in EmailClass
Xavier Detant created EMAIL-118: --- Summary: smtpPort setter and getter doesn't works with the same type in EmailClass Key: EMAIL-118 URL: https://issues.apache.org/jira/browse/EMAIL-118 Project: Commons Email Issue Type: Improvement Affects Versions: 1.3 Reporter: Xavier Detant Priority: Trivial The smtpPort in the Email class can be set as an int but is get as a String. This is quite bad design, the getter and the setter should works with the same type. As smtp ports is a number, the getter which is currently _public String getSmtpPort()_ should be _public int getSmtpPort()_: -- 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] (EMAIL-118) smtpPort setter and getter doesn't works with the same type in EmailClass
[ https://issues.apache.org/jira/browse/EMAIL-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Detant updated EMAIL-118: Attachment: SmtpAsInt.patch The patch to change smtp port from String to int. smtpPort setter and getter doesn't works with the same type in EmailClass - Key: EMAIL-118 URL: https://issues.apache.org/jira/browse/EMAIL-118 Project: Commons Email Issue Type: Improvement Affects Versions: 1.3 Reporter: Xavier Detant Priority: Trivial Labels: patch Attachments: SmtpAsInt.patch Original Estimate: 10m Remaining Estimate: 10m The smtpPort in the Email class can be set as an int but is get as a String. This is quite bad design, the getter and the setter should works with the same type. As smtp ports is a number, the getter which is currently _public String getSmtpPort()_ should be _public int getSmtpPort()_: -- 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] [Comment Edited] (EMAIL-118) smtpPort setter and getter doesn't works with the same type in EmailClass
[ https://issues.apache.org/jira/browse/EMAIL-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292524#comment-13292524 ] Xavier Detant edited comment on EMAIL-118 at 6/10/12 1:54 PM: -- The patch to change smtp port from String to int. Maybe a method _public String getSmptPortAsString()_ should be usefull. was (Author: xadet): The patch to change smtp port from String to int. smtpPort setter and getter doesn't works with the same type in EmailClass - Key: EMAIL-118 URL: https://issues.apache.org/jira/browse/EMAIL-118 Project: Commons Email Issue Type: Improvement Affects Versions: 1.3 Reporter: Xavier Detant Priority: Trivial Labels: patch Attachments: SmtpAsInt.patch Original Estimate: 10m Remaining Estimate: 10m The smtpPort in the Email class can be set as an int but is get as a String. This is quite bad design, the getter and the setter should works with the same type. As smtp ports is a number, the getter which is currently _public String getSmtpPort()_ should be _public int getSmtpPort()_: -- 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-803) Bugs in OpenMapRealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
[
https://issues.apache.org/jira/browse/MATH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292525#comment-13292525
]
Luc Maisonobe commented on MATH-803:
Perhaps we should use a post-processing branch to handle infinite or spacial
values:
{code}
// current implementation looping over non-zero instance elements goes here
if (v.isNaN() || v.isInfinite()) {
// post-processing loop, to handle 0 * infinity and 0 * NaN cases
for (int i = 0; i v.getDimension(); ++v) {
if (Double.isInfinite(v.getElement(i)) || Double.isNaN(v.getElement(i)) {
res.setEntry(i, Double.NaN);
}
}
}
{code}
This could be fast only if isNaN() and isInfinite() results are cached and the
same vector is reused, otherwise the outer if statement should be removed and
the post-processing should be done in all cases.
Bugs in OpenMapRealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
---
Key: MATH-803
URL: https://issues.apache.org/jira/browse/MATH-803
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
{{OpenMapRealVector.ebeMultiply(RealVector)}} and
{{OpenMapRealVector.ebeDivide(RealVector)}} return wrong values when one
entry of the specified {{RealVector}} is nan or infinity. The bug is easy to
understand. Here is the current implementation of {{ebeMultiply}}
{code:java}
public OpenMapRealVector ebeMultiply(RealVector v) {
checkVectorDimensions(v.getDimension());
OpenMapRealVector res = new OpenMapRealVector(this);
Iterator iter = entries.iterator();
while (iter.hasNext()) {
iter.advance();
res.setEntry(iter.key(), iter.value() * v.getEntry(iter.key()));
}
return res;
}
{code}
The assumption is that for any double {{x}}, {{x * 0d == 0d}} holds, which is
not true. The bug is easy enough to identify, but more complex to solve. The
only solution I can come up with is to loop through *all* entries of v
(instead of those entries which correspond to non-zero entries of this). I'm
afraid about performance losses.
--
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] (LANG-808) RandomStringUtils inefficient init of start and end for letters and numbers
Sebb created LANG-808: - Summary: RandomStringUtils inefficient init of start and end for letters and numbers Key: LANG-808 URL: https://issues.apache.org/jira/browse/LANG-808 Project: Commons Lang Issue Type: Bug Reporter: Sebb If either letters or numbers is true, RandomStringUtils(count, 0, 0, letters, numbers, ...) sets the default start index to space, intending to support the set of printable characters (according to the Javadoc). However, the code later uses Character.isLetter and Character.isDigit, which exclude space and some other printable characters. There is currently no direct support for generating printable characters. The current Javadoc is misleading, and the current code is inefficient because some characters cannot currently be used. The lowest char which is either digit or letter is '0' (zero). The lowest char which is a letter is 'A' (upper case a). -- 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-804) Make CurveFitter a generic class
[
https://issues.apache.org/jira/browse/MATH-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292531#comment-13292531
]
Gilles commented on MATH-804:
-
Changes committed in revision 1348613.
Make CurveFitter a generic class
--
Key: MATH-804
URL: https://issues.apache.org/jira/browse/MATH-804
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.1
In order to enhance compile-time robustness, it is proposed to parameterize
the CurveFitter class with the type of the function to be used for the fit,
i.e.:
{code}
public class CurveFitterT extends ParametricUnivariateFunction {
// ...
public double[] fit(T f, final double[] initialGuess) {
// ...
}
}
{code}
Thus enforcing that instances of subclasses like PolynomialFitter defined as
{code}
public class PolynomialFitter extends
CurveFitterPolynomialFunction.Parametric {
// ...
}
{code}
cannot call the fit method with a different function argument.
--
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] (LANG-767) Keep 'cause method names' in Lang 4.0 for ServletException
[ https://issues.apache.org/jira/browse/LANG-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292533#comment-13292533 ] Jens Bannmann commented on LANG-767: No, I have not yet encountered any other non-JDK exceptions with this problem. Within the JDK, though, I remember that SqlException is not yet fixed in Java 5, which we still have to use at work. Will Lang 4 support JDK 5? If so, it should still support the cause method name for SqlException, as well. Keep 'cause method names' in Lang 4.0 for ServletException -- Key: LANG-767 URL: https://issues.apache.org/jira/browse/LANG-767 Project: Commons Lang Issue Type: Task Affects Versions: 4.0 Reporter: Jens Bannmann Labels: deprecated http://commons.apache.org/lang/article3_0.html#Deprecations says: bq. The lone deprecation in 3.0 is that of the notion of 'cause method names' in ExceptionUtils. In Java 5.0 it is still just about needed to handle some JDK classes that have not been migrated to the getCause API. In Java 6.0 things appear to be resolved and we will remove the related methods in Lang 4.0. I see a problem with this plan: so far, javax.servlet.ServletException has not been retrofitted to make use of the getCause() API for chaining. In 2005, the Tomcat project rejected a [bug requesting this|https://issues.apache.org/bugzilla/show_bug.cgi?id=36231], stating that it had to be changed in the spec, and nothing seems to have happened since. [A bug at sun suggesting a spec change|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4395719] is still open as of today. Thus, if you remove all support for cause method names from ExceptionUtils in Lang 4.0, web application authors would be forced to either write support glue for ServletException themselves again, or keep a dependency for Lang 3.0 alongside. Both alternatives sound bad to me. How about removing most of the cause method names, but keeping those that are still required for dealing with widely used classes such as ServletException? -- 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-804) Make CurveFitter a generic class
[
https://issues.apache.org/jira/browse/MATH-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-804.
-
Resolution: Fixed
Make CurveFitter a generic class
--
Key: MATH-804
URL: https://issues.apache.org/jira/browse/MATH-804
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.1
In order to enhance compile-time robustness, it is proposed to parameterize
the CurveFitter class with the type of the function to be used for the fit,
i.e.:
{code}
public class CurveFitterT extends ParametricUnivariateFunction {
// ...
public double[] fit(T f, final double[] initialGuess) {
// ...
}
}
{code}
Thus enforcing that instances of subclasses like PolynomialFitter defined as
{code}
public class PolynomialFitter extends
CurveFitterPolynomialFunction.Parametric {
// ...
}
{code}
cannot call the fit method with a different function argument.
--
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] [Comment Edited] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13287147#comment-13287147 ] Dan Tran edited comment on VFS-180 at 6/10/12 11:14 PM: Any chance this get committed to VFS 2.1-SNAPSHOT soon? Thanks was (Author: danttran): will this get ported to VFS2? Support HTTPS / SSL for Webdav -- Key: VFS-180 URL: https://issues.apache.org/jira/browse/VFS-180 Project: Commons VFS Issue Type: New Feature Affects Versions: 1.0, 1.1 Reporter: Werner Mueller Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, patch_180_vfs2.txt, patch_180_vfs2.txt The Slide Webdav lib supports encrypted HTTPS connections. So it should be possible to add https support to vfs too. currently the webdav provider creates http urls (in WebdavClientFactory.java). maybe some provider like 'webdavs' could be added to switch to HttpsUrl. regards werner -- 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] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292610#comment-13292610 ] Gary D. Gregory commented on VFS-180: - The last time I looked at this I had some testing issues. I'll take a look this week at some point. Support HTTPS / SSL for Webdav -- Key: VFS-180 URL: https://issues.apache.org/jira/browse/VFS-180 Project: Commons VFS Issue Type: New Feature Affects Versions: 1.0, 1.1 Reporter: Werner Mueller Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, patch_180_vfs2.txt, patch_180_vfs2.txt The Slide Webdav lib supports encrypted HTTPS connections. So it should be possible to add https support to vfs too. currently the webdav provider creates http urls (in WebdavClientFactory.java). maybe some provider like 'webdavs' could be added to switch to HttpsUrl. regards werner -- 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] (IO-269) Tailer locks file from deletion/rename on Windows
[ https://issues.apache.org/jira/browse/IO-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-269. Resolution: Fixed Fix Version/s: 2.4 Sending C:/svn/org/apache/commons/trunks-proper/io/src/changes/changes.xml Sending C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/Tailer.java Sending C:/svn/org/apache/commons/trunks-proper/io/src/test/java/org/apache/commons/io/input/TailerTest.java Transmitting file data ... Committed revision 1348698. Tailer locks file from deletion/rename on Windows - Key: IO-269 URL: https://issues.apache.org/jira/browse/IO-269 Project: Commons IO Issue Type: Bug Reporter: Sebb Fix For: 2.4 Attachments: IO-269-v2.patch, IO-269-v3.patch, IO-269.patch, ReOpen.java The Tailer code works on Windows, except that it locks the file against deletion or rename. The test code fails to detect this, because it fails to check if the file deletion succeeds. This seems to be a Windows OS issue. A possible solution might be to keep closing and re-opening the file. -- 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] (IO-326) Add new FileUtils.sizeOf[Directory] APIs to return BigInteger
[ https://issues.apache.org/jira/browse/IO-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-326. Resolution: Fixed Committed back in April. Add new FileUtils.sizeOf[Directory] APIs to return BigInteger - Key: IO-326 URL: https://issues.apache.org/jira/browse/IO-326 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.3 Reporter: Gary D. Gregory Fix For: 2.4 FileUtils.sizeOfDirectory will return a negative number when the size count goes past Long.MAX_VALUE. Counting with a BigInteger will solve this issue. Options: - Change the signature of FileUtils.sizeOfDirectory() to return a BigInteger. This will obviously break BC. - Create a new API to return a BigInteger. What would this new API be called? -- sizeOfDirectoryAsBigInteger -- bigIntegerSizeOfDirectory -- largeSizeOfDirectory -- ...? -- 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-803) Bugs in OpenMapRealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
[
https://issues.apache.org/jira/browse/MATH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292642#comment-13292642
]
Sébastien Brisard commented on MATH-803:
I'm going to implement the suggested post-processing for the time being; this
should solve the bug. Caching of isNaN() and isInfinite() is postponed.
Bugs in OpenMapRealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
---
Key: MATH-803
URL: https://issues.apache.org/jira/browse/MATH-803
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
{{OpenMapRealVector.ebeMultiply(RealVector)}} and
{{OpenMapRealVector.ebeDivide(RealVector)}} return wrong values when one
entry of the specified {{RealVector}} is nan or infinity. The bug is easy to
understand. Here is the current implementation of {{ebeMultiply}}
{code:java}
public OpenMapRealVector ebeMultiply(RealVector v) {
checkVectorDimensions(v.getDimension());
OpenMapRealVector res = new OpenMapRealVector(this);
Iterator iter = entries.iterator();
while (iter.hasNext()) {
iter.advance();
res.setEntry(iter.key(), iter.value() * v.getEntry(iter.key()));
}
return res;
}
{code}
The assumption is that for any double {{x}}, {{x * 0d == 0d}} holds, which is
not true. The bug is easy enough to identify, but more complex to solve. The
only solution I can come up with is to loop through *all* entries of v
(instead of those entries which correspond to non-zero entries of this). I'm
afraid about performance losses.
--
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-803) Bugs in OpenMapRealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
[
https://issues.apache.org/jira/browse/MATH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292648#comment-13292648
]
Sébastien Brisard commented on MATH-803:
I think this does not work for {{ebeDivide(RealVector)}}. In this case, I
suggest to revert to naive implementation (loop through all entries).
Bugs in OpenMapRealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
---
Key: MATH-803
URL: https://issues.apache.org/jira/browse/MATH-803
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
{{OpenMapRealVector.ebeMultiply(RealVector)}} and
{{OpenMapRealVector.ebeDivide(RealVector)}} return wrong values when one
entry of the specified {{RealVector}} is nan or infinity. The bug is easy to
understand. Here is the current implementation of {{ebeMultiply}}
{code:java}
public OpenMapRealVector ebeMultiply(RealVector v) {
checkVectorDimensions(v.getDimension());
OpenMapRealVector res = new OpenMapRealVector(this);
Iterator iter = entries.iterator();
while (iter.hasNext()) {
iter.advance();
res.setEntry(iter.key(), iter.value() * v.getEntry(iter.key()));
}
return res;
}
{code}
The assumption is that for any double {{x}}, {{x * 0d == 0d}} holds, which is
not true. The bug is easy enough to identify, but more complex to solve. The
only solution I can come up with is to loop through *all* entries of v
(instead of those entries which correspond to non-zero entries of this). I'm
afraid about performance losses.
--
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
