Re: AW: [rng] Uniform big integers
On Sat, 22 Dec 2018 00:51:11 +0100, Bernd Eckenfels wrote:
Hello,
just noticed an adapter is already referenced
(rng.simple.JDKRandomBridge)
Forgot that one; sorry!
Thanks for the reminder; "setSeed" is even supported...
Regards,
Gilles
on the „why not java random“ page. So it
can be used with the BigInteger constructor to generate power-of-two
randoms (already).
I wont request more Features without having a usecase for them.
Thanks for Looking into this.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Samstag, 22. Dezember 2018 00:35
An: dev@commons.apache.org
Betreff: Re: [rng] Uniform big integers
Hi.
On Fri, 21 Dec 2018 16:04:05 +, 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
Gesendet: Freitag, Dezember 21, 2018 4:43 PM
An: dev@commons.apache.org
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 +, 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
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@commons.apache.org
Betreff: Re: [rng](site) broken source(current) link
Hi.
On Thu, 20 Dec 2018 12:43:51 +, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
AW: [rng] Uniform big integers
Hello,
just noticed an adapter is already referenced (rng.simple.JDKRandomBridge) on
the „why not java random“ page. So it can be used with the BigInteger
constructor to generate power-of-two randoms (already).
I wont request more Features without having a usecase for them. Thanks for
Looking into this.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Samstag, 22. Dezember 2018 00:35
An: dev@commons.apache.org
Betreff: Re: [rng] Uniform big integers
Hi.
On Fri, 21 Dec 2018 16:04:05 +, 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
> Gesendet: Freitag, Dezember 21, 2018 4:43 PM
> An: dev@commons.apache.org
> 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 +, 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
>>> Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
>>> An: dev@commons.apache.org
>>> Betreff: Re: [rng](site) broken source(current) link
>>>
>>> Hi.
>>>
>>> On Thu, 20 Dec 2018 12:43:51 +, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] Uniform big integers
Hi.
On Fri, 21 Dec 2018 16:04:05 +, 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
Gesendet: Freitag, Dezember 21, 2018 4:43 PM
An: dev@commons.apache.org
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 +, 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
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@commons.apache.org
Betreff: Re: [rng](site) broken source(current) link
Hi.
On Thu, 20 Dec 2018 12:43:51 +, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Robust file remover, other Windows-specific enhancements
I like that idea. I'll reorganize some code from the Jenkins PR into a one for IO. On Fri, 21 Dec 2018 at 11:51, Gary Gregory wrote: > That could go in Commons IO, sure. > > I would prefer the code to go in a focused class like a DeleteUtils or > DeleteFiles. It might also be neat to make the class instantiable and > configurable instead of having lots of options args. > > Gary > > On Fri, Dec 21, 2018, 09:58 Matt Sicker > > I've been refactoring some IO code in Jenkins lately that are similar to > > the FileUtils delete family of methods. I had originally wanted to > replace > > them with calls to FileUtils, but I noticed that we had a more > > sophisticated strategy for retrying deletes and other workarounds for > > (usually) Windows-specific problems (e.g., you can't delete an open file > in > > Windows; this can be commonly caused by things like virus scanners which > > cause ephemeral errors). > > > > My Jenkins code is here [1], and I was wondering if I could work on > > contributing some of this logic back to commons-io in some way. There may > > also be some useful utilities to include regarding Windows-specific > > symbolic link/directory junction manipulation, too. > > > > [1]: https://github.com/jenkinsci/jenkins/pull/3812 > > > > -- > > Matt Sicker > > > -- Matt Sicker
Re: [IO] Robust file remover, other Windows-specific enhancements
After looking through the open issues and PRs for IO, I don't see anything similar, though there is https://issues.apache.org/jira/browse/IO-295 which may be related to junctions as well. This may also be a nice opportunity to introduce a PathUtils class similar to FileUtils since IO already uses Java 7. On Fri, 21 Dec 2018 at 10:57, Matt Sicker wrote: > I've been refactoring some IO code in Jenkins lately that are similar to > the FileUtils delete family of methods. I had originally wanted to replace > them with calls to FileUtils, but I noticed that we had a more > sophisticated strategy for retrying deletes and other workarounds for > (usually) Windows-specific problems (e.g., you can't delete an open file in > Windows; this can be commonly caused by things like virus scanners which > cause ephemeral errors). > > My Jenkins code is here [1], and I was wondering if I could work on > contributing some of this logic back to commons-io in some way. There may > also be some useful utilities to include regarding Windows-specific > symbolic link/directory junction manipulation, too. > > [1]: https://github.com/jenkinsci/jenkins/pull/3812 > > -- > Matt Sicker > -- Matt Sicker
Re: [IO] Robust file remover, other Windows-specific enhancements
That could go in Commons IO, sure. I would prefer the code to go in a focused class like a DeleteUtils or DeleteFiles. It might also be neat to make the class instantiable and configurable instead of having lots of options args. Gary On Fri, Dec 21, 2018, 09:58 Matt Sicker I've been refactoring some IO code in Jenkins lately that are similar to > the FileUtils delete family of methods. I had originally wanted to replace > them with calls to FileUtils, but I noticed that we had a more > sophisticated strategy for retrying deletes and other workarounds for > (usually) Windows-specific problems (e.g., you can't delete an open file in > Windows; this can be commonly caused by things like virus scanners which > cause ephemeral errors). > > My Jenkins code is here [1], and I was wondering if I could work on > contributing some of this logic back to commons-io in some way. There may > also be some useful utilities to include regarding Windows-specific > symbolic link/directory junction manipulation, too. > > [1]: https://github.com/jenkinsci/jenkins/pull/3812 > > -- > Matt Sicker >
[IO] Robust file remover, other Windows-specific enhancements
I've been refactoring some IO code in Jenkins lately that are similar to the FileUtils delete family of methods. I had originally wanted to replace them with calls to FileUtils, but I noticed that we had a more sophisticated strategy for retrying deletes and other workarounds for (usually) Windows-specific problems (e.g., you can't delete an open file in Windows; this can be commonly caused by things like virus scanners which cause ephemeral errors). My Jenkins code is here [1], and I was wondering if I could work on contributing some of this logic back to commons-io in some way. There may also be some useful utilities to include regarding Windows-specific symbolic link/directory junction manipulation, too. [1]: https://github.com/jenkinsci/jenkins/pull/3812 -- Matt Sicker
Re: [rng] Uniform big integers
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?)
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Freitag, Dezember 21, 2018 4:43 PM
An: dev@commons.apache.org
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 +, 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
>> Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
>> An: dev@commons.apache.org
>> Betreff: Re: [rng](site) broken source(current) link
>>
>> Hi.
>>
>> On Thu, 20 Dec 2018 12:43:51 +, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
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 +, 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
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@commons.apache.org
Betreff: Re: [rng](site) broken source(current) link
Hi.
On Thu, 20 Dec 2018 12:43:51 +, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] mina86 commented on issue #35: Turn CSVRecord into a List
mina86 commented on issue #35: Turn CSVRecord into a List URL: https://github.com/apache/commons-csv/pull/35#issuecomment-449403846 FYI, you can do `StreamSupport.stream(record.splitterator(), false)` to convert CSVRecord into a stream though it’s less efficient in some cases (since the stream is unsized) than if CSVRecord was a List. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
