Go on FastDataScience.eu

Comparing speed of some fast languages

Tue, 15 Oct 2024 00:00:00 +0000

To get more familiar with Rust, I’ve lately been revisting last year’s Advent of Code problems, which I did in Go last December. My Go solution solution for Day 5 uses brute-force and is not very clever, but runs fast enough in Go (under 6 minutes). The Rust equivalent runs in 1/3 less time, and I was wondering how other languages would fare. The results might surprise you.

I ended up writing the solution in Rust, Zig, and C, in addition to the original Go solution.

The problem (at least my naive solution) is good for a language benchmark because it involves lots of repeated transformations through a series of logic steps, with math, logic, and branching/looping. It took 5:40 minutes in Go, and Rust brought that down to 3:45 (when compiled with the –release flag). The results for the four languages are interesting (times in minutes):

Go takes 50% longer than Rust, better than I expected. As you’d expect, C is faster than Rust, and at 2:40 by quite a margin (compiled using gcc with -O3 flag for optimizations, and clang did even better at 2:21). And the big surprise was Zig, which ran in 1:51, using its ReleaseFast optimization flag(i.e., zig build -Doptimize=ReleaseFast).

The cost of speed: lines of code?

Another comparison is lines of code. You’d expect Rust to require fewer lines of code because of its expressive syntax, with function chaining, functional programming (map, filter, etc.), macros and the like. This is indeed the case. C and Zig are lower level, and require more lines (and programming time) to produce results:

However, you can see from a scatter plot of these two how Zig blows the other languages out of the water from an execution time point of view, while requiring almost 20% fewer lines than C, and roughly the same as Go:

Note that these line counts exclude comments and blank lines.

Looking at Zig

Sun, 13 Oct 2024 00:00:00 +0000

I finally took some time this weekend to look at Zig, and I am very impressed. It’s a fairly low-level language, but could be appropriate for some performance-critical data science use cases. Based on an initial test, it is twice as fast as Rust, which is about 50% faster than Go. And it appears to be faster than C, which I find puzzling.

To explore the language, I rewrote a naive and computationally intensive brute-force solution to day 5 of last year’s Advent of Code. My non-sophisticated solution took 5:40 in Go for both parts, fast enough that I didn’t bother finding a more streamlined solution (which would have been necessary in Python). For comparison, I also rewrote the same solution in Rust and C.

More on the performance comparisons in a future post. Here, I want to point out some observations on the language, and some pointers on how to use it. I’m not an experienced Zig user, so bear with me if you are.

Starting a project

The Zig ecosystem can be installed from your package manager, e.g., brew install zig on the Mac or pacman -S zig on Arch Linux. You will also want to install zls, the Zig Language Server, for IDE support.

To create a new project, create a new folder, enter it and run zig init. This creates a src folder with a couple of zig files in it, and two build.zig files, which control the build process.

To compile, run zig build, and the binary will be created in ./zig-out/bin and you can run this directly, i.e., zig-out/bin/test. When you’re ready, you can compile with full optimizations by typing zig build -Doptimization=ReleaseFast and it is true to this promise, as we’ll see.

The language

The Zig language looks a lot like C, but has more checks, and a type system that looks a lot like Rust’s. E.g., i32 and i64 for ints, etc.

The big difference is that Zig is very picky about memory, and you have to manually allocate memory, and free it or the program will show a lot of errors when it’s finished. So unlike Go, which does garbage collection to manage memory automatically, and Rust, which compiles using a “borrow checker” protocol that forces you to keep track of which variable currently “owns” each value but then automatically deallocates it for you, Zig requires to to allocate memory, and free it when you’re done. I found this very tedious, but it gets easier over time (as did the initially horrendous borrow checking in Rust).

For example:

//  Get a memory allocator
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
const allocator = gpa.allocator();
defer _ = gpa.deinit();

// Create a vector for numbers, add a number to it
var nums = std.ArrayList(i64).init(allocator);
try nums.append(5);

// Create a copy of a string
const my_name = "jabba the hut";
const name = try std.mem.Allocator.dupe(allocator, u8, my_name);

// When finished, free up the list and string
nums.deinit();
allocator.free(name);

You can free things up when they go out of scope by using defer as above, but you have to be careful that these are no longer being used, as the compiler will allow you to free things that have been passed to other variables (e.g., return values from a function call). This approach led to some very time-consuming debugging.

