The Rubber Duck of Despair

Python Dev Environment: Virtualenv and Wrapper

2018-01-22T00:00:00+00:00

So you want to do some Python

Have you ever searched the web for a recipe, like for Kung Pao Chicken, and the top few links all have like 4.8 stars with 500+ reviews? Then you go to a link and it ends up being 184 pictures with an 18,900 word narrative about cooking Kung Pao chicken and some random stuff about how the family cat helps with the cooking and at the end is a note-card size recipe. I’m not going to do that here–but I think virtual environments require at least a little introduction matter. I’ll keep the intro short and try to get to the important stuff quickly.

Python Virtual Environments

There are a number of ways to do virtual environments in Python–“virtualenv”, “venv”, and even Anaconda/Conda. This is the set up that currently works for me. Even if you don’t end up using a setup exactly like this I hope you’ll at least come away with a better understanding of how these environment work and how to make them work better for you.

For starters a virtual environment is really a two way street. It lets you limit and know exactly what and which versions of python components you are using and also lets you work with many different components and versions of the same components without creating a mess of inconisitent packages and versions. Assuming you already have pip installed you can start to get a general idea of where v-envs take you by running pip list then pip list --user. The first will show all packages installed, the second will show only the “user” level packages installed. V-envs will add another layer and a big reason for it is to keep from just throwing more and more stuff into the global or user scope.

The Problem–This comes with a bit of a hidden cost that can be frustrating at first. Tools and applications you may be used to using don’t understand that they are in a virtual environment. So you fire up idle or a jupyter notebook and can’t get it to load the code you just wrote or the package you just installed in your virtual environment. So, we’ll fix that.

Software Install (Back to the main story)

Well we’re going to start off by installing all the stuff you’ll need to get started. All of this assumes you’re running inside a terminal.

The first items are the OS level stuff. sudo is used to run stuff as “root”–you’re essentially installing items that will go into system wide directories/usage. It is highly likely that some, if not all, of these are already installed–apt will simply tell you if they are and not do anything.

I won’t be covering any “git” stuff, but you’ll likely want it at some point (and gitk is just a nice tool for looking at info for a local git repo). Git doesn’t actually require any configuration to work inside a virtual environment–essentially it is like a honey-badger and just doesn’t care.

I will cover config for both Idle and Jupyter–if you use other tools they may need similar config changes to work and I hope these two as examples will at least be a good starting point.

sudo apt-get install python3
sudo apt-get install python-pip python3-pip 
sudo apt-get install git gitk idle3 idle

Now for the “user” stuff. pip and pip3 install python packages; the “–user” flag installs it to your local user python “stuff”. There isn’t really any major compelling reason to not install this stuff system wide–but it really doesn’t hurt to get into the habit of not installing everything globally.

pip install --upgrade pip --user
pip3 install --upgrade pip --user
pip install virtualenv virtualenvwrapper --user
pip3 install virtualenv ipython3 virtualenvwrapper jupyter --user

Configuration: A bunch of nitty-gritty in one place

I’m going to start with the virtual environment set up then we’ll quickly set up idle for v-envs. After that I’ll do a quick whirl-wind tour of what we’ve done and basics of using this type of setup. Finally, I’ll do the jupyter notebook set up–which is a bit more complex.

One: Create some directories

As your usual user (i.e. not as root); in your home directory (just type cd to get there if you aren’t there already) we need to create two directories. So run . . .

mkdir py_envs
mkdir .virtualenv

TWO: Edit .bashrc

The .bashrc file is a special file/script that gets run anytime you start a new terminal session. It is found in your home directory but is usually hidden because it starts with a “.” (you can see that sort of file with ls -l). Anyway edit it with idle .bashrc and add the following lines at the end . . .

export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/py_envs
source /usr/local/bin/virtualenvwrapper.sh
alias vw='virtualenvwrapper'

You can use Ctrl-s Ctrl-q to save and quit. Then just run source .bashrc. (The “source” command is a funky bit of magic that will run a file in your current session/environment–usually if you run a script or program it gets its own environment which goes away once the script/program exits. In this case we are actually changing our current shell environment. You will not need to do that if you start a new terminal as the new session will run the new modified .bashrc.)

When you run source .bashrc you should see it do a few things to your .virtualenvs directory. That is from the “source /usr/local/bin/virtualenvwrapper.sh” line. The source command is again used here to essentially keep the results of virtualenvwrapper.sh as part of your environment.

The last line added to the .bashrc file is simply an alias–lets you just type “vw” rather than “virtualenvwrapper”. At this point you can actually just run vw–it doesn’t actually do anything except show you all the commands available in the “virtualenvwrapper” system. We have more configuration to do but it is a good sneak peak at what we’re getting to.

THREE: Configure some virtualenv items

Final config stuff. Go into your .virtualenvs directory (cd .virtualenvs); and just to see what is there type ls. You should see a bunch of things like “postactivate” and “premkproject”. These are all files that are run/launched because of various virtual environment actions (their names pretty much explain when). We’ll be editing 2 of them:

idle postactivate

add:

PROJECT_SOURCE=`cat "$VIRTUAL_ENV/.project"`

