Sometimes I’ll see that movie X is awardwinning, has 95%+ on Rotten Tomatoes and rave reviews. But it looks like a difficult movie, so I opt for something more poorly reviewed and trashy. However, if I think back over my experience of moviewatching, movies of the first type I almost always enjoy while movies of the latter type I often regret watching.
This above example is something that I’ve done myself, with the same outcome as Scott’s i.e. I end up regret watching a movie that has poorer reviews but was “easier” to watch. He goes on to say:
]]>while pleasureseeking and painavoidance are powerful human motives, they aren’t the only ones. Seeking cognitive and physical ease is sometimes a more powerful one, and it can override the desire for a more enjoyable option, if that option is perceived as being more “difficult” in some way.
Haskell’s function type ((>) r)
is an Applicative functor. Similar to the previous two posts in this series, in this post I will verify that the applicative laws hold for the ((>) r)
type.
For reference, ((>) r)
is made an instance of the Applicative
class as:
1 2 3 4 5 6 7 8 9 10 

For review, here are the applicative laws:
Identity: pure id <*> v = v
Homomorphism: pure f <*> pure x = pure (f x)
Interchange: u <*> pure y = pure ($y) <*> u
Composition: pure (.) <*> u <*> v <*> w = u <*> (v <*> w)
We need to prove that the following holds for the ((>) r)
type:
1


Beginning from LHS:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 

The law’s statement is:
1


Here’s the proof:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 

The law’s statement is:
1


Starting from the LHS:
1 2 3 4 5 6 7 8 9 10 11 12 

Now, starting from the RHS:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 

As both the left and right sides reduce to the same statement, the interchange law is proved for the ((>) r)
type
The law’s statement is:
1


Starting from the right side of the equation:
1 2 3 4 5 6 7 8 9 10 11 

In the same manner, let’s consider the left side of the equation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 

(A) & (B) prove that both the left and right side of the composition law for ((>) r)
type reduce to the same statement, and thus the law is proved for the function type.
Thanks to Daniel Wagner who nudged me in the right direction by answering my questions (1 and 2) on Stack Overflow.
]]>Haskell’s list type []
is an Applicative functor. Similar to the previous post, this post will verify that the applicative laws hold for the []
type. For reference, []
is made an instance of the Applicative
class as:
1 2 3 

For review, here are the applicative laws:
Identity: pure id <*> v = v
Homomorphism: pure f <*> pure x = pure (f x)
Interchange: u <*> pure y = pure ($y) <*> u
Composition: pure (.) <*> u <*> v <*> w = u <*> (v <*> w)
Now, let’s test the Applicative laws for the []
type one by one:
We need to prove that the following holds for the []
type:
1


Consider the left side of the equation:
1 2 3 4 5 6 7 8 9 10 11 12 13 

The law’s statement is:
1


Starting from the left side:
1 2 3 4 5 6 7 8 9 10 11 

The law’s statement is:
1


Starting from the left side,
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 

The law’s statement is:
1


Starting from the left:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 

In the same manner, let’s consider the right side of the equation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 

(A) & (B) prove that both the left and right side of the composition law reduce to the same statement, and thus composition law is proved for the []
type
Identity: pure id <*> v = v
Homomorphism: pure f <*> pure x = pure (f x)
Interchange: u <*> pure y = pure ($y) <*> u
Composition: pure (.) <*> u <*> v <*> w = u <*> (v <*> w)
For more information about these laws, check out this Haskell wiki post.
Maybe
is an Applicative functor, and this post will verify that the applicative laws hold for the Maybe
instance.
Before we begin, let’s review the definition for Applicative
typeclass:
1 2 3 

Maybe
is made an instance of the Applicative
class as:
1 2 3 4 

Note that the last line above can be rewritten as:
1 2 

Now, let’s test the Applicative laws for the Maybe
type one by one:
We need to prove that the following holds for the Maybe
type:
1


Let’s start from the left side of the equation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 

The law’s statement is:
1


To prove this for Maybe
type, let’s begin from the left side of the equation:
1 2 3 4 5 6 7 8 

The law’s statement is:
1


Starting from the left side:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 

The law’s statement is:
1


Starting from the left side:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 

Maybe
type is made an instance of the Applicative
type class as follows (link):
1 2 3 4 

It took me a several attempts before I could parse this definition. I was particularly puzzled by the line (Just f) <*> something = fmap f something
. To help me understand this better, I decided to build this definition back up from the very basics.
First, let’s look at the Functor
type class definition:
1 2 

This means that for a given functor type f
(i.e. type that is an instance of the Functor
type class), fmap
takes a function from a > b
and a functor (box) that contains a
and returns a functor (box) that contains b
. An intuitive way to think about this is that fmap
opens the box containing a
and applies the function a > b
to it, which results in b
.
Now let’s see how Maybe
is an instance of the Functor
type class:
1 2 3 

Nothing
results in Nothing
.Functor
type, we know that the type of func
is a > b
and Just x
corresponds to f a
. Applying the function to x
inside the box results in a value of type b
in the functor box.Now, let’s look at the definition of the Applicative
type class:
1 2 3 

For a type f
that is an instance of the Applicative
type class, here is what each line means:
f
must also be a functor (i.e. be an instance of the Functor
type class).pure
function takes an arbitrary type a
and brings it into the functor. i.e. pure
puts a
in a box of type f
.<*>
takes a functor (box) of type f
that contains a function of type a > b
, and a functor (box) of type f
that contains type a
. It results in a functor (box) of type f
that contains b
.With the preamble out of the way, let’s make Maybe
an instance of the Applicative
type class. To do that, I need to implement the pure
and <*>
methods for the Maybe
type. Below is a linebyline implementation:
1 2 

For the Maybe
type, pure
simply wraps an arbitrary type in Just
, thus making it a Maybe
value. E.g. writing pure 4 :: Maybe Int
in GHCi results in Just 4
.
1


Here, Nothing
maps to f (a > b)
from the Applicative
class definition. We cannot extract a function out of Nothing
, so the result will be Nothing
regardless of the second argument.
1


In the line above, (Just func)
maps to f (a > b)
, and Nothing
maps to f a
from the class definition. <*>
extracts func
out of Just func
, and applies it to Nothing
. Applying a function to Nothing
results in Nothing
(or, using the box analogy, applying a function to an empty box results in an empty box)
1


(Just func)
maps to f (a > b)
, and Just x
maps to f a
from the Applicative
class definition. <*>
extracts the function from Just func
, and applies it to x
inside the Just x
box. The result is Just (func x)
.
Now, let’s put the definition of <*>
for Maybe
type next to the definition of the fmap
function:
1 2 3 4 5 

This makes it obvious that in the definition of <*>
, once we extract func
out of Just func
, we simply map that function over the second argument of <*>
(which will be of Maybe
type as well). This means that the <*>
implementation for Maybe
can be rewritten as:
1


This is exactly how the <*>
function is implemented at the beginning of this blog post.
Finally, Functors, Applicatives, And Monads In Pictures by Aditya Bhargava is one of the best posts I’ve read on functors & applicatives. I highly recommend it.
]]>1 2 3 4 5 6 7 

The numbers at the edge of the triangle are 1, and each number inside is the sum of two numbers above it. The exercise asks us to find the elements of Pascal’s triangle by means of a recursive process.
I find it helpful to deskew the triangle so that the rows and columns line up visually. Here’s the modified triangle:
1 2 3 4 5 6 7 

I decided to write the solution in Haskell, and here it is:
1 2 3 4 5 6 7 8 

This code is great for generating the element at a given row and column (e.g. pascal 3 2
produces 3
), but not so great if we wanted to generate the entire triangle up to n
rows, as we would recursively generate the elements at row n1
multiple times.
In order to generate the entire triangle, it is better to do it via an iterative process as follows: generate the first row, and from that generate the second row, and so on. I other words, we are generating the next row of the triangle, by adding each pair in the current row. My solution is as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 

Here are a couple of examples of generating the triangle:
1 2 3 4 5 6 7 8 9 10 11 12 13 

The function pascalTriangle
can be made more concise by using the builtin iterate
instead of my pascalHelper
:
1 2 

By this point, I was reasonably satisfied with the code. However, being relatively new to Haskell, I decided to explore and see if there were other (and possibly better and more idiomatic) ways to solve this problem. My favorite was by Neil Mitchell, who solved the problem in two lines! I encourage you to go read Neil’s entire post. Here’s the twoline version of Haskell’s triangle:
1 2 3 4 5 

In my view, this code is very elegant and beautiful and does a great job of highlighting the power of Haskell.
]]>foldl
or foldr
is not the first idea that comes to mind when indices are involved. However, there is a general pattern that can be applied when using folds for indexbased list operations. For example, consider the case where we need to add an element at a particular index:
1 2 3 4 5 6 7 

The basic idea is simple: We simply zip [0..]
with the input list (ys
) to get a list of tuples. The first element of each tuple is the index of the element in the list ys
(input list). This allows us to perform index based tests in the helper function, as shown in insertHelper
above.
Both left and right folds can be used for index based list operations. Here’s the same example using foldl
.
1 2 3 4 5 6 7 

Both left and right fold produce the same result. Adding an element to the head of the list (via :
) is more efficient than concatenating lists (via ++
), so generally I prefer using the 1st version, i.e. one that uses foldr
Here’s a gist with examples of insertAt
, updateAt
, and deleteAt
functions, all implemented using folds.
Compensation negotiations are presently like a stock exchange where only your counterparty can see the ticker and order book. You’d never send an order to that exchange — it would be an invitation to be fleeced. “I happen to have a share of Google and want to sell it. What’s it go for?” “Oh, $200 or so.” “Really? That feels low.” “Alright, $205 then, but don’t be greedy.”
The spot price of Google when I write this is $535. Someone offering $205 for GOOG would shock the conscience. In the years since I wrote a post on salary negotiation for engineers I have received many letters suggesting folks have received and accepted employment offers much worse than that, relative to reasonably achievable market rates.
When you are done reading this post, go and read his post Salary Negotiation: Make More Money, Be More Valued. Really informative and useful.
]]>Tony’s post is more than a year old though, and it looks like a couple of things have changed since he wrote his post, especially with the latest version of Haskell and SublimeHaskell. I wasted a good chunk of time trying to get around those problems, so now writing this post in case others run into similar issues when setting up the SublimeHaskell plugin.
Here’s a summary of the steps to setup the Haskell dev environment (from Tony’s blog).
cabal update
to update the list of available packages for Haskell.cabal install aeson haskellsrcexts haddock hdevtools
.This last step doesn’t work seamlessly. When I installed SublimeHaskell, I ran into the following error message in Sublime Text:
1 2 3 4 5 

The problem is described in more detail in issue #182 on SublimeHaskell’s GitHub page. The summary is that the master branch of SublimeHaskell is too slow to accomodate the removal of PNeg
from haskellsrcexts
. The solution is to use the hsdev
branch of SublimeHaskell. This is done as follows (recommended by MoreAxes on comment thread for issue #182):
cmdshiftp
), and use the ‘Add Repository’ command to add https://github.com/SublimeHaskell/SublimeHaskell/tree/hsdev
.hsdev
branch.You can now enter and build Haskell code from Sublime Text. To verify your setup, enter the following code in Sublime Text, and then hit cmdB
1 2 3 

You will see the following printed:
1 2 

Here’s a screenshot of my test file, with the output of the program:
]]>]]>I was hopeful when I opened Peter Seibel’s Practical Common Lisp and saw that the introduction was subtitled “Why Lisp?” Yes, tell me! Seibel echoes Graham’s claim: “You’ll get more done, faster, using [Lisp] than you would using pretty much any other language.” OK, but how? Seibel wonders whether “I like Lisp because of some quirk in the way my brain is wired. It could even be genetic, since my dad has it too.” That’s not encouraging to those of us outside your family. Ultimately, he sums up the appeal of Lisp by describing it as “the programmable programming language.” But I’ve never used a programmable programming language. Why should I start?
And by the way, when do I get the speed and power you keep promising?
In short—what’s in it for me, now?
Here are some of the essays that I particularly enjoyed:
I certainly plan on rereading this book often. Here’s my bookmarked copy
Hackers & Painters What does it mean to be a hacker? A great hacker? What is common between hackers and other makers? This essay explores all these ideas, and does so very well. Probably one of my favorites (though, it is hard to pick just one favorite).
Beating the averages Very thought provoking essay, and really resonated with me as it argues something that I too have observed. Not all highlevel programming languages are equally powerful. Some languages are more powerful than others. Programming languages fall on different points on the power continuum, and moving higher on this contiuum has allowed me to think and reason about programs in more powerful ways. In liguistics, this is the SapirWhorf hypothesis:
The principle of linguistic relativity holds that the structure of a language affects the ways in which its respective speakers conceptualize their world, i.e. their world view, or otherwise influences their cognitive processes.
The hundredyear language Another way to think about programming languages is to think them on an evolutionary tree. In this scenario, some fall on evolutionary deadends, and thus do not have any intellectual descendants. Once we start thinking about programming languages using this model, it becomes easier to see how languages might evolve, and predict the future evolution of programming languages.
How to make wealth I had not read this essay before, and had not given any serious thought to the difference betweeen money and wealth. This essay explores the differences between the two, and really sold me on the idea “Wealth is what you want, not money”. Great read & very informative.
Back to 2015. I’ve been thinking about rebooting my blog for several weeks, and finally decided to take the first step. I hope to blog more frequently than I’ve done in the past few years.
For setup, I decided to generate my blog via Octopress and host it on GitHub Pages. I really like Octopress’s simplicity, look and feel, and control over various aspects of blog generation and hosting. Another advantage is that I do most of my writing in Markdown format, which is the default for Octopress. Lastly, Octopress generates my blog as static HTML.
My next steps are to figure out what to do about my old Wordpress posts. I needed to decide whether I am going to import them here, link to them instead of importing, or simply ignore.
]]>Here is the code for the quine. I’ve broken the code below into segments to make it simpler to understand:
1 2 3 4 5 6 7 8 9 10 11 12 13 

Before I go on, 10, 64 and 34 are the ASCII character codes for newline
, @
and "
respectively. To make it clearer, I’ve broken the string into four lines. The first two lines contain the source code before the string. The 3rd line is the format string and the last line is the source code after the string. Here’s the code with all lines collapsed:
1 2 3 4 5 6 7 8 9 

Finally, here’s the output when you execute this program. As you can tell, this is the same as the original program (minus the whitespace)
1 2 

