[
https://issues.apache.org/jira/browse/MATH-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15071691#comment-15071691
]
Rostislav Krasny commented on MATH-1306:
----------------------------------------
{quote}Discussions on whether to add a feature must happen on the "dev" ML.
Then a report is opened on the tracking system.
Discussion here are more related to implementation details.{quote}
Ok. I will send an email there.
{quote}Why do you put the "subArray" allocation inside the loop?{quote}
Because this is one of the sings one needs to do when the second signature of
nextBytes() isn't awailable.
Do you have another way to benchmark its performance? Memory allocation takes
time and in Java it also initialize the memory with the default object values
that also takes time. After this temporary byte array is used and forgotten it
needs to be freed by the garbage collector. This also takes the computer
resources. I thought all this is obvious and so didn't provide any benchmark in
the beginning. Now we have benchmark implementation/methodology dispute. Why
this benchmark is so important? Isn't the performance and memory impact just
obvious? Also think about the user code that uses nextBytes(). If the second
signature of the nextBytes() method is available the user code could also be
simpler.
{quote}Could you please attach the Java files of the benchmark?{quote}
The test code I already showed. Do you mean a code of the MersenneTwister1305
and MersenneTwister1306 classes? As I told above these are classes that extend
MersenneTwister of CM 3.5 and override/add the nextByte() methods according to
MATH-1305 commit and the code proposed in this ticket. I will attach these
classes.
> 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
>
> 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 & 0x7ffffffc);
> // 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)