As noted, Zig has some useful data structures which are missing from C, but are present in every modern language, such as vectors and hash maps. Everything in the standard library is made available by importing one file, and is accessed by prefixing with std. as shown here:

// At the beginning of every program
const std = @import("std");

// Use stdout for writing formatted output, note the arguments have to be 
// in a .{} list, don't forget the period
const stdout = std.io.getStdOut().writer();
try stdout.print("A number {d} and a string {s}\n", .{33, "hello"});

// Read a file into memory, automatically allocating space for it, up to 
// the size given, fails if the file is too big. Any data must be copied 
// if you want to use it after the buffer is freed when the function ends.
const data = try std.fs.cwd().readFileAlloc(allocator, "input.txt", 10000);
defer allocator.free(data);

Functions are central as you would expect, and programs are driven by a main function which calls other functions that take and return values:

pub fn main() !void {
    try stdout.print("{d} doubled is {d}\n", .{12, double(12)});
}

fn double(n: i32) i32 {
    return n * 2;
}

You will notice that some function calls start with try and some function return types start with !. This is because they might fail, and Zig’s error handling is based on return values that might be errors, just like in Rust. In Zig, try executes the function call, and raises an error if the call fails. The ! before the return type indicates that the calling function might fail. It’s simple and quite elegant.

If you’re interested, have a look at the AoC example, the documentation, and the brief but excellent Zig by Example. There are currently no books about Zig, but that will change.

Local LLMs are getting easier

Fri, 23 Aug 2024 00:00:00 +0000

There is increasing interest in using smaller large language models (LLMs), hosted locally instead accessed from cloud-based vendors such as OpenAI. My clients have been interested in these either from a cost point of view, or for data protection reasons (since no data goes to OpenAI or other vendors).

Although this has been done for a while from Python using (mainly) the excellent Hugging Face, new options have come available that makes this easier and more flexible, especially from other languages such as Go and Rust. Here are observations and tips on a few alternatives that I’ve been trying.

Ollama

My favourite has been Ollama, a very clean and easy to use open-source tool (written in Go!) that downloads a select number of LLMs, then runs them, making available an input line for executing prompts, as well as exposing an API that is similar to the one we are used to from OpenAI.

The tool can be downloaded from the web site, and is easy to install on Mac OS and Linux. Then, just start it by typing ollama serve in a separate window.

You first need to download one of the 50 or so supported models, listed here. These include Llama 3.1 and 3.0, several variants of Mistral, phi, and others. For example:

ollama pull llama3.1

Type ollama list to see a list of models that have been downloaded (there does not seem to be a command to list all available models, see the above linked web page for that).

As soon as a model is downloaded, run it with ollama run llama3.1 and it will start up, with an input prompt that allows you to enter prompts. Type ollama info to show information about the model, such as the number of parameters and context length.

It also exposes an OpenAI-compatible API on port 11434, with endpoints generate and chat, making this an easy option for calling the LLM for any language using a REST API call. For example, from Go:

package main

import (
	"encoding/json"
	"fmt"
	"io/ioutil"
	"net/http"
	"strings"
)

// Structure for a generate request
type Generate struct {
	Model  string `json:"model"`
	Prompt string `json:"prompt"`
}

// Structure of one token returned per line
type Token struct {
	Model     string `json:"model"`
	CreatedAt string `json:"created_at"`
	Response  string `json:"response"`
	Done      bool   `json:"done"`
}

func main() {

	// Parameters for the query
	prompt := "What is time?"
	model := "llama3"
	url := "http://localhost:11434/api/generate"

	// Formulate a request to generate response to prompt, as string
	msg := Generate{model, prompt}
	b, err := json.Marshal(msg)
	if err != nil {
		fmt.Println(err.Error())
		return
	}

	// Needs to be an io.Reader for the Post request
	data := strings.NewReader(string(b))

	// Make a POST request to the API
	response, err := http.Post(url, "application/json", data)
	if err != nil {
		fmt.Println(err.Error())
		return
	}

	// Retrieve response
	responseData, err := ioutil.ReadAll(response.Body)
	if err != nil {
		fmt.Println(err.Error())
		return
	}

	// Extract and show individual tokens, one per line
	lines := strings.Split(string(responseData), "\n")
	tokens := []string{}
	for _, l := range lines {

		// End of input
		if len(l) == 0 {
			break
		}

		// Parse JSON
		tkn := Token{}
		err := json.Unmarshal([]byte(l), &tkn)
		if err != nil {
			fmt.Println(err.Error())
			return
		}

		// Stop after final token
		if tkn.Done {
			break
		}

		// Add to list of tokens
		tokens = append(tokens, tkn.Response)
	}

	// Show result
	fmt.Println(tokens)
}

