Re: Dconf Hotel?
On 22 February 2014 03:23, Manu turkey...@gmail.com wrote: On 22 February 2014 01:22, Steven Schveighoffer schvei...@yahoo.com wrote: Last year, at the conference, after the sessions everyone met up at the Aloft hotel near Facebook's HQ to have passionate and fruitful discussions about D and I think a lot of good came out of it. As someone who was NOT staying at Aloft (and who was fortunate enough to have a speaker taxiing me around, thanks Ali!), I made it a point to try and stay this year at the location that would allow me to engage in the discussions and just be able to walk to my bed (I was in no shape to drive at least one of those nights, thanks again Ali!). I know that Andrei is now living in the area, and he was the one who picked Aloft. I'm assuming Andrei's house is likely not the new location ;) Where is the hot spot this year going to be? I want to book soon :) Yeah, it was definitely worth staying at the Aloft. I had the feeling last year that it might have been better to make the 'in' spot on the other side of the bay though... people can potentially walk/ride if it's closer to town/transport/trains. Aloft was a bit inconvenient for any without cars and not staying at Aloft. Speaking of which - have you got hotel covered Manu - I always try to be economical and am willing to book a room to share. :)
1st draft of complete class-based std.random successor
Hello all,
As some of you may already know, monarch_dodra and I have spent
quite a lot of time over the last year discussing the state of
std.random. To cut a long story short, there are significant
problems that arise because the current RNGs are value types
rather than reference types. We had quite a lot of back and
forth on different design ideas, with a lot of helpful input from
others in the community, but at the end of the day there are
really only two broad approaches: create structs that implement
reference semantics internally, or use classes. So, as an
exercise, I decided to create a class-based std.random.
The preliminary (but comprehensive) results of this are now
available here:
https://github.com/WebDrake/std.random2
Besides re-implementing random number generators as classes
rather than structs, the new code splits std.random2 into a
package of several different modules:
* std.random2.generator, pseudo-random number generators;
* std.random2.device, non-deterministic random sources;
* std.random2.distribution, random distributions such as
uniform,
normal, etc.;
* std.random2.adaptor, random adaptors such as randomShuffle,
randomSample, etc.
* std.random2.traits, RNG-specific traits such as isUniformRNG
and isSeedable.
A package.d file groups them together so one can still import all
together via import std.random2. I've also taken the liberty
of following the new guideline to place import statements as
locally as possible; it was striking how easy and clean this made
things, and it should be easy to port that particular change back
to std.random.
The new package implements all of the functions, templates and
range objects from std.random except for the old
std.random.uniformDistribution, whose name I have cannibalized
for better purposes. Some have been updated: the
MersenneTwisterEngine has been tweaked to match the corresponding
code from Boost.Random, and this in turn has allowed the
definition of a 64-bit Mersenne Twister (Mt19937_64) and an
alternative 32-bit one (Mt11213b).
There are also a number of entirely new entries.
std.random2.distribution contains not just existing functions
such as dice and uniform, but also range-based random
distribution classes UniformDistribution, NormalDistribution and
DiscreteDistribution; the last of these is effectively a
range-based version of dice, and is based on Chris Cain's
excellent work here:
https://github.com/D-Programming-Language/phobos/pull/1702
The principal weak point in terms of functionality is
std.random2.device, where the implemented random devices (based
on Posix' /std/random and /std/urandom) are really very primitive
and just there to illustrate the principle. However, since their
API is pretty simple (they're just input ranges with min and max
defined) there should be plenty of opportunity to improve and
extend the internals in future. Advice and patches are welcome
for everything, but particularly here :-)
What's become quite apparent in the course of writing this
package is how much more natural it is for ranges implementing
randomness to be class objects. The basic fact that another
range can store a copy of an RNG internally without creating a
copy-by-value is merely the start: for example, in the case of
the class implementation of RandomSample, we no longer need to
have complications like,
@property auto ref front()
{
assert(!empty);
// The first sample point must be determined here to avoid
// having it always correspond to the first element of the
// input. The rest of the sample points are determined
each
// time we call popFront().
if (_skip == Skip.None)
{
initializeFront();
}
return _input.front;
}
that were necessary to avoid bugs like
https://d.puremagic.com/issues/show_bug.cgi?id=7936; because the
class-based implementation copies by reference, we can just
initialize everything in the constructor. Similarly, issues like
https://d.puremagic.com/issues/show_bug.cgi?id=7067 and
https://d.puremagic.com/issues/show_bug.cgi?id=8247 just vanish.
Obvious caveats about the approach include the fact that classes
need to be new'd, and questions over whether allocation on the
heap might create speed issues. The benchmarks I've run (code
available in the repo) seem to suggest that at least the latter
is not a worry, but these are obviously things that need to be
considered. My own feeling is that ultimately it is a
responsibility of the language to offer nice ways to allocate
classes without necessarily relying on new or the GC.
A few remarks on design and other factors:
* The new range objects have been implemented as final classes
for
speed purposes. However, I tried another approach where the
RNG
class templates were abstract classes, and the individual
parameterizations were
Re: 1st draft of complete class-based std.random successor
Out of interest but, shouldn't in the device module have a static assert(0, Not implemented yet) type of deal with the version(Posix) block?
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: Few first comments: * std.random2.adaptor, random adaptors such as randomShuffle, randomSample, etc. Please don't use stuttering names like std.random2.randomShuffle. std.random2.shuffle is enough. My own feeling is that ultimately it is a responsibility of the language to offer nice ways to allocate classes without necessarily relying on new or the GC. I don't think the language is yet there. So I think currently this is not a good idea. Do you have a simple but very fast function that generates uniforms in [0.0, 1.0]? :-) Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Wednesday, 19 March 2014 at 23:58:36 UTC, Rikki Cattermole wrote: Out of interest but, shouldn't in the device module have a static assert(0, Not implemented yet) type of deal with the version(Posix) block? Not really. There's still usable functionality in there for all architectures (although I'm not sure how practically useful).
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:09:51 UTC, bearophile wrote: Do you have a simple but very fast function that generates uniforms in [0.0, 1.0]? :-) No, but it's planned. Jerro wrote quite a nice one in the course of his work on the Ziggurat algorithm, and I'm sure he'd be happy for me to adapt it accordingly.
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:09:51 UTC, bearophile wrote: Please don't use stuttering names like std.random2.randomShuffle. std.random2.shuffle is enough. I don't object to rewriting the names if there's a valid case for it, but it does seem to me to be important to try and match as much as possible the names that are already out there in std.random. The idea is to minimize the amount of rewriting anyone will have to do to adapt their code, and as far as I can tell where the contents of std.random2.adaptor are concerned (randomShuffle, randomCover, randomSample) it should require no rewriting at all. Besides, while std.random2.adaptor.randomShuffle may be the fully-qualified name, in practice, no one will write all that out, so the redundancy is less bad; and in any case, as any magician will tell you, a shuffle is not necessarily random ;-) I don't think the language is yet there. So I think currently this is not a good idea. If the aim were to overwrite std.random, I would agree with you, but there is no need to do that. It's named std.random2 for a reason :-) However, I do think that merging it into Phobos (assuming all other factors are OK) may have to be conditional on improvements in the available allocation strategies.
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: No, but it's planned. Jerro wrote quite a nice one in the course of his work on the Ziggurat algorithm, and I'm sure he'd be happy for me to adapt it accordingly. Note: I meant a simple but very fast function that generates just one value in [0.0, 1.0] (not a range). I don't object to rewriting the names if there's a valid case for it, but it does seem to me to be important to try and match as much as possible the names that are already out there in std.random. It's the best chance to improve naming, so do not throw it away for nothing: https://d.puremagic.com/issues/show_bug.cgi?id=9106 The idea is to minimize the amount of rewriting anyone will have to do to adapt their code, If you want you can keep a deprecated randomShuffle alias name for some time in std.random2. Besides, while std.random2.adaptor.randomShuffle may be the fully-qualified name, in practice, no one will write all that out, so the redundancy is less bad; I agree. But better to improve names when you have a (the only) chance. However, I do think that merging it into Phobos (assuming all other factors are OK) may have to be conditional on improvements in the available allocation strategies. We will probably have the nice Andrei's allocators in Phobos, but not in a short time. So I suggest to not rely on them for std.random2. Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:39:43 UTC, bearophile wrote: Note: I meant a simple but very fast function that generates just one value in [0.0, 1.0] (not a range). There will be both. :-) Off the top of my head I'm not sure whether the interval will be [0.0, 1.0], [0.0, 1.0) or whether it might be possible to make it work with arbitrary boundaries. If I recall right, most uniform01 implementations are [0.0, 1.0) ... ? It's the best chance to improve naming, so do not throw it away for nothing: https://d.puremagic.com/issues/show_bug.cgi?id=9106 If you want you can keep a deprecated randomShuffle alias name for some time in std.random2. Yes, in that case, I'd be happy to make the change (and maintain the old names via aliases). Thanks for pointing me to the bug report; I'd forgotten that this was an open issue :-) We will probably have the nice Andrei's allocators in Phobos, but not in a short time. So I suggest to not rely on them for std.random2. No, I don't intend to rely on them arriving soon. But while of course a random3 is always possible too, I'd rather not be faced with the situation of needing breaking changes to handle support for alternative allocation strategies. So if necessary, I'd rather maintain std.random2 outside of Phobos for a while and get things right when it finally lands, than push it in too early and need to make breaking changes.
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:15:22 UTC, Joseph Rushton
Wakeling wrote:
On Thursday, 20 March 2014 at 00:05:20 UTC, Joseph Rushton
Wakeling wrote:
Not really. There's still usable functionality in there for
all architectures (although I'm not sure how practically
useful).
Just to expand on that remark: my impression is that individual
random devices are inevitably going to be
architecture-dependent.
/dev/random and /dev/urandom are Posix devices; Windows AFAIK
has its own alternative. So the broad idea is that you'd have
as much generic functionality as possible available to all
architectures (mostly related to what sources you read from; a
file, a socket, something else?), and then individual
architecture-dependent aliases would map this to particular
random sources available to them.
Then, finally, you'd have some default alias RandomDevice that
would point to an appropriate architectural default; so e.g.
version (Posix)
{
alias RandomDevice = DevURandom!uint;
}
else version (Windows)
{
alias RandomDevice = ...
}
// etc.
... so, unless you were quite specific about your requirements,
90% of the time you could just use RandomDevice and expect it
to Just Work whatever your platform.
But as random devices are not my strongest area of expertise,
I'll happily take advice here.
For version blocks of code, I try to make sure they implement the
same interfaces like this one. To limit the possible issues.
It just makes things a little more cleaner for API users.
In the case that this isn't production ready the static assert
can be used as a TODO type of thing. Forcibly telling you it
isn't done yet. Its better than silently going into production
and finding out that a main platform isn't ready.
But this is just my preference.
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: Thanks for pointing me to the bug report; I'd forgotten that this was an open issue :-) In Bugzilla probably there are many bug reports/enhancement requests about std.random, so I suggest you to read them. Some of them can be useful, while other are probably already addressed in the current (or planned) std.random2. Another random one that was just commented by Infiltrator: https://d.puremagic.com/issues/show_bug.cgi?id=5901 Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Wednesday, 19 March 2014 at 23:49:41 UTC, Joseph Rushton Wakeling wrote: Hello all, As some of you may already know, monarch_dodra and I have spent quite a lot of time over the last year discussing the state of std.random. To cut a long story short, there are significant problems that arise because the current RNGs are value types rather than reference types. Any chance that you could describe them? I was about to resume porting the dcrypt library into Phobos, and had intended to flip the classes into structs, to match what the rest of the library was doing.
