git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rng] Uniform big integers


Hi.

On Fri, 21 Dec 2018 16:04:05 +0000, Bernd Eckenfels wrote:
Hello,

The actual discussion on the OpenJDK list turned out to be a wrong
understanding and the simple case of generating random bytes was
enough for BigInteger.

However regarding RNG I can open requests, one would be for a
RandomAdapter and the other would be to add a factory method for
BigInteger (and possibly BigDecimal) to the Random Providers. (Or did.
You mean only the Adapter?)

I actually meant testing whether the bug you mentioned could
be seen with an RNG other than "java.util.Random". But since
(IIUC) there is no bug...

Adapter/Bridge cannot fulfill all the functionality of "Random"
(e.g., there is, intentionally, no "setSeed" method).
It's a can of worms/issues with no decent workaround.[1]
So better leave that to application developers: The bridge itself
is trivial[2]; then they must be aware of what to implement,
depending on what the code (to which they pass the adapter) is
doing with it.

Generating "BigInteger" is at a level higher than the rest of the
core API (i.e. "UniformRandomProvider"), which is meant to generate
primitive types.[3]
At first sight, I'd put that functionality in another module.

Regards,
Gilles

[1] http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
[2] We might insert a paragraph about this in the userguide, and/or
    provide the code snippet in the "commons-rng-examples" module.
[3] http://commons.apache.org/proper/commons-rng/commons-rng-client-api/apidocs/org/apache/commons/rng/RestorableUniformRandomProvider.html


Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
Gesendet: Freitag, Dezember 21, 2018 4:43 PM
An: dev@xxxxxxxxxxxxxxxxxx
Betreff: Re: [rng] Uniform big integers

On Thu, 20 Dec 2018 17:30:44 +0100, Gilles wrote:
Hi.

On Thu, 20 Dec 2018 15:15:55 +0000, Bernd Eckenfels wrote:
Hello,

I don’t know what the usecase is, it is motivated by a Bug about
BigInteger(num, Random). I guess one of the users is actually the
crypto usecase (starting with random numbers to find primes).

I wanted to check how RNG deals with this

You can do it by defining a bridge from [RNG] "UniformRandomProvider"
to "java.util.Random":
--- CUT (untested) ---
public class BridgeToRandom extends Random {
private final UniformRandomProvider delegate;

public BridgeToRandom(UniformRandomProvider rng) {
delegate = rng;
}

@Override
protected int next(int unused) {
return rng.nextInt();
}
}
---CUT---

Then, you can test all the generators implemented in [RNG].

FTR: In case you don't pursue it, please file a report on JIRA
to keep track of this if we want to explore how it could extend
the test suite.

Thanks,
Gilles


(since the additional need
for generating a random bitlength looks unfamiliar but logical to
me).
Is it really not enough to fill all bits randomly (especially for
the
case where it is a 0 .. 2^n range only)?

Discussion is here:


http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057594.html

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@xxxxxxxxxxxxxxxxxx
Betreff: Re: [rng](site) broken source(current) link

Hi.

On Thu, 20 Dec 2018 12:43:51 +0000, Bernd Eckenfels wrote:
I wanted to check if RNG can construct uniformly distributed
BigIntegers and how it is doing it (answer: it doesn’t)

It could be a feature request.
[I guess that you mean "within a given range".]

Being curious: What's the use-case for random "BigInteger"s?

while doing so
I noticed that the site link to the source is broken, maybe this is
due to git-wip migration?

Yes.
Thanks; fixed now.


BTW: http://cr.openjdk.java.net/~bpb/8146153/webrev.01/index.html


Regards,
Gilles


Gruss
Bernd
--
http://bernd.eckenfels.net




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx