in Code

So I’m going to be running a series soon on computation and (physical) simulations using AFRP (Arrowized Functional Reactive Programming) principles.

I consider (A)FRP to actually be a pretty game changing paradigm. It provides us with semantics by which to compose and build time-varying, reactive behaviors and completely changes the way we approach any sort of simulation/state-like project.

AFRP has its own elegant way of approaching problems, but to be able to properly use it for simulations, we’re going to have to start by learning about the fundamental abstraction behind its implementation: machines.¹

(This post will assume a somewhat basic knowledge of Haskell. I’ll try explaining concepts here and there if I feel that they might not be very commonly known. But if you have any questions, feel free to leave a comment or stop by freenode’s #haskell on irc!)

(A short disclaimer: this article has not too much to do with the great machines library by Rúnar Bjarnason and Edward Kmett)

Read more … Comments

I spent some time over the past week writing a preprocessor for the entry copy markdowns and getting Fay to deploy some simple scripts.

The need for a preprocessor was sparked by a post I’m writing that sort of necessitated the features. I write all of my posts in markdown, and it all integrated well with the preprocessor. In addition I needed some javascript scripting to make the preprocessor actions worthwhile, so I buckled down and wrestled with getting Fay to work in a production environment. So I guess this post is to show off some new features of the blog engine?

Read more … Comments

It’s a bit late, but, inspired by my own admittedly egregious tweet in participation of the awesome #code2013 hashtag, here is a review of 2013 in terms of the programming languages I’ve worked on and a general wrap-up of the adventures that 2013 had to offer me. It was quite surely the most productive/adventurous year of programming of my entire life.

Read more … Comments

Today we’re going to learn to solve the classic and ageless logic problems without any data structures besides List’s monadic properties as a MonadPlus!

We are going to be solving this old-as-time logic puzzle, which Wikipedia claims dates back to the 9th century:

A farmer has a wolf, a goat, and a cabbage that he wishes to transport across a river. Unfortunately, his boat can carry only one thing at a time with him. He can’t leave the wolf alone with the goat, or the wolf will eat the goat. He can’t leave the goat alone with the cabbage, or the goat will eat the cabbage. How can he properly transport his belongings to the other side one at a time, without any disasters?

We’re going to assume a somewhat basic familiarity with functional programming concepts and a basic understanding of monads (if you don’t know that much, check out adit’s great concise guide). If you aren’t familiar with MonadPlus/Alternative (and how they work as monads) check out Part 1 and Part 2, which should provide all the background and most of the syntax. Most Haskell syntax is either be explained here as we get to it or in the previous parts. Still, if you have any questions, feel free to leave a comment, give Learn You A Haskell a quick read, or stop by freenode’s friendly #haskell!

Read more … Comments

Part two of an exploration of a very useful design pattern in Haskell known as MonadPlus, a part of an effort to make “practical” monads less of a mystery and fun to the good peoples of this earth.

When we last left off on the MonadPlus introduction, we understood that there are times when you want to chain functions on objects in a way that “resembles” a failure/success process. We did this by exploring the most simple of all MonadPlus’s: a simple “dumb” container for a value is either in a success or a failure. We looked at how the MonadPlus design pattern really “behaved”.

This time we’re going to look at another MonadPlus — the List. By the end of this series we’re going to be using nothing but the list’s MonadPlus properties to solve this classic logic problem:

A farmer has a wolf, a goat, and a cabbage that he wishes to transport across a river. Unfortunately, his boat can carry only one thing at a time with him. He can’t leave the wolf alone with the goat, or the wolf will eat the goat. He can’t leave the goat alone with the cabbage, or the goat will eat the cabbage. How can he properly transport his belongings to the other side one at a time, without any disasters?

Let’s get to it!

Read more … Comments

Monads. Haskell’s famous for them, but they are one of the most ill-understood concepts to the public. They are mostly shrouded in mystery because of their association with how Haskell models I/O. This reputation is undeserved. Monads don’t have anything to do with I/O.

This series is a part of a global effort to pull away the shroud of mystery behind monads and show that they are fun! And exciting! And really just a way of chaining together functions that allow for new ways of approaching puzzles.

The first sub-series (chapter?) will be on a specific class/family of monads known as MonadPlus. At the end of it all, we are going to be solving the classic logic puzzle, as old as time itself, using only the List monad instance, and no loops, queues, or fancy stuff like that:

A farmer has a wolf, a goat, and a cabbage that he wishes to transport across a river. Unfortunately, his boat can carry only one thing at a time with him. He can’t leave the wolf alone with the goat, or the wolf will eat the goat. He can’t leave the goat alone with the cabbage, or the goat will eat the cabbage. How can he properly transport his belongings to the other side one at a time, without any disasters?

Let us enter a brave new world!

Read more … Comments

Okay! In this series we will be going over many subjects in both physics and computational techniques, including the Lagrangian formulation of classical mechanics, basic principles of quantum mechanics, the Path Integral formulation of quantum mechanics, the Metropolis-Hastings Monte Carlo method, dealing with entropy and randomness in a pure language, and general principles in numerical computation! Fun stuff, right?

The end product will be a tool for deriving the ground state probability distribution of arbitrary quantum systems, which is somewhat of a big deal in any field that runs into quantum effects (which is basically every modern field). But the real goal will be to hopefully impart some insight that can be applied to broarder and more abstract applications. I am confident that these techniques can be applied to many problems in computation to great results.

I’m going to assume little to no knowledge in Physics and a somewhat intermediate working knowledge of programming. We’re going to be working in both my favorite imperative language and my favorite functional language.

In this first post I’m just going to go over the basics of the physics before we dive into the simulation. Here we go!

Read more … Comments

One of the crazy ideals of functional programming is the idea that your program is simply a list of definitions of mathematical functions. And like real math functions, FP functions are pure. That means that (1) they cannot affect any state, and (2) that they must return the same thing every time they are called with the same arguments.

When you first learn functional programming, this manifests as “your variables are immutable and you can’t do loops; use recursion instead.” And if you do that, everything is “fine”.

However, there is an apparent glaring problem with this adherence to purity: I/O. Input and output are inherently stateful.

Read more … Comments