

Measuring Startup Success 
[Startups] 
Posted on September 27, 2013 @ 05:28:00 AM by Paul Meagher
Tom Bloomfield has a useful blog post on measuring startup success. Citing Paul Graham he argues that, "merely measuring something has an uncanny tendency to improve it".
Tom makes some useful suggestions such as:
 Start by measuring one thing. You need some key metric to track whether you are improving or not.
 Choose a proxy for long term value. Because startups may not be profitable from the get go, it is important that you still figure out what measure needs to be constantly improving to help guarantee the long term survival and growth of your startup.
 Break down you key metric into Key Performance Indicators that track subactivities that need to be performed if you are to meet your improvement goals. These should be objective measures of performance that are shared within the company among all employees.
 Use your KPI planning to implement a business strategy.

Permalink 
Intro to Linear Programming: Part 2 
[Decision Making] 
Posted on September 26, 2013 @ 04:59:00 AM by Paul Meagher
In yesterday's blog, I gave a brief overview of what Linear Programming is and the main equations that are used to specify a Linear Programming decision problem.
Today I want to provide you with some resources you might use to learn how to use Linear Programming to optimize some aspect of your business.
The first resource that I would direct you to are a series of IBM developerWorks articles on using the GNU Linear Programming Kit (GLPK) to solve linear programming problems. This 3 part series walks you through 5 different problem scenarios that you can apply linear programming to and how to specify the equations in a format that the GLPK Solver can work with.
The second set of resources I would point you to are the links to free opensource software that can be used to solve linear programming problems (often referred to as "LP Solvers").
The two main highqualtiy opensource LP Solver packages that I am aware of are the GLPK package mentioned in the article links above and the LPSolve package. Here are a couple of links to learn more about these packages.
 Wikipedia Page for GLPK. The page has useful links to various implementations of GLPK, including a javascriptbased one that looks interesting as it would be easy to embed in a web page.
 LPSolve Reference Guide. In my opinion, LPSolve's main feature is that is has bindings for many popular programming languages which makes it easy to call from these languages. Also, the documentation is quite good.
The 3 tutorial links and the links to 2 highquality LP Solvers should help you to get started in learning more about the nuts and bolts of Linear Programming and whether it might be useful in the context of optimizing some aspect of your business.