cd () {
    if (( $# == 0 ))
    then
        builtin cd $PROJECT_SOURCE
    else
        builtin cd "$@"
    fi
}

cd

#if [ ! -d "notebooks" ]; then
#  mkdir notebooks
#fi

#jupyter-notebook notebooks/ > /dev/null 2>&1 &
#echo $! > notebooks/pid.file 

The last five lines are actually commented out. If you remove the pound signs they’d create a notebooks directory in your virtual environment and also launch jupyter notebook anytime you activeate your environment. Only useful if you really use notebooks a lot.

The uncommented lines at the start make it so the “cd” command will put you back in your virtual environments root directory (rather than your home directory).

idle postdeactivate

add:

#NPID=`cat "$PROJECT_SOURCE/notebooks/pid.file"`

#kill -9 $NPID 

unset -f cd

This essentially reverses the items from postactivate. The commented lines would kill the notebook server if you are running it. The uncommented line sets the “cd” command back to normal.

FOUR: Edit Idle

So, we’re actually done with the v-env setup. But we still need to get idle to work in a virtual environment.

Again, if you aren’t in your user’s home directory type cd to get there. Then run mkdir bin. Now run cp /usr/bin/idle bin/ – so we’ve just copied the OS/global version of idle to your personal user’s bin directory. Now run idle bin/idle and change the first line from “#! /usr/bin/python” to “#!/usr/bin/env python”. Ctrl-S Ctrl-Q to save and quit. (Yes that was some inception level shit right there.)

What this does: Your user’s “bin” directory should be the first in your path–so running “idle” will now use ~/bin/idle. (You can run which idle to verify that.) Changing the first line makes it so idle will use your current environments python–this will work from inside a virtual environment or when you are not in a virtual environment.

The one big reason to do this in your user’s bin directory is so that when idle gets updated your changes won’t get squashed.

. . . and we’re done

So, that is it, virtualenv and virtualenvwrapper are now ready to go.

But wait, there is more . . .

So now you can type vw again just to see what the general commands are and their descripts. We’re going to start with mkproject first_test. . . . And it will create your virtualenv and put you in its directory. Your command line should now start with “(first_test)”. Now run pip list–not much there. And a few more things to try . . .

lssitepackages
toggleglobalsitepackages followed by pip list then togglegloabalsitepackages again–“toggle…” will essentially add your global site packages to your environment. Can be useful at times. (And if you aren’t familiar with “tab-completion” try just toggl[tab] so you don’t have to type all that.)
cdsitepackages; ls; cd–“cdsite…” is occasionally useful, but the main point here is that cd, at least for now, returns you to your venv directory and not your user’s home directory.

And finally run deactivate. This takes you out of your virtual environment (although you’ll still be in its directory). Now run mkproject second_test. You can run some of the previous commands again but they’ll pretty much show the same stuff. So run deactivate again.

Now–the command you’ll really need–run workon [TAB]. You should get a list of your v-envs. Continuing by type f[TAB] should auto-complete to “workon first_test”. Hit [ENTER] and we’re back in the first_test v-env.

And now for something completely different

While still in “first_test” run idle np_test.py &. Then type or paste . . .

import numpy as np

np_array = np.array([0, 2, 4, 5])
print(np_array)

Then hit [f5] to run the code. Even if you have numpy already installed outside your v-env you will get an error. So go back to the terminal (where it starts with (first_test)) and run pip install numpy (you can then run pip list again). Now go back to the file in idle and hit [f5] again.

You’ve now installed numpy in your virtual environment.

At this point you can try some commands like pip freeze, then wipeenv followed by pip list (numpy should be gone).

As far as “idle”

http://zafar.cc/2016/12/13/python-virtual-environment-and-jupyter-notebooks/

[‘/home/jack/.virtualenvs/numbers/lib/python3.5/site-packages’, ‘’, ‘/usr/lib/python35.zip’, ‘/usr/lib/python3.5’, ‘/usr/lib/python3.5/plat-x86_64-linux-gnu’, ‘/usr/lib/python3.5/lib-dynload’, ‘/home/jack/.local/lib/python3.5/site-packages’, ‘/usr/local/lib/python3.5/dist-packages’, ‘/usr/lib/python3/dist-packages’, ‘/home/jack/.local/lib/python3.5/site-packages/IPython/extensions’, ‘/home/jack/.ipython’]

sys.path = [ ‘/home/jack/venvs/numbers/notebooks’, ‘/home/jack/.virtualenvs/numbers/lib/python35.zip’, ‘/home/jack/.virtualenvs/numbers/lib/python3.5’, ‘/home/jack/.virtualenvs/numbers/lib/python3.5/plat-x86_64-linux-gnu’, ‘/home/jack/.virtualenvs/numbers/lib/python3.5/lib-dynload’, ‘/usr/lib/python3.5’, ‘/usr/lib/python3.5/plat-x86_64-linux-gnu’, ‘/home/jack/.virtualenvs/numbers/lib/python3.5/site-packages’, ‘/home/jack/.virtualenvs/numbers/lib/python3.5/site-packages/bookofnumbers-0.1.0-py3.5.egg’, ‘/home/jack/.local/lib/python3.5/site-packages’, ‘/usr/local/lib/python3.5/dist-packages’, ‘/usr/lib/python3/dist-packages’, ] USER_BASE: ‘/home/jack/.local’ (exists) USER_SITE: ‘/home/jack/.local/lib/python3.5/site-packages’ (exists) ENABLE_USER_SITE: True

CDNF Part II: Take the namedtuples bowling

2017-09-01T00:00:00+00:00

Reducing from Normal Form

The basics of reducing is that you need two terms like ABC and ABC’. This can be reduced to AB(C + C’). In Logic (C + C’) evaluates to 1–so you have AB(1) which is AB. Essentially the C and C’ cancel each other so you go from 2 terms, ABC and ABC’, to one term AB.

The general rules are:

Individual inputs must have a 1 to 1 match for inputs/letters. So ABC and ABD fail on this front.
Of the inputs only one can differ in its primed vs. unprimed form. So ABC and AB’C’ cannot be reduced. Extracting (C + C’) in this case leaves us with AB + AB’–which simply goes against the rules.
Finally, when performing reductions, terms of any generation can be used multiple times to come up with new terms.

I hope to make a lot of this clearer shortly, but for starters it is important to note that each generation will have the same number of inputs as all other items in the generation. For the bowling example the 1st generation will all have 4 inputs (and will also have the same set of inputs A, B, C, and D). 2nd generation will have 3 inputs–however, because of reduction, the set of inputs will not necessarily match. You could have terms with ABC and other terms with ACD. The 3rd generation will have 2 inputs in each term.

Situation 1 as an Example

So for Situation 1 we have the following terms in the 1st generation:

                ones    Ancestors
  ABCD       4       1
  ABCD'      3       2
  ABC'D      3       3
  ABC'D'     2       4
  AB'CD      3       5
  AB'CD'     2       6
  AB'C'D     2       7

Term 1 (ABCD) can be “minimized” with 3 other terms; 2, 3, and 5 (ABCD’, ABC’D, and AB’CD)–each of which differ from ABCD by having only 1 “primed” term. This results in 3 new 2nd generation terms–ABC, ABD, and ACD. ABC is derived from Term 1 (ABCD) and Term2 (ABCD’) to get ABC(D + D’) == ABC. ABD is T1 (ABCD) and T3 (ABC’D)–>ABD, etc.

Term 4 – Term2 and Term3 to get ABD’ and ABC’

Term 6 – Term2 and Term5 to get ACD’ and AB’C

Term 7 – Term3 and Term5 to get AC’D and AB’D

Generation 2 looks like:

            ones    Ancestors
 ABC     3       1, 2
 ABD     3       1, 3
ACD     3       1, 5
ABD'    2       4, 2
ABC'    2       4, 3
ACD'    2       6, 2
AB'C    2       6, 5
AC'D    2       7, 3
AB'D    2       7, 5

So for generation 2 we only have . . .

Term9 (ABD) and Term11 (ABD’) –> AB Ancestors(Term1, Term3, Term2, Term4)
Term10 (ACD) and Term13 (ACD’) –> AC Ancestors(Term2, Term6, Term1, Term5)
Term10 (ACD) and Term15 (AC’D) –> AD Ancestors(Term7, Term5, Term1, Term5)

Generation 3 ends up being:

            ones    Ancestors
AB      2       1, 3, 2, 4
AC      2       2, 6, 1, 5
AD      2       7, 5, 1, 5

For future reference things to note . . .

The ones column essentially helps us with Rule 2 above–terms can only differ by 1 item. ABC (111) has 3 ones, it can not be reduced with AB’C’ (100) as there is more than 1 different item (it has one 1). It can be compared with AB’C (101) as there are 2 ones. It could also be compared with ABD’ (11-0) but would fail based on rule 1.
The other item, may be the most important, is the ancestors. To form a complete reduction we need to have all the minterms from our original canonical form (generation 1) represented in our reduced terms. In this case generation 3; AB, AC, and AD; cover all 7 terms from the original canonical form. The ancestor lists for those 3 terms include 1, 2, 3, 4, 5, 6, and 7.
There is also no point in doing redundant minimizations. Term 8 (ABC) for example can be used to reduce with Term12 (ABC’) and Term14 (AB’C). But reducing T8 with T12 giving AB with 1, 2, 3, 4 as ancestors is the same as reducing T9 (ABD) with T11 (ABD’) with 1, 2, 3, 4 as ancestors. T8 with T14 similarly is the same as T10 and T13 to get AC with 1, 2, 5, 6 as ancestors.

Back to why this matters

It seems the most common case and use for reducing from a canonical form is with electronics/circuits. But as part of that whole “Turing Machine” thing it is actually something that occurs almost constantly in code–more often than not we are dealing with simpler cases and intuitively arrive at a minimized or close to minimized form.

Quine-McCluskey and Petrick’s Method (finally)

First some links:

In a nutshell–getting to a final minimized form involves using Quine-McClusky to reduce your terms from the canonical form. Once no more reduction is possible Petrick’s Method can be used to select a set of terms that will “cover” all the terms from the original canonical form.

Now for some code

So, we finally get to the namedtuple portion of our program. Throughout my implementation a list of namedtuples (term_list) is used for storing information on the terms and the reductions. The tuples definition is:

Term = namedtuple('Term', 'termset used ones source generation final')

Some of the named fields should be familiar from the example above. The major use for this is for the term_list variable that stores all of our generations and reductions. Within our “namedtuple” Term the fields are . . .

termset – these are actual python sets that will contain the inidividual inputs for a term. So ABC would be (“A”, “B”, “C”), ABD’ would be (“A”, “B”, “D’”).
used – this will be True or False. If a term is “used” that means it was used to create a term for a later generation and can be ignored in finding our final reduction.
ones – A simple count of the number of 1s or un-primed inputs. ABC would have this as 3, ABD’ would have it as 2. Ultimately we sort each generation by the “ones” column.
source – specifies which terms were used in creating this term. Generation 1 terms will have source set to themselves. Gen 2 would have items like (0, 3), Gen 3 would have (0, 3, 2, 4), etc.
generation – simply the generation of this item
final – by default it is “None”. After processing the items needed for our final reduction will have either “Required” or “Added” in this field.

The basic layout of the code/functions is . . .

quinemc()

To perform a reduction you’d simply call quinemc . . .

def quinemc(myitem, highorder_a=True, full_results=False):

myitem – can be an int, a string containing a canonical form, or a list containing terms from a canonical form. If you provide an int quinemc will call canonical(myitem) to get the canonical form. If you provide a string or list you’ll get an error if it is not a true canonical form (e.g. “ABC + ABD”).
highorder_a – like canonical() this determines whether A is the highorder bit or loworder bit. Default is A as highorder.
full_results – The default (False) simply returns the reduced form as a string. If set to True quinemc() returns 3 items
- A string of the reduced form
- The term_list list–a list containing all of the Term namedtuples
- For some reductions there will be multiple ways to create a final form. If this is the case the 3rd item will be a dictionary containing all of the possible completions.

Examples

quinemc(65024)
quinemc("ABCD + ABCD' + ABC'D + ABC'D' + AB'CD + AB'CD' + AB'C'D")
quinemc(["ABCD", "ABCD'", "ABC'D", "ABC'D'", "AB'CD", "AB'CD'", "AB'C'D"])
a, b, c = quinemc(65024, full_results=True)

All 4 are equivalent and give “AB + AC + AD” as a result.

quinemc() itself just validates that the input is either an int, string, or list. Then also validates that the input item is in fact a canonical form (lines 11-14). From there it simply calls _minimize_() where the real processing takes place. In case you are wondering the cdnf variable is just a list of the terms like . . .

['ABCD', "ABCD'", "ABC'D", "ABC'D'", "AB'CD", "AB'CD'", "AB'C'D"]

_minimize_()

_minimize_() is essentially the driver function. It simply calls 3 other functions. The first two (in order), _create_first_generation_ and _merge_terms_ are the Quine-McCluskey portion. The last, _implicants_, is the Petrick method portion that finds our final result(s).

The final bit of code handles special cases. The first is for a zero input. The second is for cases like quinemc(15) or quinemc(255) where all the terms end up canceling out.

_create_first_generation_()

For our first step we are simply taking the terms from our canonical form and putting them into the term_list namedtuple. For situation 1, quinemc(65024), we get a 1st gen term_list of . . .

Term(termset={"C'", 'A', 'B', "D'"}, used=False, ones=2, source=[0], generation=1, final=None)  
Term(termset={'A', 'C', "D'", "B'"}, used=False, ones=2, source=[1], generation=1, final=None)  
Term(termset={"C'", 'A', "B'", 'D'}, used=False, ones=2, source=[2], generation=1, final=None)  
Term(termset={'A', 'C', 'B', "D'"}, used=False, ones=3, source=[3], generation=1, final=None)  
Term(termset={"C'", 'A', 'B', 'D'}, used=False, ones=3, source=[4], generation=1, final=None)  
Term(termset={'A', 'C', "B'", 'D'}, used=False, ones=3, source=[5], generation=1, final=None)  
Term(termset={'A', 'C', 'B', 'D'}, used=False, ones=4, source=[6], generation=1, final=None)  

This is simply taking the 7 terms from our canonical form and putting them into the “Term” namedtuple data structure. The first bit of code converts our terms to python sets (line 3). Line 6 exists only to clean up duplicate terms if quinemc was called with a string or list. Lines 8/9 actually creates our Term namedtuple. We then sort it by the number of “ones” at line 10 and then update our namedtuple with each items index at lines 11 & 12. (_replace is something from the namedtuple item–essentially a short cut for updating an immutable object. As the name implies it isn’t “updating” the immutable tuple but is replacing it with a copy of the original and a single value changed.)

As far as our “Term” namedtuple goes–_merge_terms_ will use python set functions so “termset” puts our terms into “sets”. The “used” flag will also be used by merge_terms; ultimately only items that are still used=False will be potential terms for our final result. As noted before it only makes sense to compare terms where the number of “ones” differs by 1 so the whole list is sorted by how many “ones” are in a term.

For our first generation the “source” list is essentially a reference to the item itself. This simplifies things in merge_terms so that we do not need to use list indexes for our first gen items.

“generation” is another item used by _merge_terms_. Again, it only makes sense to compare/reduce items that exist in the same generation as the number of inputs needs to match. Each successive generation will reduce the number of items in the “termset” by one. So, as in this case, Generation 1 has 4 inputs; if we can reduce anything then all Generation 2 items will have 3 inputs; if Gen 2 items can be reduced all Generation 3 items will have 2 inputs; finally if possible Generation 4 would have termsets with a single input.

“final” is ultimately used by the _implicants_/Petrick’s method part of the code.

_merge_terms_ and _create_new_terms_

_merge_terms_ is pretty simple. It is called for each generation and it then tries to minimize that generation. When nothing can be minimized done becomes True.

_create_new_terms_ is where we perform our actual reductions. Taking terms like ABC and ABC’ to get AB. working_list is simply a stripped down version of our term_list variable containing only items for the current “generation”. Lines 21 and 22 do a nested loop over the items in working_list.

The “tricky” bit is the “sym_set” variable. Line 24 does a set comparison of our term_list.termset items and gets a “difference” set on them. So comparing ABC to ABC’ results in a “sym_set” of (C, C’). Line 26 then checks whether we have only 2 items in our “sym_set”–this would fail if we had AB’C’ and ABC. Then also checks that the inputs (e.g. C) match – list(sym_set)[0][0] == list(sym_set)[1][0]. If that all works out we then create a new merged term.

Lines 31 - 36 avoid doing duplicate sources for reductions.

After all of this work is done the used_dict dictionary is used to update our global term_list to mark all items that have been used in merges.

At this point our term_list looks like . . .

Term(termset={'B', 'A', "C'", "D'"}, used=True, ones=2, source=[0], generation=1, final=None)
Term(termset={"B'", 'C', 'A', "D'"}, used=True, ones=2, source=[1], generation=1, final=None)
Term(termset={"B'", 'A', "C'", 'D'}, used=True, ones=2, source=[2], generation=1, final=None)
Term(termset={'B', 'C', 'A', "D'"}, used=True, ones=3, source=[3], generation=1, final=None)
Term(termset={'B', 'A', "C'", 'D'}, used=True, ones=3, source=[4], generation=1, final=None)
Term(termset={"B'", 'C', 'A', 'D'}, used=True, ones=3, source=[5], generation=1, final=None)
Term(termset={'B', 'C', 'A', 'D'}, used=True, ones=4, source=[6], generation=1, final=None)
Term(termset={'B', 'A', "D'"}, used=True, ones=2, source=[0, 3], generation=2, final=None)
Term(termset={'B', 'A', "C'"}, used=True, ones=2, source=[0, 4], generation=2, final=None)
Term(termset={'C', 'A', "D'"}, used=True, ones=2, source=[1, 3], generation=2, final=None)
Term(termset={"B'", 'C', 'A'}, used=True, ones=2, source=[1, 5], generation=2, final=None)
Term(termset={'A', "C'", 'D'}, used=True, ones=2, source=[2, 4], generation=2, final=None)
Term(termset={"B'", 'A', 'D'}, used=True, ones=2, source=[2, 5], generation=2, final=None)
Term(termset={'B', 'C', 'A'}, used=True, ones=3, source=[3, 6], generation=2, final=None)
Term(termset={'B', 'A', 'D'}, used=True, ones=3, source=[4, 6], generation=2, final=None)
Term(termset={'C', 'A', 'D'}, used=True, ones=3, source=[5, 6], generation=2, final=None)
Term(termset={'B', 'A'}, used=False, ones=2, source=[0, 3, 4, 6], generation=3, final=None)
Term(termset={'C', 'A'}, used=False, ones=2, source=[1, 3, 5, 6], generation=3, final=None)
Term(termset={'A', 'D'}, used=False, ones=2, source=[2, 4, 5, 6], generation=3, final=None)

Major things to note–the generations I think are clearer here. The _merge_terms_ function has set “used” to true for everything in Gen 1 and Gen 2. Looking at Gen 2 you can see in the source column that all 7 items (0-6) have been used. Generation 3 points to an important part of the code in this regard. Line 32 of _create_new_terms_ prevents us from doing duplicate “merges”, but the preceding lines (28 and 29) mark the items we aren’t actually using as duplicates as far as “used” is concerned.

The for loop at lines 39 - 42 is the code that actually goes through and marks the individual terms as “used”. This ends the Quine-McCluskey portion of the reduction. For Petrick’s method we will only need to consider the Term items that have “used=False”.

If you look at the Simplifying with Quine-McCluskey Method section at Circuits and Petrick The table under “Now to find the prime implicants:” is essentially what we have accomplished. Each of the 3 columns represent a generation. Within a generation the terms are grouped by the number of 1s. And finally check marks have been added for each term that has been used in a reduction.

Petrick’s Method

From Situation 1 we have ended up with 3 terms that may be needed to form our final result.

Term(termset={'B', 'A'}, used=False, ones=2, source=[0, 3, 4, 6], generation=3, final=None) Term(termset={'C', 'A'}, used=False, ones=2, source=[1, 3, 5, 6], generation=3, final=None) Term(termset={'A', 'D'}, used=False, ones=2, source=[2, 4, 5, 6], generation=3, final=None)

On paper starting Petrick’s method would require putting this into a table form with 1 column for each term from our canonical form (generation 1) and a row for each term that hasn’t been used. The remainder of the grid is filled in using the “source” values for the terms–with the goal being to find a set of terms that “fills” all of the columns.

    0   1   2   3   4   5   6
---------------------------------
AB  x           x   x       x    
AC      x       x       x   x
AD          x       x   x   x

A “required” prime implicant can be found by finding columns that only contain 1 “x”–that essentially means that term is the only one that “covers” the corresponding term from the canonical form. In this case columns 0, 1, and 2 all have single x’s and they are each for one of our 3 terms.

The other consideration is that all terms from the canonical form must be covered. In this case this is met using the 3 “required” terms. (In fact any time when all of the “used=False” terms are required terms they would cover all of the canonical terms.)

Situation 2 is slightly more interesting. In that case the final reduction looks like . . .

Term(termset={'B', "D'", "C'", 'A'}, used=True, ones=2, source=[0], generation=1, final=None) Term(termset={"D'", "B'", 'C', 'A'}, used=True, ones=2, source=[1], generation=1, final=None) Term(termset={"C'", "B'", 'D', 'A'}, used=True, ones=2, source=[2], generation=1, final=None) Term(termset={'B', "C'", 'D', 'A'}, used=True, ones=3, source=[3], generation=1, final=None) Term(termset={"B'", 'C', 'D', 'A'}, used=True, ones=3, source=[4], generation=1, final=None) Term(termset={'B', "C'", 'A'}, used=False, ones=2, source=[0, 3], generation=2, final='None') Term(termset={'A', "B'", 'C'}, used=False, ones=2, source=[1, 4], generation=2, final='None') Term(termset={"C'", 'D', 'A'}, used=False, ones=2, source=[2, 3], generation=2, final=None) Term(termset={"B'", 'D', 'A'}, used=False, ones=2, source=[2, 4], generation=2, final='None')

In this case the canonical form only has 5 terms and the reduction is complete with generation 2–and all of the generation 2 items have “used=False”. In this case our table looks like . . .

        0   1   2   3   4
--------------------------
ABC'    x           x
AB'C        x           x
AC'D            x   x
AB'D            x       x

In this case only the 1st 2 terms are required (ABC’ and AB’C) because columns 0 and 1 are the only ones with a single X. But we still need to make sure all of the terms from the original canonical form are covered. ABC’ covers 0 and 3, AB’C cover 1 and 4. So the only “uncovered” item is term 2–both AC’D and AB’D will take care of column 2. Since they are both the same length we could use either one so . . .

ABC’ + AB’C + AC’D and ABC’ + AB’C + AB’D

are equivalent. And logically this makes sense if you consider the Situation 2 story where Bob and Clara won’t bowl together.

Ultimately, for the code purposes, none of our 4 situations actually exercise all of the code (they really are pretty simple situations). For that I’ll be using 2046 (‘0b11111111110’). canonical(2046) and quinemc(2046) give us . . .

“AB’CD’ + AB’C’D + AB’C’D’ + A’BCD + A’BCD’ + A’BC’D + A’BC’D’ + A’B’CD + A’B’CD’ + A’B’C’D” and “AB’D’ + B’C’D + A’B + A’C”

I really have no idea what Alan, Bob, Clara and Declan are doing here, but again note the canonical form starts with 10 terms corresponding to the number of 1’s in the binary representation. After reduction we end up with . . .

Term(termset={"D'", "C'", "B'", 'A'}, used=True, ones=1, source=[0], generation=1, final=None) Term(termset={'B', "C'", "A'", "D'"}, used=True, ones=1, source=[1], generation=1, final=None) Term(termset={"D'", "B'", "A'", 'C'}, used=True, ones=1, source=[2], generation=1, final=None) Term(termset={"C'", "B'", 'D', "A'"}, used=True, ones=1, source=[3], generation=1, final=None) Term(termset={"D'", "B'", 'C', 'A'}, used=True, ones=2, source=[4], generation=1, final=None) Term(termset={"C'", "B'", 'D', 'A'}, used=True, ones=2, source=[5], generation=1, final=None) Term(termset={'B', "D'", "A'", 'C'}, used=True, ones=2, source=[6], generation=1, final=None) Term(termset={'B', "C'", 'D', "A'"}, used=True, ones=2, source=[7], generation=1, final=None) Term(termset={"B'", 'D', "A'", 'C'}, used=True, ones=2, source=[8], generation=1, final=None) Term(termset={'B', 'D', "A'", 'C'}, used=True, ones=3, source=[9], generation=1, final=None) **Term(termset={"D'", "B'", 'A'}, used=False, ones=1, source=[0, 4], generation=2, final='None') **Term(termset={"C'", "B'", 'A'}, used=False, ones=1, source=[0, 5], generation=2, final=None) Term(termset={'B', "D'", "A'"}, used=True, ones=1, source=[1, 6], generation=2, final=None) Term(termset={'B', "C'", "A'"}, used=True, ones=1, source=[1, 7], generation=2, final=None) **Term(termset={"D'", "B'", 'C'}, used=False, ones=1, source=[2, 4], generation=2, final=None) Term(termset={"D'", "A'", 'C'}, used=True, ones=1, source=[2, 6], generation=2, final=None) Term(termset={"B'", "A'", 'C'}, used=True, ones=1, source=[2, 8], generation=2, final=None) **Term(termset={"C'", 'D', "B'"}, used=False, ones=1, source=[3, 5], generation=2, final='None') Term(termset={"C'", 'D', "A'"}, used=True, ones=1, source=[3, 7], generation=2, final=None) Term(termset={"B'", 'D', "A'"}, used=True, ones=1, source=[3, 8], generation=2, final=None) Term(termset={'B', "A'", 'C'}, used=True, ones=2, source=[6, 9], generation=2, final=None) Term(termset={'B', 'D', "A'"}, used=True, ones=2, source=[7, 9], generation=2, final=None) Term(termset={'D', "A'", 'C'}, used=True, ones=2, source=[8, 9], generation=2, final=None) **Term(termset={'B', "A'"}, used=False, ones=1, source=[1, 6, 7, 9], generation=3, final='None') **Term(termset={"A'", 'C'}, used=False, ones=1, source=[2, 6, 8, 9], generation=3, final='None') **Term(termset={'D', "A'"}, used=False, ones=1, source=[3, 7, 8, 9], generation=3, final=None)

I’ve added “**” in front of the unused terms just to highlight the sporadic locations of unused terms. The short list of only items where “used=False” is . . .

Term(termset={"D'", "B'", 'A'}, used=False, ones=1, source=[0, 4], generation=2, final='None') Term(termset={"C'", "B'", 'A'}, used=False, ones=1, source=[0, 5], generation=2, final=None) Term(termset={"D'", "B'", 'C'}, used=False, ones=1, source=[2, 4], generation=2, final=None) Term(termset={"C'", 'D', "B'"}, used=False, ones=1, source=[3, 5], generation=2, final='None') Term(termset={'B', "A'"}, used=False, ones=1, source=[1, 6, 7, 9], generation=3, final='None') Term(termset={"A'", 'C'}, used=False, ones=1, source=[2, 6, 8, 9], generation=3, final='None') Term(termset={'D', "A'"}, used=False, ones=1, source=[3, 7, 8, 9], generation=3, final=None)

From this our table would look like . . .

        0   1   2   3   4   5   6   7   8   9
---------------------------------------------
AB'D'   x               x    
AB'C'   x                   x    
B'CD'           x       x    
B'C'D               x       x
A'B         x                   x   x       x
A'C             x               x       x   x
A'D                 x               x   x   x

In this case the only required term is A’B as column 1 is the only one with a single x. It is probably obvious that shorter terms from later generations have more sources/ancestors–so they will often take care of larger groups. Anyway, removing A’B and all of the columns it covers (1, 6, 7, 9) gives us . . .

        0   2   3   4   5   8
------------------------------
AB'D'   x           x    
AB'C'   x               x    
B'CD'       x       x    
B'C'D           x       x
A'C         x               x
A'D             x           x

From this table it should be obvious that you’ll need either AB’D’ or AB’C’ to cover column 0, and you’ll also need one of A’C or A’D to cover column 8. I personally think doing this by hand is a pain–but ultimately you end up with 2 equivalent alternatives

“AB’D’ + B’C’D + A’B + A’C”
“AB’C’ + B’CD’ + A’B + A’D”

Petrick’s Method and the _implicants_ code

Going back to the call graph _implicants_() uses 3 functions–_get_columns_(), _make_find_dict_(), and _check_combinations_().

Our first order of business in _implicants_ is to make one large list containing all of the “source=[]” items from our terms where used=False. (Lines 5 and 6) This list will contain duplicates as it is used to find the required sources on Line 8 where we look for sources that appear once. For quinemc(2046) this list looks like . . .

[0, 4, 0, 5, 2, 4, 3, 5, 1, 6, 7, 9, 2, 6, 8, 9, 3, 7, 8, 9]

So, we have “0, 4” for AB’D’, then “0, 5” for AB’C’, etc. The only source that appears only once is 1–so our required list ends up looking like [1].

With that information in hand we now move onto _keep_columns_(). At this point the code starts to use some set operations and there are more of those to come. The major function of this code is to A) find and mark “required” terms and B) create two python sets: 1) the sources from our required items and 2) one containing the sources for the rest or the terms.

