[jira] [Commented] (MATH-826) RFE: low discrepancy sequence generator
[ https://issues.apache.org/jira/browse/MATH-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652481#comment-13652481 ] Thomas Neidhart commented on MATH-826: -- Hmm, I totally missed the RandomVectorGenerator, which makes indeed much more sense. Regarding the assets: the big file with 21000 dimensions has ~1.8 MB, which is too much I guess. We should limit to a reasonable size and provide an option for users to load other data files. > RFE: low discrepancy sequence generator > --- > > Key: MATH-826 > URL: https://issues.apache.org/jira/browse/MATH-826 > Project: Commons Math > Issue Type: Wish >Reporter: Sam Halliday >Priority: Minor > Labels: features > Attachments: SobolSequenceRandomGenerator.java > > > Please provide a low discrepancy sequence random number generator. > http://en.wikipedia.org/wiki/Low-discrepancy_sequence > Support for such a generator is poor in Java and existing implementations > tend to be standalone and do not provide a user friendly API. Ideally, such a > generator would implement Random, but using the Apache Commons Math random > API would be acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-381) Add FileUtils.copyInputStreamToFile API with option to leave the source open
[
https://issues.apache.org/jira/browse/IO-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652467#comment-13652467
]
Sebb commented on IO-381:
-
URL: http://svn.apache.org/r1480346
Log:
IO-381 Alternative implementation suggested by Sebb.
Modified:
commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java
URL: http://svn.apache.org/r1480491
Log:
Javadoc fix
Modified:
commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java
> Add FileUtils.copyInputStreamToFile API with option to leave the source open
>
>
> Key: IO-381
> URL: https://issues.apache.org/jira/browse/IO-381
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
> Maven home: C:\Java\apache-maven-3.0.5\bin\..
> Java version: 1.7.0_17, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_17\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.5
>
>
> Add the API: {{copyInputStreamToFile(final InputStream source, final File
> destination, boolean closeSource)}}
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to
> destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}, will be closed
> * @param destination the non-directory File to write bytes
> to
> * (possibly overwriting), must not be {@code null}
> * @param closeSource If true, closes the source
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but
> can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyInputStreamToFile(final InputStream source, final
> File destination, boolean closeSource)
> throws IOException {
> {code}
> Related to [IO-380].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated IO-380:
Comment: was deleted
(was:
URL: http://svn.apache.org/r1480346
Log:
[IO-381] Alternative implementation suggested by Sebb.
Modified:
commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java
URL: http://svn.apache.org/r1480491
Log:
Javadoc fix
Modified:
commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java
)
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
> Fix For: 2.5
>
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652465#comment-13652465
]
Sebb commented on IO-380:
-
URL: http://svn.apache.org/r1480346
Log:
[IO-381] Alternative implementation suggested by Sebb.
Modified:
commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java
URL: http://svn.apache.org/r1480491
Log:
Javadoc fix
Modified:
commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
> Fix For: 2.5
>
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-826) RFE: low discrepancy sequence generator
[ https://issues.apache.org/jira/browse/MATH-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652255#comment-13652255 ] Luc Maisonobe commented on MATH-826: This seems very interesting. I have two remarks. The first one (less important) is that we could put the complete list of direction numbers in the original text file and upload it from within the jar as a resource in the assets directory. The second remark (more important) is that I don't think having Sobol sequences implement AbstractRandomGenerator is good. I would rather have it implement RandomVectorGenerator as they are clearly oriented towards multi-dimensional numbers generation. > RFE: low discrepancy sequence generator > --- > > Key: MATH-826 > URL: https://issues.apache.org/jira/browse/MATH-826 > Project: Commons Math > Issue Type: Wish >Reporter: Sam Halliday >Priority: Minor > Labels: features > Attachments: SobolSequenceRandomGenerator.java > > > Please provide a low discrepancy sequence random number generator. > http://en.wikipedia.org/wiki/Low-discrepancy_sequence > Support for such a generator is poor in Java and existing implementations > tend to be standalone and do not provide a user friendly API. Ideally, such a > generator would implement Random, but using the Apache Commons Math random > API would be acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-826) RFE: low discrepancy sequence generator
[ https://issues.apache.org/jira/browse/MATH-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-826: - Attachment: SobolSequenceRandomGenerator.java First draft of a random generator based on a Sobol sequence. The user can select the dimension when creating the generator. Thus when a user is interested in 3d points, 3 generators are needed. The generator includes direction numbers from [http://web.maths.unsw.edu.au/~fkuo/sobol/] for the first 100 dimensions (they are under BSD license), but custom ones can be provided. Does this make sense? > RFE: low discrepancy sequence generator > --- > > Key: MATH-826 > URL: https://issues.apache.org/jira/browse/MATH-826 > Project: Commons Math > Issue Type: Wish >Reporter: Sam Halliday >Priority: Minor > Labels: features > Attachments: SobolSequenceRandomGenerator.java > > > Please provide a low discrepancy sequence random number generator. > http://en.wikipedia.org/wiki/Low-discrepancy_sequence > Support for such a generator is poor in Java and existing implementations > tend to be standalone and do not provide a user friendly API. Ideally, such a > generator would implement Random, but using the Apache Commons Math random > API would be acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652123#comment-13652123
]
Claudio Nieder commented on IO-380:
---
I like the copyToFile very much. And the comment in copyInputStreamToFile is
now very clear. Thank you!
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
> Fix For: 2.5
>
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652104#comment-13652104
]
Gary Gregory commented on IO-380:
-
Please take a look at trunk and tell us what you think. Thank you!
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
> Fix For: 2.5
>
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652095#comment-13652095
]
Claudio Nieder commented on IO-380:
---
I think the behaviour of copyFile Sebb mentions is better because if you get
passed an open stream, it shouldn't be your business to close it. But that's a
design decision of commons-io, how it wants to handle passed streams. So as
long as the behaviour is properly documented, it is fine for me.
Thanks for fixing this so quickly!
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
> Fix For: 2.5
>
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652079#comment-13652079 ] Jeff Hain commented on MATH-740: Nice :) I used it at work too, but it wasn't called intensively enough to be worth it (maybe because in some places I cached sin/cos values along with angles, not to recompute them every time), so I removed it. I have a lot of fast geodetic code lying around, but I don't think it's stable enough to be published, especially because much methods have different flavors, depending on whether you just specify angles (double), or angles + sin and cos (not to recompute them inside), or angles + temporary DoubleWrapper so that FastMath.sinAndCos(...) can be used, etc., and I'm still wondering if I should cache sin/cos in angular classes and use them instead of "double" (and just have one method), or make them immutable with cached sin/cos lazily initialized, etc. -Jeff > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 4.0 > > Attachments: jafamatests.zip > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-381) Add FileUtils.copyInputStreamToFile API with option to leave the source open
[
https://issues.apache.org/jira/browse/IO-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651940#comment-13651940
]
Gary Gregory commented on IO-381:
-
The style of the class is unfortunate IMO: copySourceTypeToDestType(SourceType,
DestType, ...). I would have rather seen copyToDestType(). So I follow the
current style of the APIs.
I though that adding a copyToFile(InputStream, File) which does not close next
to copyInputStreamToFile(InputStream, File) which does close would be confusing.
> Add FileUtils.copyInputStreamToFile API with option to leave the source open
>
>
> Key: IO-381
> URL: https://issues.apache.org/jira/browse/IO-381
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
> Maven home: C:\Java\apache-maven-3.0.5\bin\..
> Java version: 1.7.0_17, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_17\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.5
>
>
> Add the API: {{copyInputStreamToFile(final InputStream source, final File
> destination, boolean closeSource)}}
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to
> destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}, will be closed
> * @param destination the non-directory File to write bytes
> to
> * (possibly overwriting), must not be {@code null}
> * @param closeSource If true, closes the source
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but
> can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyInputStreamToFile(final InputStream source, final
> File destination, boolean closeSource)
> throws IOException {
> {code}
> Related to [IO-380].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-381) Add FileUtils.copyInputStreamToFile API with option to leave the source open
[
https://issues.apache.org/jira/browse/IO-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-381.
-
Resolution: Fixed
> Add FileUtils.copyInputStreamToFile API with option to leave the source open
>
>
> Key: IO-381
> URL: https://issues.apache.org/jira/browse/IO-381
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
> Maven home: C:\Java\apache-maven-3.0.5\bin\..
> Java version: 1.7.0_17, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_17\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.5
>
>
> Add the API: {{copyInputStreamToFile(final InputStream source, final File
> destination, boolean closeSource)}}
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to
> destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}, will be closed
> * @param destination the non-directory File to write bytes
> to
> * (possibly overwriting), must not be {@code null}
> * @param closeSource If true, closes the source
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but
> can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyInputStreamToFile(final InputStream source, final
> File destination, boolean closeSource)
> throws IOException {
> {code}
> Related to [IO-380].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-381) Add FileUtils.copyInputStreamToFile API with option to leave the source open
[
https://issues.apache.org/jira/browse/IO-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651935#comment-13651935
]
Sebb commented on IO-381:
-
Alternatively create a new method by analogy with copyFile(File, OutputStream),
for example
copyToFile(InputStream, File)
Given that the existing method exists, not sure there is much point having a
new public method that exposes both old and new behaviours - there's no need
for the end user to ever use closeSource=true as there is already an API for
that.
Of course we can choose to implement the two behaviours by delegating to a
single private method with the boolean parameter.
> Add FileUtils.copyInputStreamToFile API with option to leave the source open
>
>
> Key: IO-381
> URL: https://issues.apache.org/jira/browse/IO-381
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
> Maven home: C:\Java\apache-maven-3.0.5\bin\..
> Java version: 1.7.0_17, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_17\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.5
>
>
> Add the API: {{copyInputStreamToFile(final InputStream source, final File
> destination, boolean closeSource)}}
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to
> destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}, will be closed
> * @param destination the non-directory File to write bytes
> to
> * (possibly overwriting), must not be {@code null}
> * @param closeSource If true, closes the source
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but
> can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyInputStreamToFile(final InputStream source, final
> File destination, boolean closeSource)
> throws IOException {
> {code}
> Related to [IO-380].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-380.
-
Resolution: Fixed
Fix Version/s: 2.5
See also [IO-381].
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
> Fix For: 2.5
>
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (MATH-826) RFE: low discrepancy sequence generator
[ https://issues.apache.org/jira/browse/MATH-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501904#comment-13501904 ] Thomas Neidhart edited comment on MATH-826 at 5/8/13 2:21 PM: -- Some pointers to information on Sobol sequences: * [http://www.deltaquants.com/sobol-sequence.html] * [http://web.maths.unsw.edu.au/~fkuo/sobol/joe-kuo-notes.pdf] * [http://web.maths.unsw.edu.au/~fkuo/sobol/] was (Author: tn): Some pointers to information on Sobol sequences: * [http://www.deltaquants.com/sobol-sequence.html] * [http://web.maths.unsw.edu.au/~fkuo/sobol/joe-kuo-notes.pdf] > RFE: low discrepancy sequence generator > --- > > Key: MATH-826 > URL: https://issues.apache.org/jira/browse/MATH-826 > Project: Commons Math > Issue Type: Wish >Reporter: Sam Halliday >Priority: Minor > Labels: features > > Please provide a low discrepancy sequence random number generator. > http://en.wikipedia.org/wiki/Low-discrepancy_sequence > Support for such a generator is poor in Java and existing implementations > tend to be standalone and do not provide a user friendly API. Ideally, such a > generator would implement Random, but using the Apache Commons Math random > API would be acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651925#comment-13651925
]
Sebb commented on IO-380:
-
URL: http://svn.apache.org/r1480284
Log:
IO-380 FileUtils.copyInputStreamToFile should document it closes the input
source
Modified:
commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java
URL: http://svn.apache.org/r1480286
Log:
IO-380 FileUtils.copyInputStreamToFile should document it closes the input
source
Modified:
commons/proper/io/trunk/src/changes/changes.xml
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-381) Add FileUtils.copyInputStreamToFile API with option to leave the source open
Gary Gregory created IO-381:
---
Summary: Add FileUtils.copyInputStreamToFile API with option to
leave the source open
Key: IO-381
URL: https://issues.apache.org/jira/browse/IO-381
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
Maven home: C:\Java\apache-maven-3.0.5\bin\..
Java version: 1.7.0_17, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_17\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.5
Add the API: {{copyInputStreamToFile(final InputStream source, final File
destination, boolean closeSource)}}
{code:java}
/**
* Copies bytes from an {@link InputStream} source to a file
* destination. The directories up to destination
* will be created if they don't already exist. destination
* will be overwritten if it already exists.
*
* @param source the InputStream to copy bytes from, must not
be {@code null}, will be closed
* @param destination the non-directory File to write bytes to
* (possibly overwriting), must not be {@code null}
* @param closeSource If true, closes the source
* @throws IOException if destination is a directory
* @throws IOException if destination cannot be written
* @throws IOException if destination needs creating but can't
be
* @throws IOException if an IO error occurs during copying
* @since 2.5
*/
public static void copyInputStreamToFile(final InputStream source, final
File destination, boolean closeSource)
throws IOException {
{code}
Related to [IO-380].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
[
https://issues.apache.org/jira/browse/IO-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651920#comment-13651920
]
Sebb commented on IO-380:
-
Note that copyFile(final File input, final OutputStream output) does not close
the output file.
Maybe there should be a version that does not close the input file at the end.
> FileUtils.copyInputStreamToFile should document it closes the input source
> --
>
> Key: IO-380
> URL: https://issues.apache.org/jira/browse/IO-380
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: JDK 7, OSX 10.8.3 (doesn't matter)
>Reporter: Claudio Nieder
>Priority: Trivial
>
> It would be nice to extend the parameter description
> @param source the InputStream to copy bytes from, must not be
> {@code null}
> to read:
> @param source the InputStream to copy bytes from, must not be
> {@code null}, will be closed
> so that one is aware it cannot be used e.g. on ZipInputStream which require
> the stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-380) FileUtils.copyInputStreamToFile should document it closes the input source
Claudio Nieder created IO-380:
-
Summary: FileUtils.copyInputStreamToFile should document it closes
the input source
Key: IO-380
URL: https://issues.apache.org/jira/browse/IO-380
Project: Commons IO
Issue Type: Improvement
Affects Versions: 2.4
Environment: JDK 7, OSX 10.8.3 (doesn't matter)
Reporter: Claudio Nieder
Priority: Trivial
It would be nice to extend the parameter description
@param source the InputStream to copy bytes from, must not be
{@code null}
to read:
@param source the InputStream to copy bytes from, must not be
{@code null}, will be closed
so that one is aware it cannot be used e.g. on ZipInputStream which require the
stream to still be open for executing zip.getNextEntry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-467) LRUMap remove callback
[
https://issues.apache.org/jira/browse/COLLECTIONS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651869#comment-13651869
]
l0co commented on COLLECTIONS-467:
--
Suggested implementation with example usage:
{code}
public class LRUMap extends org.apache.commons.collections.map.LRUMap {
public LRUMap() {
super();
}
public LRUMap(int maxSize) {
super(maxSize);
}
public LRUMap(int maxSize, boolean scanUntilRemovable) {
super(maxSize, scanUntilRemovable);
}
public LRUMap(int maxSize, float loadFactor) {
super(maxSize, loadFactor);
}
public LRUMap(int maxSize, float loadFactor, boolean
scanUntilRemovable) {
super(maxSize, loadFactor, scanUntilRemovable);
}
public LRUMap(Map map) {
super(map);
}
public LRUMap(Map map, boolean scanUntilRemovable) {
super(map, scanUntilRemovable);
}
@Override
protected void removeEntry(HashEntry entry, int hashIndex, HashEntry
previous) {
onRemove(entry.getKey(), entry.getValue());
super.removeEntry(entry, hashIndex, previous);
}
@Override
protected void addEntry(HashEntry entry, int hashIndex) {
onAdd(entry.getKey(), entry.getValue());
super.addEntry(entry, hashIndex);
}
@Override
public void clear() {
for (MapIterator i=mapIterator(); i.hasNext(); ) {
i.next();
onRemove(i.getKey(), i.getValue());
}
super.clear();
}
@Override
public Object get(Object key) {
return super.get(key);
}
protected void onAdd(Object key, Object value) {
// to override
}
protected void onRemove(Object key, Object value) {
// to override
}
// test
public static void main(String [] args) {
LRUMap map = new LRUMap(5) {
@Override
protected void onRemove(Object key, Object value) {
System.out.println("remove: "+key);
}
@Override
protected void onAdd(Object key, Object value) {
System.out.println("add: "+key);
}
};
for (int i=1; i<=10; i++)
map.put(i, i);
map.clear();
}
}
{code}
> LRUMap remove callback
> --
>
> Key: COLLECTIONS-467
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-467
> Project: Commons Collections
> Issue Type: New Feature
>Affects Versions: 3.2
>Reporter: l0co
>Priority: Minor
>
> If you use LRUMap with objects that require doing some disposal when they are
> dropped (eg. close()) and you hold these objects only in LRUMap, you cannot
> do it with current implementation. I propose to add onRemove() and onAdd()
> methods to the implementation, so that you can create anonymous inherited
> class and be able to react to these events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-467) LRUMap remove callback
l0co created COLLECTIONS-467: Summary: LRUMap remove callback Key: COLLECTIONS-467 URL: https://issues.apache.org/jira/browse/COLLECTIONS-467 Project: Commons Collections Issue Type: New Feature Affects Versions: 3.2 Reporter: l0co Priority: Minor If you use LRUMap with objects that require doing some disposal when they are dropped (eg. close()) and you hold these objects only in LRUMap, you cannot do it with current implementation. I propose to add onRemove() and onAdd() methods to the implementation, so that you can create anonymous inherited class and be able to react to these events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-466) Replace Collection with Iterable where applicable in the API
[
https://issues.apache.org/jira/browse/COLLECTIONS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651810#comment-13651810
]
Thomas Neidhart commented on COLLECTIONS-466:
-
hmm the classes in functor package always use size() on the input collection to
create an array of appropriate length. We could iterate over the elements, put
them into a list and then convert the list to an array, but I am not sure if it
is worth the effort.
> Replace Collection with Iterable where applicable in the API
>
>
> Key: COLLECTIONS-466
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-466
> Project: Commons Collections
> Issue Type: Improvement
>Reporter: Thomas Neidhart
> Fix For: 4.0
>
>
> There are still several places in the API which take a Collection as input
> but could be much more useful if replaced with an Iterable.
> Examples:
> * many of the functor classes have a static factory method to add a
> collection of predicates:
> {noformat}
>public static Predicate anyPredicate(final Collection Predicate> predicates)
>
>should better be
>public static Predicate anyPredicate(final Iterable Predicate> predicates) {
> {noformat}
> * CollectionUtils: forAllDo, collate, select ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-466) Replace Collection with Iterable where applicable in the API
[
https://issues.apache.org/jira/browse/COLLECTIONS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651807#comment-13651807
]
Thomas Neidhart commented on COLLECTIONS-466:
-
Replaced MapUtils.populateMap in r1480230.
> Replace Collection with Iterable where applicable in the API
>
>
> Key: COLLECTIONS-466
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-466
> Project: Commons Collections
> Issue Type: Improvement
>Reporter: Thomas Neidhart
> Fix For: 4.0
>
>
> There are still several places in the API which take a Collection as input
> but could be much more useful if replaced with an Iterable.
> Examples:
> * many of the functor classes have a static factory method to add a
> collection of predicates:
> {noformat}
>public static Predicate anyPredicate(final Collection Predicate> predicates)
>
>should better be
>public static Predicate anyPredicate(final Iterable Predicate> predicates) {
> {noformat}
> * CollectionUtils: forAllDo, collate, select ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-140) isBase64 returns true for any UTF8 string
[
https://issues.apache.org/jira/browse/CODEC-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651805#comment-13651805
]
Sebb commented on CODEC-140:
Adding further validation to check the length etc would change the behaviour of
the method, which is currently clearly documented to only check for valid
characters in the Base64 alphabet.
Not sure it's worth creating 3 other methods to add this extra validation.
> isBase64 returns true for any UTF8 string
> -
>
> Key: CODEC-140
> URL: https://issues.apache.org/jira/browse/CODEC-140
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: windows/linux
>Reporter: Mohit Anchlia
>Assignee: Julius Davies
>
> I just called Base64.isBase64("Hello") for instance and it returns true. I
> thought it would return true only if it is valid base64 encoded string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-354) Add Collection utils from MINA: e.g. CopyOnWriteMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651795#comment-13651795 ] Thomas Neidhart commented on COLLECTIONS-354: - After some second thoughts, this addition may not be useful anymore with the availability of ConcurrentHashMap in the JDK. Also the mina project seems to have removed this class. > Add Collection utils from MINA: e.g. CopyOnWriteMap > --- > > Key: COLLECTIONS-354 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-354 > Project: Commons Collections > Issue Type: New Feature > Components: Map >Reporter: Sebb > Fix For: 4.x > > > MINA has some useful Collection utilities, for example CopyOnWriteMap. > http://svn.apache.org/repos/asf/mina/trunk/core/src/main/java/org/apache/mina/util/CopyOnWriteMap.java > Several of the other utilities look useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-448) [PATCH] Proposal for addinig random pick methods to Bags
[ https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651793#comment-13651793 ] Thomas Neidhart commented on COLLECTIONS-448: - Link to the discussion on the mailinglist http://markmail.org/message/slja55jfia4o3jzr > [PATCH] Proposal for addinig random pick methods to Bags > > > Key: COLLECTIONS-448 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-448 > Project: Commons Collections > Issue Type: Wish > Components: Bag >Affects Versions: 4.0 >Reporter: Othmen Tiliouine >Priority: Minor > Labels: patch > Fix For: 4.x > > Attachments: pickFromABag2.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > Hello, > This is a patch to add two methods to Bag interface and classes > public E pick(); > public E pickAndRemit(); > as discussed in this mail. > - > http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E > I just saw the Bag interface and its implementations, I'm surprised that Bag > (and none of these implementations) expose the method > public T pick() and public T pickAndRemit() (pick a random element) > The Bag object we see in nature, it is mainly used to this, that's why it is > widely used in the probability that when I met 2 white balls and one black, > when I draw a ball randomly I have 2 times more likely to have a white ball > I think that if this caracteristic exists it would be very valuable. > -- > these methods pick a random element from the bag, The probability of picking > a copy of a given element is proportional to the number of copies of this > element in the bag. > the diference between pick() and pickAndRemit() is that with pick() the > picked element is removed from the bag. > this is my first contribution on open source project > if you accept to add this feature to bags and validate my patch i will > propose one other patch to add this methods > public Iterator pick(int n); //pick random n element (with remove) > public Iterator pickAndRemit(int n) ; //pick random n element (without > remove) > -Question : should i regenerate the serialVersionUID of classes that i have > changed ? > Othmen Tiliouine -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COMPRESS-111) support for lzma files
[ https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651683#comment-13651683 ] Damjan Jovanovic edited comment on COMPRESS-111 at 5/8/13 7:42 AM: --- Compared to the normal way of extracting a file from an archive (read->decompress->write), the temp-file solution requires read->decompress->write-temp->read-temp->write, increasing I/O time proportionally to the size of the decompressed file (ie. at least doubling it), which is why I didn't even consider it. It seems like LZMA2 breaks up the stream to be compressed into blocks, and can (de)compress the blocks independently of each other (which has the benefit of allowing fast, multi-threaded decompression). In Lasse's code, LZMA2InputStream uses O\(n) memory per block in the method RangeDecoder.prepareInputBuffer() called from LZMA2InputStream.decodeChunkHeader(). For LZMA however, the "block" is the entire file. Luckily it seems pretty easy to patch RangeDecoder to read incrementally. LZMA2InputStream probably has to also be modified, as I don't think LZMA has a chunk header. I don't know what else may be necessary. Oh and even if LZMA is a legacy format, we still need it for reading .7z files, which always use LZMA for header compression (which is enabled by default). was (Author: damjan): Compared to the normal way of extracting a file from an archive (read->decompress->write), the temp-file solution requires read->decompress->write-temp->read-temp->write, increasing I/O time proportionally to the size of the decompressed file (ie. at least doubling it), which is why I didn't even consider it. It seems like LZMA2 breaks up the stream to be compressed into blocks, and can (de)compress the blocks independently of each other (which has the benefit of allowing fast, multi-threaded decompression). In Lasse's code, LZMA2InputStream uses O(n) memory per block in the method RangeDecoder.prepareInputBuffer() called from LZMA2InputStream.decodeChunkHeader(). For LZMA however, the "block" is the entire file. Luckily it seems pretty easy to patch RangeDecoder to read incrementally. LZMA2InputStream probably has to also be modified, as I don't think LZMA has a chunk header. I don't know what else may be necessary. Oh and even if LZMA is a legacy format, we still need it for reading .7z files, which always use LZMA for header compression (which is enabled by default). > support for lzma files > -- > > Key: COMPRESS-111 > URL: https://issues.apache.org/jira/browse/COMPRESS-111 > Project: Commons Compress > Issue Type: New Feature > Components: Compressors >Affects Versions: 1.0 >Reporter: maurel jean francois > Attachments: compress-trunk-lzmaRev0.patch, > compress-trunk-lzmaRev1.patch > > > adding support for compressing and decompressing of files with LZMA algoritm > (Lempel-Ziv-Markov chain-Algorithm) > (see > http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-111) support for lzma files
[ https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651683#comment-13651683 ] Damjan Jovanovic commented on COMPRESS-111: --- Compared to the normal way of extracting a file from an archive (read->decompress->write), the temp-file solution requires read->decompress->write-temp->read-temp->write, increasing I/O time proportionally to the size of the decompressed file (ie. at least doubling it), which is why I didn't even consider it. It seems like LZMA2 breaks up the stream to be compressed into blocks, and can (de)compress the blocks independently of each other (which has the benefit of allowing fast, multi-threaded decompression). In Lasse's code, LZMA2InputStream uses O(n) memory per block in the method RangeDecoder.prepareInputBuffer() called from LZMA2InputStream.decodeChunkHeader(). For LZMA however, the "block" is the entire file. Luckily it seems pretty easy to patch RangeDecoder to read incrementally. LZMA2InputStream probably has to also be modified, as I don't think LZMA has a chunk header. I don't know what else may be necessary. Oh and even if LZMA is a legacy format, we still need it for reading .7z files, which always use LZMA for header compression (which is enabled by default). > support for lzma files > -- > > Key: COMPRESS-111 > URL: https://issues.apache.org/jira/browse/COMPRESS-111 > Project: Commons Compress > Issue Type: New Feature > Components: Compressors >Affects Versions: 1.0 >Reporter: maurel jean francois > Attachments: compress-trunk-lzmaRev0.patch, > compress-trunk-lzmaRev1.patch > > > adding support for compressing and decompressing of files with LZMA algoritm > (Lempel-Ziv-Markov chain-Algorithm) > (see > http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