Running this returns the following rather fanciful answer:

What a profound and complex question!

Time is a fundamental concept in our experience of the universe, but its nature has puzzled philosophers, scientists, and scholars for centuries. Here's an attempt to provide a comprehensive answer:

**Philosophical Perspectives:**

1. **Classical view:** Time is an objective feature of the universe, a linear progression from past to present to future. This perspective assumes time is a fixed, one-way dimension that governs our experience.
2. **Relational view:** Time is relative and dependent on the observer's frame of reference. According to this perspective, time is not absolute, but rather an emergent property of physical laws and human perception.
3. **Subjective view:** Time is a subjective experience, shaped by individual experiences, emotions, and memories.

**Scientific Theories:**

1. **Newtonian Mechanics:** Time is an absolute concept, independent of the observer's frame of reference. According to Newton's laws, time flows at the same rate everywhere in the universe.
2. **Relativity Theory (Einstein):** Time and space are intertwined as a single entity called spacetime. The laws of physics are the same for all observers, regardless of their relative motion or position. Time can appear to pass differently depending on the observer's frame of reference (e.g., time dilation).
3. **Quantum Mechanics:** Time is not a fixed dimension but rather an emergent property of quantum systems. Quantum phenomena, such as wave functions and entanglement, operate outside our classical understanding of time.

**Paradigm Shifts:**

1. **Kaluza-Klein Theory:** Higher-dimensional theories propose that our universe has more than the four dimensions we experience (three spatial and one temporal). This could imply that time is not an absolute concept.
2. **Fractal Time:** The idea that time is fractal, with repeating patterns at different scales, challenges our classical understanding of time as a linear progression.

**Philosophical Implications:**

1. **Free will vs. determinism:** If time is relative or subjective, does this imply free will, or are events predetermined?
2. **The nature of change:** Does the relativity of time imply that change is an illusion, or that reality is fundamentally dynamic?

**Conclusion:**

Time is a multifaceted concept that has been debated and explored across various disciplines. While our understanding of time has evolved significantly, the fundamental nature of time remains a subject of ongoing research and philosophical inquiry.

What's your take on time? Do you have any questions or perspectives to share?

Ollama also has options for importing GGUF files, creating models with a built-in system prompt, and more. See the GitHub page for more.

LlamaFile

Another good alternative is LlamaFile, which provides an executable that contains the model inside it. To run this model, just download one of the models from the web site, make it executable, and run it directly.