The for loop on lines 5 - 10 handles this. We “enumerate()” over the term_list where used=False–enumerate is important because we will need the index in term_list to update the “required” items.

Line 6 – we perform set intersection of required and the current terms sources. An intersection will return any values that are in both sets. The items in “required” will only be in one of our term’s source lists; however a term could potentially cover more than one required item which is why line 6 used >= 1.
Lines 7 & 8 – if our current term is required we update term_list and set final=”Required”. We also add the sources for the required term to our ignore list–it is a list at this point.
Line 10 – if our current term isn’t required we add its sources to a “keep” list
Line 12 – finally we generate a list of everything that is in “keep” but not in “ignore” by treating them as sets and using the set difference operator.

So for quinemc(2046) after the for loop “keep” contains [0, 4, 0, 5, 2, 4, 3, 5, 2, 6, 8, 9, 3, 7, 8, 9]. Ignore contains [1, 6, 7, 9]. And the final result after performing a set difference on the 2 is [0, 2, 3, 4, 5, 8]. Which is the same as the table above–we’ve removed the source items for the A’B term and marked that term as “Required”.

For something like our Situation 1 (quinemc(65024)) “keep” will end up empty as the 3 terms cover all terms from the canonical expression. Back in _implicants_ this situation is covered on line 11 where we set “finished” to True so we can skip the next bits of processing.

