I've been developing a PRNG recently, and studying how it behaves
with phobos' other stuff, in particular, range and algorithm.
I quickly came to the conclusion that if a PRNG does not have
reference semantics, it is just as good as useless.
Why? Because everything in phobos is passed "by val
On Tuesday, September 18, 2012 17:05:26 monarch_dodra wrote:
> This is issue #1: I'd propose that all objects in std.random be
> migrated to classes (or be made reference structs), sooner than
> later. This might break some code, so I do not know how this is
> usually done, but I think it is necess
On Tuesday, 18 September 2012 at 17:59:04 UTC, Jonathan M Davis
wrote:
On Tuesday, September 18, 2012 17:05:26 monarch_dodra wrote:
This is issue #1: I'd propose that all objects in std.random be
migrated to classes (or be made reference structs), sooner than
later. This might break some code, s
On Thursday, September 20, 2012 08:51:28 monarch_dodra wrote:
> On Tuesday, 18 September 2012 at 17:59:04 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, September 18, 2012 17:05:26 monarch_dodra wrote:
> >> This is issue #1: I'd propose that all objects in std.random be
> >> migrated to classes
On Thursday, 20 September 2012 at 07:26:01 UTC, Jonathan M Davis
wrote:
On Thursday, September 20, 2012 08:51:28 monarch_dodra wrote:
On Tuesday, 18 September 2012 at 17:59:04 UTC, Jonathan M Davis
wrote:
> On Tuesday, September 18, 2012 17:05:26 monarch_dodra wrote:
>> This is issue #1: I'd pr
Am Thu, 20 Sep 2012 08:51:28 +0200
schrieb "monarch_dodra" :
> > Moving to classes would definitely break code, but it should be
> > possible to
> > make them reference types simply by making it so that their
> > internal state is
> > in a separate object held by a pointer.
>
> I was thinking
On Thursday, 20 September 2012 at 09:58:41 UTC, Johannes Pfau
wrote:
Am Thu, 20 Sep 2012 08:51:28 +0200
schrieb "monarch_dodra" :
> Moving to classes would definitely break code, but it should
> be possible to
> make them reference types simply by making it so that their
> internal state is
>
Am Thu, 20 Sep 2012 12:23:12 +0200
schrieb "monarch_dodra" :
>
> That is a good point, I'd also make the "default" heap allocated,
> but give a way to access a stack allocated payload.
>
> Regarding the "developer mistake", the problem is that currently:
> "Misnstdrand a;"
> Will create a valid
On Thursday, 20 September 2012 at 10:46:22 UTC, Johannes Pfau
wrote:
That's what I did in std.digest. All Digests have a start()
method,
even if it's not necessary for that specific Digest. It's
probably a
good solution if you want a uniform interface for types which
need
initialization and
On Thursday, September 20, 2012 12:57:03 monarch_dodra wrote:
> BTW: std.container also has MakeContainter, but, AFAIK, I've
> never seen ANYONE use it :/
What std.container has is make, which is supposed to construct a type where it
goes by default (classes on the heap with new, and structs on t
On Thursday, 20 September 2012 at 11:10:43 UTC, Jonathan M Davis
wrote:
[SNIP]
- Jonathan M Davis
#1
Hey, I've been working on this (locally): I've made all the PRNGs
reference ranges. It actually works perfectly. I took the "ensure
initialized" route, as you suggested. I was able to take an
On Friday, 21 September 2012 at 13:19:55 UTC, monarch_dodra wrote:
QUESTION:
If I (were to) deprecate "save", how would that work with the
range traits type? If a range has "save", but it is deprecated,
does it answer true to isForwardRange?
Never mind I found out the answer: Using something
On Friday, September 21, 2012 15:20:49 monarch_dodra wrote:
> #3
> The only thing I'm having an issue with is "save". IMO, it is
> exceptionally dangerous to have a PRNG be a ForwardRange: It
> should only be saved if you have a damn good reason to do so. You
> can still "dup" if you want (manually
On Friday, 21 September 2012 at 19:47:16 UTC, Jonathan M Davis
wrote:
On Friday, September 21, 2012 15:20:49 monarch_dodra wrote:
#3
The only thing I'm having an issue with is "save". IMO, it is
exceptionally dangerous to have a PRNG be a ForwardRange: It
should only be saved if you have a damn
On Friday, 21 September 2012 at 19:47:16 UTC, Jonathan M Davis
wrote:
On Friday, September 21, 2012 15:20:49 monarch_dodra wrote:
#3
The only thing I'm having an issue with is "save". IMO, it is
exceptionally dangerous to have a PRNG be a ForwardRange: It
should only be saved if you have a damn
On 18/09/12 17:05, monarch_dodra wrote:
As you can see from the ouput, that is not very random. That's just the "tip of
the iceberg". *Anything* in phobos that iterates on a range, such a fill,
filter, or whatever, will not advance the PRNG, arguably breaking it.
At best, a "global" PRNG will wo
On Tuesday, 25 September 2012 at 16:15:24 UTC, Joseph Rushton
Wakeling wrote:
On 18/09/12 17:05, monarch_dodra wrote:
As you can see from the ouput, that is not very random. That's
just the "tip of
the iceberg". *Anything* in phobos that iterates on a range,
such a fill,
filter, or whatever, wi
On 25/09/12 18:36, monarch_dodra wrote:
Thank you for bringing it up. The problem is indeed as you said, and making the
PRNGs references types fixes it.
I have a pretty well developed first iteration. I hope that by the end of next
week, I'll have something to show.
That would be fantastic. I
On Thursday, 27 September 2012 at 10:06:54 UTC, Joseph Rushton
Wakeling wrote:
On 25/09/12 18:36, monarch_dodra wrote:
Thank you for bringing it up. The problem is indeed as you
said, and making the
PRNGs references types fixes it.
I have a pretty well developed first iteration. I hope that by
19 matches
Mail list logo
