On Tuesday, 25 March 2014 at 00:08:27 UTC, bearophile wrote:
I don't mind, I am happy :-) Thank you for adding a sorely
needed function.
It's been merged :-)
On Tuesday, 25 March 2014 at 00:08:27 UTC, bearophile wrote:
I don't mind, I am happy :-) Thank you for adding a sorely
needed function.
You are very kind, and far too modest. :-)
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]? :-)
On that note:
https://github.com/D-Programming-Language/phobos/pull/2050
Hope you don't mind me jumping ahead of your existing PR on this
--
Joseph Rushton Wakeling:
Hope you don't mind me jumping ahead of your existing PR on
this -- it's been inactive so I didn't know if you were
planning on following up.
I don't mind, I am happy :-) Thank you for adding a sorely needed
function.
The useless patch I opened should be closed.
On Saturday, 22 March 2014 at 23:56:35 UTC, bearophile wrote:
They seem good.
Excellent!
There may need to be some attention to the internals of
uniform01. Its correctness depends on whether one can always
trust a float-based RNG to return values in [min, max) or whether
[min, max] is
Joseph Rushton Wakeling:
int r = data[uniform![)(0, data.length)];
D also accepts:
immutable r = data[uniform![)(0, $)];
Bye,
bearophile
Joseph Rushton Wakeling:
I think all std.random functions now support a default RNG.
Is the issue is already fixed in std.random you can close it :-)
However, I'd have thought that
int r = data.sample(1, rndGen).front;
would have been a more efficient way to implement choice, as
it
On Sun, Mar 23, 2014 at 11:17 AM, bearophile bearophileh...@lycos.com wrote:
Joseph Rushton Wakeling:
int r = data[uniform![)(0, data.length)];
D also accepts:
immutable r = data[uniform![)(0, $)];
Really? The '$' part works?
On Sunday, 23 March 2014 at 10:15:32 UTC, bearophile wrote:
Is the issue is already fixed in std.random you can close it :-)
Well, your request for a choice method is still open ... :-)
The best thing is to add an efficient choice() function, so no
efficiency mistake happens :-)
Sure, I'm
Joseph Rushton Wakeling:
Latest patches rename randomSample = sample, again offering a
documented alias to assist migration.
Perhaps it's better to not document this alias.
permutation seems good to me (or permute?), but perhaps
others have suggestions or can point to a typical naming
Latest patches rename randomSample = sample, again offering a
documented alias to assist migration.
It would be nice to complete the set and eliminate randomCover,
but in this case cover seems too vague a name to use. Any
suggestions for alternatives? I wasn't able to readily find an
On Saturday, 22 March 2014 at 20:09:00 UTC, bearophile wrote:
Perhaps it's better to not document this alias.
For now it will be documented, for clarity if nothing else.
Whether that documentation makes it into a Phobos submission, I
think should depend on formal review.
I'd like a
Joseph Rushton Wakeling:
How does your desired concept relate to the existing
std.algorithm.nextPermutation ... ?
The API of the lazy permutations/combinations ranges is similar
to the one I have written here:
http://rosettacode.org/wiki/Permutations#Fast_Lazy_Version
That is also very
Latest patches just pushed to repo make the randomSample =
sample change and introduce a fast uniform01 and
uniform01Distribution :-)
Joseph Rushton Wakeling:
Latest patches just pushed to repo make the randomSample =
sample change and introduce a fast uniform01 and
uniform01Distribution :-)
They seem good.
More ideas:
Three suggestions for std.random:
https://d.puremagic.com/issues/show_bug.cgi?id=4851
Strongly pure
On Thursday, 20 March 2014 at 21:17:33 UTC, Joseph Rushton
Wakeling wrote:
On Thursday, 20 March 2014 at 08:30:09 UTC, ponce wrote:
Related: please consider using parts of SimpleRNG the
excellent work of John D. Cook which provides many random
distributions in a compact and documented way.
On Friday, 21 March 2014 at 16:01:28 UTC, ponce wrote:
On Thursday, 20 March 2014 at 21:17:33 UTC, Joseph Rushton
Wakeling wrote:
On Thursday, 20 March 2014 at 08:30:09 UTC, ponce wrote:
Related: please consider using parts of SimpleRNG the
excellent work of John D. Cook which provides many
On Thursday, 20 March 2014 at 00:39:43 UTC, bearophile wrote:
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
I think the following patch should fix that for you:
Joseph Rushton Wakeling:
I think the following patch should fix that for you:
https://github.com/WebDrake/std.random2/commit/fb5429de77b3c1f7fe3968fd0bd92209c9021f31
I've also made shuffle composable as per your request. Looks
good? :-)
Seems good. Onward! :-)
Bye,
bearophile
On Wednesday, 19 March 2014 at 23:49:41 UTC, Joseph Rushton
Wakeling wrote:
* std.random2.distribution, random distributions such as
uniform,
normal, etc.;
Related: please consider using parts of SimpleRNG the excellent
work of John D. Cook which provides many random distributions in
On Thursday, 20 March 2014 at 01:32:41 UTC, Chris Williams wrote:
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.
On Thursday, 20 March 2014 at 00:09:51 UTC, bearophile wrote:
Joseph Rushton Wakeling:
* 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.
Agreed.
monarch_dodra:
I think there is 0 doubt that reference semantics is the way to
go.
I agree.
Furthermore, even in terms of performance, I think a heap
allocated PRNG will still flat-out beat the value based one, if
only because of the size of the damn thing.
OK.
Do you have a simple
On Thursday, 20 March 2014 at 08:22:37 UTC, monarch_dodra wrote:
The issue isn't class vs struct, but rather value semantic vs
reference semantic (classes are always ref, but structs can
be either).
That's only completely true if structs are referred to by
pointer. ref parameters/returns
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
On Thursday, 20 March 2014 at 19:04:01 UTC, Andrea Fontana wrote:
Still no cmwc rng... IMO cmwc should replace mt as default RNG.
Faster. Longer period. More passed tests (if i'm right MT
didn't pass testu01). And it is parametric to get faster result
or longer period.
On Thursday, 20 March 2014 at 01:07:54 UTC, bearophile wrote:
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.
On Thursday, 20 March 2014 at 01:32:41 UTC, Chris Williams wrote:
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.
I think there's a good
On Thursday, 20 March 2014 at 08:30:09 UTC, ponce wrote:
Related: please consider using parts of SimpleRNG the excellent
work of John D. Cook which provides many random distributions
in a compact and documented way.
https://github.com/p0nce/gfm/blob/master/math/gfm/math/simplerng.d
(here a
On Thursday, 20 March 2014 at 21:16:27 UTC, Joseph Rushton
Wakeling wrote:
I think there's a good case for a std.random2.crypto module
that contains RNGs that are specifically suitable for
cryptography. That said I think the bar here has to be set
VERY high, which is why I didn't even begin
On Thursday, 20 March 2014 at 08:51:08 UTC, monarch_dodra wrote:
Agreed.
There is consensus it seems. I will make the fix ;-)
I think there is 0 doubt that reference semantics is the way to
go. An advantage of using class is that it is still *possible*
to place them on the stack with
On Thursday, 20 March 2014 at 21:42:13 UTC, Chris Williams wrote:
To be certain that the implementation doesn't have any security
holes?
Yes. Of course, in the current climate one might fear that
they'd be the ones introducing them ... :-)
On Thursday, 20 March 2014 at 18:43:49 UTC, Chris Williams wrote:
That's only completely true if structs are referred to by
pointer. ref parameters/returns aren't quite sufficient to keep
a struct acting as a reference for all purposes.
As far as I can tell, you're thinking of _passing_
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?
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
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
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
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
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
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
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
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
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
43 matches
Mail list logo
