Scientific computing: probability calculator - test 1 ordering?

[shapeshifter42]

I was convinced my code for populating and returning ‘contents’ worked just fine and was perplexed at failing test 1.

The test

        hat = prob_calculator.Hat(red=3,blue=2)
        actual = hat.contents
        expected = ["red","red","red","blue","blue"]

what my code returns: [‘blue’, ‘blue’, ‘red’, ‘red’, ‘red’]

The user is free to pass in balls of any colour with no restrictions. So I created init() to have a list of colour args that all default to zero. That makes it impossible to determine the order of balls in the call.

Each line in my init looks something like this:

        self.contents += ["blue"] * blue

So to pass the test I can just make sure red is processed first.

But this is very unsatisfactory and a massive fudge. I’ve also seen that test 3 (I haven’t got that far) creates a hat with those colour arguments reversed. Luckily it doesn’t test for contents again, but if it did there is no way I could ever pass all 3 tests in 1 pass.

You may disagree, but I would say my list and the test’s list are effectively the same (I hope to prove this when I implement def experiment()). If the test was just insisting on the list having the balls in alphabetical order that would be trivial to solve (ideally the test would do its own sort). But it just seems to be insisting on the order of balls in the container being the same order as passed in.

If I’m right, that would force me into a particular style of solution, when I should be free to implement as I choose as long as the spec is matched.

Am I missing something here?

[sanity]

Unfortunately experiment results will be different if the order of contents is different - number returned from random.randint will point to different ball, resulting in different set of balls being drawn.

Actually there’s an example in description:

For example, if your hat is {"red": 2, "blue": 1} , contents should be ["red", "red", "blue"] .

What if somebody would want to use purple balls? Or if they would use different language for colors than English?

There are some constraints on the implementation - yes, to some extent that’s always a case. This project has it particularly harder, as there’s the random factor.

[shapeshifter42]

tldr; order doesn’t matter: it passes all tests with either my original (out of order) or revised (preserved order) method.

My finished project

I’ve replaced my original method (using default params) with one using kwargs, which preserves the order the calling method asks for. I’ve also tested my finished project with my original method which gives the same SET of balls, but in a different ORDER.

“experiment results will be different if the order of contents is different”

Yes and no. Consider the following from the test:

hat = Hat(blue=3,red=2,green=6)
probability = experiment(hat=hat, expected_balls={“blue”:2,“green”:1}, num_balls_drawn=4, num_experiments=1000)
expected = 0.272

In a single draw, using both methods, the results are very likely to differ, just like rolling 2 dice. But just as 2 dice contain the same set of numbers, over many iterations (of either throwing dice or the above test) they both converge about the same result, as expected.

In fact, the draw() and experiment() part of this was very straight-forward, not sure why so many people had issues here. No need to worry about seeding random number generators or anything. The only bit that caught me out was that I was initially coding against the draw for a MATCHING NUMBER of balls, when it should be using (for the above example) >= 2, >= 1

I still maintain that the first test should test for the SET of items, not a fixed order.

But I’ll concede sanity’s point about arbitrary ball types (one of the tests has a ‘test’ ball), although I’m not sure the spec suggested this could happen.