The algorithm is pretty straightforward:
The algorithm is straightforward and it is relatively easy to create a mental model and get an intuitive sense of why it works.
Now, a slight twist to the same question asks: “Given a circular linked list, what is the algorithm to find the first node of the loop.”
For instance, in the circular list A>B>C>D>E>C
, the first node of the loop is node C. The first part of the algorithm is identical to the algorithm for finding if there is a loop (above). Once a loop has been found, the following additional steps will give us the starting node of the loop:
This algorithm isn’t too difficult compared to the algorithm for detecting a loop. However, the mental model seems a bit trickier. Why and how does it always find the start of the loop?
Here’s some explanation which would hopefully help you intuitively understand why the algorithm works, without going into a lot of mathematical detail.
Consider two pointers: a slow pointer S
that increments by one node at each step, and a fast pointer F
that increments by two nodes at each step (i.e. it is twice as fast as S
). Both pointers start at the same time from the beginning of an nnode loop. In the time S
covers n nodes. F
will have covered 2n
nodes and they will both meet at the start of the loop.
Now, let us say that the slow pointer S
starts at the beginning of the loop, and the fast pointer F
starts at node k (where k < n) of the loop. As these two pointers move along the loop, they will meet at node (nx).
What we really need to do is figure out x, as it will give us the node at which the two pointers meet inside the loop.
S
takes n/2
steps, it will be at node n/2
. During the same time, F
will have taken 2(n/2) = n
steps, and it will be at node (k+n)
. Since the we are inside a loop, F
will be effectively back at node k
.(nx)
, S
needs to take a further (nxn/2)=(n/2x)
steps and it will end up at node nx
. During the same time, F
will have taken 2*(n/2x)=(n2x) steps and will be at node k+(n2x)
. Given our assumption that both S and F
meet at the same node:1 2 

This means that if S starts from the start of the loop, and F starts k nodes into the loop, both of them will meet at node (nk), i.e k nodes from the end of the loop. This is a key insight.
Now, coming back to the linked list that contains a loop. Suppose the start of the loop is m
(e.g. m
=3) nodes from the start of the linked list. Both S
and F
start at the beginning of the linked list [Figure1].
Figure1: Circular linked list with S and F pointers at the start
By the time S
gets to node m
(i.e. start of loop), F
will be at node 2m
[Figure2]. This means that S
will be at the start of the loop and F
will be m
nodes into the loop.
Figure2: Circular linked list, with S at the start of loop and F m nodes into the loop
Based on the discussion above, we already know that if S
begins from the start of the loop and F
starts from node m
, they will meet m
nodes from the end of the loop (i.e. the orangenode in [Figure3]).
Figure3: Both F and S meet m nodes from the end of the loop
At this point, keep the pointer F
at the orangenode where the two pointers met (i.e. m
nodes from the start of the loop), and move the pointer S
to the beginning of the linked list [Figure4]. Now, if we increment both S
and F
one node at a time, it is obvious that they will meet at ‘Nodem’ (rednode) of the list, which is the start of the loop.
Figure4: S at the start of linked list, F at the point they met. Both increment one at a time from hereon
For the curious, here’s the Java code snippets for detecting a loop in a linked list and finding the starting node. The complete source code for my linked list project is at my Github page (https://github.com/umairsd/LinkedListJava):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 

m/n
, where m
and n
are relatively prime. To construct the tree, the basic idea is to start with two fractions (0/1
, 1/0
) and then repeat the following operation:
Insert (m+m’)/(n+n’) between two adjacent fractions m/n and m’/n’
The first step gives us the entry 1/1
between 0/1
and 1/0
. Similarly, the 2nd step gives us two more: 0/1
, 1/2
, 1/1
, 2/1
, 1/0
.
Continuing on like this results in an infinite binary search tree which preserves the usual ordering of rational numbers.
The figure below shows the 1st 4 levels of the SternBrocot tree.
The first 4 levels of SternBrocot Tree
The path from the root of the tree to a number k
in the SternBrocot tree can be found using binary search. At each node, k
will either be in the left half of the tree, or the right half. We continue down the left or right subtree until we finally find k
.
L
to 0/1
and right fraction R
to 1/0
k
is found:
M
(which is (m+m')/(n+n')
)(k>M)
, then k
is in the right half of the tree. L:=M
and continue.(M>k)
, then k
is in the left half of the tree. R:=M
and continue.k=M
, terminate search.There’s a couple of things to tackle in our implementation. First, I need an easy way to represent fractions, so I create my own SternBrocotFraction
class. I deliberately chose to make it very specific to this algorithm because I needed a special way to handle the fraction 1/0 (which by definition is greater than all other rationals).
Secondly, I needed a good way to represent the path from the root of the tree to k. I do this by using a StringBuilder
, and at each step I append either the letter L
or R
depending on which subtree we take. When the search is finished, this gives us a string representation of the path from the root of the tree to the number k
. This approach is similar to the approach advocated by ACM Programming Competitions for the “SternBrocot Number System” problem.
Here’s the code to find path to a number k:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 

The special SternBrocotFraction
class is:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 

Finally, some test code to exercise my class:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 

When managing memory manually, two major issues to watch out for are premature deallocation and memory leaks.
Cocoa Touch framework uses manual reference counting to manage memory on the iOS devices. Reference counting works on the principle that once created, every object has an owner. During its existence, its owner may change and it may even have more than one owners. When the number of owners for an object drops to zero, it deallocates itself to free up the memory being used.
Owners are tracked via retain counts. When an object is created it always has a retain count of 1. To own an object its retain count is incremented via the retain
message. On the other hand, when the object is no longer needed its ownership is relinquished by decrementing the retain count via the release
message. When the count reaches zero, the object sends itself the dealloc
message and returns all the memory back to the heap.
autorelease
marks an object for future release (delayed release). When an object is sent the autorelease message, it is added to an instance of NSAutoreleasePool
. The Autorelease pool keeps track of all the objects that have been sent the autorelease
message. This pool is drained periodically, at which time all the objects within it are sent the release message.
autorelease
is really handy when the creator of an object (e.g. a factory) simply creates the object and returns it to the caller. At this point, the creator has nothing to do with the object anymore, so it is up to the caller to retain the returned object in order to continue using it.
Let us work through an example to see manual memory management in action. Suppose I am writing a ticketing framework, and I have a Ticket entity. The header file for Ticket looks as:
1 2 3 4 5 6 7 8 9 10 11 

And the implementation file for Ticket looks as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 

There are three memory management points to note here:
Inside dealloc
, an object must release all its instance variables first. Then it should go up its class hierarchy and release any instance variables of its superclass. We should never directly send the dealloc
message to instance variables, as some other objects might still have references to those variables.
A setter must retain the value passed in before it releases the old value, as tid
and ticketId
could be pointers to the same object.
The ticketWithId:
method creates a ticket and simply returns it to the caller. It has no use for the newTkt
, but it owns newTkt
by virtue of creating it. At this point, if newTkt
were released before method exit, then the caller would get a pointer to unallocated heap. To avoid this, we put the newTkt
on the autorelease pool. Periodically, the autorelease pool is drained and all the objects it it are sent the release
message thus decrementing the retain count.
Essentially, the ticketWithId:
method is saying that it does not want to be the owner for newTkt
and puts that responsibility on the caller. If the caller wants to hold on to newTkt
once it is returned, it must send it the retain
message.
1 2 3 4 5 6 7 8 

At this point, the retain count for tkt
is 1. Moreover, since the processTicketWithId:
method created the tkt
object, it is now the owner and thus is responsible for cleaning it up before this method exits. Clean up is done by sending it the release
message
Let’s see another example:
1 2 3 4 5 6 7 8 9 

In this example, the memory for tkt
wasn’t allocated by processTicketWithId
method, so it doesn’t own the tkt
object. However, as we’ve seen in the implementation of the Ticket class, the ticketWithId:
method created the Ticket object and added it to the autorelease pool. In order to continue using tkt
, we must retain it so that even if it is drained from the autorelease pool, we can still continue to use the tkt
object. Once done, we need to clean up and send the release message.
Rule1: If you get/create the object from new
, alloc
or copy
, you must release
it when done.
Rule2: If you get the object any other way, assume that it has been autoreleased. If you want to hold on to this object, send it the retain
message.
Rule3: If you retain
an object, you must balance every retain
with a release
.
Rule4: Never send the dealloc
message to an object directly. Others might be holding references to this object, and if deallocated, they’ll be left with pointers to unallocated memory.