On Friday, 20 June 2014 at 18:15:49 UTC, Nick Sabalausky wrote:
I'm on the fence:
Pro: Upgrade paths and backwards compatibility are great,
especially for Phobos.
Con: If any semantics are changed (default ref/value passing is
the only one that comes to mind), then maybe it would mask
Joseph Rushton Wakeling:
Anyway, here's my thinking behind the opCall idea. One of the
major shifts of the move to classes is that, suddenly, all of
these entities have to be explicitly allocated.
So creating a random number generator can't be @nogc?
Bye,
bearophile
On Sunday, 13 July 2014 at 15:31:51 UTC, bearophile wrote:
Joseph Rushton Wakeling:
Anyway, here's my thinking behind the opCall idea. One of the
major shifts of the move to classes is that, suddenly, all of
these entities have to be explicitly allocated.
So creating a random number
On Sunday, 13 July 2014 at 15:31:51 UTC, bearophile wrote:
So creating a random number generator can't be @nogc?
I think even as things are there is nothing stopping the user
from manually allocating and using emplace to create an RNG
instance without relying on the GC. However, even if
On Sunday, 13 July 2014 at 15:34:31 UTC, Dicebot wrote:
std.typecons.scoped _should_ still work - I actually suggest
adding unit tests for this as it is quite an important use case.
std.typecons.scoped works per se (I'm adding unittests as we
speak) but using my current dmd, this:
//
On Sunday, 13 July 2014 at 16:01:11 UTC, Joseph Rushton Wakeling
wrote:
Is this possibly an issue with 'scoped'? Was it only quite
recently patched to support @nogc? I'll update my installed
compiler if so.
Quite likely it has not been updated to @nogc at all - which
makes scoped kind of
Joseph Rushton Wakeling:
What really matters to me is stuff like Sample and Cover, where
we can readily expect that they may be called in inner loops of
the program, and so having lots of allocations via new would
be a big problem. So, it follows that the current helper
functions (sample,
On Sunday, 13 July 2014 at 16:12:16 UTC, Dicebot wrote:
Quite likely it has not been updated to @nogc at all - which
makes scoped kind of joke if it is true :)
Seems to be the case, looking at current scoped() code in Phobos
(I just updated my dmd/druntime/phobos install:-)
BTW I note that
On Sunday, 13 July 2014 at 16:20:12 UTC, Joseph Rushton Wakeling
wrote:
I'm guessing the reason it doesn't in this case is because it's
all wrapped up in the scoped() template
... no, it's because the private Scoped_store is passed out via
the Scoped_payload property.
Anyway, the actual
On Sunday, 13 July 2014 at 16:24:29 UTC, bearophile wrote:
Even if the 1.0.0 release of std.random2 is not much @nogc, in
my opinion it needs to have an API designed to allow it to be
retrofitted cleanly and nicely for @nogc usages too.
Completely agree. Incidentally the library is intended
On Sunday, 13 July 2014 at 16:29:11 UTC, Joseph Rushton Wakeling
wrote:
Anyway, the actual scoped() method itself is templated, so
whether it can be @nogc or not obviously depends on its
arguments and has to be inferred.
Hmm, I tried patching up what I could of the Scoped struct's
methods to
On Sunday, 13 July 2014 at 15:34:31 UTC, Dicebot wrote:
std.typecons.scoped _should_ still work - I actually suggest
adding unit tests for this as it is quite an important use case.
Unittest at least for scoped _without_ @nogc:
On Thursday, 19 June 2014 at 21:27:17 UTC, Joseph Rushton
Wakeling wrote:
I realized that it ought to be possible to allow a more direct
drop-in replacement for std.random by adding static opCalls to
the classes which were previously structs.
Thoughts on this, in favour, against ... ?
I'd
On 6/19/2014 5:27 PM, Joseph Rushton Wakeling wrote:
I realized that it ought to be possible to allow a more direct drop-in
replacement for std.random by adding static opCalls to the classes which
were previously structs.
Thoughts on this, in favour, against ... ?
I'm on the fence:
Pro:
On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling
wrote:
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
On Wednesday, 11 June 2014 at 16:35:31 UTC, Kagamin wrote:
In some scenarios impredictability is not enough. For example,
when you generate a session id, an attacker doesn't have to
predict it ahead of time, he can guess it at any time later.
And if they listen to radio waves - that's an open
On Wednesday, 11 June 2014 at 06:41:34 UTC, Joseph Rushton
Wakeling wrote:
Done :) ... if I get a response, I'll make sure to incorporate
everything said.
Great, let me know how that goes. :-)
Well, the ultimate conclusion of the conversation with the guy is
that:
1. ISAAC probably isn't
On Thursday, 12 June 2014 at 08:49:45 UTC, Chris Cain wrote:
Well, the ultimate conclusion of the conversation with the guy
is that:
1. ISAAC probably isn't cryptographically secure. Despite not
having found any attacks, it just isn't proof of security. It's
not been looked at enough to really
On 6/12/2014 4:49 AM, Chris Cain wrote:
Also, it has suggestions for entropy on
Windows (CryptGenRandom) which is something that will be necessary as well.
It should be RtlGenRandom: It's used by CryptGenRandom, it
loads/requires/involves far less unnecessary cruft, and it's
On Thursday, 12 June 2014 at 17:35:39 UTC, Nick Sabalausky wrote:
Naturally, it doesn't yet exist in hap.random because, as
Joseph said, hap.random's step one is to match the current
std.random as closely as possible. I'd be happy to put together
a PR to adapt my RNG stuff above to hap.random
On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling
wrote:
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
On Thursday, 12 June 2014 at 21:51:28 UTC, Joseph Rushton
Wakeling wrote:
A few things I'd really like to hear back on, if anyone can
give them a go:
... obviously I have tested the above myself, but Works for me
is not a valid quality control strategy ;-)
The other thing I'd really like to
On Tuesday, 10 June 2014 at 23:08:33 UTC, Chris Cain wrote:
I had an opportunity to give the entire code a good once over
read and I have a few comments.
Thanks! :-)
1. Biggest thing about the new hap.random is how much nicer it
is to actually READ. The first few times I went through the
On Tuesday, 10 June 2014 at 23:48:09 UTC, bearophile wrote:
Please stop, I am not worth that, and I don't even know how
much good that generator is. So for you it's better to focus on
more important matters of the new random module. Extra
generators can be added later if needed.
After all
On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling
wrote:
Hello all,
Incidentally, would it be a good idea to post a link to the blog
post on r/programming? Haven't done so yet, as generally I
prefer to leave decisions about D publicity to others, but can do
so if people would
On 6/10/2014 7:08 PM, Chris Cain wrote:
3. I'd also REALLY like to see seed support ranges/values giving ANY
type of integer and guarantee that few bytes are wasted (so, if it
supplies 64-bit ints and the generator's internal state array only
accepts 32-bit ints, it should spread the 64-bit int
On 6/11/2014 2:41 AM, Joseph Rushton Wakeling wrote:
5. Another possible improvement would be something akin to a remix
function. It should work identically to reseeding, but instead of
setting the internal state to match the seed (as I see in
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
Have you any plan to implement CMWC?
http://en.wikipedia.org/wiki/Multiply-with-carry#Complementary-multiply-with-carry_generators
On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling
wrote:
Hello all,
Some of you may remember my earlier draft of a class-based
std.random
On Wednesday, 11 June 2014 at 07:42:10 UTC, Andrea Fontana wrote:
Have you any plan to implement CMWC?
http://en.wikipedia.org/wiki/Multiply-with-carry#Complementary-multiply-with-carry_generators
I hadn't made any concrete plans about that particular family of
generators (my impression was
On Tuesday, 10 June 2014 at 10:57:32 UTC, bearophile wrote:
Kagamin:
Pass it by reference, I see no reason why MT can't be pure.
I meant strongly pure :-)
I'm afraid, this pure rng pattern precludes all pure
optimizations, so it's effectively weakly pure.
On Tuesday, 10 June 2014 at 23:08:33 UTC, Chris Cain wrote:
4. I'd just like to say the idea of using ranges for seeds gets
me giddy because I could totally see a range that queries
https://random.org for true random bits to seed with, wrapped
by a range that zeroes out the memory on popFront.
On 6/11/2014 12:35 PM, Kagamin wrote:
In some scenarios impredictability is not enough. For example, when you
generate a session id, an attacker doesn't have to predict it ahead of
time, he can guess it at any time later. And if they listen to radio
waves - that's an open protocol, an attacker
On Wednesday, 11 June 2014 at 07:24:11 UTC, Chris Cain wrote:
I almost always like all the D posts I see on r/programming,
but in general if any language highlighted the efforts in the
RNG part of the standard library, I would like it. Too many
languages get it wrong or don't care enough about
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
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
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
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
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
On Tuesday, 10 June 2014 at 10:37:17 UTC, Kagamin wrote:
Pass it by reference, I see no reason why MT can't be pure.
For what it's worth, the Mersenne Twister in hap.random is
already weakly pure (.front and .popFront are both pure methods).
On Tuesday, 10 June 2014 at 11:32:54 UTC, bearophile wrote:
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?
Joseph Rushton Wakeling:
Forgive me if I'm missing something obvious, but as it stands I
don't see how the R250/521 algorithm you pointed me to can be
strongly pure.
Sorry, the R250/521 idea and the strongly pure idea are unrelated
to each other.
but wouldn't that be a memory allocation
On Tuesday, 10 June 2014 at 21:02:54 UTC, bearophile wrote:
Sorry, the R250/521 idea and the strongly pure idea are
unrelated to each other.
Ah, good. That makes things simpler. I'll implement R250/521
for you, though.
For the strongly pure random generator we should choose a
generator
Hey again Joe,
I had an opportunity to give the entire code a good once over
read and I have a few comments.
1. Biggest thing about the new hap.random is how much nicer it is
to actually READ. The first few times I went through the current
std.random, I remember basically running out of
Joseph Rushton Wakeling:
I'll implement R250/521 for you, though.
Please stop, I am not worth that, and I don't even know how much
good that generator is. So for you it's better to focus on more
important matters of the new random module. Extra generators can
be added later if needed.
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
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
49 matches
Mail list logo