Our next little bit of code in _implicants_ is lines 13 through 19 which essentially checks to see if a single term will cover the remaining columns. It first, however, makes a detour to create “find_dict” by calling _make_find_dict_

_make_find_dict_

At this point in _implicants_ we have “keep_columns” which tells us which columns we still need to include in our final result. However, in our big “term_list” list each term still contains the columns we want to ignore in their “source” items. _make_find_dict_ addresses this by creating a dictionary containing a terms index from “term_list” along with a new namedtuple containing that term_list item’s sources with columns we want to ignore removed. This simplifies later set operations and our new namedtuple also includes a “length” item as it is possible to find many different reductions but some can be longer than others. It also covers the situation where an item in “term_list” can be completely ignored because the ancestors/sources it covers are already covered by a required item.

To illustrate what is going on–for quinemc(2046) our current term_list of “used=False” items (with term_list indexes) is . . .

Term(termset={"B'", 'A', "D'"}, used=False, ones=1, source=[0, 4], generation=2, final='None')
Term(termset={"B'", "C'", 'A'}, used=False, ones=1, source=[0, 5], generation=2, final=None)
Term(termset={"B'", 'C', "D'"}, used=False, ones=1, source=[2, 4], eneration=2, final=None)
Term(termset={"B'", "C'", 'D'}, used=False, ones=1, source=[3, 5], generation=2, final='None')
Term(termset={"A'", 'B'}, used=False, ones=1, source=[1, 6, 7, 9], generation=3, final='Required')
Term(termset={'C', "A'"}, used=False, ones=1, source=[2, 6, 8, 9], generation=3, final='None')
Term(termset={'D', "A'"}, used=False, ones=1, source=[3, 7, 8, 9], generation=3, final=None)

Note 23 (A’B) is marked as required and so we want to ignore [1, 6, 7, 9]. When _make_find_dict_() is finished we end up with a find_dict that looks like . ..

search_tuple(sourceSet={0, 4}, length=3)
search_tuple(sourceSet={0, 5}, length=3)
search_tuple(sourceSet={2, 4}, length=3)
search_tuple(sourceSet={3, 5}, length=3)
search_tuple(sourceSet={8, 2}, length=2)
search_tuple(sourceSet={8, 3}, length=2)

For 10, 11, 14, and 17 nothing changes; for 24 and 25 [6, 9] and [7, 9] (respectively) have been removed. And length is the length of each item’s term.

Final Step – _check_combinations_

After _make_find_dict_() we head back into _implicants_() and back into lines 13-19 where we are checking to see if a single term will complete our minimized form.

    if not finished:
        find_dict = _make_find_dict_(term_list, keep_columns)
        for idx, val in find_dict.items():
            if set(keep_columns) == val.sourceSet:
                term_list[idx] = term_list[idx]._replace(final="Added")
                finished = True
                break

At this point we have the new “find_dict” dictionary and “keep_columns” which contains the columns/canonical terms we still need to cover. The for loop at 15-19 (for idx, val ...) simply loops through our newly created “find_dict” and checks whether any of the “sourceSet” items there are an exact match for “keep_columns”. If any one item does cover all the needed columns then we are done–we simply update “term_list” at the index taken from find_dict’s key and set that term_list item’s final attribute to “added”.

So ultimately the final attribute within term_list will have one of 3 values . . .

None – The default. The term is not used in our final minimized form
Required – Denotes prime implicant set in _get_columns_(). Again, these are terms that are the only ones that cover one or more of our original canonical terms.
Added – These are the additional terms needed to cover the remaining items from our canonical form. Essentially there is a choice of multiple possible terms and we attempt to find the best/shortest set that will fill out our final minimized version.

At this point in _implicants_, if a single term will not work we need to get a little more drastic and try and find combinations of terms that will work. So with . . .

    if not finished:
        possible_terms = _check_combinations_(find_dict, term_list, keep_columns)

. . . in _implicants_, we head into _check_combinations_

_check_combinations_

This function actually does two things and for good design principles the second half should probably be split off into its own function. I’m going to claim it is a borderline case and that leaving it as is is slightly less complex than the complexity of moving the second half out.

So, the first half of the code (upto line 16) works quite a bit like the code to check if a single term will match/cover all items in the “keep_columns” list. The difference here is we take the “sourceSet” items from “find_dict” and mash them together in all possible combinations.

Lines 7 and 8 – Line 6 “x” is a counter going from 2 to the number of keys in “find_dict”. Line 7 creates all combinations of those keys starting with all combinations of 2 keys, then 3 keys, etc. Funky thing here is that for a “find_dict” containing 7 items (for example) we may find a solution using a combination of just 2 items. However, the code continues to look for solutions that would be combinations of 3, then 4, then 5, etc. For a complex case this does add a ton of probably unneeded computation. But I haven’t been able to rule out the possibilities of a corner case where 3 terms would actually be shorter than 2 terms (for example AB + BC’ + AD’ is considered shorter than ABCD + ABC’D’).

Anyway, using our example of quinmc(2046) with find_dict containing keys of 10, 11, 14, 17, 24, and 25 our code starts with “items” containing (10, 11), then (10, 14), etc. Ultimately for 7 items we end up with 15 combinations of indexes. [And we are dealing with combinations–order doesn’t matter. Permutations, where order matters isn’t what we need.]

Lines 9 and 10 – we set up variables local to the for loop. Each time we go through a combination (10, 11) then (10, 14) we are resetting “combined_sources” and “temp_count”.

Lines 11-13 – We look up the items for our current combination [10, 11] and mash their sources together in “combined_sources”. We also use “find_dict” to keep track of how long this result is. So for [10, 11] combined_sources would be {0, 4, 5}, for [10, 14] it would be {0, 2, 4}

Line 14 – Just like searching for a single item that will cover everything we need we check whether combined sources covers what we need. Even if this succeeds we will continue checking all combinations. Essentially, if there are any number of ways to complete our reduction using 2 terms we will look at them all. So for example we’d check if set([0, 2, 3, 4, 5, 8]) == {0, 4, 5}–and it will finally succeed when we find a group of items from “find_dict” covering all of set([0, 2, 3, 4, 5, 8]). (Might be good to remind you at this point that every item in “find_dict” will only contain 1 or more of [0, 2, 3, 4, 5, 8] – but in this case would never contain a 1 or 6 as they have been stripped out.}

Lines 15-16 – if we find a match we add the list of keys to the matches list. We also add its length to matches_idx.

The second half.

a, b, c = quinemc(548738420677, full_results=True) 8534 13 possible items

“A’BC’DF’ + A’BC’D’F + B’C’D’F’ + AB’C’F’ + AB’C’E’ + AB’C’D’ + A’BD’E’ + A’B’CD’ + A’B’DE + A’CDE”

{0, 2, 3, 4, 8, 9, 11, 12, 14, 17, 18, 21}

find dict 34: search_tuple(sourceSet={9, 2}, length=5) – 49: search_tuple(sourceSet={9, 18}, length=5) 67: search_tuple(sourceSet={0, 4}, length=4) – 68: search_tuple(sourceSet={0, 8, 2, 3}, length=4) – 69: search_tuple(sourceSet={0, 3, 11, 4}, length=4) – 70: search_tuple(sourceSet={14}, length=4) 73: search_tuple(sourceSet={8, 17, 2}, length=4) 74: search_tuple(sourceSet={8, 17, 3, 12}, length=4) 75: search_tuple(sourceSet={3, 11, 12, 21}, length=4) 76: search_tuple(sourceSet={4, 14}, length=4) 77: search_tuple(sourceSet={11, 4}, length=4) 78: search_tuple(sourceSet={11, 21}, length=4) 79: search_tuple(sourceSet={18}, length=4) 34 search_tuple(sourceSet={9, 2}, length=5) 67 search_tuple(sourceSet={0, 4}, length=4) 68 search_tuple(sourceSet={0, 8, 2, 3}, length=4) 69 search_tuple(sourceSet={0, 3, 11, 4}, length=4) 70 search_tuple(sourceSet={14}, length=4) 73 search_tuple(sourceSet={8, 17, 2}, length=4) 74 search_tuple(sourceSet={8, 17, 3, 12}, length=4) 75 search_tuple(sourceSet={3, 11, 12, 21}, length=4) 76 search_tuple(sourceSet={4, 14}, length=4) 77 search_tuple(sourceSet={11, 4}, length=4) 78 search_tuple(sourceSet={11, 21}, length=4) 79 search_tuple(sourceSet={18}, length=4) 49 search_tuple(sourceSet={9, 18}, length=5)

if len(matches) > 0:
    min_index = match_idx.index(min(match_idx))
    indexes = [i for i, v in enumerate(match_idx) if v == min(match_idx)]
    print("indexes", indexes)
    print("matches", matches)
    for idx, value in enumerate(matches):
        if idx in indexes:
            for i in value:
                if idx == min_index:
                    term_list[i] = term_list[i]._replace(final="Added")
                # also create a list of all options that will fit the bill
                if (not set(matches[min_index]).issubset(matches[idx])) or min_index == idx:
                    possible_terms[idx].append(term_list[i])

Closures or: How I learned to stop classing and love the function

2017-08-01T00:00:00+00:00

Python Closures

I’m not going to say closures are simple–if you come from an object oriented background or are starting off with no background and learning a functional language they can be a bit of a mind-bender. Once you get past the world of syntax (the “ifs”, “whiles”, and “fors”) you essentially enter the world of “how do I put all that together?”. For languages with functions as “first-class objects” (FCOs) you’ll probably encounter closures or closure like constructs.

You could probably get away with writing a ton of code in python without ever using a closure–but they can be a great tool to make your code simpler, more useful, and easier to extend and maintain. I don’t think you’d survive reading or writing Java Script without closures. I’m going to, however, focus on python.

\[\begin{align*} & \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right) = \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\ & (x_1, \ldots, x_n) \left( \begin{array}{ccc} \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\ \vdots & \ddots & \vdots \\ \phi(e_n, e_1) & \cdots & \phi(e_n, e_n) \end{array} \right) \left( \begin{array}{c} y_1 \\ \vdots \\ y_n \end{array} \right) \end{align*}\]

Wikipedia != ELI5

Wikipedia starts their article on closures with . . .

In programming languages, closures (also lexical closures or function closures) are techniques for implementing lexically scoped name binding in languages with first-class functions. Operationally, a closure is a record storing a function[a] together with an environment:[1] a mapping associating each free variable of the function (variables that are used locally, but defined in an enclosing scope) with the value or reference to which the name was bound when the closure was created.[b] A closure—unlike a plain function—allows the function to access those captured variables through the closure’s copies of their values or references, even when the function is invoked outside their scope.

. . . which is pretty dense. Dense in the sense it is accurate, complete, and correct; not in the “idiot” sense. It is, however, the R-rated version; I’ll try to stick to the PG or PG-13 version.

To the Code

Before parsing that and going into a bit of detail on the “Why?”/”When?” of closures I’m going to get to the code. I’ll be using FizzBuzz for the first example–in many other places I’ve seen simple “adders” used for example closures and as far as examples go they seem limited.

So the basic fizzbuzz I’ll use is:

def fizzbuzz(x):
    return "Fizz" * (x % 3 == 0) + "Buzz" * (x % 5 == 0) or x

print([fizzbuzz(x) for x in range(0,20)])

If you’re wondering how that works the two expressions (x % 3 == 0) and (x % 5 == 0) return either True or False. True evaluates to 1 and False to zero. So when x is 6 you end up with "Fizz" * 1 + "Buzz" * 0 or x then "Fizz" or x. In Python logic the following (plus some others) evaluate to False:

0 (zero)
None
False
any of “”, (), {}, or [].

See: Notes about Booleans In "Fizz" or x “Fizz” is taken as true so “x” is ignored. For something like x = 7 you end up with "" or x–which is False or x resulting in “x”.

That, however, is not a closure–it is simply the function we’ll be returning from our closure. The actual closure wraps around the function like . . .

With that code you can then run stuff like:

fb35 = fbclosure()
fb27 = fbclosure(2, 7)
print([fbclosure()(x) for x in range(0,20)])
print([fb35(x) for x in range(0,20)])
print([fb27(x) for x in range(0,20)])

print(fb35(224))
print(fb27(224))

In this case the closure itself is created on lines 1 and 5: def fbclosure and return fizzbuzz. I’ve also added the fizz and buzz parameters defaulting to 3 and 5 to make our fizzbuzz a little more versatile. Going back to the Wikipedia definition–the fizz and buzz variables are “lexically scoped names”. Our “function” is fizzbuzz, our environment includes ‘fizz’ and ‘buzz’–they are the “captured” items.

At this point the Wikipedia definition is starting to take form. Our closure is returning a function, fizzbuzz–although we rename it with lines like fb35 = fbclosure() or fb27 = fbclosure(2, 7). Our renamed functions store the information/environment of the enclosing closure (“lexically scope”). For fb35() that is fizz = 3 and buzz = 5; for fb27() we have fizz = 2 and buzz = 7.

As far as using it–you can call the closure directly as in the first print statement (fbclosure()(x)), but that probably isn’t typical. The real magic and power of functional languages is assigning the enclosed function to a variable which is actually a function.

So, why Closures?

For the most part closures provide two things . . .

Act as mini-classes/objects
Conveniently hide data (i.e. provides a “private” scope)

On Item 1–a closure provides some sort of functionality and each instance of a closure maintains its own state. From wikipedia this is the “lecixally scoped binding”.

Item 2 builds on Item 1. Java Script and Python are pretty liberal with their scoping. In either language you can trample on or redefine a lot of things–either on purpose or by mistake. The more object oriented/class based languages tend to be defensive (private-ish) by default–functional languages are quite a bit more liberal.

That said, though, while the defensive programming aspect can be important the real power of closures is in Item 1. In languages with functions as first class objects encapsulating and reusing important functions saves a lot of work, lines of code, and provides consistency. For a smaller application you avoid repeating code with functions. When an application grows you will typically start collecting code into modules or classes.

Closures provide something of a middle ground. Rather than having to continually call a function with a set of parameters or instantiate a class–common bits of code can be centralized so they are easily re-used throughout an application or by multiple developers.

Another Example: Multiple Functions

This may be quite a bit less common, but a closure in python can return multiple functions. Fizzbuzz isn’t a particularly good example for this, but something like simple geometry does fit the bill. Iconoclast that I am I’m going to use triangles for this example rather than the more typical points and circles that seem to be the rage.

In this case def triangle(a, b, c) is our enclosure. Then it gets a little funky. At the bottome Lines 18-24 we define an empty function T() then assign two of our functions to it T.area = area and T.height = height. We then complete our closure by simply returning T.

If you come from an object oriented background this is very much like simply creating a minimalistic “object”. t345 = triangle(3, 4, 5) will create an object with two functions, area() and height(). Our third function, semiperimeter(), remains hidden, essentially a private function used only internally.

NOTE: This code will only work in Python 3–Python 2 does not have the “nonlocal” feature.

Okay, back to our functions. For the most part the 3 functions are pretty straightforward and standard. semiperimeter() is only used internally by area(). Both area() and height() are exposed to end-users with our closure. Should probably note that height() calls area() which also calls semiperimeter(). So, anyway, you can run code like . . .

tri = triangle(2,4,5)
tri.height()  # ((2, 3.799671038392666), (4, 1.899835519196333), (5, 1.5198684153570663))
tri.area()    # 3.799671038392666

But then there is that nonlocal stuff in area(). According to area’s signature/definition (def area(A=a, B=b, C=c):) we can call it and replace any combination of our closures sides to get an area using the passed in values. So tri.area(3), replaceing “a = 2” with “a = 3” will return 6.0. The first thing to note is that if nothing is passed in (tri.area()) it will simply use the a, b, and c values from the closure. So what does nonlocal do? If you comment out the nonlocal related lines (7 and 8) then run . ..

tri = triangle(2,4,5)
tri.area(3)

. . . it seems to run fine. But tri.area(3) returns “3.2113081446662823” when the area of a 3, 4, 5 triangle should be 6.0!!! What?!? The problem here is that area() relies on semiperimeter(). Without nonlocal our area fucntion is using a = 3, b = 4, and c = 5, but semiperimeter is still using a = 2 from the original closure. So line 7 tells area that we need to (possibly) change the enclosure’s copies of a, b, and c; line 8 then updates those variables temporarily so that our call to semiperimeter will use a = 2. So, with the nonlocal lines in place, ‘tri.area(3)’ will correctly return 6.0.

The height() function however is never affected by the nonlocal changes. A call like tri.area(3) is only a temporary change, once it returns its results the original enclosure keeps “a = 2”.

You may be saying “What’s the difference between nonlocal and global?”. Good question. In this case our a, b, and c are not global variables–they are enclosed within our closure. nonlocal looks for variables in the immediate enclosing scope, but will not go as far as global scope. (Essentially if the immediate enclosing scope is global, nonlocal will not go there.)

If you’re totally new to Python then A) you probably shouldn’t be reading my mad and meandering ravings, but more importantly B) you should probably really get accustomed to going to PEPs for the inside-skinny on Python language feature. A PEP (Python Enhancement Proposal) is essentially a concise clear design document for a Python language feature or change. They are generally very well written and extremely clear on 1) what the problem/issue is, 2) how the issue relates to the over all Python language universe, 3) a break down of what the proposed solutions to the issue are and what the advantages/disadvantages of a solution entail, and finally 4) what the proposed solution is/entails. Anyway, for nonlocal PEP 3104 is a great read not only for nonlocal but also as a pretty accessible primer on scoping issues for Python and how they compare/relate to other languages.

Now, back to triangle()–height() could be altered in a similar way as area() so you could “fudge” side lengths to find some required height.

In hindsight this may have been a crud example and I should’ve stuck with circles and points.

Where to go from here

Please do not use closures as a hammer and everything is a nail. (The triangle example is a good example.) But some ideas to play around with . . .

Implement a data structure like a linked list with your nodes as closures
Do some geometry crud with points as closures
Populate a list with different versions of the same enclosure and do something with it.
Implement a deck of cards as a closure with shuffle() resetting and randomizing the deck and getcard() returning the next card. Potentially allow your closure to use multiple decks (e.g. a 6 deck shoe).
Go outside and hit some golf balls or whatever you do to take your mind off of things. Quite often the best way to learn is to not learn. (Seriously, you’ll do your best thinking when you aren’t thinking.)

Like any other aspect of learning the idioms and intricacies of a specific language becoming familiar with them, playing with them, and being able to read/write them is the actual “hard” part of learning a language. You will come across closures in other people’s code and learning when to use them or go a different direction is an important step in writing good code. Python, by design, lets you do quite a bit with a few lines of code. It is very often referred to as a “multi-paradigm” language–you can accomplish the same goals writing objected-oriented classes or in a more purely functional (or even imperative) manner. And that is the beauty of Python–once you’ve added closures, how to make your objects iterable, or how to put a set of functions into a module you’ll begin to see how all of these tools fit into a work belt and start to design software rather than write lines of code.

After that soapbox-ish last paragraph I’m going to admit that I’m still much more of an “end result” programmer than a “design” programmer. I’ll write lines of code and functions to solve a problem. I’ll look back at my creation and say “This is goo…d?–this should probably be an object in a class, this should probably be a separate set of functions in a module, can I drop this function with a simple list comprehension?, this is not my beautiful house . . .”

Links and Inspirations

I in no way endorse, collude with, or vouch for the moral integrity of any of the writers for the links below. But I found at least parts of these pages interesting and useful. Googling is 80% of the battle. Somewhat JS Module heavy but closures seem to be almost endemic in JS and python/python closures are probably a gateway drug to JS closures.

PLCAS: Python List Comprehension Anxiety Syndrome

2017-08-01T00:00:00+00:00

PLCAS: Python List Comprehension Anxiety Syndrome

PLCAS is a real disease. The latest DSM (Diagnostic and Statistical Manual of Mental Disorders) was finalized before PLCAS was discovered as a full-blown mental issue. But it should be covered in the next edition.

However, if you think you may suffer from PLCAS you are not alone. There are ways to live with this potentially debilitating disease and most importantly, ways to a cure.

TL;DWR – Too Long; Don’t Want to Read

Trey Hunter’s Python List comprehensions now in color will turn you into a LC pro. Or at least get you on the path to building PLCs (Python List Comprehensions) when you are reviewing your own code.

My personal suggestion–don’t worry about an LC when writing your code if you’re happier doing a quick for loop.

define your list, e.g. mylist = []
create a for loop
once the code is working go back and look for all of your xxxlist = [] and use Hunter’s info to change them.

Do that a couple of times and you’ll quickly start to stomp out list comprehensions. The reality is they’re just a tool–none of us are going to become the Pablo Picasso of list comprehensions. Being able to write and read them is a great skill. Anyway, Pablo Picasso was a bit of an asshole.

Now back to my meandering BS.

Do I have PLCAS?

Common symptoms of PLCAS include:

Spending 3 hours trying to write a list comprehension when you could’ve written the code in a “for” loop in 20 minutes
A constant nagging suspicion that people will dismiss your code because you don’t have a list comprehension at least once for every 30 lines of code
Ignoring your loved ones so that you can read every Stack Overflow question that mentions list comprehensions

First Steps to a Cure

Again, remember, you are not alone. That said–the first real step is realising you don’t need to use list comprehensions. One of the hallmarks of PLCAS is the belief that you are being judged for not using them. This is not true. A readable nested for loop is far better than an obtuse list comprehension. [However, once you are comfortable with them list comprehensions will not only make your code easier to read but will help immensely when looking at other people’s code.]

Write the code that makes the most sense to you. A program that is correct is far superior to anything that is “clever” but hard to follow.

Available Drugs

Trey Hunter has the cure. He beautifully explains and breaks down how to create a list comprehension from a for loop. If list comprehensions aren’t coming to you naturally write your code in for loops. Then go back and look for short ones that can be “condensed”. You will pretty quickly learn how to do a list comprehension. And just as importantly how to grok what is going on in ones in other peoples code.

Even after you’re comfortable with list comprehensions and you need to write soemthing that you know is probably doable with an LC–but it just isn’t coming to you. Write the “for” loop and move on. “for” loops have existed since the first programming language crawled from the primordial assembly language muck. They are the “learning to walk” of programming. LCs are like learning to ride a bike, drive a car, or swim.

PLCAS Cure

A personal example

This may be a bit of an obtuse example because it somewhat depends on knowing a bit about what the over all program was doing. But for my own code to get things done I wrote . . .

result = []

for x in final_result:
    temp_item = (sorted(list(x.termset)))
    result.append("".join(temp_item))

. . . based on Trey Hunter’s help I changed it to . . .

result = ["".join(sorted(temp_item.termset)) for temp_item in final_result]

And this is a great example of why you shouldn’t care. It is possible in this case the list comprehension would be faster–but speed isn’t really a concern here. So it comes down to which is quicker for you to write. If you’re new to Python it may not be obvious or easy to see how to do a list comprehension using "".join(zed). But getting it down in your code as a simple for loop should make it clearer to figure out how a comprehension can be composed.

After a few go-rounds with convertering for loops to LCs the relationship between for loops and list comprehensions should start to become second nature. Writing code you’ll start to skip the for loop part and just do a LC. Reading code you’ll (likely) find list comprehensions make things alot easier to read.

Final Notes

Always write code that makes sense to you. Obviously don’t be stupid about it but spending hours or days looking for an elegant solution is almost always wasted time if you can spend 25% of that time and get a working piece of code. And that goes for everything–not just list comprehensions. You’ll be able to get your code up and running faster and, I hope, you’ll also know the areas you want to go back to to improve.

As Donald Knuth said “premature optimization is the root of all evil”. Refactoring is how applications and systems are written today. Finding ways to optimize your code after you’ve gotten stuff working is truly a great way to learn more about coding and software development. Worrying about or agonizing over the “perfect solution” whether it is a list comprehension or anything else is usually wasted time–at least until you have “a” solution.

In short “keep coding and carry on”.

CDNF Part I: Canonical Fodder

2017-08-01T00:00:00+00:00

Canonical Normal Forms and Minimization

Quite a while ago I read parts of Randy Hyde’s The Art of Assembly Language Programming (AoA). The section on boolean logic and Canonical Normal forms intrigued me for some reason. The whole book is available online and the specific section is 3.4 Canonical Forms.

More recently I’ve been messing around with functions that take numbers and output “something”–things like fizzbuzz(6) or isprime(17). Canonical Normal Forms came to mind and that also led to Quine-McCluskey reduction (more on Q-M later). So I wrote something up in Python.

In case you’re wondering–the title is meant to be a reference to Camper Van Beethoven 1985 smash hit “Take the Skinheads Bowling”. And I used a named tuple for doing quite a bit of the work in cdnf.py.

Canonical (Disjunctive) Normal Forms explained

So the basic gist of CDNFs is that for any set of inputs (e.g. A, B, and C) all the logical functions of those inputs can be written with “minterms” that include all 3 inputs. For example “A’BC + AB’C” and “A’BC + AB’C + A’BC’ + A’B’C’” would both be CDNFs with 3 inputs. Each minterm’s input items are ANDed (so ABC is “A AND B AND C”). And the individual minterms are ORd (using “+”). And finally ‘ is used to represent negation, so B’ is “NOT B”. The “OR” portion is where the Disjunctive part comes from; for Conjunctive Normal Forms each input is ORd within a minterm and each minterm is ANDd–but I won’t be dealing with Conjunctive Normal Forms here.

These normal forms can be ordered based on binary numbers (or converting ints to binary). For CDNF each “1” bit in the binary representation “points” to a minterm. For example the CDNF of 228 is “ABC + ABC’ + AB’C + A’BC’”. In binary 228 is 11100100–so the number of terms in the CDNF corresponds to the number of 1’s in the binary representation. The individual terms are derived from the columns of a truth table.

So for our example of 228 (where BP is bitposition) . . .

BP  |  A  |  B  |  C  | 228 | Term
--------------------------------------
 |  0  |  0  |  0  |  0  |
 |  0  |  0  |  1  |  0  |
 |  0  |  1  |  0  |  1  | A'BC' (010)
 |  0  |  1  |  1  |  0  |
 |  1  |  0  |  0  |  0  |
 |  1  |  0  |  1  |  1  | AB'C  (101)
 |  1  |  1  |  0  |  1  | ABC'  (110)
 |  1  |  1  |  1  |  1  | ABC   (111)

. . . every row where 228 has a 1 is used to create a term. The term itself is created from the A, B, and C columns. If the letter is a zero it is “primed”–meaning NOT B. If the letter is a one it is un-primed.

For the canonical() function it is important to note that the Bit Position (BP) corresponds to the binary version of the BP. So BP 5 == 101 which is a minterm of AB’C. BP 0 = 000 – A’B’C’.

Note: Art of Assembly uses “A” as the low order bit–so it is the rightmost letter going 010101. Others, such as Logic Circuit Simplification do the reverse where the last letter (in this case C) is the low order bit. For my canonical() A is the high order bit as in the table above–for 3 inputs it is 00001111 and C is 01010101. The second argument to canonical() can be used to switch this so A would be 01010101 and C 00001111.

The Canonical() code

The code itself is actually pretty minimal. There may be a bit of hinky razza-ma-taz going on but it is probably more concise than the explanation above.

The basic definition is canonical(x, highorder_a=True, includef=False) . . .

x – is our int to convert
highorder_a – lets us switch between A being the HO and LO bit
includef – if True simply adds “F(x) =” in front of the result

Walking through the code using canonical(228) gives us . . .

Lines 5 and 6 Convert the int to binary and reverse the order–essentially for a binary number the right-most bit is our BP 0, next is BP 1, etc. So we need to reverse it. For 228–Binary is 11100100, reversed is ‘00100111’.

Lines 8 to 10 Next we determine how many inputs/letters we need. This part may take a bit of thinking, but essentially the length of the binary version of our input will determine the number of inputs/letters we will need. So for 228 the binary representation is 8 digits. So its length can be represented by a 3 digit binary. This corresponds to the number of columns (A, B, C) needed. We stick with a minimum of 2 letters mostly so the 1st 15 integers provide standard results.

Line 12 Here we are just making a list of the binary represenations of the Bit Positions where a 1 appears. So for 228 we have BPs (using a zero indexed array) at 2, 5, 6, 7. (That is the i in re.finditer('1', binary) of the list comprehension.) And this is why we reversed the bits on line 6. format(i.start(), '0' + str(letters) + 'b' ) converts 2, 5, 6, and 7 to a binary format with a zero fill based on the number of letters. For 228 with BPs of 2, 5, 6, 7 we end up with [‘010’, ‘101’, ‘110’, ‘111’]–which are the binary versions of our minterms.

Line 13 We now take our list from line 12 and feed each item into the minterm() function.

_minterm_() Line 21 Simply creating a list of all the letters. Very much overkill as A-Za-z would allow more inputs/permutations than the universe can contain.

Line 23 and 24 If we want A as the low order bit we reverse the digits for each of our minterms.

Line 26 to 29 Finally, we simply loop over the digits in our term. For each digit we add the next letter–then if the digit is a zero we add ‘ after the letter. So 111 becomes ABC and 110 becomes ABC’.

Line 14 Back in canonical we convert the new list of minterms to a string with “ + “ between each item.

From Canonical to a Minimized version

So what’s the big deal about a canonical expression? Essentially it represents all of the “terms” from a truth table. From the canonical version it is possible to minimize the expression to make things simpler. This means both electronics and code and other applications don’t have to deal with typically large numbers of circuits or if/else statements.

And now for an example . . .

Let’s go Bowling!

So, Alan likes to bowl. But he never bowls alone. He has three friends that he bowls with: Bob, Clara, and Declan. For the examples I’ll use 4 distinct situations . . .

Situation 1 The base case of Alan never bowling alone.

Situation 2 Same as 1 but Bob owes Clara money so Bob won’t bowl if Clara is bowling

Situation 3 Same as 2 (Bob still owes Clara) but Bob will bowl with Clara if Declan is also bowling because Declan is a really funny guy.

Situation 4 Bob has payed Clara–but Alan will only bowl if there is an even number (2 or 4) bowlers because the bowling alley charges a higher rate for 3 bowlers.

All 4 of these situations are summarized in the table below. Columns A, B, C, and D specify whether someone is available/willing to bowl. The columns 1, 2, 3, and 4 are the 4 situations a 1 means they go bowling–zero means they do not go bowling.

ABCD  1 2 3 4  Row #
----  -------  ------
0 0 0 0   0
0 0 0 0   1
0 0 0 0   2
0 0 0 0   3
0 0 0 0   4
0 0 0 0   5
0 0 0 0   6
0 0 0 0   7
0 0 0 0   8
1 1 1 1   9 x
1 1 1 1  10 x
1 1 1 0  11 y
1 1 1 1  12 x
1 1 1 0  13 y
1 0 0 0  14 z
1 0 1 1  15 y2

Rows 0-7: Alan can’t bowl so everything is zero
Row 8: Alan can bowl but none of his friends can (zeros). A=1, B,C,D=0
Rows 9, 10, 12 (x): Alan can bowl and exactly 1 friend can so all are true
Row 11 and 13 (y): S 1, 2, and 3 are true because either Clara or Bob can’t bowl. S4 is false because it is only 3 bowlers.
Row 14 (z): S 2 and 3 are false because Bob and Clara won’t bowl together. And S4 is False again because of 3 bowlers
Row 16 (y2): Only false for S2 where Bob absolutely will not bowl with Clara.

Canonical to minimized forms for Bowling

Situation 1 – 65024 There are 7 “True” instances so we’ll have 7 minterms. Starting with row 15 the minterm would be ABCD, next would be ABCD’, etc. We could manually translate these terms–but we can also just use int('1111111000000000', 2) to get 65024 and feed it to canonical(). To get . . .

ABCD + ABCD’ + ABC’D + ABC’D’ + AB’CD + AB’CD’ + AB’C’D

. . . which represents all cases where Alan will bowl. Using some premises of logical operations/reductions this can be reduced to . . .

AB + AC + AD

This probably seems obvious from the description of Situation 1. If we know Alan will only bowl if at least one of his friends is we aren’t going to come up with all the permutations of the canonical form–we’d simply say Alan will bowl if Bob does (Clara and/or Declan can bowl as well); if Bob isn’t bowling but Clara is Alan will bowl (Declan may or may not); if neither Bob or Clara are bowling but Declan is Alan will bowl.

Situation 2 – 15872 Next up we have the situation where Bob and Clara will not bowl together int('0011111000000000', 2) or 15872. The canonical form is . . .

ABC’D + ABC’D’ + AB’CD + AB’CD’ + AB’C’D

Note the 1st 4 terms. In the 1st 2 Clara isn’t bowling (C’) so Bob can. Terms 3 and 4 Bob isn’t bowling (B’) so Clara can. Fifth term Bob and Clara are probably together having angry sex while Alan and Declan are bowling [more on Bob and Clara later]. The minimized form is:

ABC’ + AB’C + AC’D

Situation 3 – 48640 Bob and Clara will only bowl together if Declan is bowling. . . .

ABCD + ABC’D + ABC’D’ + AB’CD + AB’CD’ + AB’C’D

This is where things may start to be counter-intuitive. 2nd Term has Declan bowling so both Bob and Clara “can” bowl–but Clara isn’t. This simply means Clara wasn’t going to bowl regardless and it needs to be represented. The minimized version really clears this up . . .

ABC’ + AB’C + AD

The final term “AD” essentially allows Bob and Clara to bowl together at that point. The first 2 terms would allow Bob or Clara to bowl with Alan alone or Alan and Declan. Note the first 2 terms here are the same as Situation 2, but the final term removes the C’ restriction.

Situation 4 – 38400 This one is a bit funky. We need 2 or 4 bowlers. (Bob and Clara have settled up.) The canonical form is:

ABCD + ABC’D’ + AB’CD’ + AB’C’D

and the minmized form is:

ABCD + ABC’D’ + AB’CD’ + AB’C’D

So this one can not be minimized at all. Essentially either all 4 play (ABCD) or two of them absolutely can not play.

So What’s Up with Bob and Clara

In a strange twist of the universe all of these inputs and variables we so non-chalantly throw around actually lead very full lives. Bob and Clara seem to constantly argue and get on each others nerves–but they have been carrying on a rather secret relationship. Declan is almost constantly commenting that they should “get a room”; but Alan has had a thing for Clara for quite a while. Bob and Clara essentially came up with a plan that if they can get Alan and Declan to bowl together more often they’d be tied up at the bowling alley and Bob and Clara could safely have their sordid rendevous.

Clara has been trying to get her friend Erica to take up bowling in the hopes of distracting Alan. But that all gets a little too complex for what is meant to be a relatively simple example. But seriously–why am I explaining this to you. Can’t you just let Bob and Clara live their lives? Really, the next time you just non-chalantly throw around a B’ or D’ just remember Bob may be out having a great time so he is not available, but he could also be sitting at home playing REM’s “Everybody Hurts” on a constant loop while watching the Powerpuff Girls on netflix just waiting for his phone to ring.

Oops. Sorry, where was I. Oh . . . Heading into Quine-McCluskey. Which I’ll take up in Part II since this is getting a bit long.