Permalink 
Intro to Linear Programming: Part 1 
[Business Models] 
Posted on September 25, 2013 @ 07:28:00 AM by Paul Meagher
Today I want to begin introducing you to a powerful optimization technique you might have occasion to use in your business. The
technique is called Linear Programming and is the primary technique taught and used in Operations Research. Wikipedia defines Operations Research as "a discipline that deals with the application of advanced analytical methods to help make better decisions. It is often considered to be a subfield of mathematics. The terms management science and decision science are sometimes used as synonyms".
Linear Programming is a fairly difficult technique to master because it involves some advanced math and the ability translate a
business problem into a set of equations representing what it is you want to optimize (i.e., maximize or minimize the value of) and the constraints
that exist upon how you can solve the problem (i.e., subject to constraints on labor, capital, machinery, time, etc...). The ability to translate a business problem into a set of equations is generally acquired by studying standard types of business problems that Linear Programming has been applied to and then using those example solutions as a template for applying the technique to your own similar situation.
In today's blog, I want to simply display the main set of formulas that are used in linear programming. I am reproducing the main linear programming formulas from the book Mathematical Programming for Agricultural, Enviornmental, and Resource Economics by Harry M. Kaiser & Kent D. Messer, Wiley, 2012. This was also an opportunity for me to take the MathJax library I setup yesterday for another test drive and learn more about how to add some professional looking math to my blog.
Here is the general form of the Linear Program (LP) model. First we need to define the objective function $Z$ that we want to maximize or minimize.
\[Z = c_1x_1 + c_2x_2 + ... + c_nx_n\]
Then we need to specify the various business constraints (labor costs, material costs, transport costs) that our business decision is subject to. These constraints are formulated in terms of equations with a left hand side being less than, equal to, or greater than some value in the right hand side:
\[a_{11}x_1\ + a_{12}x_2 + \cdots + a_{1n}x_n \lbrace {\le, =, \ge} \rbrace b_1\]
\[a_{21}x_1\ + a_{22}x_2 + \cdots+ a_{2n}x_n \lbrace {\le, =, \ge} \rbrace b_2\]
\[\cdots\]
\[\cdots\]
\[a_{m1}x_1\ + a_{m2}x_2 + \cdots+ a_{mn}x_n \lbrace {\le, =, \ge} \rbrace b_m\]
Finally, we generally add the constraint that all "activities" are nonnegative (we can't have negative activity values in our production model).
\[x_1, x_2, \cdots x_n \ge 0\]
We'll explore the technique of linear programming in further detail in my next blog
Note: If you want to see the tex code used to generate the equations in this blog, all you have to do is rightclick on the equation and MathJax supplies a viewer application for inspecting and copying the formulas.

Permalink 
MathJax Testing 
[Site News] 
Posted on September 24, 2013 @ 11:16:00 AM by Paul Meagher
MathJax is a javascript library (www.mathjax.org) that makes writing math on the web easier and more professional looking. It is generally not difficult to install or get working. I had issues with escape "/" characters and php's stripslashes function not working together very well and I also needed to add a config option for dealing with escape delimiters. After these issues were resolved, MathJax appears to work as advertised on their site.
To take MathJax for a tour, I first downloaded the "source code" for a classic textbook, Introduction to Probability, by Grimstead and Snell. The "source code" I downloaded was the tex code used to write the book with. I figured that one way to learn how to use the tex language to write math symbols would be to see how it was used in a beautifully typeset textbook whose content I want to read.
So here are a few sample sentences taken from the textbook, now reproduced online using MathJax:
Let $X$ be a numericallyvalued discrete random
variable with sample space $\Omega$ and distribution function $m(x)$. The expected value $E(X)$ is defined by $$ E(X) = \sum_{x \in \Omega} x m(x)\ , $$ We often refer to the expected value as the mean and denote $E(X)$ by $\mu$ for short.
The probability of getting \(k\) heads when flipping \(n\) coins is:
\[P(E) = {n \choose k} p^k (1p)^{ nk} \]
P.S. I had the opportunity to correspond with one of the authors of the Introduction to Probability textbook, Laurie Snell, a few years back on a few probability concepts (Markov Processes, Analysis of Repeated Surveys, and Chi Square analysis). Snell was around 80 at that time but still very active in the probability community spearheading the Chance News project. Snell also collaborated with Kemeny on writing a Finite Math textbook. Kemeny was the originator of the BASIC programming language.

Permalink 
Good Advice on Fund Raising 
[Venture Capital] 
Posted on September 19, 2013 @ 05:44:00 AM by Paul Meagher
Paul Graham is one of the cofounders and the leading voice for Y Combinator.
Since 2005, Y Combinator has funded over 450 startups, including Dropbox, Airbnb, Stripe, and Reddit.
Paul's latest blog posting, How to
Raise Money, offers excellent and authoritative advice for anyone trying to raise money for their startup. Below is a listing of his main points. To obtain more details on each point you should
read the full blog:
 Don't raise money unless you want it and it wants you.
 Be in fundraising mode or not.
 Get introductions to investors.
 Hear no till you hear yes.
 Do breadthfirst search weighted by expected value.
 Know where you stand.
 Get the first commitment.
 Close committed money.
 Avoid investors who don't "lead."
 Have multiple plans.
 Underestimate how much you want.
 Be profitable if you can.
 Don't optimize for valuation.
 Yes/no before valuation.
 Beware "valuation sensitive" investors.
 Accept offers greedily.
 Don't sell more than 25% in phase 2.
 Have one person handle fundraising.
 You'll need an executive summary and (maybe) a deck.
 Stop fundraising when it stops working.
 Don't get addicted to fundraising.
 Don't raise too much.
 Be nice.
 The bar will be higher next time.
 Don't make things complicated.

Permalink 
The Sharing Economy 
[Trends] 
Posted on September 17, 2013 @ 04:06:00 AM by Paul Meagher
Janelle Orsi is a lawyer specializing in supporting businesses and nonprofits that share services and resources. In a recent Post Carbon Institute article called The Sharing Economy Just Got Real she discusses what the sharing economy is and some of the legal grey areas that sharing companies operate within. It is worth a read to learn more about this important economic trend and how it might legally evolve in the future.
Below is video promoting the idea of sharing resources at the community level and all the good things that flow from such sharing.
The sharing economy is one trend for entrepreneurs and investors to keep and eye on as it has the potential to be very disruptive and potentially economic for those developing the sharing platform.

Permalink 
Processing Decisions 
[Decision Making] 
Posted on September 12, 2013 @ 06:14:00 AM by Paul Meagher
In the last few blogs I've discussed using Graphviz to generate nice looking decision trees. Sometimes, however, it is difficult to get exactly what you want out of Graphviz because it is designed to generate graphs dynamically (easy to change values/labels and generate a new graph) rather than uniquely crafted oneoffs. I decided to explore other alternatives to creating decision tree graphs and, to make a long story short, I have decided that a programming language called "Processing" (see http://www.processing.org website) offers the flexibility I need along with many other benefits. Processing opens up the possibilities for visualizing decisions exponentially because it can be used to create multimedia output, including graphs, on a huge range of devices (e.g., desktop browers, mobile devices, embedded devices). It is also a very elegant language and has a javascript+html5 implementation that makes executing "sketches" (e.g., the processing term for a program) in a webpage a breeze (the output of which can be static, animated, sonically enhanced, etc...). It also has an excellent development environment bundled with it and a large opensouce developer community. Finally, there are some extremely well written books on learning and using the language. The one to start with is by the language's authors:
Processing: A Programming Handbook
for Visual Designers and Artists
Casey Reas and Ben Fry (Foreword by John Maeda).
Published August 2007, MIT Press. 736 pages. Hardcover.
To give you a flavor of the language I'll offer up a couple of processing sketches from the book above. I was looking for some code that would get me started on drawing a tree and found this code (p. 202) for drawing a T.
int x = 50; int y = 100; int a = 35;
void setup() { size(100, 100); noLoop(); }
void draw() { drawT(x, y, a); }
void drawT(int xpos, int ypos,int apex) { line(xpos, ypos, xpos, yposapex); line(xpos(apex/2),yposapex, xpos+(apex/2), yposapex); }
The code above generates a simple tree structure that could be the starting point for a decision tree:
Cool! By making a few modifications to this program (e.g., adding recursive calls to the drawT function) a fractal tree can be generated with the following code:
int x = 50; int y = 100; int a = 35; int n = 3;
void setup() { size(200, 200); noLoop(); }
void draw() { drawT(x, y, a, n); }
void drawT(int x, int y,int apex, int num) { line(x, y, x, yapex); line(xapex, yapex, x+apex, yapex); if (num > 0) { drawT(xapex, yapex, apex/2, num1); drawT(x+apex, yapex, apex/2, num1); } }
Here is the output that the sketch above generates:
This, of course, is not a fullbodied decision tree but it gives us some insight into how the skeleton of a simple binary decision tree might be created  by calling a drawT function multiple times with the appropriate positional parameters. I'd prefer a lefttoright layout rather than a bottomtotop layout so that connections can be labelled easier.

Permalink 
Devil is in the Details 
[Decision Trees] 
Posted on September 10, 2013 @ 04:25:00 AM by Paul Meagher
In my previous blog, I showed how to construct a nice decision tree for a decision
about how much nitrogen to apply to a crop. In this blog, I want to advance our thinking about decision trees in two ways:
 Show how expected returns can be calculated using PHP.
 Discuss the issue of how detailed we should get when constructing a decision tree.
Computing Expected Return
In my blog titled Computing Expected Values I referred you to a video tutorial
on how to calculate expected values. In this blog, I will implement that calculation in a PHP script. Implementing the calculation
programmatically allows us to see what types of data structures need to be defined and how they looped over in order to compute
expected returns. We need a data structure to represent our actions (i.e., a $nitrogen array), our
events (i.e., a $weather ), our outcomes (i.e., a $payoffs matrix), and to store the expected returns
that are computed for each action option (i.e., an $EV array). With these basic elements in place we can
compute our expected values in a straightforward manner as illustrated in the code below:
<?php /** * @author Paul Meagher * @modified Sept 10/2013 * @purpose Compute expected return on nitrogen application amounts */
$nitrogen['lo']= 100; $nitrogen['med'] = 160; $nitrogen['hi'] = 220;
$weather['good'] = .2; $weather['ave'] = .5; $weather['poor'] = .3;
$payoffs['lo']['good'] = 8000; $payoffs['lo']['ave'] = 7000; $payoffs['lo']['poor'] = 6000;
$payoffs['med']['good'] = 9000; $payoffs['med']['ave'] = 8000; $payoffs['med']['poor'] = 7000;
$payoffs['hi']['good'] = 10000; $payoffs['hi']['ave'] = 9000; $payoffs['hi']['poor'] = 8000;
foreach($weather AS $type=>$prob) { foreach($nitrogen AS $level=>$amount) { $EV[$level] += $payoffs[$level][$type] * $prob; } }
echo "<pre>"; print_r($EV); echo "</pre>"; ?>
The output of this script looks like this:
Array
(
[lo] => 6900
[med] => 7900
[hi] => 8900
)
These are the expected returns for low, medium, and high levels of nitrogen application and correspond to the expect returns that
appeared in the decision tree appearing in my last blog.
Levels of Detail
The decision tree we have constructed to represent a nitrogen application decision is vague in many of its details and, as such,
would be difficult to use for the purposes of making an actual decision about whether to apply nitrogen or not.
Our biggest omission is to just talk about an "expected return" without talking specifically about whether this is expected
revenue, expected profit, or expected utility. If our payoffs are expected revenue amounts then our decision tree is not going to
be that useful because it hides the costs involved. For this reason, the expected profit would be a better value to compute as
our "payoffs" rather than expected revenues. Theoretically, an even better value to compute would be the expected utility
associated with each action option but that is a tricky value to compute because it depends on subjective factors and more complex
formulas. For this reason, we can be satisfied if we can at least compute expected profits for each decision option.
Another omission in our decision tree is any discussion of the costs associated with each proposed action. In order to compute
such costs we must get detailed about the when, where, and how of applying nitrogen. We also need to estimate the price
of nitrogen at the time of application. If we have already purchased our nitrogen then this would simplify our calculations.
Other costs include the cost of fuel to apply our nitrogen. We also need to be specific about what crop we are applying our
nitrogen to. In order to compute expected profits we would need to compute some other costs associated with planting,
cultivating, and harvesting the crop per acre so that these can be subtracted from the overall revenue generated to compute
our expected profits.
Our nitrogen application decision is impacted by weather which we have characterized as poor, average, or good. This is also
not very precise and would need to be specified in more detail. Weather could specifically mean rainfall amounts in the spring
phase of the year.
Once we get very specific about costs and what our variables specifically refer to, then our decision tree would provide better
guidance on how to act. The visual depiction of a decision as a decision tree helps to organize our research efforts but it
omits much of the research work that will have gone into making the decision tree useful and realistic.

Permalink 
Decision Tree Subgraphs 
[Decision Trees] 
Posted on September 5, 2013 @ 04:55:00 AM by Paul Meagher
I experimented with two Graphviz features that I thought might improve the appearance of my decision trees:
 I wanted the connecting lines to be rectilinear rather than curvilinear. Unfortunately, I am not able to achieve this effect when I use labelled edges; rectilinear connections only works when labels are applied to nodes, when labels are applied to edges it may be more difficult to calculate line placement. Rectilinear connections might have looked better but I'll have to live with curvilinear connections because I prefer labelled edges for the decision trees I'm exploring right now.
 I wanted to separately highlight actions, events, and outcome sections of the decision tree. I found a way to do this for the outcome nodes but have not found a way to apply further labelling or highlighting to labelled edges.
Todays blog shows how to use the "subgraph" feature of the dot language to highlite nodes that are related in some way. I used the subgraph feature to better highlite what the payoffs were for each separate action. The possible payoffs associated with each action option are distinguished by having a different color and bounding box for each set of payoffs.
Notice that the payoffs associated with each action are separately highlited and that I also add up the payoffs for each set of payoffs and report it as the expected value (EV) for that action. Here is where I get into calculating expected values manually because the dot language is not a general purpose programming language. For that I'll be using PHP in my next blog to compute expected values and supply them to the dot file that is generated.
Here is the dot file that was used to generate a decision tree that uses subgraphs to highlite sections of it.
/** * @author Paul Meagher * @modified Sept 5/2013 * @purpose Decision tree for nitrogen application decision */
digraph NitrogenDecision {
// orient graph left to right (instead of the top to bottom default) rankdir=LR; // don't display any directional arrows on the edges edge [dir=none]; // labelled nodes will appear inside a box shape node [shape=box]; // name your subgraphs with cluster_* identifiers subgraph cluster_lo { node [style=filled, color=orange]; GoodSeason100Kg AveSeason100Kg PoorSeason100Kg; label = "EV = $6900"; color=orange; }
subgraph cluster_med { node [style=filled, color=green]; GoodSeason160Kg AveSeason160Kg PoorSeason160Kg; label = "EV = $7900"; color=green; }
subgraph cluster_hi { node [style=filled, color=yellow]; GoodSeason220Kg AveSeason220Kg PoorSeason220Kg; label = "EV = $8900"; color=yellow; } // small connector shape without labels between actions and events Apply100Kg[shape=diamond,style=filled,label="",height=.1,width=.1]; Apply160Kg[shape=diamond,style=filled,label="",height=.1,width=.1]; Apply220Kg[shape=diamond,style=filled,label="",height=.1,width=.1]; // labels for terminal nodes when applying 100 kg nitrogen GoodSeason100Kg[label="Payoff = 0.2 * $8000"]; AveSeason100Kg[label="Payoff = 0.5 * $7000"]; PoorSeason100Kg[label="Payoff = 0.3 * $6000"];
// labels for terminal nodes when applying 160 kg nitrogen GoodSeason160Kg[label="Payoff = 0.2 * $9000"]; AveSeason160Kg[label="Payoff = 0.5 * $8000"]; PoorSeason160Kg[label="Payoff = 0.3 * $7000"];
// labels for terminal nodes when applying 220 kg nitrogen GoodSeason220Kg[label="Payoff = 0.2 * $10000"]; AveSeason220Kg[label="Payoff = 0.5 * $9000"]; PoorSeason220Kg[label="Payoff = 0.3 * $8000"];
// define edges and edge labels for each action Decision > Apply100Kg[label="Apply 100 kg N ($40)"]; Decision > Apply160Kg[label="Apply 160 kg N ($64)"]; Decision > Apply220Kg[label="Apply 220 kg N ($88)"];
// define edges and edge labels for each action + events combo Apply100Kg > GoodSeason100Kg[label="Good Season ... P = 0.2"]; Apply100Kg > AveSeason100Kg[label="Ave. Season ... P = 0.5"]; Apply100Kg > PoorSeason100Kg[label="Poor Season ... P = 0.3"]; Apply160Kg > GoodSeason160Kg[label="Good Season ... P = 0.2"]; Apply160Kg > AveSeason160Kg[label="Ave. Season ... P = 0.5"]; Apply160Kg > PoorSeason160Kg[label="Poor Season ... P = 0.3"]; Apply220Kg > GoodSeason220Kg[label="Good Season ... P = 0.2"]; Apply220Kg > AveSeason220Kg[label="Ave. Season ... P = 0.5"]; Apply220Kg > PoorSeason220Kg[label="Poor Season ... P = 0.3"];
}

Permalink 
Turtle Island Preserve 
[Nature] 
Posted on September 4, 2013 @ 05:43:00 AM by Paul Meagher
I'm watching a couple of documentaries this morning on Eustace Conway. Eustace is one of the featured people on the Mountain Men Reality TV series. I wanted to learn more about what Eustace's property, the Turtle Island Preserve, is all about. The reality TV series does not give one a good sense of how Turtle Island works as a whole. This documentary gives that overview and is quite entertaining, informative, and well done.

Permalink 
Improved Decision Tree Layout 
[Decision Trees] 
Posted on September 3, 2013 @ 05:34:00 AM by Paul Meagher
To date I have not been fully satisfied with how my decision trees have appeared. They did not appear to use space efficiently and they were not as easy to read as I would have liked. Today we will make some improvements to a Graphviz recipe for constructing decision trees. These improvements will make for a more space efficient decision tree that is also easier to read.
The main improvements I have made are:
 All of the labelling for actions and events appears on the edges instead of the nodes. In previous examples, most labelling was done at the nodes.
 There is no labelling at all between actions and events, just a small connector shape.
The combination of these two improvements means that 1) it is easier to read the graph as all the edges are labelled and the flow is oriented in a lefttoright fashion, and 2) the layout is more space efficient as the nodes connecting actions to events takes up alot of space when they include labelling. Now, we have only small connector shapes with no labelling.
I'll illustrate the improved decision tree in the context of a decision about how much nitrogen to apply to a crop per acre that involves calculating the payoffs you might expect if you get Good, Average, or Poor weather during the growing season. This is what such a decision tree looks like with the improvements mentioned above:
There are a couple of other aspects of this decision tree that are also noteworthy. First, the labels for each possible action (e.g., Nitrogen application amounts) includes the cost per acre of applying that amount of Nitrogen. One aspect of constructing a decision tree is computing the cost for each course of action. The second aspect to note is that the terminal nodes on our decision tree are often payoffs that involve multiplying an estimate of revenue by the probability of some event that significantly affects the payoff (e.g., the quality of the weather during the growing season).
I created the visualization for the nitrogen application decision using Graphviz. To do so I piped the recipe below into the graphviz program "dot". The recipe illustrates how to add comments to your dot file to make it easy to follow your recipe for rendering a graph shape. The recipe is also organized into logical sections to also make it easier to read.
/** * @author Paul Meagher * @modified Sept 3/2013 * @purpose Decision tree for nitrogen application decision */
digraph NitrogenDecision {
// orient graph left to right (instead of the top to bottom default) rankdir=LR; // don't display any directional arrows on the edges edge [dir=none]; // labelled nodes will appear inside a box shape node [shape=box];
// small connector shape without labels between actions and events Apply100Kg[shape=diamond,style=filled,label="",height=.1,width=.1]; Apply160Kg[shape=diamond,style=filled,label="",height=.1,width=.1]; Apply220Kg[shape=diamond,style=filled,label="",height=.1,width=.1]; // labels for terminal nodes when applying 100 kg nitrogen GoodSeason100Kg[label="Payoff = 0.2 * $8000"]; AveSeason100Kg[label="Payoff = 0.5 * $7000"]; PoorSeason100Kg[label="Payoff = 0.3 * $6000"];
// labels for terminal nodes when applying 160 kg nitrogen GoodSeason160Kg[label="Payoff = 0.2 * $9000"]; AveSeason160Kg[label="Payoff = 0.5 * $8000"]; PoorSeason160Kg[label="Payoff = 0.3 * $7000"];
// labels for terminal nodes when applying 220 kg nitrogen GoodSeason220Kg[label="Payoff = 0.2 * $10000"]; AveSeason220Kg[label="Payoff = 0.5 * $9000"]; PoorSeason220Kg[label="Payoff = 0.3 * $8000"];
// define edges and edge labels for each action Decision > Apply100Kg[label="Apply 100 kg N ($40)"]; Decision > Apply160Kg[label="Apply 160 kg N ($64)"]; Decision > Apply220Kg[label="Apply 220 kg N ($88)"];
// define edges and edge labels for each action + events combo Apply100Kg > GoodSeason100Kg[label="Good Season ... P = 0.2"]; Apply100Kg > AveSeason100Kg[label="Ave. Season ... P = 0.5"]; Apply100Kg > PoorSeason100Kg[label="Poor Season ... P = 0.3"]; Apply160Kg > GoodSeason160Kg[label="Good Season ... P = 0.2"]; Apply160Kg > AveSeason160Kg[label="Ave. Season ... P = 0.5"]; Apply160Kg > PoorSeason160Kg[label="Poor Season ... P = 0.3"]; Apply220Kg > GoodSeason220Kg[label="Good Season ... P = 0.2"]; Apply220Kg > AveSeason220Kg[label="Ave. Season ... P = 0.5"]; Apply220Kg > PoorSeason220Kg[label="Poor Season ... P = 0.3"];
}
Figuring out how to render decision trees with labelled intermediate edges instead of labelled intermediate nodes was a big step in creating a decision tree format that I find is more workable. I'm not done yet, however, as I want to explore some other features of graphviz to add some more tweaks to my decision tree.

Permalink 


