hap.random: a new random number library for D
Chris Cain via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Wed Jun 11 00:15:27 PDT 2014
On Wednesday, 11 June 2014 at 06:41:34 UTC, Joseph Rushton
Wakeling wrote:
> That would be very cool. Can you point me at your code
> examples?
It's written in Nimrod (in a way that someone who learned Nimrod
the day before would write them, because I learned Nimrod the day
before and worked on it for something like 17 hours straight to
produce everything):
https://github.com/Zshazz/Ramrod/blob/master/util.nim
I'd like to make this concept a range in D. Not sure what exactly
to call it but it's an "adaptor." Honestly, I wouldn't be
surprised if something like this didn't already exist in D in
some form, but it didn't seem like Nimrod had anything like it.
> The paranoiac in me feels that anything that involves getting
> random data via HTTPS is probably insecure crypto-wise :-)
Paranoia is good in this case. I appreciate the caution.
> However, I think sourcing random.org is a perfect case for an
> entry in hap.random.device. I think the best thing to do would
> probably be to offer a RandomOrgClient (which offers a very
> thin API around the random.org HTTP API) and then to wrap that
> in a range type that uses the client internally to generate
> random numbers with particular properties.
This sounds like it would be beautiful. As a note, if we expose
this via a part of the standard library, we would have to make
certain that we follow the guidelines outlined on random.org (in
particular, I'm concerned about having an internal locking
mechanism to prevent multiple threads from asking for bits at the
same time because that will cause clients to be banned ... global
state, impurity, and all the nasty things will likely have to be
a natural part of such a thing).
> Also a very interesting suggestion. Is there a standard name
> for this kind of procedure?
I'm not really aware if there is. I remember hearing about the
concept when talking with my cryptography professor awhile back
(it may have even been in a lecture). IIRC, the description used
was "mixing" in entropy, so my first thought is to call it a
mix/remix function.
> Just for clarity, here's how I see things rolling out for the
> future:
>
> * First goal is to ensure the existing codebase "plays nice"
> with
> people's programs and that it works OK with dub, rdmd, etc.
> and
> doesn't have any serious architectural or other bugs. The
> 1.0.0
> release will not have any new functionality compared to
> what is
> in place now.
>
> * Once it seems to be reasonably stable then work can begin
> on a
> 1.x release series that brings in successive pieces of new
> functionality.
I like this procedure. Definitely confidence inspiring.
More information about the Digitalmars-d-announce
mailing list