[
https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15769967#comment-15769967
]
Gilles edited comment on TEXT-36 at 12/22/16 1:14 PM:
------------------------------------------------------
bq. It would be good to hear why people are concerned about a link between TEXT
and RNG.
+1
Indeed, are there technical objections?
There is nothing in favour of using the JDK's {{Random}} class in new
applications (or libraries such as TEXT):
* no speed of generation advantage,
* no quality of randomness advantage,
* no memory consumption advantage.
Over the course of developing what has become Commons RNG, I've made a summary
of [why not to use
{{java.util.Random}}|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html].
The only justification for using it is when applications are required to
reproduce the same sequence as the particular algorithm implemented by
{{Random}} (needless to say: It is not the most obvious case for "randomness").
bq. Is it a fear of Maven jar hell?
This would be bogus, given that we don't release code that could create it (due
to the change of package name and coordinates).
bq. Eat our own dog food
+1
IOW tell the world to come and taste it too. :)
And grow the community...
bq. Users can bridge to java.util.Random using RNG's bridge classes
Not sure what you mean.
[JDKRandomBridge|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/JDKRandomBridge.html]
is a bridge *from* Commons RNG's {{RandomSource}} *to* JDK's {{Random}} (so
not applicable to pass to a TEXT API based on Commons RNG).
A user who would want to use {{Random}} as the underlying generator would
create the corresponding
[{{UniformRandomProvider}}|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/RandomSource.html#JDK].
bq. explicitly offer overloads with java.util.Random.
This is what Gary proposes.
Thus, assuming a {{TextRandomProvider}} interface:
{code}
import java.util.Random;
public class JdkRandomBridge implements TextRandomProvider {
private final Random delegate;
public JdkRandomBridge(Random rng) {
delegate = rng;
}
// TextRandomProvider methods.
/** {@inheritDoc} */
public int nextInt(int min, int max) {
// Generate an integer in range [min, max].
return delegate.nextInt(max + 1) + min;
}
}
{code}
{code}
import org.apache.commons.rng.UniformRandomProvider;
public class CommonsRngBridge implements TextRandomProvider {
private final UniformRandomProvider delegate;
public CommonsRngBridge(UniformRandomProvider rng) {
delegate = rng;
}
// TextRandomProvider methods.
// ...
}
{code}
bq. Offer only java.util.Random in the interface, but shade RNG so that our
internal default implementations are as good as can be.
This does not look good: Users who care about the source of randomness are
stuck with a sub-par algorithm, while users who don't care get a better one...
Moreover, as a general remark, I'm -0 on "hiding" a fundamental parameter of
some functionality (here, the RNG for building _random_ strings).
bq. Don't use RNG at all.
Does not make any sense. ;)
was (Author: erans):
bq. It would be good to hear why people are concerned about a link between TEXT
and RNG.
+1
Indeed, are there technical objections?
There is nothing in favour of using the JDK's {{Random}} class in new
applications (or libraries such as TEXT):
* no speed of generation advantage,
* no quality of randomness advantage,
* no memory consumption advantage.
Over the course of developing what has become Commons RNG, I've made a summary
of [why not to use
{{java.util.Random}}|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html].
The only justification for using it is when applications are required to
reproduce the same sequence as the particular algorithm implemented by
{{Random}} (needless to say: It is not the most obvious case for "randomness").
bq. Is it a fear of Maven jar hell?
This would be bogus, given that we don't release code that could create it (due
to the change of package name and coordinates).
bq. Eat our own dog food
+1
bq. Users can bridge to java.util.Random using RNG's bridge classes
Not sure what you mean.
[JDKRandomBridge|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/JDKRandomBridge.html]
is a bridge *from* Commons RNG's {{RandomSource}} *to* JDK's {{Random}} (so
not applicable to pass to a TEXT API based on Commons RNG).
A user who would want to use {{Random}} as the underlying generator would
create the corresponding
[{{UniformRandomProvider}}|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/RandomSource.html#JDK].
bq. explicitly offer overloads with java.util.Random.
This what Gary proposes.
Thus, assuming a {{TextRandomProvider}} interface:
{code}
import java.util.Random;
public class JdkRandomBridge implements TextRandomProvider {
private final Random delegate;
public JdkRandomBridge(Random rng) {
delegate = rng;
}
// TextRandomProvider methods
}
{code}
{code}
import org.apache.commons.rng.UniformRandomProvider;
public class CommonsRngBridge implements TextRandomProvider {
private final UniformRandomProvide delegate;
public CommonsRngBridge(UniformRandomProvider rng) {
delegate = rng;
}
// TextRandomProvider methods
}
{code}
bq. Offer only java.util.Random in the interface, but shade RNG so that our
internal default implementations are as good as can be.
This does not look good: users who want to control the randomness generation
are stuck with a sub-par algorithm, while users who don't care get a better
one...
Moreover, as a general remark, I'm -0 on "hiding" a fundamental parameter of
some functionality (here, the RNG for building _random_ strings).
bq. Don't use RNG at all.
Does not make any sense. ;)
> Dependency on "Commons RNG"
> ---------------------------
>
> Key: TEXT-36
> URL: https://issues.apache.org/jira/browse/TEXT-36
> Project: Commons Text
> Issue Type: Improvement
> Reporter: Gilles
> Labels: api
> Fix For: 1.0
>
>
> This is a follow-up of a
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
> held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api"
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
> of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project
> as a whole) to not advertize or use other Commons components, despite the
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and
> define TEXT's own interface to random numbers, with bridges to it from
> {{UniformRandomProvider}} and from {{java.util.Random}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
