Am I sufficient? Am I even necessary? If you’re plagued by these existential questions and have ended up here in your quest for an answer, then I’ve got some bad news for you. The answer to both is no. I keed. I keed. Actually, the bad news is that this post is about necessity and sufficiency and their rigid definitions in the domain of mathematical logic. If you are only interested in looking for meaning in your life then move along, but if you are one of the enlightened few that knows that math really is the answer to every question, then by all means, read on!

Finite state automata (FSA), also known as finite state machines (FSM), are usually classified as being deterministic (DFA) or non-deterministic (NFA). A deterministic finite state automaton has exactly one transition from every state for each possible input. In other words, whatever state the FSA is in, if it encounters a symbol for which a transition exists, there will be just one transition and obviously as a result, one follow up state. For a given string, the path through a DFA is deterministic since there is no place along the way where the machine would have to choose between more than one transition.  Given this definition it isn’t too hard to figure out what an NFA is. Unlike in DFA, it is possible for states in an NFA to have more than one transition per input symbol. Additionally, states in an NFA may have states that don’t require an input symbol at all, transitioning on the empty string ε.

Superficially it would appear that deterministic and non-deterministic finite state automata are entirely separate beasts. It turns out, however, that they are equivalent. For any language recognized by an NFA, there exists a DFA that recognizes that language and vice versa. The algorithm to make the conversion from NFA to DFA is relatively simple, even if the resulting DFA is considerably more complex than the original NFA.  After the jump I will prove this equivalence and also step through a short example of converting an NFA to an equivalent DFA.

In my last post, “Kleene’s Theorem,” I provided some useful background information about strings, regular languages, regular expressions, and finite automata before introducing the eponymously named theorem that has become one of the cornerstones of artificial intelligence and more specifically, natural language processing (NLP).  Kleene’s Theorem tells us that regular expressions and finite state automata are one and the same when it comes to describing regular languages. In the post I will provide a proof of this groundbreaking principle.

Stephen Kleene

Stephen Cole Kleene was an American mathematician who’s groundbreaking work in the sub-field of logic known as recursion theory laid the groundwork for modern computing.  While most computer programmers might not know his name or the significance of his work regarding computable functions, I am willing to bet that anyone who has ever dealt with regular expressions is intimately familiar with an indispensable operator that resulted directly from his work and even bears his name, the *, or as it is formally known, the Kleene star.

While his contributions to computer science in general cannot be overstated, Kleene also authored a theorem that plays an important role in artificial intelligence, specifically the branch known as natural language processing, or NLP for short. Kleene’s Theorem relates regular languages, regular expressions, and finite state automata (FSAs). In short, he was able to prove that regular expressions and finite state automata were the same thing, just two different representations of any given regular language.

As a computer programmer for more than a quarter of century, I don’t think I have ever thought much about strings. I knew the basics. In every language I’d worked with, strings were a data type unto themselves. Superficially they are a sequence of characters, but behind the scenes, computers store and manipulate them as arrays of one or more binary bytes. In programs, they can be stored in variables or constants, and often show up in source code as literals, ie., fixed, quoted values like “salary” or “bumfuzzle.” (That is my new favorite word, btw.) Outside of occasionally navigating the subtleties of encoding and decoding them, I never gave strings a second thought.

Even when I first dipped my toe into the waters of natural language processing, aka NLP (not to be confused with the quasi-scientific neuro linguistic programming which unfortunately shares the same acronym), I still really only worked with strings as whole entities, words or affixes, As I made my through familiarizing myself with existing NLP tools, I didn’t have to dive any deeper than that. It was only when I started programming my own tools from the ground up, did I learn about the very formal mathematics behind strings and their relationship to sets and set theory. This post will be an attempt to explain what I learned.

Boolean functions, sometimes also called switching functions, are functions that take as their input zero or more boolean values (1 or 0, true or false, etc.) and output a single boolean value. The number of inputs to the function is is called the arity of the function and is denoted as k. Every k-ary function can be written as a propositional formula, a sentence in propositional logic. A binary Boolean function, a Boolean function with two arguments, can be described by one out of sixteen canonical formulas.

If you are an artist, photographer, graphic designer, or web developer, having a firm understanding of colors is a necessity.  Key to being able to study and discuss colors is a formal framework for quantizing their properties. Abstract mathematical models called color models do just this, allowing people to discuss the qualities of a color in a consistent manner. These models usually assign tuples of numbers to a color, often either ordered triplets or quartets, where each value represents a property of the color. This post will introduce one the most popular models: the RGB color model.

For almost the last 20 years, an Apple laptop of one variety or another has been my main computing device. Imagine my surprise when I finally learned today that Apple keyboards don’t have an Insert key. In almost two decades I have never needed it, but that changed this morning.

While working in my favorite Python editor, Wing IDE by Wingware, some sloppy touch typing resulted in the cursor changing from the blinking vertical line I am used to a blinking underline. That change was subtle enough that I missed it, but as soon as I began typing and the text I was entering started overwriting the existing code, I knew something was up. WTF!

I know that this post will probably be of interest to about a dozen people worldwide, and even those few may be disappointed by it. Since the official SWI-Prolog packages aren’t often kept up to date and because compiling and installing SWI-Prolog from source should be both quick and straightforward, that is the recommended way to do it on Linux and other *nix systems.

If you are looking for tips, tricks or assistance with an installation problem, you likely won’t find it here. The instructions provided on the SWI-Prolog site for building and installing SWI-Prolog from source code “just worked” for me. Nevertheless, I want to document what I did, and if you are looking for the Cliff Notes version, then by all means, read on.

GIMP has done such a good job filling the Photoshop-shaped hole in my software arsenal left during my transition from OS X to Ubuntu, that until today I forgot that I sometimes work with vector-based images, and for that I had been using Adobe Illustrator.  The best free, as in both beer and speech, Illustrator alternative is Inkscape, a professional vector graphics editor available for Windows, OS X, and Linux.

The problem:
I want to import an Adobe color palette (.aco file) into Inkscape.

The solution:
This is not as straightforward as I expected. Without using a third party plugin, the solution is a multi-step process. Read on to learn how I did it.