[jira] [Created] (MATH-1308) Deprecate and remove "AbstractRandomGenerator"
Gilles created MATH-1308:
Summary: Deprecate and remove "AbstractRandomGenerator"
Key: MATH-1308
URL: https://issues.apache.org/jira/browse/MATH-1308
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Minor
Fix For: 4.0, 3.6
While discussing MATH-1307, [~psteitz] suggested to remove the
{{AbstractRandomGenerator}} class (cf. [this
message|http://markmail.org/message/wrbymqx7wgemtcjx]).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MATH-1302) Rotation constructor with RotationOrder and angles produces wrong rotation
[ https://issues.apache.org/jira/browse/MATH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1302. - Resolution: Fixed Two methods, compose and composeInverse have been added. They both allow specifying rotation convention. > Rotation constructor with RotationOrder and angles produces wrong rotation > -- > > Key: MATH-1302 > URL: https://issues.apache.org/jira/browse/MATH-1302 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: James Boyer >Assignee: Luc Maisonobe > Fix For: 3.6 > > Original Estimate: 3h > Remaining Estimate: 3h > > Rotation constructor taking (RotationOrder, double, double, double) has the > local variable "composed" set to an incorrect rotation because the use of r1 > and r3 are swapped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1297) multistep integrator start failure triggers NPE
[
https://issues.apache.org/jira/browse/MATH-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-1297.
-
Resolution: Fixed
Fixed in git repository, both in MATH_3_X and master branches.
> multistep integrator start failure triggers NPE
> ---
>
> Key: MATH-1297
> URL: https://issues.apache.org/jira/browse/MATH-1297
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Luc Maisonobe
>Assignee: Luc Maisonobe
> Fix For: 3.6
>
>
> Multistep ODE integrators like Adams-Bashforth and Adams-Moulton require a
> starter procedure.
> If the starter integrator is not configured properly, it will not create the
> necessary number of initial points and the multistep integrator will not be
> initialized correctly. This results in NullPointErException when the scaling
> array is referenced later on.
> The following test case (with an intentionally wrong starter configuration)
> shows the problem.
> {code}
> @Test
> public void testStartFailure() {
> TestProblem1 pb = new TestProblem1();
> double minStep = 0.0001 * (pb.getFinalTime() - pb.getInitialTime());
> double maxStep = pb.getFinalTime() - pb.getInitialTime();
> double scalAbsoluteTolerance = 1.0e-6;
> double scalRelativeTolerance = 1.0e-7;
> MultistepIntegrator integ =
> new AdamsBashforthIntegrator(4, minStep, maxStep,
>
> scalAbsoluteTolerance,
>
> scalRelativeTolerance);
> integ.setStarterIntegrator(new DormandPrince853Integrator(0.2 *
> (pb.getFinalTime() - pb.getInitialTime()),
>
> pb.getFinalTime() - pb.getInitialTime(),
> 0.1, 0.1));
> TestProblemHandler handler = new TestProblemHandler(pb, integ);
> integ.addStepHandler(handler);
> integ.integrate(pb,
> pb.getInitialTime(), pb.getInitialState(),
> pb.getFinalTime(), new
> double[pb.getDimension()]);
> }
> {code}
> Failure to start the integrator should be detected and an appropriate
> exception should be triggered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1306) Add public void nextBytes(byte[] bytes, int position, int length) method into the RandomGenerator interface
[
https://issues.apache.org/jira/browse/MATH-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072260#comment-15072260
]
Rostislav Krasny commented on MATH-1306:
{quote}Since the new feature is about reusing the same array to fill different
regions of it at different times, why not also keep the small array for
reuse?{quote}
This is not about reusing the same array but about having a direct access to
the destination array. And reusing the same intermediate array is not always
possible or practical. But even without temporary array allocation in each loop
iteration the {{System.arraycopy()}} also takes time, although it is a native
method.
{quote}Could you please provide a use-case of such a simplification?{quote}
Cryptography. I had seen a cryptographic software that uses a method with a
signature similar to the proposed.
{quote}I only see that the signature is more complex; the purpose of Commons
Math is not to cover all hypothetical cases.{quote}
This is very common to have methods that works with regions of arrays or
collections. The mentioned here {{System.arraycopy()}} or methods of
{{java.util.Arrays}} class. And I'm sure this list could be much longer.
I just found the proposed nextByte() method signature already exists in
{{gnu.crypto.util.PRNG}} pseudo-random number generator.
[http://www.gnu.org/software/gnu-crypto/manual/api/gnu/crypto/util/PRNG.html]
Also there is a not exact but very similar method signature in
{{RandomData.OneShot}} of javacard
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html]#nextBytes%28byte[],%20short,%20short%29
Apache Tomcat has a tricky method with similar functionality just because
{{java.lang.Random}} doesn't have the proposed method
[https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/tribes/util/UUIDGenerator.html]#nextBytes%28byte[],%20int,%20int,%20java.util.Random%29
So why not to add the proposed method signature into CM as well?
P.S. why URLs with # are not supported by Jira?
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html#nextBytes%28byte[],%20short,%20short%29]
> Add public void nextBytes(byte[] bytes, int position, int length) method into
> the RandomGenerator interface
> ---
>
> Key: MATH-1306
> URL: https://issues.apache.org/jira/browse/MATH-1306
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Rostislav Krasny
> Attachments: MersenneTwister1305.java, MersenneTwister1306.java
>
>
> I propose to add {{public void nextBytes(byte[] bytes, int position, int
> length)}} method into the {{RandomGenerator}} interface.
> Rationality: to improve performance and memory usage in cases when one needs
> to fill only a specified region of a byte array. Today to do that you need to
> use a temporary byte array and copy it by yourself into the specified region
> of the destination byte array.
> I propose the following code, based on the code of {{BitsStreamGenerator}}
> commited in MATH-1305
> {code:java}
> @Override
> public void nextBytes(byte[] bytes) {
> nextBytesFill(bytes, 0, bytes.length);
> }
> // TODO add this method into RandomGenerator interface
> //@Override
> public void nextBytes(byte[] bytes, int position, int length) {
> if (position < 0 || position > bytes.length - 1) {
> throw new
> OutOfRangeException(LocalizedFormats.OUT_OF_RANGE_SIMPLE, position, 0,
> bytes.length - 1);
> }
> if (length < 0 || length > bytes.length - position) {
> throw new
> OutOfRangeException(LocalizedFormats.OUT_OF_RANGE_SIMPLE, length, 0,
> bytes.length - position);
> }
> nextBytesFill(bytes, position, length);
> }
> private void nextBytesFill(byte[] bytes, int position, int length) {
> int index = position;
> // Position plus multiple 4 part of length (i.e. length with
> two least significant bits unset).
> final int indexLoopLimit = position + (length & 0x7ffc);
> // Start filling in the byte array, 4 bytes at a time.
> while (index < indexLoopLimit) {
> final int random = next(32);
> bytes[index++] = (byte) random;
> bytes[index++] = (byte) (random >>> 8);
> bytes[index++] = (byte) (random >>> 16);
> bytes[index++] = (byte) (random >>> 24);
> }
> final int indexLimit = position + length;
>
> // Fill in the remaining bytes.
> if (i
[jira] [Comment Edited] (MATH-1306) Add public void nextBytes(byte[] bytes, int position, int length) method into the RandomGenerator interface
[
https://issues.apache.org/jira/browse/MATH-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072260#comment-15072260
]
Rostislav Krasny edited comment on MATH-1306 at 12/27/15 10:12 PM:
---
{quote}Since the new feature is about reusing the same array to fill different
regions of it at different times, why not also keep the small array for
reuse?{quote}
This is not about reusing the same array but about having a direct access to
the destination array. And reusing the same intermediate array is not always
possible or practical. But even without temporary array allocation in each loop
iteration the {{System.arraycopy()}} also takes time, although it is a native
method.
{quote}Could you please provide a use-case of such a simplification?{quote}
Cryptography. I had seen a cryptographic software that uses a method with a
signature similar to the proposed.
{quote}I only see that the signature is more complex; the purpose of Commons
Math is not to cover all hypothetical cases.{quote}
This is very common to have methods that work with regions of arrays or
collections. The mentioned here {{System.arraycopy()}} or methods of
{{java.util.Arrays}} class. And I'm sure this list could be much longer.
I just found the proposed nextByte() method signature already exists in
{{gnu.crypto.util.PRNG}} pseudo-random number generator.
[http://www.gnu.org/software/gnu-crypto/manual/api/gnu/crypto/util/PRNG.html]
Also there is a not exact but very similar method signature in
{{RandomData.OneShot}} of javacard
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html]#nextBytes%28byte[],%20short,%20short%29
Apache Tomcat has a tricky method with similar functionality just because
{{java.lang.Random}} doesn't have the proposed method
[https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/tribes/util/UUIDGenerator.html]#nextBytes%28byte[],%20int,%20int,%20java.util.Random%29
So why not to add the proposed method signature into CM as well?
P.S. why URLs with # are not supported by Jira?
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html#nextBytes%28byte[],%20short,%20short%29]
was (Author: rosti.bsd):
{quote}Since the new feature is about reusing the same array to fill different
regions of it at different times, why not also keep the small array for
reuse?{quote}
This is not about reusing the same array but about having a direct access to
the destination array. And reusing the same intermediate array is not always
possible or practical. But even without temporary array allocation in each loop
iteration the {{System.arraycopy()}} also takes time, although it is a native
method.
{quote}Could you please provide a use-case of such a simplification?{quote}
Cryptography. I had seen a cryptographic software that uses a method with a
signature similar to the proposed.
{quote}I only see that the signature is more complex; the purpose of Commons
Math is not to cover all hypothetical cases.{quote}
This is very common to have methods that works with regions of arrays or
collections. The mentioned here {{System.arraycopy()}} or methods of
{{java.util.Arrays}} class. And I'm sure this list could be much longer.
I just found the proposed nextByte() method signature already exists in
{{gnu.crypto.util.PRNG}} pseudo-random number generator.
[http://www.gnu.org/software/gnu-crypto/manual/api/gnu/crypto/util/PRNG.html]
Also there is a not exact but very similar method signature in
{{RandomData.OneShot}} of javacard
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html]#nextBytes%28byte[],%20short,%20short%29
Apache Tomcat has a tricky method with similar functionality just because
{{java.lang.Random}} doesn't have the proposed method
[https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/tribes/util/UUIDGenerator.html]#nextBytes%28byte[],%20int,%20int,%20java.util.Random%29
So why not to add the proposed method signature into CM as well?
P.S. why URLs with # are not supported by Jira?
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html#nextBytes%28byte[],%20short,%20short%29]
> Add public void nextBytes(byte[] bytes, int position, int length) method into
> the RandomGenerator interface
> ---
>
> Key: MATH-1306
> URL: https://issues.apache.org/jira/browse/MATH-1306
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Rostislav Krasny
> Attachments: MersenneTwister1305.java, MersenneTwister1306.java
>
>
> I propose to add {{public void nextBytes(byte[] bytes, int position, int
> length)}} method into the {{RandomGenerator}} interface.
>
[jira] [Comment Edited] (MATH-1306) Add public void nextBytes(byte[] bytes, int position, int length) method into the RandomGenerator interface
[
https://issues.apache.org/jira/browse/MATH-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072260#comment-15072260
]
Rostislav Krasny edited comment on MATH-1306 at 12/27/15 10:13 PM:
---
{quote}Since the new feature is about reusing the same array to fill different
regions of it at different times, why not also keep the small array for
reuse?{quote}
This is not about reusing the same array but about having a direct access to
the destination array. And reusing the same intermediate array is not always
possible or practical. But even without temporary array allocation in each loop
iteration the {{System.arraycopy()}} also takes time, although it is a native
method.
{quote}Could you please provide a use-case of such a simplification?{quote}
Cryptography. I had seen a cryptographic software that uses a method with a
signature similar to the proposed.
{quote}I only see that the signature is more complex; the purpose of Commons
Math is not to cover all hypothetical cases.{quote}
This is very common to have methods that work with regions of arrays or
collections. The mentioned here {{System.arraycopy()}} or methods of
{{java.util.Arrays}} class. And I'm sure this list could be much longer.
I just found the proposed nextByte() method signature already exists in
{{gnu.crypto.util.PRNG}} pseudo-random number generator.
[http://www.gnu.org/software/gnu-crypto/manual/api/gnu/crypto/util/PRNG.html]
Also there is a not exact but very similar method signature in
{{RandomData.OneShot}} of javacard
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html]#nextBytes%28byte[],%20short,%20short%29
Apache Tomcat has a tricky method with similar functionality just because
{{java.util.Random}} doesn't have the proposed method
[https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/tribes/util/UUIDGenerator.html]#nextBytes%28byte[],%20int,%20int,%20java.util.Random%29
So why not to add the proposed method signature into CM as well?
P.S. why URLs with # are not supported by Jira?
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html#nextBytes%28byte[],%20short,%20short%29]
was (Author: rosti.bsd):
{quote}Since the new feature is about reusing the same array to fill different
regions of it at different times, why not also keep the small array for
reuse?{quote}
This is not about reusing the same array but about having a direct access to
the destination array. And reusing the same intermediate array is not always
possible or practical. But even without temporary array allocation in each loop
iteration the {{System.arraycopy()}} also takes time, although it is a native
method.
{quote}Could you please provide a use-case of such a simplification?{quote}
Cryptography. I had seen a cryptographic software that uses a method with a
signature similar to the proposed.
{quote}I only see that the signature is more complex; the purpose of Commons
Math is not to cover all hypothetical cases.{quote}
This is very common to have methods that work with regions of arrays or
collections. The mentioned here {{System.arraycopy()}} or methods of
{{java.util.Arrays}} class. And I'm sure this list could be much longer.
I just found the proposed nextByte() method signature already exists in
{{gnu.crypto.util.PRNG}} pseudo-random number generator.
[http://www.gnu.org/software/gnu-crypto/manual/api/gnu/crypto/util/PRNG.html]
Also there is a not exact but very similar method signature in
{{RandomData.OneShot}} of javacard
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html]#nextBytes%28byte[],%20short,%20short%29
Apache Tomcat has a tricky method with similar functionality just because
{{java.lang.Random}} doesn't have the proposed method
[https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/tribes/util/UUIDGenerator.html]#nextBytes%28byte[],%20int,%20int,%20java.util.Random%29
So why not to add the proposed method signature into CM as well?
P.S. why URLs with # are not supported by Jira?
[https://docs.oracle.com/javacard/3.0.5/api/javacard/security/RandomData.OneShot.html#nextBytes%28byte[],%20short,%20short%29]
> Add public void nextBytes(byte[] bytes, int position, int length) method into
> the RandomGenerator interface
> ---
>
> Key: MATH-1306
> URL: https://issues.apache.org/jira/browse/MATH-1306
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Rostislav Krasny
> Attachments: MersenneTwister1305.java, MersenneTwister1306.java
>
>
> I propose to add {{public void nextBytes(byte[] bytes, int position, int
> length)}} method into the {{RandomGenerator}} interface.
> R
[jira] [Commented] (MATH-1301) Create a test class for "JDKRandomGenerator"
[
https://issues.apache.org/jira/browse/MATH-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072267#comment-15072267
]
Gilles commented on MATH-1301:
--
Commit c7f7da754a911302dcaa6935be6fded84e1ac348 makes {{JDKRandomGenerator}}
delegate to (rather than inherit from) {{java.util.Random}}.
> Create a test class for "JDKRandomGenerator"
>
>
> Key: MATH-1301
> URL: https://issues.apache.org/jira/browse/MATH-1301
> Project: Commons Math
> Issue Type: Test
>Reporter: Gilles
>Priority: Minor
> Fix For: 4.0
>
>
> {{JDKRandomGenerator}} has no unit test.
> Creating a test class that inherits from {{RandomGeneratorAbstractTest}} will
> require to handle the exceptions thrown from two of its test methods:
> * testNextIntNeg
> * testNextIntIAE2
> Those expect {{MathIllegalArgumentException}} whereas {{JDKRandomGenerator}}
> would throw {{IllegalArgumentException}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1306) Add public void nextBytes(byte[] bytes, int position, int length) method into the RandomGenerator interface
[
https://issues.apache.org/jira/browse/MATH-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072273#comment-15072273
]
Gilles commented on MATH-1306:
--
bq. So why not to add the proposed method signature into CM as well?
I will since nobody was opposed.
Our local benchmark code did not show significant degradation (nor improvement)
for the baseline case due to the additional method indirection.
See MATH-1307 (which I've linked to this request).
Side note: For the case where only part of a big array is filled (i.e. your
use-case), I have either a ~8% improvement or ~40% degradation wrt the
{{System.arraycopy}} version. Since you seem to like to get top performance,
perhaps you could help figure out whether there are flaws in the benchmarking
code which I'm using.
> Add public void nextBytes(byte[] bytes, int position, int length) method into
> the RandomGenerator interface
> ---
>
> Key: MATH-1306
> URL: https://issues.apache.org/jira/browse/MATH-1306
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Rostislav Krasny
> Attachments: MersenneTwister1305.java, MersenneTwister1306.java
>
>
> I propose to add {{public void nextBytes(byte[] bytes, int position, int
> length)}} method into the {{RandomGenerator}} interface.
> Rationality: to improve performance and memory usage in cases when one needs
> to fill only a specified region of a byte array. Today to do that you need to
> use a temporary byte array and copy it by yourself into the specified region
> of the destination byte array.
> I propose the following code, based on the code of {{BitsStreamGenerator}}
> commited in MATH-1305
> {code:java}
> @Override
> public void nextBytes(byte[] bytes) {
> nextBytesFill(bytes, 0, bytes.length);
> }
> // TODO add this method into RandomGenerator interface
> //@Override
> public void nextBytes(byte[] bytes, int position, int length) {
> if (position < 0 || position > bytes.length - 1) {
> throw new
> OutOfRangeException(LocalizedFormats.OUT_OF_RANGE_SIMPLE, position, 0,
> bytes.length - 1);
> }
> if (length < 0 || length > bytes.length - position) {
> throw new
> OutOfRangeException(LocalizedFormats.OUT_OF_RANGE_SIMPLE, length, 0,
> bytes.length - position);
> }
> nextBytesFill(bytes, position, length);
> }
> private void nextBytesFill(byte[] bytes, int position, int length) {
> int index = position;
> // Position plus multiple 4 part of length (i.e. length with
> two least significant bits unset).
> final int indexLoopLimit = position + (length & 0x7ffc);
> // Start filling in the byte array, 4 bytes at a time.
> while (index < indexLoopLimit) {
> final int random = next(32);
> bytes[index++] = (byte) random;
> bytes[index++] = (byte) (random >>> 8);
> bytes[index++] = (byte) (random >>> 16);
> bytes[index++] = (byte) (random >>> 24);
> }
> final int indexLimit = position + length;
>
> // Fill in the remaining bytes.
> if (index < indexLimit) {
> int random = next(32);
> while (true) {
> bytes[index++] = (byte) random;
> if (index < indexLimit) {
> random >>>= 8;
> } else {
> break;
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MATH-1307) Create a base class for all RNGs
[
https://issues.apache.org/jira/browse/MATH-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1307:
-
Attachment: (was: BaseAbstractRandomGenerator.java)
> Create a base class for all RNGs
>
>
> Key: MATH-1307
> URL: https://issues.apache.org/jira/browse/MATH-1307
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, inheritance
> Fix For: 4.0
>
>
> I proposed to create a base class which the existing abstract classes
> {{AbstractRandomGenerator}} and {{BitsStreamGenerator}} will extend.
> This would allow to define {{nextBytes(byte[])}} at the base class level.
> The code for that method is almost identical in the two hierarchies: they
> only differ in a call to either {{nextInt()}} or {{next(32)}} respectively;
> the latter is however the same as the former, in disguise, and is not subject
> to change given the type of return value.
> As a corollary, the new base class can be the unique place where to add
> utilities such as the one proposed in MATH-1306.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MATH-1307) Create a base class for all RNGs
[
https://issues.apache.org/jira/browse/MATH-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1307:
-
Attachment: BaseRandomGenerator.java
Proposed base class for all RNGs (to replace {{BitsStreamGenerator}}).
The source of randomness is abstract method "int nextInt()".
> Create a base class for all RNGs
>
>
> Key: MATH-1307
> URL: https://issues.apache.org/jira/browse/MATH-1307
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, inheritance
> Fix For: 4.0
>
> Attachments: BaseRandomGenerator.java
>
>
> I proposed to create a base class which the existing abstract classes
> {{AbstractRandomGenerator}} and {{BitsStreamGenerator}} will extend.
> This would allow to define {{nextBytes(byte[])}} at the base class level.
> The code for that method is almost identical in the two hierarchies: they
> only differ in a call to either {{nextInt()}} or {{next(32)}} respectively;
> the latter is however the same as the former, in disguise, and is not subject
> to change given the type of return value.
> As a corollary, the new base class can be the unique place where to add
> utilities such as the one proposed in MATH-1306.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MATH-1309) RNG: public "setSeed" method should not be called from inside the constructor
Gilles created MATH-1309: Summary: RNG: public "setSeed" method should not be called from inside the constructor Key: MATH-1309 URL: https://issues.apache.org/jira/browse/MATH-1309 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 4.0 It is dangerous to call an overridable method from inside a constructor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FILEUPLOAD-270) CLONE - Bug in docs: tmp file delete conditions in "Resource Cleanup" section of "using.html"
loremipsum created FILEUPLOAD-270: - Summary: CLONE - Bug in docs: tmp file delete conditions in "Resource Cleanup" section of "using.html" Key: FILEUPLOAD-270 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-270 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.3 Reporter: loremipsum Priority: Minor Fix For: 1.4 The guide at http://commons.apache.org/proper/commons-fileupload/using.html incorrectly writes: "Such temporary files are deleted automatically, if they are no longer used (more precisely, if the corresponding instance of java.io.File is garbage collected.". (The following affects maven version: http://search.maven.org/#artifactdetails|commons-fileupload|commons-fileupload|1.2.2|jar ) However, the code for org.apache.commons.io.FileCleaningTracker.Tracker.Tracker(...) passes org.apache.commons.fileupload.disk.DiskFileItemFactory.this specified by org.apache.commons.fileupload.disk.DiskFileItemFactory.createItem(String, String, boolean, String) in tracker.track(result.getTempFile(), this), and not java.io.File. I.e. the "using.html" guide must be corrected. The correct (fixed) phrasing is: "Such temporary files are deleted automatically, if they are no longer used (more precisely, if the corresponding instance of org.apache.commons.fileupload.disk.DiskFileItemFactory is garbage collected.". (The following affects maven version: http://search.maven.org/#artifactdetails|commons-fileupload|commons-fileupload|1.3|jar ) However, the code for org.apache.commons.io.FileCleaningTracker.Tracker.Tracker(...) passes DiskFileItem.this specified by org.apache.commons.fileupload.disk.DiskFileItemFactory.createItem(String, String, boolean, String) in DiskFileItem result=[...]; [...]; tracker.track(result.getTempFile(), result), and not java.io.File. I.e. the "using.html" guide must be corrected. The correct (fixed) phrasing is: "Such temporary files are deleted automatically, if they are no longer used (more precisely, if the corresponding instance of org.apache.commons.fileupload.disk.DiskFileItem is garbage collected.". (The following holds for both versions 1.2.2 and 1.3) The correct (fixed) phrasing is: "Such temporary files are deleted automatically, if they are no longer used (more precisely, if the corresponding instance of org.apache.commons.fileupload.disk.DiskFileItem (for commons-fileupload v.1.3) and instance of org.apache.commons.fileupload.disk.DiskFileItemFactory (for commons-fileupload v.1.2.2) is garbage collected.". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1306) Add public void nextBytes(byte[] bytes, int position, int length) method into the RandomGenerator interface
[
https://issues.apache.org/jira/browse/MATH-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072287#comment-15072287
]
Gilles commented on MATH-1306:
--
I changed the precondition checks of {{nextBytes(byte[], int, int)}}, e.g. to
consider it an error to not insert anything (otherwise, a bug could go
unnoticed). Please have a look.
> Add public void nextBytes(byte[] bytes, int position, int length) method into
> the RandomGenerator interface
> ---
>
> Key: MATH-1306
> URL: https://issues.apache.org/jira/browse/MATH-1306
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Rostislav Krasny
> Attachments: MersenneTwister1305.java, MersenneTwister1306.java
>
>
> I propose to add {{public void nextBytes(byte[] bytes, int position, int
> length)}} method into the {{RandomGenerator}} interface.
> Rationality: to improve performance and memory usage in cases when one needs
> to fill only a specified region of a byte array. Today to do that you need to
> use a temporary byte array and copy it by yourself into the specified region
> of the destination byte array.
> I propose the following code, based on the code of {{BitsStreamGenerator}}
> commited in MATH-1305
> {code:java}
> @Override
> public void nextBytes(byte[] bytes) {
> nextBytesFill(bytes, 0, bytes.length);
> }
> // TODO add this method into RandomGenerator interface
> //@Override
> public void nextBytes(byte[] bytes, int position, int length) {
> if (position < 0 || position > bytes.length - 1) {
> throw new
> OutOfRangeException(LocalizedFormats.OUT_OF_RANGE_SIMPLE, position, 0,
> bytes.length - 1);
> }
> if (length < 0 || length > bytes.length - position) {
> throw new
> OutOfRangeException(LocalizedFormats.OUT_OF_RANGE_SIMPLE, length, 0,
> bytes.length - position);
> }
> nextBytesFill(bytes, position, length);
> }
> private void nextBytesFill(byte[] bytes, int position, int length) {
> int index = position;
> // Position plus multiple 4 part of length (i.e. length with
> two least significant bits unset).
> final int indexLoopLimit = position + (length & 0x7ffc);
> // Start filling in the byte array, 4 bytes at a time.
> while (index < indexLoopLimit) {
> final int random = next(32);
> bytes[index++] = (byte) random;
> bytes[index++] = (byte) (random >>> 8);
> bytes[index++] = (byte) (random >>> 16);
> bytes[index++] = (byte) (random >>> 24);
> }
> final int indexLimit = position + length;
>
> // Fill in the remaining bytes.
> if (index < indexLimit) {
> int random = next(32);
> while (true) {
> bytes[index++] = (byte) random;
> if (index < indexLimit) {
> random >>>= 8;
> } else {
> break;
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
