Create a choose function

[ntoll]

Many games that kids make require randomly choosing something from a collection. We should make this easy for them to do by implementing something akin to Python's own random.choice function.

Something like the following straw man perhaps..?

microbit.choose takes a collection and returns a randomly selected item therein (or key, in the case of a dict).

Why not choice? Because choose will sit in the microbit namespace and microbit.choose (i.e. let the microbit choose) feels more natural to read than choice (to my eyes at least). Also, choose is imperative.

[whaleygeek]

why not random.choice() just like normal python?

[ntoll]

There was some discussion about this on the mailing list. I think the problem is that we'd be setting a precedent by starting to implement "random" (no pun intended) bits of the standard library as single methods in modules. It was felt that a top level choose function would be more 11yo-friendly and there wouldn't be too much mental-dissonance in moving to real Python because "now we have a standard library, all the random related stuff is in its own namespace".

Make sense..?

[dpgeorge]

Coming back to this, I'm now of the opinion that we should implement the random module with a few useful functions, such as:

random.seed(a)
random.randint(a, b) # int in [a..b]
random.choice(seq) # one of seq
random.random() # float in [0..1)
random.uniform(a, b) # float in [a..b]

This should use a pseudo RNG that can be re-seeded in a repeatable way (unlike the microbit.random(n) function which is seeded automatically by a real RNG).

Note that this random module would be in addition to the existing microbit.random() function.

[ntoll]

We'd need to make it very clear that this is different to the built-in microbit.random although I quite like that we get random.choice.

+1 :-)

[dpgeorge]

Probably microbit.random should be renamed... something like microbit.random_number?

[ntoll]

+1

[markshannon]

Why not just get rid of microbit.random? Only one way to do it, etc...

[dpgeorge]

Why not just get rid of microbit.random? Only one way to do it, etc...

Same question for microbit.sleep (could be time.sleep...). Same answer: need to have a very low barrier of entry for basic stuff (you can argue if random is basic or not :)

Also, fro a technical point of view, random module is based on a repeatable PRNG. Whilst microbit.random is supposed to be derived from the hardware RNG (and it sort of is...).

[markshannon]

According to the docs if seed is set to None, than a "random source provided by the operating system" is used. In other words it can be either repeatable, or use genuine randomness.

[dpgeorge]

According to the docs if seed is set to None, than a "random source provided by the operating system" is used. In other words it can be either repeatable, or use genuine randomness.

That's just for setting the seed (either given by the user, or seeded from the system time, or from os.urandom). The actual generator itself must be repeatable.

[markshannon]

Both the standard Mersenne twister and the linear congruent generator in the DAL are deterministic.

[dpgeorge]

The DAL's PRNG is seeded by the hardware RNG. But that's exactly the same as Python's semantics for the random module... so maybe we should just have a random module only (with standard CPython functions, sourced by the DAL's implementation), and no microbit.random function?

How much will microbit.random be missed? Is it too much to ask users to do "import random" then "random.randrange(N)" instead? (And they also get lots of other useful random functions as well.)

[ntoll]

Given this is more like "real" Python then I'm inclined to go with your suggestion.

[ntoll]

Fixed by #167