I believe, bearophile was interested in this - a strongly pure immutable Xorshift32(1) PRNG: http://dpaste.dzfl.pl/5f710daf

On Tuesday, 7 January 2014 at 12:32:23 UTC, Kagamin wrote:
> I believe, bearophile was interested in this - a strongly pure immutable Xorshift32(1) PRNG: http://dpaste.dzfl.pl/5f710daf

I would consider this weakly pure, because the implicit parameter "this" is not immutable. A strongly pure PRNG cannot change internal state.

On 07/01/14 13:37, qznc wrote:
> I would consider this weakly pure, because the implicit parameter "this" is not
> immutable. A strongly pure PRNG cannot change internal state.

Related -- the work I've been doing on an updated std.random:
https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d

It's easy to make class-based PRNGs weakly pure and const (i.e. pure in everything bar perhaps some of the seed functions, const apart from seed functions and popFront).  I don't think it'd meed the criteria of a very strict functional-programming interpretation of purity, though.

Kagamin:
> I believe, bearophile was interested in this

The ER:
https://d.puremagic.com/issues/show_bug.cgi?id=5249

Bye,
bearophile

On Tuesday, 7 January 2014 at 12:37:39 UTC, qznc wrote:
> On Tuesday, 7 January 2014 at 12:32:23 UTC, Kagamin wrote:
>> I believe, bearophile was interested in this - a strongly pure immutable Xorshift32(1) PRNG: http://dpaste.dzfl.pl/5f710daf
>
> I would consider this weakly pure, because the implicit parameter "this" is not immutable. A strongly pure PRNG cannot change internal state.

Without this, http://dilbert.com/strips/comic/2001-10-25/

On 08/01/14 02:13, deadalnix wrote:
> Without this, http://dilbert.com/strips/comic/2001-10-25/

I guess you could do a design where you pass an immutable RNG state, and you get back whatever random number you ask for plus a new immutable state (perhaps provided via an out parameter).  It's just that in this case it puts the responsibility on the user to be really careful in ensuring that the RNG state is passed around properly (the main PITA being getting back the updated state rather than passing the current one).

It's really much easier to do it as a class which updates internal state, and where you can apply @safe pure nothrow and (with obvious exceptions) const to just about every method; and I don't really see what you lose in a practical sense by doing it this way.

On Wednesday, 8 January 2014 at 01:13:12 UTC, deadalnix wrote:
> On Tuesday, 7 January 2014 at 12:37:39 UTC, qznc wrote:
>> On Tuesday, 7 January 2014 at 12:32:23 UTC, Kagamin wrote:
>>> I believe, bearophile was interested in this - a strongly pure immutable Xorshift32(1) PRNG: http://dpaste.dzfl.pl/5f710daf
>>
>> I would consider this weakly pure, because the implicit parameter "this" is not immutable. A strongly pure PRNG cannot change internal state.
>
> Without this, http://dilbert.com/strips/comic/2001-10-25/

Nice :)

Of course, mandatory xkcd PRNG:
https://d.puremagic.com/issues/show_bug.cgi?id=11138

You know, it *is* pure...

On Tuesday, 7 January 2014 at 12:37:39 UTC, qznc wrote:
> On Tuesday, 7 January 2014 at 12:32:23 UTC, Kagamin wrote:
>> I believe, bearophile was interested in this - a strongly pure immutable Xorshift32(1) PRNG: http://dpaste.dzfl.pl/5f710daf
>
> I would consider this weakly pure, because the implicit parameter "this" is not immutable. A strongly pure PRNG cannot change internal state.

Formally it is immutable, see line 36.

On Saturday, 11 January 2014 at 10:19:00 UTC, Kagamin wrote:
> Formally it is immutable, see line 36.

Well, by breaking the type system you can make every PRNG immutable. ;)

David

Only the cast breaks the type system, I go through holes. It's just a joke, purity and immutability are valued for their deterministic traits, so a random number generator is the last thing one would want to make pure or immutable.