o.uniform should take a seed/state

[maccallum]

o.uniform should take a seed and state. If the /seed address is in the bundle, it should seed srand(). If /state is also in the bundle, it should wind forward by calling rand() that many times before outputting. This will allow people to reproduce pseudo-random sequences.

[adrianfreed]

Can this be designed so the output teaches this input api?

On Jun 13, 2014, at 5:30 PM, John MacCallum notifications@github.com wrote:

o.uniform should take a seed and state. If the /seed address is in the bundle, it should seed srand(). If /state is also in the bundle, it should wind forward by calling rand() that many times before outputting. This will allow people to reproduce pseudo-random sequences.

— Reply to this email directly or view it on GitHub.

[ilzxc]

Yes. I'll take care of it later on tonight and push an RFC.

On Jun 13, 2014, at 6:11 PM, Adrian Freed notifications@github.com wrote:

Can this be designed so the output teaches this input api?

On Jun 13, 2014, at 5:30 PM, John MacCallum notifications@github.com wrote:

o.uniform should take a seed and state. If the /seed address is in the bundle, it should seed srand(). If /state is also in the bundle, it should wind forward by calling rand() that many times before outputting. This will allow people to reproduce pseudo-random sequences.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[ilzxc]

RFC:

the problem with /seed and /state:

In our use of odot, more and more do we rely on throwing the results of our of patches up to an o.var or such. If there's an o.uniform in your stuff and you keep giving it /seed or /state it will become super-duper annoying.

proposed solution:

• dedicated addresses - injecting /uniform/set/seed and/or /uniform/set/state will alter the state;
• peel off these addresses - the output of o.uniform makes these be /uniform/seed and /uniform/state to avoid resets when undesirable.

A build for RFC will be emailed to John & Adrian (available upon request). Source code already checked in.

[adrianfreed]

We could be trying to copy the wrong API from Linux/Posix. Please look at this: http://man7.org/linux/man-pages/man3/drand48.3.html

[adrianfreed]

Note that the library functions aren't thread safe so these initializations might not work as expected (i.e. reproducing a previous pseudorandom sequence.

It's tempting to implement the whole thing explicitly as an abstraction according to that Posix spec. Then people can strip the state off if they want to be secretive about where the random number come from.

[ilzxc]

One thing I noticed when testing, two instances of o.uniform will correctly yield the same pseudo-random number when receiving identical seeds and state variables. (Will attach a Max patch when I get my laptop back.) However, if you were to bang these objects, consequent numbers become different. I have looked over my code and am unable to explain this behavior.

On Jun 14, 2014, at 3:10 PM, Adrian Freed notifications@github.com wrote:

Note that the library functions aren't thread safe so these initializations might not work as expected (i.e. reproducing a previous pseudorandom sequence.

It's tempting to implement the whole thing explicitly as an abstraction according to that Posix spec. Then people can strip the state off if they want to be secretive about where the random number come from. — Reply to this email directly or view it on GitHub.

[adrianfreed]

I think we should put off the seed/state api until the next release when there should be a wide range of distributions and random sources. It is hard to say what we should promise and what we can deliver with o.uniform without more work than we have time for.

On Jun 14, 2014, at 5:07 PM, ilya notifications@github.com wrote:

One thing I noticed when testing, two instances of o.uniform will correctly yield the same pseudo-random number when receiving identical seeds and state variables. (Will attach a Max patch when I get my laptop back.) However, if you were to bang these objects, consequent numbers become different. I have looked over my code and am unable to explain this behavior.

On Jun 14, 2014, at 3:10 PM, Adrian Freed notifications@github.com wrote:

Note that the library functions aren't thread safe so these initializations might not work as expected (i.e. reproducing a previous pseudorandom sequence.

It's tempting to implement the whole thing explicitly as an abstraction according to that Posix spec. Then people can strip the state off if they want to be secretive about where the random number come from. — Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

[ilzxc]

Adrian: I'm not opposed to this at all. To clarify - no o.uniform at all, then? Should I revert back to the old one that operates like the abstraction in the repo? I'm going to prioritize the o.listiter external tonight and tomorrow, but will look over boost::random in particular and report back re-o.uniform in v2.0.

[adrianfreed]

How about o.uniform seeded with entropy of some kind and then for 2.0 an o.rng with whatever we understand by then to be best practices with all this seed/state stuff and distributions etc.

My main feature request for that one is that we support the distribution that randomly chooses a distribution and pulls a number from that distribution. This is known as the Freed distribution because you are freed of thinking about what distribution you want the number to come from.

On Jun 14, 2014, at 9:46 PM, ilya notifications@github.com wrote:

Adrian: I'm not opposed to this at all. To clarify - no o.uniform at all, then? Should I revert back to the old one that operates like the abstraction in the repo? I'm going to prioritize the o.listiter external tonight and tomorrow, but will look over boost::random in particular and report back re-o.uniform in v2.0.

— Reply to this email directly or view it on GitHub.

[adrianfreed]

Since RNGs can be implemented with the core as it stands, the only new primitive really needed for "o." is o.entropy to slip information about the "real world" into the computation.

On Jun 15, 2014, at 9:52 AM, Adrian Freed adrian@adrianfreed.com wrote:

How about o.uniform seeded with entropy of some kind and then for 2.0 an o.rng with whatever we understand by then to be best practices with all this seed/state stuff and distributions etc.

My main feature request for that one is that we support the distribution that randomly chooses a distribution and pulls a number from that distribution. This is known as the Freed distribution because you are freed of thinking about what distribution you want the number to come from.

On Jun 14, 2014, at 9:46 PM, ilya notifications@github.com wrote:

Adrian: I'm not opposed to this at all. To clarify - no o.uniform at all, then? Should I revert back to the old one that operates like the abstraction in the repo? I'm going to prioritize the o.listiter external tonight and tomorrow, but will look over boost::random in particular and report back re-o.uniform in v2.0.

— Reply to this email directly or view it on GitHub.

[maccallum]

I like this o.entropy idea, but I'd like to bottleneck all information leaked from the environment through o.context. o.context should provide the time, the current state of the cycle counter, and, where possible, information about the trackpad, the gyros if present, etc etc. Those could be used to implement an o.uniform in whatever host environment we're in.

So, I'd like to propose that we remove o.uniform as an external and go back to a wrapper around Max's random object for now.

[adrianfreed]

agreed

I have retagged the issue for release 2.0 so we can return to it later.

[maccallum]

Odot should provide the bare minimum support for random number generation, and o.uniform in its current state provides that support. There's a mention of some anxiety in one of the comments above that this creates a dependency on a Max external, but I would say that this is the right way to do this, by wrapping whatever is available in the host. Additional support should be provided by external libraries like https://github.com/maccallum/x