Hello all,

Some of you may remember my earlier draft of a class-based std.random successor:
http://forum.dlang.org/thread/cyytvhixkqlbwkmiugex@forum.dlang.org

Following revisions made in response to feedback, and some further development, I decided that it would be best to release the results as a dub package with a new library name:
http://code.dlang.org/packages/hap

Source code and documentation is available here:
https://github.com/WebDrake/hap
http://code.braingam.es/hap/random/

I've also written a blog post describing new features and the motivations behind this library:
http://braingam.es/2014/06/hap-random-a-new-random-number-library-for-d/

I think that hap.random fixes certain fundamental design issues with std.random.  However, this needs to be put to the test "in the wild", so I'd really appreciate it if as many people as possible could try it out with their code, and report on the experience:

   * Does it run faster, slower, etc?

   * Do any undesirable memory allocation issues arise?

   * Is the API (broadly similar but not identical to std.random)
     pleasant to use?

If it proves to be effective for everyone, then I will begin the process of submission as a new Phobos module.

Thanks in advance for all testing and feedback.

Best wishes,

    -- Joe

On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling wrote:
> I've also written a blog post describing new features and the motivations behind this library:
> http://braingam.es/2014/06/hap-random-a-new-random-number-library-for-d/
>
> I think that hap.random fixes certain fundamental design issues with std.random.  However, this needs to be put to the test "in the wild", so I'd really appreciate it if as many people as possible could try it out with their code, and report on the experience:
>
>    * Does it run faster, slower, etc?
>
>    * Do any undesirable memory allocation issues arise?
>
>    * Is the API (broadly similar but not identical to std.random)
>      pleasant to use?

It definitely looks interesting.  The 64bit MT is definitely something I'm after.  I have a particularly strange need with PRNGs though.  I need to easily make a bunch of child RNGs based off a master RNG.  Nothing cryptographic about it but solely to make reasoning about generating random maps and worlds easier.  That way changing one part of the algorithm (say city placement) doesn't affect how the map itself is generated, or vice-versa.  It sounds like the reference types here would actually make my life much easier since I'd need to pass in RNGs into each section of the generation and would let me be a bit looser with how carefully i have to control access to them which is a good thing.

On Monday, 9 June 2014 at 18:51:53 UTC, Ryan Voots wrote:
> It definitely looks interesting.  The 64bit MT is definitely something I'm after.  I have a particularly strange need with PRNGs though.  I need to easily make a bunch of child RNGs based off a master RNG.  Nothing cryptographic about it but solely to make reasoning about generating random maps and worlds easier.  That way changing one part of the algorithm (say city placement) doesn't affect how the map itself is generated, or vice-versa.  It sounds like the reference types here would actually make my life much easier since I'd need to pass in RNGs into each section of the generation and would let me be a bit looser with how carefully i have to control access to them which is a good thing.

Sounds interesting -- I seem to recall we had some discussion
about this a while back ... ?  Anyway, glad to hear that the
library may be useful for you.  Let me know how you get on! :-)

Awesome! I'll definitely check this out :)

Would there be any chance of additional contributions, such as an ISAAC RNG implementation, being accepted? I wouldn't go as far as to guarantee it for crypto purposes, but I've been messing around with an implementation recently and wouldn't mind porting it over to D (it's based on the public domain implementation found on this website: http://burtleburtle.net/bob/rand/isaacafa.html )

So far the numbers it puts out appear to be pretty good from my observations, PLUS it's really fast for a large number of outputs (it costs a lot up-front, however).

I also have a variation of "ISAAC+" as described by the paper here: http://eprint.iacr.org/2006/438.pdf

The problem I have with "ISAAC+", though, is that the paper incorrectly describes the original ISAAC algorithm (Algorithm 1.1 fails to `xor a` at line 6) so it's unclear whether the paper actually solves a problem. Furthermore, I'd really prefer to keep that xor regardless (because it may have simply been an oversight but intended) so it's hard (I don't want to) to really call it "ISAAC+" since it is notably different than the paper's description.

That said, it's a paper that comes up often enough in discussions about ISAAC that people suggest a desire for it.

On Tuesday, 10 June 2014 at 06:53:46 UTC, Chris Cain wrote:
> Awesome! I'll definitely check this out :)

Thanks, that would be great!

> Would there be any chance of additional contributions, such as an ISAAC RNG implementation, being accepted? I wouldn't go as far as to guarantee it for crypto purposes, but I've been messing around with an implementation recently and wouldn't mind porting it over to D (it's based on the public domain implementation found on this website: http://burtleburtle.net/bob/rand/isaacafa.html )

Yea, it'd be great to have submissions like this.  I plan on
having a hap.random.crypto as another experimental module (i.e.
not included if you do "import hap.random", copiously labelled as
experimental until it's had a security review, etc.) so
guaranteeing crypto possibilities straight away is not a problem.
  Part of the point of hap is that it gives us a place where we
can get things wrong and correct them. ;-)

I think I'll create a 1.x.x branch for the current release
process and add a crypto module shortly in the ~master branch,
I'll ping you when that's done.

> So far the numbers it puts out appear to be pretty good from my observations, PLUS it's really fast for a large number of outputs (it costs a lot up-front, however).
>
> I also have a variation of "ISAAC+" as described by the paper here: http://eprint.iacr.org/2006/438.pdf
>
> The problem I have with "ISAAC+", though, is that the paper incorrectly describes the original ISAAC algorithm (Algorithm 1.1 fails to `xor a` at line 6) so it's unclear whether the paper actually solves a problem. Furthermore, I'd really prefer to keep that xor regardless (because it may have simply been an oversight but intended) so it's hard (I don't want to) to really call it "ISAAC+" since it is notably different than the paper's description.
>
> That said, it's a paper that comes up often enough in discussions about ISAAC that people suggest a desire for it.

Why not write to the paper's author and ask about it?  It may
seem like a small thing, but they'll probably be grateful for the
interest and feedback.

Joseph Rushton Wakeling:

> Thanks in advance for all testing and feedback.

I have appreciated to use this generator (but I am not yet sure how much good it is. I have seen it's fast and sufficiently good for some of my simpler purposes):
http://en.literateprograms.org/R250/521_%28C%29

------

Is it worth having a fully pure generator that takes a constant state and returns the modified state? (The state should be small, so Mersenne Twister is not fit for this). Writing such generator is easy, but then how do you use it with the API of the functions of the random module?

Bye,
bearophile

Pass it by reference, I see no reason why MT can't be pure.

Kagamin:

> Pass it by reference, I see no reason why MT can't be pure.

I meant strongly pure :-)

Bye,
bearophile

On Tuesday, 10 June 2014 at 10:21:39 UTC, bearophile wrote:
> I have appreciated to use this generator (but I am not yet sure how much good it is. I have seen it's fast and sufficiently good for some of my simpler purposes):
> http://en.literateprograms.org/R250/521_%28C%29

Should be straightforward enough to implement. :-)

> Is it worth having a fully pure generator that takes a constant state and returns the modified state? (The state should be small, so Mersenne Twister is not fit for this). Writing such generator is easy, but then how do you use it with the API of the functions of the random module?

The API as given is of course designed to create ranges of random variates, and that in turn means that you're dealing with weakly pure class methods.

However, I don't see any reason why one couldn't have a strongly pure function that purely transforms state, which could be wrapped by an RNG class or otherwise used as needed.

Joseph Rushton Wakeling:

> However, I don't see any reason why one couldn't have a strongly pure function that purely transforms state, which could be wrapped by an RNG class

So can you can generate random values in strongly pure functions with this? You can allocate the RNG class inside the function... If that's right, then is this simple strongly pure random generator worth adding to std.random2?

Bye,
bearophile