On Saturday, November 26, 2016 12:24:47 Andrei Alexandrescu via Digitalmars-
d wrote:
> On 11/26/2016 01:55 AM, Martin Nowak wrote:
> > On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
> >> Maybe non-copyability needs to become a requirement for InputRanges.
> >
> > Could have an
On 11/26/2016 01:55 AM, Martin Nowak wrote:
On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
Maybe non-copyability needs to become a requirement for InputRanges.
Could have an optional .clone if copying is supported.
What would be an InputRange where copying is correct?
On Saturday, 26 November 2016 at 06:55:24 UTC, Martin Nowak wrote:
Should we split off this discussion to a dlang-study thread?
I would personally really welcome that, but subject to the
understanding that people agree to look seriously at random
algorithms (like RandomSample) and not focus
On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
Yes the problems are inadvertent copies and a disabled
this(this) would prevent that. RNGs should have unique
ownership of their internal state.
Using InputRanges with phobos is somewhat clumsy. Maybe people
have been burned by
On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
Maybe non-copyability needs to become a requirement for
InputRanges.
Could have an optional .clone if copying is supported.
What would be an InputRange where copying is correct?
We already have refRange for that, no?
Also
On Wednesday, 23 November 2016 at 01:34:23 UTC, Andrei
Alexandrescu wrote:
On 11/22/16 7:30 PM, John Colvin wrote:
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei
Alexandrescu wrote:
The proposed design has disabled copy ctor and uses opCall()
for a new element. That seems to be a
On Thursday, 24 November 2016 at 14:22:05 UTC, Jonathan M Davis
wrote:
Then call popFront or drop before passing it along if you're
paranoid about it.
There's little need for it, as it was pointed out earlier that
the generate algorithm does the right thing and needs only
opCall, also a nice
On Friday, November 25, 2016 08:32:07 Joseph Rushton Wakeling via
Digitalmars-d wrote:
> On Wednesday, 23 November 2016 at 21:19:51 UTC, Jonathan M Davis
>
> wrote:
> > It's quite feasible if you don't calculate front until it's
> > called or popFront is called, and then you cache the result so
>
On Wednesday, 23 November 2016 at 21:19:51 UTC, Jonathan M Davis
wrote:
It's quite feasible if you don't calculate front until it's
called or popFront is called, and then you cache the result so
that subsequent calls to front prior to the call to popFront
return the same result, but it creates
On Thursday, 24 November 2016 at 08:36:41 UTC, Andrea Fontana
wrote:
On Wednesday, 23 November 2016 at 17:31:58 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei
Alexandrescu wrote:
Interesting. Could you please add a couple of links about
that? -- Andrei
On 24.11.2016 14:50, Kagamin wrote:
On Thursday, 24 November 2016 at 12:02:22 UTC, John Colvin wrote:
Because it's correct. If a.length is larger than int.max then
cast(int)a.length will half the time be negative and therefore a
simple rightshift would not be equivalent to division by 2.
It
On Thursday, 24 November 2016 at 17:04:43 UTC, John Colvin wrote:
If druntime was initialised by default using
__attribute__((constructor)) for static and linker .init for
shared libraries, would that be good enough for you*? I feel
like you're limiting your design choices because of a
On Thursday, 24 November 2016 at 16:09:23 UTC, Ilya Yaroshenko
wrote:
On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis
wrote:
Alternatively, you could just do rndGen().take(1).front, and
as long as rndGen() gives you a reference type, it works just
fine. Unfortunately,
On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis
wrote:
Alternatively, you could just do rndGen().take(1).front, and as
long as rndGen() gives you a reference type, it works just
fine. Unfortunately, std.random did not use reference types for
its ranges. _That_ is the big
On Thursday, November 24, 2016 13:54:50 Kagamin via Digitalmars-d wrote:
> On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis
>
> wrote:
> > How so? Because someone might call range.front again without
> > bothering to call popFront?
>
> That's what everything in std.algorithm does.
On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis
wrote:
How so? Because someone might call range.front again without
bothering to call popFront?
That's what everything in std.algorithm does.
On Thursday, 24 November 2016 at 12:02:22 UTC, John Colvin wrote:
Because it's correct. If a.length is larger than int.max then
cast(int)a.length will half the time be negative and therefore
a simple rightshift would not be equivalent to division by 2.
It can't be possibly correct when
On Thursday, November 24, 2016 09:05:34 Kagamin via Digitalmars-d wrote:
> On Wednesday, 23 November 2016 at 21:33:53 UTC, Jonathan M Davis
>
> wrote:
> > though I think that using the comma operator like that is
> > deprecated now. Adding a helper function such as
> >
> > auto getNext(R)(ref R
On Thursday, 24 November 2016 at 10:41:44 UTC, Kagamin wrote:
On Thursday, 24 November 2016 at 10:16:11 UTC, John Colvin
wrote:
I was talking about andrei's example. He has a cast(int) in it
before the division.
And you think that compilation of cast(int)a.length/2 to 3
instructions is
On Thursday, 24 November 2016 at 10:16:11 UTC, John Colvin wrote:
I was talking about andrei's example. He has a cast(int) in it
before the division.
And you think that compilation of cast(int)a.length/2 to 3
instructions is optimized just fine? How is it better that one
shift?
On Thursday, 24 November 2016 at 10:14:27 UTC, Kagamin wrote:
On Thursday, 24 November 2016 at 09:46:16 UTC, John Colvin
wrote:
That's because of the cast(int), dividing by two is optimised
just fine.
What about Andrei's example?
I was talking about andrei's example. He has a cast(int) in
On Thursday, 24 November 2016 at 09:46:16 UTC, John Colvin wrote:
That's because of the cast(int), dividing by two is optimised
just fine.
What about Andrei's example?
On Thursday, 24 November 2016 at 08:55:18 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 21:18:27 UTC, Andrei
Alexandrescu wrote:
[Details needed]
I just took a look https://godbolt.org/g/EMy6X4, it's
happening.
That's three instructions instead of one shr eax,1
That's because of
On 23.11.2016 00:55, Andrei Alexandrescu wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to C++)
This seems like a gratuitous departure from common D practice. Random
number generators are most naturally modeled in D as infinite
On Wednesday, 23 November 2016 at 16:54:44 UTC, Andrei
Alexandrescu wrote:
On 11/23/2016 10:52 AM, Ilya Yaroshenko wrote:
I started with Engines as basis. The library will be very
different
comparing with Phobos and _any_ other RNG libraries in terms
of floating
point generation quality. All
On Thursday, 24 November 2016 at 08:59:03 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 19:40:47 UTC, Ilya Yaroshenko
wrote:
Current adaptor should be used in a function scope. (Would be
great to have a DIP for that kind of semantic check). An RC
adaptor can be added too. First we need
On 24.11.2016 09:55, Kagamin wrote:
On Wednesday, 23 November 2016 at 21:18:27 UTC, Andrei Alexandrescu wrote:
[Details needed]
I just took a look https://godbolt.org/g/EMy6X4, it's happening.
That's three instructions instead of one shr eax,1
That would be wrong code. Cast to int after
On Wednesday, 23 November 2016 at 21:33:53 UTC, Jonathan M Davis
wrote:
though I think that using the comma operator like that is
deprecated now. Adding a helper function such as
auto getNext(R)(ref R range)
if(isInputRange!R)
{
range.popFront();
return range.front;
}
would solve
On Wednesday, 23 November 2016 at 19:40:47 UTC, Ilya Yaroshenko
wrote:
Current adaptor should be used in a function scope. (Would be
great to have a DIP for that kind of semantic check). An RC
adaptor can be added too. First we need to find a real world
use case where we need to store a random
On Wednesday, 23 November 2016 at 21:18:27 UTC, Andrei
Alexandrescu wrote:
[Details needed]
I just took a look https://godbolt.org/g/EMy6X4, it's happening.
That's three instructions instead of one shr eax,1
On Wednesday, 23 November 2016 at 17:31:58 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei
Alexandrescu wrote:
Interesting. Could you please add a couple of links about
that? -- Andrei
http://xoroshiro.di.unimi.it/
Very short public domain implementation:
I have to agree that creating a different API that uses opCall
or whatever instead of a the range API is a bad idea,
particularly when a simple helper function would make it
possible to use a random number generator in a fashion more
like rand() for the cases where that's preferable, and for a
On Wednesday, November 23, 2016 15:29:14 Kagamin via Digitalmars-d wrote:
> On Wednesday, 23 November 2016 at 14:30:53 UTC, Andrei
>
> Alexandrescu wrote:
> > This claim would apply to all ranges. There seems to be
> > evidence it is unfounded.
> >
> > The main argument for using the range
On Wednesday, November 23, 2016 08:54:30 Andrei Alexandrescu via
Digitalmars-d wrote:
> On 11/23/2016 06:14 AM, Ilya Yaroshenko wrote:
> > I think that Range API is bad and useless overengineering for RNGs.
>
> So it either "takes 1 minute" to change the interface from opCall to
> ranges (i.e.
On Wednesday, November 23, 2016 14:02:36 Joseph Rushton Wakeling via
Digitalmars-d wrote:
> On Wednesday, 23 November 2016 at 13:56:27 UTC, Andrei
>
> Alexandrescu wrote:
> > Well I do see another small problem with
> > https://github.com/libmir/mir-random/blob/master/source/random/algorithm
> >
On 11/23/16 3:05 PM, Ilya Yaroshenko wrote:
On Wednesday, 23 November 2016 at 19:51:50 UTC, Andrei Alexandrescu wrote:
On 11/23/16 2:40 PM, Ilya Yaroshenko wrote:
On Wednesday, 23 November 2016 at 19:16:29 UTC, Andrei Alexandrescu
wrote:
A tip for the range adaptor: have it allocate and own
On 11/23/16 11:10 AM, Kagamin wrote:
On Wednesday, 23 November 2016 at 14:30:53 UTC, Andrei Alexandrescu wrote:
That seems to be a minor matter. Of course at best some measurements
would be in order.
Yes, it's just Joseph worries about microoptimizations.
Though we saw that the compiler
On Wednesday, 23 November 2016 at 19:51:50 UTC, Andrei
Alexandrescu wrote:
On 11/23/16 2:40 PM, Ilya Yaroshenko wrote:
On Wednesday, 23 November 2016 at 19:16:29 UTC, Andrei
Alexandrescu wrote:
A tip for the range adaptor: have it allocate and own the
generator
internally. That way it's easy
On 11/23/16 2:40 PM, Ilya Yaroshenko wrote:
On Wednesday, 23 November 2016 at 19:16:29 UTC, Andrei Alexandrescu wrote:
A tip for the range adaptor: have it allocate and own the generator
internally. That way it's easy to make it reference counted economically.
Current adaptor should be used
On Wednesday, 23 November 2016 at 19:16:29 UTC, Andrei
Alexandrescu wrote:
A tip for the range adaptor: have it allocate and own the
generator internally. That way it's easy to make it reference
counted economically.
Current adaptor should be used in a function scope. (Would be
great to
On 11/23/2016 01:13 PM, Ilya Yaroshenko wrote:
1. Engine must not have implicit copy semantic: it is not correct for
RNGs and has performance issues. They also should not be copied
explicitly in this example.
OK, so (lack of) copyability is a good argument. I'm ready to live with
random
On Wednesday, 23 November 2016 at 18:13:52 UTC, Ilya Yaroshenko
wrote:
Assume your are building a modification Mod_X ~ 1 / X + X for a
distribution. This is how it will look in Mir Random:
EDIT: Mod_X ~ Y + X, Y ~ X. (X & Y are independent)
On Wednesday, 23 November 2016 at 16:54:44 UTC, Andrei
Alexandrescu wrote:
On 11/23/2016 10:52 AM, Ilya Yaroshenko wrote:
I started with Engines as basis. The library will be very
different
comparing with Phobos and _any_ other RNG libraries in terms
of floating
point generation quality. All
On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei
Alexandrescu wrote:
Interesting. Could you please add a couple of links about that?
-- Andrei
http://xoroshiro.di.unimi.it/
On 11/23/2016 10:52 AM, Ilya Yaroshenko wrote:
I started with Engines as basis. The library will be very different
comparing with Phobos and _any_ other RNG libraries in terms of floating
point generation quality. All FP generation I have seen are not
saturated (amount of possible unique FP
On Wednesday, 23 November 2016 at 14:30:53 UTC, Andrei
Alexandrescu wrote:
That seems to be a minor matter. Of course at best some
measurements would be in order.
Yes, it's just Joseph worries about microoptimizations.
Though we saw that the compiler can't optimize some simple
operations
On Wednesday, 23 November 2016 at 16:01:14 UTC, Ryan wrote:
On Wednesday, 23 November 2016 at 15:44:10 UTC, Joseph Rushton
Wakeling wrote:
auto m = ().map!(a=>1);
...? (Untested, but I think it should work.)
Tested, works with 2.071.1
r.randomRangeAdaptor.map!(a=>1);
On Wednesday, 23 November 2016 at 15:59:39 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 15:44:10 UTC, Joseph Rushton
Wakeling wrote:
auto m = ().map!(a=>1);
...? (Untested, but I think it should work.)
Or RefRange https://issues.dlang.org/show_bug.cgi?id=10888 :)
What the
On Wednesday, 23 November 2016 at 15:44:10 UTC, Joseph Rushton
Wakeling wrote:
auto m = ().map!(a=>1);
...? (Untested, but I think it should work.)
Tested, works with 2.071.1
On Wednesday, 23 November 2016 at 15:44:10 UTC, Joseph Rushton
Wakeling wrote:
auto m = ().map!(a=>1);
...? (Untested, but I think it should work.)
Or RefRange https://issues.dlang.org/show_bug.cgi?id=10888 :)
On Wednesday, 23 November 2016 at 13:41:25 UTC, Andrei
Alexandrescu wrote:
On 11/23/2016 12:58 AM, Ilya Yaroshenko wrote:
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei
Alexandrescu wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used
On Wednesday, 23 November 2016 at 14:30:53 UTC, Andrei
Alexandrescu wrote:
That seems to be a minor matter.
Yes, it's just Joseph worries about microoptimizations.
The main counter-argument is that the abstraction is not
fitting well and another abstraction (such as opCall) is more
On Wednesday, 23 November 2016 at 15:25:29 UTC, Kagamin wrote:
struct A
{
bool empty;
int front;
void popFront(){}
@disable this(this);
}
import std.algorithm;
void f()
{
A r;
auto m=r.map!(a=>1);
}
Does this compile for you?
auto m =
On Wednesday, 23 November 2016 at 15:29:14 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 14:30:53 UTC, Andrei
Consider this okayish looking code:
consume(rng());
consume(rng.take(2)); //reuses previous value
consume(rng()); //discards unused value
Also consider the case of using 1
On Wednesday, 23 November 2016 at 13:41:25 UTC, Andrei
Alexandrescu wrote:
An input range can be made noncopyable.
If you implement it as a noncopyable input range, you get a
large support network working for you.
struct A
{
bool empty;
int front;
void popFront(){}
On Wednesday, 23 November 2016 at 14:30:53 UTC, Andrei
Alexandrescu wrote:
This claim would apply to all ranges. There seems to be
evidence it is unfounded.
The main argument for using the range interface for RNGs is
reuse of abstraction. Minute implementation matters are much
less
On 11/23/2016 09:12 AM, Kagamin wrote:
xorshift128+ returns a temporary value computed during state update, so
it can't efficiently separate font from popFront.
That seems to be a minor matter. Of course at best some measurements
would be in order.
Also this API is prone
to reuse some
On Wednesday, 23 November 2016 at 01:34:23 UTC, Andrei
Alexandrescu wrote:
We should add a reference RNG that transforms any other RNG
into an input range that shares the actual RNG.
Didn't we have a generic Ref!T wrapper in std.typecons that would
work this way? Can't find it now.
On Wednesday, 23 November 2016 at 10:57:04 UTC, Joseph Rushton
Wakeling wrote:
struct MyRNG
{
void popFront() { /* update internal state */ }
UIntType front() @property { return /* whatever part of
internal state */; }
UIntType opCall()
{
this.popFront();
On Wednesday, 23 November 2016 at 13:56:27 UTC, Andrei
Alexandrescu wrote:
Well I do see another small problem with
https://github.com/libmir/mir-random/blob/master/source/random/algorithm.d#L19. It creates the first value eagerly upon construction. That's just a bit awkward. It's not the first
On 11/23/2016 08:26 AM, Joseph Rushton Wakeling wrote:
On Wednesday, 23 November 2016 at 13:03:04 UTC, Ilya Yaroshenko wrote:
Added RandomRangeAdaptor for URBGs:
https://github.com/libmir/mir-random/blob/master/source/random/algorithm.d
This has exactly the problem I identified above,
On Wednesday, 23 November 2016 at 13:44:00 UTC, Andrei
Alexandrescu wrote:
Well we need to get to the bottom of this if we're to make
progress. Otherwise it's copypasta with little changes followed
by disappointment all the way down. -- Andrei
Would you be up for a direct discussion of this
On 11/23/2016 06:14 AM, Ilya Yaroshenko wrote:
I think that Range API is bad and useless overengineering for RNGs.
So it either "takes 1 minute" to change the interface from opCall to
ranges (i.e. they're virtually the same thing), or it's the above.
There's precious little overengineering
On Wednesday, 23 November 2016 at 13:35:33 UTC, Ilya Yaroshenko
wrote:
1. Current default RNG (Mt19937) has not state for the latest
value.
That's a detail of your implementation, though, and it's not true
for lots of other pseudo-RNGs.
2. The structure is allocated on stack and compilers
On 11/23/2016 05:47 AM, Joseph Rushton Wakeling wrote:
On Wednesday, 23 November 2016 at 01:34:23 UTC, Andrei Alexandrescu wrote:
I'm unclear on what that statistically unsafe default behavior is - my
understanding is it has to do with RNGs being inadvertently copied. It
would be great to
On 11/23/2016 01:16 AM, Ilya Yaroshenko wrote:
The std.range is good example of degradation, it has a lot of API and
implementation bugs.
EDIT: std.range -> std.random
Oh, that narrows it down. Thx. -- Andrei
On 11/23/2016 05:27 AM, Joseph Rushton Wakeling wrote:
Alternative solution: functionality that expects the full unsigned
integer word (UIntType) to be filled with random bits, should validate
that the min/max values of the generator correspond to UIntType.min and
UIntType.max.
That introduces
On 11/23/2016 12:58 AM, Ilya Yaroshenko wrote:
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to C++)
This seems like a gratuitous departure from common D
On Wednesday, 23 November 2016 at 13:01:22 UTC, Andrea Fontana
wrote:
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko
wrote:
- 64-bit Mt19937 initialization is fixed
- 64-bit Mt19937 is default for 64-bit targets
I wonder why Mersenne Twister is *always* choosen over other
On Wednesday, 23 November 2016 at 13:26:41 UTC, Joseph Rushton
Wakeling wrote:
On Wednesday, 23 November 2016 at 13:03:04 UTC, Ilya Yaroshenko
wrote:
Added RandomRangeAdaptor for URBGs:
https://github.com/libmir/mir-random/blob/master/source/random/algorithm.d
This has exactly the problem I
On Wednesday, 23 November 2016 at 13:01:22 UTC, Andrea Fontana
wrote:
I wonder why Mersenne Twister is *always* choosen over other
algorithms.
The weight of history, I suspect. Mersenne Twister was the major
new high-quality RNG back when people started getting really
concerned about having
On Wednesday, 23 November 2016 at 13:03:04 UTC, Ilya Yaroshenko
wrote:
Added RandomRangeAdaptor for URBGs:
https://github.com/libmir/mir-random/blob/master/source/random/algorithm.d
This has exactly the problem I identified above, though: you're
unnecessarily cacheing the latest variate
On Wednesday, 23 November 2016 at 11:44:44 UTC, Joseph Rushton
Wakeling wrote:
Yes, most uses of RNGs in std.random involve calling `front`
and then `popFront()` (although it would probably be better the
other way round). But it's readily possible to imagine
range-based use-cases for random
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko
wrote:
- 64-bit Mt19937 initialization is fixed
- 64-bit Mt19937 is default for 64-bit targets
I wonder why Mersenne Twister is *always* choosen over other
algorithms.
My vote goes for CMWC, of course.
Andrea
On Wednesday, 23 November 2016 at 11:44:44 UTC, Joseph Rushton
Wakeling wrote:
On Wednesday, 23 November 2016 at 11:14:38 UTC, Ilya Yaroshenko
wrote:
For example, Mir Random basic utilities (more low level then
distributions):
On Wednesday, 23 November 2016 at 11:14:38 UTC, Ilya Yaroshenko
wrote:
For example, Mir Random basic utilities (more low level then
distributions):
https://github.com/libmir/mir-random/blob/master/source/random/package.d
Also you can explore std.random code. opCall would almost
always more
On Wednesday, 23 November 2016 at 10:57:04 UTC, Joseph Rushton
Wakeling wrote:
On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
It is safe low level architecture without performance and API
issues. It prevents users to do stupid things implicitly (like
copying RNGs). A
On Wednesday, 23 November 2016 at 11:03:33 UTC, Ilya Yaroshenko
wrote:
It is only question of `Random` alias, which can be changed in
the future anyway. Both Mt19937_32 and Mt19937_64 are defined.
I think we're at an impasse in terms of priorities, because
that's exactly the reason that I
On Wednesday, 23 November 2016 at 10:33:21 UTC, Joseph Rushton
Wakeling wrote:
On Wednesday, 23 November 2016 at 05:26:12 UTC, Ilya Yaroshenko
wrote:
[...]
All of which is fine in its own terms, but why prioritize the
speed of the default behaviour over its reliability and
reproducibility?
On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
It is safe low level architecture without performance and API
issues. It prevents users to do stupid things implicitly (like
copying RNGs). A hight level range interface can be added in
the future (it will hold a _pointer_
On Wednesday, 23 November 2016 at 01:34:23 UTC, Andrei
Alexandrescu wrote:
I'm unclear on what that statistically unsafe default behavior
is - my understanding is it has to do with RNGs being
inadvertently copied. It would be great to formalize that in a
well-explained issue.
I'll see if I
On Wednesday, 23 November 2016 at 05:26:12 UTC, Ilya Yaroshenko
wrote:
Mir Random is going to be a library with saturated uniform FP
RNGs and almost saturated exponential FP RNGs. Comparing with
all other libraries (any language) the basic uniform FP numbers
will be generated in interval (-1,
On Wednesday, 23 November 2016 at 10:27:00 UTC, Joseph Rushton
Wakeling wrote:
On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
### Example of API+implementation bug:
Bug: RNGs has min and max params (hello C++). But, they
are not used when an uniform integer number
On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
### Example of API+implementation bug:
Bug: RNGs has min and max params (hello C++). But, they
are not used when an uniform integer number is generated :
`uniform!ulong` / `uniform!ulong(0, 100)`.
Solution: In
On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei
Alexandrescu wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar
to C++)
This seems like a gratuitous
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu
wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to
C++)
This seems like a gratuitous departure from common D practice.
Random number generators are most naturally
On Wednesday, 23 November 2016 at 00:44:26 UTC, Joseph Rushton
Wakeling wrote:
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko
wrote:
- 64-bit Mt19937 is default for 64-bit targets
This means that seemingly identical code will produce different
results depending on whether
On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei
Alexandrescu wrote:
On 11/22/16 7:44 PM, Joseph Rushton Wakeling wrote:
These days it's debatable whether Mersenne Twister of _any_
word size is
the optimal choice for a default RNG
Interesting. Could you please add a couple of links
On 11/22/16 7:30 PM, John Colvin wrote:
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to C++)
This seems like a gratuitous departure from common D practice.
On 11/22/16 7:36 PM, Joseph Rushton Wakeling wrote:
* random _generators_, i.e. sources of uniformly distributed random bits:
- random _engines_ (seedable, pseudo-random algorithms)
- random _devices_ (non-deterministic sources of uniformly
distributed bits)
* random
On 11/22/16 7:44 PM, Joseph Rushton Wakeling wrote:
These days it's debatable whether Mersenne Twister of _any_ word size is
the optimal choice for a default RNG
Interesting. Could you please add a couple of links about that? -- Andrei
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko
wrote:
- 64-bit Mt19937 is default for 64-bit targets
This means that seemingly identical code will produce different
results depending on whether it's compiled for 64-bit or 32-bit.
Is that really worth it, when anyone who
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko
wrote:
# Integer uniform generators
[WIP]
# Real uniform generators
[WIP]
# Nonuniform generators
[WIP]
As we discussed in relation to Seb's project, I think this is a
problematic conceptualization of the best way to
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu
wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to
C++)
This seems like a gratuitous departure from common D practice.
Random number generators are most naturally
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu
wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to
C++)
This seems like a gratuitous departure from common D practice.
Random number generators are most naturally
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to C++)
This seems like a gratuitous departure from common D practice. Random
number generators are most naturally modeled in D as infinite ranges. --
Andrei
96 matches
Mail list logo