This option exposes a web interface for exploring chats (at http://localhost:8080), as well as an API compatible with the OpenAI one.

This is an attractive way to explore local LLMs, but I have since found Ollama easier to use and it offers a broader range of models.

LlamaCPP

Most of the adaptions described above are derived from Llama.cpp, and amazing C++ program that loads and runs Llama and some other transformer models inside a single program. It exposes both a web interface and an API. A large selections of models have been ported to this option.

It is more fiddly than Ollama, because it requires you to separately obtain the LLM in GGUF format, and specify this on the command line when running it. Most GGUF models are available on Hugging Face, but it’s still an extra step with some hassle.

I’ll create a separate post describing the running of LlamaCPP here, but you can probably figure out from from the GitHub page linked above.

Candle

Another interesting and ambitious option implemented in Rust is Candle, which supports about 20 models, and due to its support by Hugging Face is well documented and supported.

I plan on creating a separate post for this as I explore it further.

Advent of Code as a Lab for Fast Computing

Sat, 16 Dec 2023 00:00:00 +0000

This year’s Advent of Code is well past the half-way mark, and I’ve been reflecting on some of the harder or more interesting problems over the last few years, and the lessons learned about making code faster, or large problems tractable.

In case you haven’t encountered it, AoC is an annual coding competition, with a new problem every day, from December 1 through 25. Each day, there are two parts, and the second (usually harder) part unlocks after you solve the first part. You can use any programming language, and only need to submit the right answer (usually a number) to solve each part.

There is a global leaderboard, with amazingly short times for the top 100, and my company also has an internal leaderboard. We have a chat channel to share solutions and learnings, making it a very rich community experience.

The hardest problems for me have involved seeing things differently in order to solve them. In many cases, Part 2 requires a better algorithm, because while brute force may have sufficed for Part 1, the second part is 100 or a million times bigger.

I did these in a combination of Go, Julia, Rust, and Python. The code for all my solutions for 2020 through 2024 are in GitHub.

Here are some comments and observations about selected problems, with a perspective on techniques that made large problems computable in a reasonable amount of time.

2021

Day 15 (Go, Julia): Find the lowest cost path through a graph, starting at the top left, and ending up at the bottom right, adding up any cells you enter along the path that minimizes total cost. I did this in Go using graph library, Julia with Dijstra shortest-path algorithm (medium). A great learning experience for me, because it reinforced my application of when and how to use graph algorithms. In general, simple graphs are easy and quick to search using brute force, but larger graphs need algorithms to navigate quickly.

Day 19 (Go): Match up 3-dimensional cubes in space, adjusting x,y,z offset and also rotation along any 3 axes, so that at least 12 points in the each pair of cubes line up exactly. Then (Part 2), calculate the maximum distance between the cubes (hard). This problem required the right data structures to represent shapes in space, which made the searching and measurement feasible and quick.

Day 20 (Julia): Transform an image by successively replacing pixels with values looked up from a translation table, the index being the value of the 9 cells surrounding each pixel, converted from binary to decimal. Much complicated by the fact that the input data has a 1 in the first position of the translation table, meaning that empty areas are filled with 1s, which muck up the pixel count (hard).

Day 21 (Go): Simulate a game of rolling dice and moving round a board, trivial in Part 1. In Part 2, fork a set of parallel “universes” with identical state after every throw of a 3-sided die, and get the number of universes in which the winner won. This is one of the most head-breaking problems I’ve encountered, required thinking about state in a different way (hard).

Day 22 (Go): Turn on/off points in space, defined by 3-d ranges (like rectangular cubes). Part 1 quite easy (basically used brute force), but for Part 2 used recursive evaluation of volumes solution subtracting intersections. This required thinking about space in a more abstract way, and basically working backwards to get to an initial state (hard).

Day 23 (Go): Find the most economical solution to a board game, involving 4 (later 8) pieces from random starting tunnels to ordered destination tunnels via a corridor, sort of like the Towers of Hanoi. Solved the first part (8 pieces) on paper, second part using recursive depth-first search, eliminating branches that exceeded best solution found so far. This was a breakthrough for me in my understanding of Dynamic Programming (hard).

2022

Day 11 (Go, 100 lines): Simulate transfer of objects between a bunch of monkeys, with “worry levels” assigned to each object. Each monkey modifies the worry level according to some rules, then passes it to one of two monkeys, depending on whether the worry level is divisible by that monkey’s “test” number. Count up the number of inspections each monkey makes during the simulation. The answer is the product of the two highest inspection counts. Trivial (if tedious) for 20 iterations in Part 1, but integer values overflow for 10,000 iterations in Part 2, unless you apply an adjustment that preserves the decision outcomes while keeping the numbers fom getting too large. This was one of numerous problems in AoC that required finding a work-around for very large numbers (hard for Part 2).

Day 13 (Python, 49 lines): Given pairs of nested lists of numbers, count up how many are in the right order according to an arcane comparison function (Part 1), then combine all the pair elements into one big list, add a couple of marker elements, and sort the list according to the comparison function. For Part 2, report the product of the indices of the two marker elements. This was interesting because it’s quite easy in Python, due to its tolerance for mixed types, and illustrates how different languages are better for different things.

Day 15 (Go, 166 lines): Given a list of “sensors” and their distance to nearest “beacon”, find positions in a row that could not possibly have a beacon (Part 1), and the possible location of an undetected beacon (i.e., where there is in coverage by known beacons) for Part 2. I did this one by mapping every cell in the space, and it worked. But a colleague blew my mind with a very short solution, that used a geospatial library that instantly solves this sort of thing. Again, makes you reflect on which tool is best for every job (hard).

Day 16 (Go, also 166 lines): Given a network (graph) of closed “valves”, each with a certain flow rate, connected by “tunnels”, find the sequence of opening the valves (takes one minute, plus one minute per step to get there) that yields the highest possible total flow during a 30-minute period. For Part 2, same but try two decisions (one for you and one for the “elephant”) each time step, over 26 minutes. Used simple depth-first dynamic programming solution, recursively tries each feasible candidate unopened valve, excluding those for which we wouldn’t have enough time to get any flow. Same for Part 2, but tried all possible pairs of remaining valves, one for each actor (slow but works). Some colleagues did this using linear programming (DP solution very hard).

Day 17 (Go 123 lines + Python 87 lines): Simulate simple geometric shapes falling down a shaft, getting moved left and right by gusts of “gas”, and falling on top of each other. For Part 1, determine the total height of the shapes after 2022 have fallen. For Part 2, do the same for 1 000 000 000 000 shapes (infeasible to simulate, so looked for repeating pattern in height deltas, and applied simple math in separate Python script). This one was hard, but a breakthrough for me because it was infeasible to simulate, had to find a way around this, which turned out to be detecting repeating cycles in the output (which comes up regularly in AoC).

Day 18 (Go, 65 lines): Given a list of 1x1x1 cubes in 3-d space, count up surfaces that don’t touch another point (Part 1). For Part 2, only count surfaces that are outside the shape (may include some face inside of a “tunnel”, so can’t just look outward from surface). I rated this one as medium difficuly at the time (and my solution is quite short), but I remember being stretched by the need to think about space and anti-space.

Day 19 (Go, 152 lines): Basically a set of optimizations, to find the maximum number of “geodes” that can be produced over 24 periods from a set of four types of “robots”. Each robot can produce one mineral of its own kind each time period. There are 30 “blueprints” (cost schedules), each of which lists the number of each type of ingredient required to build a robot. So it’s a production plan optimization. Part 1 asks you to optimize all 30 schedules, Part 2 only the first 3 blueprints, but for 32 periods instead of 24 (hard, used dynamic programming but linear programming would have been possible). This one was a real breakthrough for me in the application of Dynamic Programming, including using recursion to break down a problem, and memoization to avoid recomputing values already encountered.

Day 20 (Go, 95 lines): Given a list of numbers (7 in sample, but 5000 in input), simulate moving each number forward or backward in the (circular) list, forward if positive or backward if negative. For Part 1, do this once, and report the sum of the values 1000, 2000, and 3000 after zero. For Part 2, multiply each number by a huge value, and do it 10 times, report same sum. Complicated by duplicate values in the main input, so you can’t just look for position of a value. Also, iterations in Part 2 are infeasible with large multiplier as well as 10 iterations (hard). This one was a breakthrough for me because it highlighted the importance of using the right data structure, in this case a circular queue.

Day 21 (Go, 72 lines): Given a list of variable names, each with either a numbers or a simple formula, recursively evaluate the root node (Part 1), and find the value for one cell that makes the two sides of the root node equal. This one was only medium difficulty for me, but I remember having the “aha” moment when I realized that it could be solved using gradient descent, which I have several times coded during my career.

Day 22 (Go, 374 lines): Simulate movement on a 2D map, according to a list of instructions, which can either be to move n steps, or to turn 90 degrees left or right. There are obstacles to avoid, and one wraps around to the other side when walking off and edge. For Part 1, the map is in 2D. For Part 3, the map gets folded into a cube. This one was very hard, because of the 2D movements on different contiguous surfaces of a 3D object. I created a very verbose solution that mapped each possible transition from one surface to another.

Day 24 (Go, 175 lines): Find shortest path from entry to exit of a rectangular field, avoiding “blizzards” that move every time step. For Part 2, also move back to entry then back to exit, and add up all the steps. Used dynamic programming, depth-first search with memoization of previously found best values for each position+time combination (medium). Again a problem that reinforced my understanding and appreciation of Dynamic Programming.

Linear Programming in Go

Sun, 12 Nov 2023 00:00:00 +0000

I’ve been away helping Bain set up a new capability in generative AI, on the back of our OpenAI partnership, and am coming back to standard data science problems. In this post, I’d like to share some experiments doing linear programming optimization, using Gonum’s optimization library. It’s a very basic facility, but has helped me learn how to set up problems using the venerable Simplex algorithm, first developed by George Danzig in 1947.

First of all, I wouldn’t recommend using this approach for real problem solving, since it’s rather cumbersome, as you will see. Instead, use Pulp or another Python library, or a dedicated mathematical programming tool such as GLPK (open source) or Gurobi (commercial license). Nevertheless, I found this approach helpful for finally understanding how problems are represented as matrices, and it serves as a readily available, minimalist approach to solving simpler linear optimization problems.

A simple problem

Here is a simple example LP problem, from Brunel University:

A company is involved in the production of two items (X and Y). The resources need to produce X and Y are twofold, namely machine time for automatic processing and craftsman time for hand finishing. The table below gives the number of minutes required for each item:

         Machine time Craftsman time
Item X   13           20
     Y   19           29

The company has 40 hours of machine time available in the next working week but only 35 hours of craftsman time. Machine time is costed at £10 per hour worked and craftsman time is costed at £2 per hour worked. Both machine and craftsman idle times incur no costs. The revenue received for each item produced (all production is sold) is £20 for X and £30 for Y. The company has a specific contract to produce 10 items of X per week for a particular customer.

Formulating the problem

A simple formulation to this problem into decision variables, objective function, and constraints, looks as follows:

Let
    x be the number of items of X
    y be the number of items of Y

Maximise
    20x + 30y - 10(machine time worked) - 2(craftsman time worked)

Subject to:
    13x + 19y <= 2400       // machine time
    20x + 29y <= 2100       // craftsman time
    x >= 10                 // contract
    x,y >= 0

The objective function can be expanded and simplified as:

Maximise
    20x + 30y - 10(13x + 19y)/60 - 2(20x + 29y)/60
    => 17.1667x + 25.8667y

Converting to matrix

The above formulation can be input almost verbatim into the various standard optimization libraries (example below). To use Gonum’s simplex optimizer, however, you need to convert it to a matrix. This process is not described in the documentation, and I could not find any pages that show examples with explanation. So here we go.

The call to the optimizer will look like this:

opt, x, err := lp.Simplex(c, A, b, 0, nil)

There are three important arguments to Simplex:

c is a vector (array of float64 numbers) of the objective function coefficients (negative to minimize)
A is a matrix of the left hand side coefficients for the constraints, one row per constraint
b is a vector of the right hand side values of the constraints

Let’s take them in turn.

Objective function coefficients

The objective function is

Maximise:
    17.1667x + 25.8667y

There are only two decision variables (x and y), so we are only interested in two columns here. However, we need to add three more columns for the “slack” variables, one per constraint, otherwise there will be no feasible solution if the optimum values do not exactly equal the constraints.

Note: can we make do with two slack variables, one per decision variable (x and y) instead of one for each of the three constraints?

Furthermore, the Simplex algorithm does minimization, so to maximize, we need to multiply the coefficents by -1.

So c, our vector for the objective function coefficients, is:

c := []float64{-17.2, -25.9, 0, 0, 0}

LHS constraint coefficients

A is a Gonum matrix of the left hand side coefficients for the constraints. There is one row per constraint. There is also one column per decision variable (x and y), but also additional columns with diagonal ones, one per constraint.

Note that

<= constraints are converted to = by adding slack variables
<= constraints are represented with the same sign as the problem definition
Any >= constraints need to have the coefficients multiplied by -1, both in the left hand side (matrix A), and also the vector of right-hand side values (c, see below)

Our constraints are:

Subject to:
    13x + 19y <= 2400       // machine time
    20x + 29y <= 2100       // craftsman time
    x >= 10                 // contract
    x,y >= 0

The matrix is 3 rows x 5 columns (note that x,y >= 0 does not need to expressed, as the algorithm takes care of this constraint):

13 19  1  0  0
20 29  0  1  0
-1  0  0  0  1

The first row is 13x + 19y, the second row is 20x + 20y, and the third row is 1x (converted to negative because it is >= instead of <=).

The Go matrix (using Gonum’s mat module) is:

A := mat.NewDense(3, 5, []float64{
    13, 19, 1, 0, 0,
    20, 29, 0, 1, 0,
    -1, 0, 0, 0, 1})

Right hand constraint values

Finally, b is a vector of the right hand side values of the constraints, the bounds to which we are restricting the various constraints.

Again, given these constraints:

Subject to:
    13x + 19y <= 2400       // machine time
    20x + 29y <= 2100       // craftsman time
    x >= 10                 // contract

The bounds are 2400, 2100, and 10. But the 10 needs to be -10, since it is a >= instead of <= constraint. So the Go array is:

b := []float64{2400, 2100, -10}

Putting it all together

The complete program looks as follows:

package main

import (
    "fmt"
    "gonum.org/v1/gonum/mat"
    "gonum.org/v1/gonum/optimize/convex/lp"
)

func main() {

    // Problem formulation
    c := []float64{-17.2, -25.9, 0, 0, 0}
    A := mat.NewDense(3, 5, []float64{
        13, 19, 1, 0, 0,
        20, 29, 0, 1, 0,
        -1, 0, 0, 0, 1})
    b := []float64{2400, 2100, -10}

    // Run Simplex algorithm, last parameter is initialBasic
    opt, x, err := lp.Simplex(c, A, b, 0, nil)
    if err != nil {
        fmt.Println(err.Error())
        return
    }

    fmt.Printf("Optimum = %f, x = %f, y = %f\n", opt, x[0], x[1])
}

Note that in addition to c, A, and b, lp.Simplex also requires a number as the tolerance (0 as in the example above), and optionally a vector representing the starting values.

Also note that lp.Simplex returns the optimum value, an array of coefficients, and an error (e.g., solution is infeasible, or problem is unbounded). The array of solution coefficients corresponds to the columns in the A matrix, so you only need to the first two in the example above (altough the others are interesting for seeing the slack values).

You will need to install Gonum’s matrix and simplex modules:

go get gonum.org/v1/gonum

So to build and run the program, do the following:

mkdir lpexample
cd lpexample
vim main.go
(paste the above code and save)
go mod init lpexample
go get gonum.org/v1/gonum
go build
./lpexample

You should get the solution x = 10, y = 65.52, max = 1866.5

Formulation in Python

As mentionned above, such programs are much easier to create and understand using a Python library or a dedicated mathematical programming tool. For comparison, below is the same problem formulated in Python using Pulp. It’s a bit longer, but easier to read and maintain, because you don’t need to keep track of the columns and signs in the matrices and vectors. It also allows you to switch between different solvers.

from pulp import *

# Create the 'prob' variable to contain the problem data
prob = LpProblem("Example", LpMaximize)

# Problem variables (use LpInteger for integer solution)
x = LpVariable("x", 0, None, LpContinuous)
y = LpVariable("y", 0, None, LpContinuous)

# Objective function
prob += 17.2*x + 25.9*y

# Constraints
prob += 13*x + 19*y <= 2400 # machine time constraint
prob += 20*x + 29*y <= 2100 # labor time constraint
prob += x >= 10 # contract commitment

# Solve the problem
status = prob.solve()

# Print results
print("Status:", LpStatus[status])
print("x:", value(x))
print("y:", value(y))
print("Objective:", value(prob.objective))

Again, you should get the solution x = 10, y = 65.52, max = 1866.5 (or slightly different if you chose to use LpInteger for integer programming).

Starting a New Go Project

Thu, 30 Jun 2022 00:00:00 +0000

If you are new to Go, here is the basic process for setting up a new project and building/running it. This assumes that you have already installed Go as described in the previous blog post.

First, create a working directory for the project, and change into it:

mkdir ~/myproject
cd ~/myproject

Then, use your favorite text editor or IDE to create a Go program, with any name that ends in .go, for example main.go:

vim main.go

Here is the canonical simplest program, that just prints a message:

package main

import "fmt"

func main() {
    fmt.Println("Welcome to Go")
}

You could compile this program directly, by typing:

go build main.go

Then, you will see a new file called main in the directory, and you can run this executable by typing:

./main

However, I recommend that you set up the program as a module, so you can use go build to build a program from multiple source files, and run tests. This also plays nicely with IDEs:

go mod init fastdatascience.io/myprogram

Replace the URL with your own (or with github.com if creating an open-source module that others can pull in). The module name (“myprogram” in the example above) should be the same name as the directory, so IDEs like LiteIDE will build correctly. Note the URL is optional, and you don’t need the slash if you omit the URL.

Then, you can just type:

go build

to create the executable. As before type ./main to run the program.

You can also type go run to build and run the program in one step (but this does not keep the executable).

Finally, you should initialize the directory with Git and make a commit with you your new program:

git init
git add main.go
git commit -a -m "Initial commit of new Go program

You can also create a respository in GitHub, and sync the repository to to GitHub.

That’s it, you now have a project to build upon.

A Basic Go Setup

Sun, 19 Jun 2022 00:00:00 +0000

In this article, I wanted to share the setup I use for writing data science programs in Go. I’ve found it very easy to get started with this language, but thought it might be useful to describe the setup.

I use both Linux and a Mac, so this article will describe those platforms, but Go should work well on Windows as well. In any case, we assume that you are comfortable running the command line.

Installing the Go compiler and tools

First of all, install Go itself. On Linux, use your package manager, e.g., on Arch Linux it would be:

pacman -S go

On Mac OS, you can either use Homebrew:

brew install go

Or download and run the installer from https://go.dev/dl

Either way, you should be able to run the go program to get the version, e.g.,

go version

Choosing an editor or IDE

Go programs are just text files, so you can use any editor. Many editors have plug-ins to support Go programming, so you will want to look into these. I use vim, and have found go-vim quite useful.

If you like something bigger, this page describes various Integrated Development Environments (IDEs). The most widely used seem to be VS Code (free but not open source) with this extension, and GoLand (commercial product requiring a paid license) from JetBrains, the makers of PyCharm for Python.

And my favorite option has become LiteIDE, a simple and small open-source IDE specifically for Go. It can be downloaded and installed from the above link (or using your package manager on Linux). I like LiteIDE’s simple project architecture (just a directory containing code), debugging support, and simple interface, which has buttons to build, run, and test your code.

In the next post, I’ll assume you’ve set up Go and your favorite editor or IDE, and will describe how to create and run a simple program.

Why Speed Matters

Sun, 08 May 2022 00:00:00 +0000

The vast bulk of data science work is done using Python and R, and that’s fine. Those languages are well suited to analytics, and make available a rich infrastucture of libraries and documentation.

Looking at just Python (R is similar), there is however a problem. Python is slow, due to its interpreted execution model and dynamic typing. As a Python program runs, it is constantly checking for the types of different variables and data, and for the feasibility of certain operations such as converting data types and expanding lists. While this makes for fast development and prototyping, it can be very slow for some types of analysis.

The penny dropped for me after I worked on a price optimization project for a global beer company, which optimized wholesale and retail prices across four countries, partly using complex procedural logic to calculate the impact of price changes on volume. The Python optimization was done using simulated annealing, using the standard scikit-learn library. The optimization took twelve minutes to run, and defeated our hopes of running it in real time behind an interactive user interface.

The problem was that the objective function (which needs to run hundreds or thousands of times as the optimization explores the solution space) consisted of about 200 lines of Python. While the simulated annealing was presumably efficient, this complex objective function code made the optimization a slow process.

Discovering Alternatives

During some vacation after the project, I took advantage of the down-time to learn Julia. As a specific project, I rewrote the optimization in Julia, using its optional static typing, and an open-source simulated annealing libary, and the execution time went from twelve minutes down to six seconds. This massive speed improvement (a factor of 120x), brought the idea of a user interface running the simulation in the background into the realm of possibility.

A few months later, I decided to learn Go. Again, I rewrote the optimization, using an open-source simulated annealing implementation around the recoded objective function. This time, execution was even faster, reaching 0.6 seconds. This was now performant enough to enable the interactivity we had been hoping for, and Go’s suitability for microservices was another strong enabler of this vision.

It should be noted that neither Julia nor Go involved a massive rewrite of the original Python objective function. Both languages allow for a procedural style and syntax that is not very far from Python’s, so the translations were reasonably forward, and took about half a day in each language.

It’s not just about saving time

The point that excited me was not the speed per se (since we routinely tolerate code that takes a long time to run, and adapt our workflows accordingly). It was the new set of possibilities, either through the quick calculation of a lot more parameters or scenarios, or the ability to do calculations fast enough for users to explore the problem space in an interactive way, which is not possible when it takes 12 minutes or longer to recalculate.

In this blog site, then, I’d like to share my continuing journey around fast data science, and using different languages, architectures, and algorithms to enable new explorations in data science.