[
https://issues.apache.org/jira/browse/MATH-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15075905#comment-15075905
]
Rostislav Krasny commented on MATH-1307:
----------------------------------------
{quote}> Zero length must be considered correct as well.
>
It is a possibility; not a must IMHO. I wouldn't mind changing it if others
agree that a no-op call should not be guarded against as a probable bug.{quote}
I strongly believe this restriction would make only troubles to CM users. Many
of them would need to do the same check by themselfs just because CM is trying
to be a nanny and not because they will have a bug otherwise. This is just
wrong and will annoy.
{quote}Are you sure?
I usually leave such considerations to the JIT compiler in favour of
self-documenting code.{quote}
Yes and it's simple to check. Just call each of the following methods and see
after how much recursion calls each of them produces a StackOverflowError.
{code:java} private static void recursion1(int n) {
System.out.println(n++);
recursion1(n);
}
private static void recursion2(int n) {
final long n01 = 1;
final long n02 = 1;
final long n03 = 1;
final long n04 = 1;
final long n05 = 1;
final long n06 = 1;
final long n07 = 1;
final long n08 = 1;
final long n09 = 1;
final long n11 = 1;
final long n12 = 1;
final long n13 = 1;
final long n14 = 1;
final long n15 = 1;
final long n16 = 1;
final long n17 = 1;
final long n18 = 1;
final long n19 = 1;
final long n20 = 1;
System.out.println(n++);
recursion2(n);
}
{code}
{quote}About "start" as a parameter name, see our "o.a.c.m.util.MathArrays"
class...{quote}
Interesting. It has {{shuffle()}} methods with both start and position
parameters, where position is an enum.
> 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,
> BaseRandomGeneratorFloatGenerationPerformanceTest.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.
> *Update:* {{AbstractRandomGenerator}} and {{BitsStreamGenerator}} are both
> obsoleted by the class proposed in this report.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
