[jira] [Created] (MATH-582) Percentile does not work as described in API
Percentile does not work as described in API
Key: MATH-582
URL: https://issues.apache.org/jira/browse/MATH-582
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Reporter: Andre Herbst
example call:
StatUtils.percentile(new double[]{0d, 1d}, 25) returns 0.0
The API says that there is a position being computed: p*(n+1)/100 - we have
p=25 and n=2
I would expect position 0.75 as result. Next step according to the API is:
interpolation between both values at floor(0.25) and at ceil(0.25). Those
values are 0d and 1d ... so lower + d * (upper - lower) should give 0d +
0.25*(1d - 0d) = 0.25
But the above call returns 0 as result. This does not make sense to me.
another example where I think the result is not correct:
StatUtils.percentile(new double[]{0d, 1d, 1d, 1d}, 25) returns 0.25
we have pos = 25*5/100 = 1.25 ... so d = 0.25
values at position floor(1.25) and ceil(1.25) are 1d and 1d. How comes that the
result is not between 1d?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FILEUPLOAD-193) FileNotFoundException thrown by DiskFileItem.write
FileNotFoundException thrown by DiskFileItem.write
--
Key: FILEUPLOAD-193
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-193
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.2
Environment: Ubuntu 10.10
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
Reporter: Dan Washusen
Priority: Critical
Under certain conditions the DiskFileItem.write throws a FileNotFound
exception. It seems to be when outputFile.renameTo(file) fails...
A little digging seems to suggest that the following code is back to front:
{code}in = new BufferedInputStream(
new FileInputStream(outputFile));
out = new BufferedOutputStream(
new FileOutputStream(file));
IOUtils.copy(in, out);{code}
It seems to be trying to copy the outputFile (which doesn't exist yet) to the
input file.
{code}java.io.FileNotFoundException:
/tmp/UploadController/uploading/upload_69651d04_13000a31964__8000_1651.tmp
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:447)
at upload.UploadController.handle(UploadController.java:90){code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037503#comment-13037503 ] Matt Benson edited comment on COLLECTIONS-213 at 5/24/11 2:30 PM: -- It would seem appropriate for such an animal to cache the contents of the original iterator to support additional calls. There could be multiple factory methods to get Iterable instances with or without this behavior. was (Author: mbenson): It would seem appropriate for an animal to cache the contents of the original iterator to support additional calls. There could be multiple factory methods to get Iterable instances with or without this behavior. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[
https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038586#comment-13038586
]
Matt Benson commented on COLLECTIONS-213:
-
I would argue that the contract of Iterable suggests implicitly that multiple
.iterator() calls will return multiple Iterator instances. This is not
necessarily about resetting the original instance so much as forking it. I
would either make this the default behavior of IteratorIterable, or forego the
public constructor in favor of descriptive factory methods, e.g.:
{{IteratorIterable.adaptForSingleUse(Iterator)}}
{{IteratorIterable.adaptForMultipleUse(Iterator)}}
CollectionUtils API extension: algorithm methods accept an Iterator argument
Key: COLLECTIONS-213
URL: https://issues.apache.org/jira/browse/COLLECTIONS-213
Project: Commons Collections
Issue Type: Improvement
Components: Core
Reporter: Dusan Chromy
Assignee: Brent Worden
Fix For: 4.x
Attachments: COLLECTIONS-213.patch, CollectionUtils.java,
TestCollectionUtils.java, collections-4.0-213.diff
I just finished the Iterator additions to CollectionUtils, including test
cases and I am going to
attach them to this issue very shortly (basically as soon as I figure out how
attaching in JIRA works :)
At first I was thinking for a while whether CollectionUtils is a good place
to accomodate the methods with the
new signature, until I noticed the collect method already accepts an Iterator
argument.
Following methods now accept an Iterator argument (besides collect):
cardinality
find
forAllDo
countMatches
exists
I also noticed cardinality used to throw a NPE if the collection argument was
null.
I see no reason why it should not return zero. The Iterator flavour does
return zero
and I also modified the Collection version to return zero (including Javadoc
modification) for the sake of consistence.
I stopped to think for a while before touching the method, but the fact
that the Javadoc does not mention may not be null made me think the NPE is
not thrown
intentionally. And after all, cardinality(..) is nothing else than
specialized countMatches(..),
which returns 0 for null collection. However, feel free to reject the change
to the cardinality(Object,Collection)
method if you think otherwise.
I worked on a fresh checkout from subversion and I just updated few minutes
ago to make sure I have modified
the latest version. Anyway, please double-check before commiting the changes.
Cheers,
Dusan
I think that these methods would make useful additions to the API.
I don't have the time to do much collections work these days, but if you
want to code the methods with test cases and attach them to JIRA then that
would be great.
Stephen
dusan.chr...@freenet.de wrote:
I've been using some algorithm methods from the CollectionUtils, for
example
find(Collection, Predicate)
exists(Collection, Predicate)
countMatches(Collection, Predicate)
forAllDo(Collection, Closure)
However, I would also like to be able to use these algorithms with an
Iterator:
find(Iterator, Predicate)
exists(Iterator, Predicate)
countMatches(Iterator, Predicate)
forAllDo(Iterator, Closure)
The obvious workaround is to use IteratorUtils.toList(Iterator), however
this comes at the cost of constructing a list object (an ArrayList
presumably) which could be avoided, as the Iterator itself is sufficient
for the above algorithms to work.
What do you think? Is there any reason not to provide the algorithms for
an Iterator? I personally think that the algorithms should have been
there for Iterators in the first place, because every collection is
Iterable (or has an Iterator, prior to JDK 5.0).
If noone is interested or has time to implement these changes, I can also
contribute to the project - but at the moment I just wanted to discuss
the idea / check if this has been already considered or planned.
Best Regards,
Dusan Chromy
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038595#comment-13038595 ] Stephen Colebourne commented on COLLECTIONS-213: Dont forget that [collections] has ResettableIterator, so there is another case to consider. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-306) Use Predicate in subtract
[ https://issues.apache.org/jira/browse/COLLECTIONS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-306. -- Resolution: Fixed Fix Version/s: 4.0 r1127124 and r1127125. Added predicated subtract method to CollectionUtils. Use Predicate in subtract - Key: COLLECTIONS-306 URL: https://issues.apache.org/jira/browse/COLLECTIONS-306 Project: Commons Collections Issue Type: New Feature Components: Collection Environment: all OSs Reporter: Chris Shayan Fix For: 4.0 Original Estimate: 0.75h Remaining Estimate: 0.75h It is good idea to use Predicate in subtract method, I've developed myself the mentioned method and now I am testing it. I mean we should have following methods: The one already exist is: public static Collection subtract(Collection a, Collection b) I offer to have one more which is: public static Collection subtract(Collection a, Collection b, Predicate predicate) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-583) Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix
Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix -- Key: MATH-583 URL: https://issues.apache.org/jira/browse/MATH-583 Project: Commons Math Issue Type: Bug Reporter: Vishv jeet Attachments: matrix.csv Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-583) Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix
[ https://issues.apache.org/jira/browse/MATH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishv jeet updated MATH-583: Attachment: matrix.csv matrix data Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix -- Key: MATH-583 URL: https://issues.apache.org/jira/browse/MATH-583 Project: Commons Math Issue Type: Bug Reporter: Vishv jeet Attachments: matrix.csv Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-583) Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix
[ https://issues.apache.org/jira/browse/MATH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishv jeet updated MATH-583: Attachment: svd.py EigenAndSVDFailure.java 1) java code to reproduce error 2) python code that works Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix -- Key: MATH-583 URL: https://issues.apache.org/jira/browse/MATH-583 Project: Commons Math Issue Type: Bug Reporter: Vishv jeet Attachments: EigenAndSVDFailure.java, matrix.csv, svd.py Eigen value and SVD fail on a matrix with InvalidMatrixException while numpy has no problem on the same matrix -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-313) Allow Closure and CollectionUtils.forAllDo to throw Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-313. -- Resolution: Fixed Fix Version/s: 4.0 r1127199. Added abstract closure that is capable of handling thrown exceptions from closure execution. Allow Closure and CollectionUtils.forAllDo to throw Exception - Key: COLLECTIONS-313 URL: https://issues.apache.org/jira/browse/COLLECTIONS-313 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2 Reporter: David J. M. Karlsen Assignee: Brent Worden Fix For: 4.0 Attachments: collections-313.txt Original Estimate: 0h Remaining Estimate: 0h It would be nice if Closure.execute and CollectionUtils.forAllDo would be allowed to throw Exceptions as the work inside of the Closure might very well throw exceptions -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-274) Tailer returning partial lines when reaching EOF before EOL
Tailer returning partial lines when reaching EOF before EOL --- Key: IO-274 URL: https://issues.apache.org/jira/browse/IO-274 Project: Commons IO Issue Type: Bug Affects Versions: 2.0.1 Reporter: Frank Grimes As reported here: http://mail-archives.apache.org/mod_mbox/commons-user/201105.mbox/%3cbanlktim6ha-xgjn8ca6ffcpkva6ax6k...@mail.gmail.com%3e -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-274) Tailer returning partial lines when reaching EOF before EOL
[ https://issues.apache.org/jira/browse/IO-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Grimes updated IO-274: Attachment: Tailer.patch Test case and patch. Tailer returning partial lines when reaching EOF before EOL --- Key: IO-274 URL: https://issues.apache.org/jira/browse/IO-274 Project: Commons IO Issue Type: Bug Affects Versions: 2.0.1 Reporter: Frank Grimes Attachments: Tailer.patch As reported here: http://mail-archives.apache.org/mod_mbox/commons-user/201105.mbox/%3cbanlktim6ha-xgjn8ca6ffcpkva6ax6k...@mail.gmail.com%3e -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FILEUPLOAD-193) FileNotFoundException thrown by DiskFileItem.write
[
https://issues.apache.org/jira/browse/FILEUPLOAD-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Washusen updated FILEUPLOAD-193:
Description:
Under certain conditions the DiskFileItem.write throws a FileNotFound
exception. It seems to be when outputFile.renameTo(file) fails.
{code}java.io.FileNotFoundException:
/tmp/UploadController/uploading/upload_69651d04_13000a31964__8000_1651.tmp
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:447)
at upload.UploadController.handle(UploadController.java:90)
...{code}
I can't see any obvious reason why the source file (outputFile) wouldn't
exist...
was:
Under certain conditions the DiskFileItem.write throws a FileNotFound
exception. It seems to be when outputFile.renameTo(file) fails...
A little digging seems to suggest that the following code is back to front:
{code}in = new BufferedInputStream(
new FileInputStream(outputFile));
out = new BufferedOutputStream(
new FileOutputStream(file));
IOUtils.copy(in, out);{code}
It seems to be trying to copy the outputFile (which doesn't exist yet) to the
input file.
{code}java.io.FileNotFoundException:
/tmp/UploadController/uploading/upload_69651d04_13000a31964__8000_1651.tmp
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:447)
at upload.UploadController.handle(UploadController.java:90){code}
Updated description to remove incorrect description of issue.
FileNotFoundException thrown by DiskFileItem.write
--
Key: FILEUPLOAD-193
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-193
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.2
Environment: Ubuntu 10.10
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
Reporter: Dan Washusen
Priority: Critical
Under certain conditions the DiskFileItem.write throws a FileNotFound
exception. It seems to be when outputFile.renameTo(file) fails.
{code}java.io.FileNotFoundException:
/tmp/UploadController/uploading/upload_69651d04_13000a31964__8000_1651.tmp
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:447)
at upload.UploadController.handle(UploadController.java:90)
...{code}
I can't see any obvious reason why the source file (outputFile) wouldn't
exist...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
