The last few posts in this Simple Tricks series were perhaps a bit less than simple, so this month, here at the end of the year, I’m going to take it easy and enjoy the season. (I hope you are doing so as well!)

I’ve put together a random grab bag of little bits and pieces of Python. Nothing too complicated. And in all honesty, probably nothing terribly interesting or that useful, either. But you may find some of the approaches helpful.

First up, just some simple functions for vetting an object as a number of the desired type (converting if possible). Perhaps a set of functions or methods expects a certain type of number. Rather than writing the same vetting code for each one, write a general function they all call. Suppose our functions expect integers:

The SafeInt function (lines #1 to #17) takes an object and checks to see if it’s an integer (lines #5 & #6) or a float (line #9 & #10). It returns the object as is if it’s an integer or converts it to an integer if it’s a float. Note the use of round rather than int to convert a float to the nearest integer.

Next (lines #13 & #14), we check to see if the object is a numeric string and, if so, use the int function to convert it. Finally, if we can’t identify the object, we return zero (line #17).

When run, this prints:

4:int      -> 4:int
4.4:float  -> 4:int
4.5:float  -> 4:int
4.6:float  -> 5:int
4:str      -> 4:int
4.5:str    -> 0:int
-4:str     -> 0:int
+4:str     -> 0:int

The function is simplistic and fails on otherwise legit cases due to a leading plus or minus. And it doesn’t return the same thing for the string “4.5” as it does for the float 4.5. The problem is that the str.isnumeric test fails on a leading plus or minus. We can improve on the first problem like this:

Now, if it’s a string, we try to convert it inside a try block and simply continue if the attempt fails (lines #14 to #19). Otherwise, we return the integer value (line #17). To avoid an error from converting a number with a decimal, we chop off one if found (lines #15 & #16).

When run, this prints:

4:int      -> 4:int
4.4:float  -> 4:int
4.5:float  -> 4:int
4.6:float  -> 5:int
4:str      -> 4:int
4.5:str    -> 4:int
4.6:str    -> 4:int
-4:str     -> -4:int
+4:str     -> 4:int

Note that we still have a difference between the float 4.6 and the string “4.6”. It’s possible to fix this, but it makes the string-handling part a lot messier. Basically, if the string has a decimal point, convert using the float function and then use the round function to return an integer. Otherwise, use the int function as above.

Using the same pattern, we could also write a SafeFloat or a SafeComplex function. In fact, the basic pattern, a small function with a series of checks with multiple return points is one I find very useful, but which is viewed negatively from the purist point of view that functions must have only one return point. To the contrary, I find the ability to jump out of a function useful and clear. Far more readable than the gyrations often required to get all control flows to the one and only final return.

The general pattern looks either like this:

function check_good (value)
begin
    if condition1(value) then return TRUE
    if condition2(value) then return TRUE
    if condition3(value) then return TRUE
    return FALSE
end function

Or like this:

function check_bad (value)
begin
    if condition1(value) then return FALSE
    if condition2(value) then return FALSE
    if condition3(value) then return FALSE
    return TRUE
end function

In the first example, we’re looking for a special value that matches some condition. For example, looking for certain words. In the second, we’re looking for conditions that falsify the value. For example, we might want to reject unprintable characters. The SafeInt function is an example of the former.

There’s a math puzzle that goes: Given the numbers 1 to 1000, does any digit appear the most times?

At first glance, one might think all digits appear an equal number of times. Which turns out to not be unreasonable. But in this case, the digit “1” appears 301 time compared to the digits “2” through “9”, which appear 300 times. Since no number begins with “0”, there are always fewer zeros. In this case, 192 occurrences.

However, if the question uses the numbers from 1 to 999, then the digits “1” to “9” all appear 300 times. The “0” still lags behind with 189 occurrences.

More to the point, if one is a Python programmer, this is an easy problem to solve:

The code should be largely self-explanatory. The number_of_digits function starts by initializing a histogram vector to keep track of ten digits (line #3). Then it just iterates through the number range, converts each number to a string, and scans the string to count the digits (lines #5 to #7). Then it prints the histogram results (lines #9 to #12) and figures out if any digit won (lines #14 to #21).

When run, this prints:

Numbers: 1 to 999
0: 189
1: 300
2: 300
3: 300
4: 300
5: 300
6: 300
7: 300
8: 300
9: 300

No winner: 9 digits with 300 occurrences

Numbers: 1 to 1000
0: 192
1: 301
2: 300
3: 300
4: 300
5: 300
6: 300
7: 300
8: 300
9: 300

Winner: The digit 1 with 301 occurrences

If you’re the sort of person who runs into a little math puzzle like this, and one of the first thoughts you have is how you could write code to solve it … then you’re probably thinking like a programmer.

Speaking of math puzzles, a famous one is the Monty Hall Three-Door Problem. The problem got notoriety when it appeared in the Parade magazine “Ask Marilyn” column in 1990. There was a bruhaha over the answer Marilyn vos Savant gave — many well-trained readers disagreed with her, often disdainfully to their later shame.

Once again, thinking like programmers, we can simulate the problem:

At the top (lines #6 to #9) we initialize some variables. We’ll use the strings ‘goat’ and ‘car’ and put them in a three-item list to represent the three doors. In lines #12 to #20, we generate n_times sets of door lists. In line #14, we initialize doors to have three goats, but in line #17 we randomly change one to a car. (Doing it this way is just a bit easier than trying to generate a random list of two goats and one car.) Line #20 appends each list of three doors to the list of tries.

In lines #23 to #30 we go over all the tries to see how many times a car is behind each door. If our generating routine was good, it should be one-third of the time.

Lines #33 to #67 comprise a large for loop that iterates over the tries. In it, we start by picking a door (line #35). Then Monty Hall (who knows what’s behind each door), opens a door other than the one we picked, and this door has a goat behind it. Line #38 generates a list of all doors in the current try that do not have a car and are not the door we picked. Line #41 picks one of those randomly.

If our strategy is to switch doors (lines #44 to#56), then we calculate the other door number (line #46) and see if it has a car behind it (line #49). If it does, we win.

If our strategy is to keep the door we first picked (lines #59 to #67), then we see if a car is behind that door (line #61).

The function takes three parameters: switch_doors, a Boolean that determines our strategy; n_times, the number of tries to make; and verbose, a Boolean flag that allows monitoring the function.

We run our simulation twice, once keeping the picked door and once swapping:

When run, this prints:

Run {N} tests and KEEP the door we pick.
Doors: [1]=66,823, [2]=66,929, [3]=66,248; tries=200,000
tries: 200,000, wins: 66,699 (33.349500 %)

Run {N} tests and CHANGE the door we pick.
Doors: [1]=66,783, [2]=66,640, [3]=66,577; tries=200,000
tries: 200,000, wins: 133,238 (66.619000 %)

The results are clear. We see firstly that the car is evenly distributed between all three doors. More importantly, we see that when we stay with the door we picked, we win only 33% of the time, but when we swap, we win 66% of the time.

Despite the initially counter-intuitive sense that swapping can’t possibly help, in fact it doubles your chances.

If we use larger values for N, the tests take a bit of time to run (depending on the speed of system, as always). If we’re curious how long these tests take, there’s a handy Python library function you can use, timeit:

The timeit function is a little weird in that it expects text, not code. The simplest way around this is, as done here, to put the code to test in a function, and then just call that function in the string passed to timeit.

When run, this prints:

Run {N} tests and KEEP the door we pick.
Doors: [1]=333,547, [2]=332,738, [3]=333,715; tries=1,000,000
tries: 1,000,000, wins: 333,284 (33.328400 %)

Run {N} tests and CHANGE the door we pick.
Doors: [1]=333,411, [2]=333,306, [3]=333,283; tries=1,000,000
tries: 1,000,000, wins: 666,328 (66.632800 %)

ts0=2.594643, ts1=2.584221

Running the test with one million tries takes about two-and-a-half seconds. And, of course, we got the same results. The larger value for N makes them even closer to the predicted values.

I’ll leave you with a little useless cuteness that tests the limits of recursion:

These are three examples of tail recursion. In all three cases, if the list of numbers passed to the function is of length one, then that single list element is returned. Otherwise (list has more than one element), the return value is the first item in the list operating on the remainder of the list.

Take the time to be sure you understand how these functions work; they are the soul of recursion and functional programming. Note that, in the “main” code, we’re invoking the functions with a list of numbers that’s longer each time the function is called.

Note that the limit on recursion limits how large a list these functions can handle.

Link: Zip file containing all code fragments used in this post.

∅