Proposal: Add getStdGenState and stdGenFromState

[John Meacham]

yes, bytestring makse sense. Just include a note that when presented a
bytestring not generated by stdGenToState stdGenFromState will utilize
the data in the bytestring to seed the RNG in an unspecified
implementation defined fashion. So we can use it to feed arbitrary
seed data into the RNG as well as re-create a specific previous state.
So if it isn't of just the right size, feed it to a hash to get an
appropriate one. I'd recommend the 64 bit mix function from this page
http://www.concentric.net/~ttwang/tech/inthash.htm, nice and simple
and reversible. quite handy.

   John

On Tue, Feb 7, 2012 at 2:04 PM, wren ng thornton <wren at freegeek.org> wrote:
> On 2/6/12 1:36 PM, Tyson Whitehead wrote:
>>
>> Jumping in without having paid much attention to the thread or API, but I
>> expect [Word8] (ByteString?) would fit the general case better than
>> [Int32]
>
>
> I'd second the vote for ByteString. If the goal is to dump a bunch of bits
> without declaring how many there are beforehand, then ByteString is exactly
> the right interface for that. If the goal is to serialize things
> efficiently, then ByteString is one of the better target representations for
> that[1]. I don't know what exactly StdGen is storing under the hood, but I
> don't imagine that it really has the semantic structure of a list of Int32.
>
>
> [1] Depending on the details of what all you need exactly, it may not be the
> best. For example, if the semantic interpretation of the bits is
> non-uniform, then you'll probably want an intermediate structure which
> expresses the non-uniform chunks; and from there you'll almost surely need
> to start worrying about things like versioning of the format etc.
>
> --
> Live well,
> ~wren
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries