This morning my computer crashed. So I rebooted it. I was in the midst of a project that had a lot of git branches (as I was working on competitive ideas to see which version would work best), and I couldn’t recall which branch I was on.

I thought it would be a good time to update my .bashrc file to perhaps add a git status to my bash prompt. Afterall, there are some pretty nice prompt string hacks for git out there.

And so I started to edit my .bashrc file. I opened it, and I discovered that I have over 20 aliases and functions that I created, and I haven’t used any of them in the last 2 years. Heck, over the years, I even went from a colourful prompt to a black and white prompt!

I used to have fancy dotfiles for most of my things, but now I use mostly default stuff. It makes portability much easier – I can work on any station without having to bother much about the configs.

I think the YAGNI approach works best. You Ain’t Gonna Need It when it comes to adornments for your computer. All you need is to be able to do work without extra distraction. Of course an argument could be made that having your prompt show your git status makes it unnecessary for you to git status everytime you start afresh on a new project. It really depends on how much time you have saved. The tradeoff for me constantly knowing my git status is not worth it.

What was worth it for me? This piece of code in my .bashrc file:

# http://stackoverflow.com/questions/21160386/trigger-a-command-when-cding-into-a-directory
function workspace_cd() {
    cd $@ && [ -f ".bashworkspace" ] && source .bashworkspace
alias cd="workspace_cd"

Other than that, nothing from the custom alert functions to the shortcuts for extracting files (turns out I just type tar -xzvf all the time anyway) were particularly used.

So I truncated my bashrc file to something like 50 lines. And… that’s enough yak shaving for the day.

An Apology

I made a mistake in posting a women-hostile picture on Twitter yesterday. This is an apology. But first, let’s start with a recap.

Yesterday I posted this tweet:

I first saw the picture on /r/funny. And I tweeted the picture after a brief view. I mainly tweeted the comic because I believe that politicking identity issues is generally a waste of time[1]. I had neglected to notice that it came from @AntiFemComics.

This morning, a shitstorm ensued. I woke up and the first notification was from Nick Coghlan:

Upon reading that, I went and re-read the comic. I realize the horror that I have in fact misread the comic. And the issue snowballed on. This blog post will stand as an official apology from me.
Continue reading

  1. [1] Politicking of any issue is generally a waste of time, in my opinion.

Go Test Files Are Part of the Same Package

Just a quick one. I was working on improving performance for a certain method of mine. I had found the hot loop [1], and I wrote a few benchmark methods to test some ideas.

I was using the testing package’s benchmark function to benchmark the methods, and for a method, I had abstracted out some code so that it can run in a goroutine. Here’s the code for the function:

func receiver(ch chan tmp, out chan []float64, wg *sync.WaitGroup) {
    Ys := make([]float64, len(x))
    for v := range ch {
        Ys[v.id] = v.res
    out <- Ys

Spotted the problem? No? It's the second line: retVal := make([]float64, len(x)). You'll note that x wasn't declared anywhere. And yet, the benchmarks ran! I only ran into a problem when I fed the test case a weird corner case where I knew funny things would happen.

At first I was puzzled why the compiler hadn't caught it. I scoured all through both files (it was a throwaway package, written solely to test ideas, so it had only two files: throwaway.go and throwaway_test.go)

Here are the top few lines of my throwaway_test.go file:

package throwaway

import (

var x []float64 = X(784) // <-- THE DECLARATION THAT CAUSED PAIN
func init() { ... }

I had added that variable originally as part of a setup/teardown function. I had then forgotten completely about it. I had been so used to writing code in the *_test.go files as if they were part of a separate package that just imported the functions, that I forgot that they were part of the same package.

The lesson learned today, other than global variables are evil[2], is that variables declared in the test files can have an effect on the main files if you're not careful about it, because the test files are part of the same package.

Now I want my hour lost back!


As Damian kindly points out:

The above only really happened because I was running go test -bench . a lot. If I had used go build . the compiler would have thrown an error

  1. [1] pprof is an amazing godsend. The days of dicking around in valgrind or cProfile are long a memory of the past
  2. [2] but sometimes are necessary, which I would argue for this specific test case, is

Whole Fruit Espresso

I’ve been toying around with new ideas of coffee lately. Here is one that I think went particularly well. It started with red-eyes: you put a shot of espresso in filter coffee, just to boost acidity and body of the coffee whilst still keeping the basic aromatics in the coffee (making espresso kills quite a bit of those).

I then moved on to the idea of making cascara red-eyes. If red eyes were flavourful, perhaps then using the pulp of the fruit will yield a different thing all together? And indeed it did. The hibiscus-y nature of the cascara tea does accentuate the espresso. Then I wondered if I could push it further – what if the cascara “tea” was made under pressure – i.e. espresso?
Continue reading

Intuitions From The Price Equation

George Price was a rather interesting fellow. A few months ago, I was reading a rather interesting piece about his life from HN. If you follow my blog posts (hello to the two of you), you’ll note that altruism and cooperative games is one of the things I like to blog about.

Following that article, I discovered the Price equation[1]. While grokking the equation, it had suddenly occurred to me that kin selection and group selection were indeed the same thing. It was a gut feeling, and I couldn’t prove otherwise.

So what I told you was true... from a certain point of view

I recently had a lot of time on hand[2], so I thought I’d sit down and try to make sense of my gut feel that kin selection and group selection were in fact the same thing. Bear in mind I’m neither a professional mathematician nor am I a professional biologist. I’m not even an academic and my interest in the Price equation came from an armchair economist/philosopher point of view. And so, while I grasp a lot of concepts, I may actually have understood them wrongly. In fact, just be forewarned that this entire post was a result of me stumbling around.

So, let’s recap what the Price equations look like (per Wikipedia):

\Delta z = \frac{1}{w} cov(w_i, z_i) + \frac{1}{w} E(w_i \Delta z_i)

Simply put, \Delta z is the difference in phenotype between a parent population and the child population. And that difference is a function of two things:

  1. The covariance of fitness and phenotype – \frac{1}{w} cov(w_i, z_i) where w is the average fitness of the population, w_i is the individual fitness of i , and z_i is the phenotype shared in the group.
  2. The expected value of the fitness of the difference between the group’s phenotype and the parent group’s phenotype.

Continue reading

  1. [1] Funny story. I was quite surprised I hadn’t heard of the Price equation, so I hit the books. I found the equation being referenced very very very very briefly in Martin Nowak’s Evolutionary Dynamics, and that was all
  2. [2] Being laid off does that to you :)

The Skynet Argument Against Social Media

In The Terminator (1984), Skynet sends a T-800 to terminate Sarah Connor. And the Terminator had to look up a phone book to find three Sarah Connors, because it mainly didn’t know what Sarah Connor looked like or where she lived.

That made sense in 1984. If the records had been destroyed in the war – records can be destroyed because physical drives were expensive and don’t have much capacity. Skynet wouldn’t have known how Sarah Connor looked like, or any other of her personal details. Rewatching The Terminator in 2015, this would have made no sense. If Skynet were made today, it would simply scour the cloud for information about Sarah Connor. And she’d be cleanly terminated.

There you go, kids. Don’t use social media. Arnold Schwartzeneggar and the T-1000 will come kill you.

Algorithms Are Chaotic Neutral

Carina Zona gave the Sunday keynote for PyConAU 2015. It was a very interesting talk about the ethics of insight mining from data, and algorithms. She gave examples of data mining fails – situations where Target discovered a teenage girl was pregnant before her parents even knew; or like machine learned Google search matches that implied black people were more likely to be arrested. It was her last few points that I got interested in the ethical dilemmas that may occur. And it is these last few points that I want to focus the discussion on.

One of the key points that I took away[1] was that the newer and more powerful machine learning algorithms out there are inadvertantly discriminate along the various power axes out there (think race, social economic background, gender, sexual orientation etc). There was an implicit notion that we should be designing better algorithms to deal with these sorts of biases.

I have experience designing these things and I quite disagree with that notion. I noted on Twitter that the examples were basically the machine learning algorithms were exposing/mirroring what is learned from the data.

Carina did indeed point out that the data is indeed biased – she did indeed point out that for example, film stock in the 1950s were tuned for fairer skin, and therefore the amount of photographic data for darker skinned peole were lacking [2]

But before we dive in deeper, I would like to bring up some caveats:

  • I very much agree with Carina that we have a problem. The points I’m disagreeing upon is the way we should go about to fix it
  • I’m not a professional ethicist, nor am I a philosopher. I’m really more of an armchair expert
  • I’m not an academic dealing with the topics – I consider myself fairly well read, but I am by no means an expert.
  • I am moderately interested in inequality, inequity and injustice, but I am absolutely disinterested with the squabbles of identity politics, and I only have a passing familiarity of the field.
  • I like to think of myself as fairly rational. It is from this point of view that I’m making my arguments. However, in my experience I have been told that this can be quite alienating/uncaring/insensitive.
  • I will bring my biases to this argument, and I will disclose my known biases whereever possible. However, it may be possible that I have missed, and so please tell me.

Continue reading

  1. [1] not necessarily the key points she was trying to communicate – it could just be I have shitty comprehension, hence rendering this entire blogpost moot
  2. [2] This NPR article seems to be the closest reference I have, which by the way is fascinating as hell.

Operator Overloading With Right Associativity In Python

It’s actually quite fun that after years of using something, you still find a new way to do something. So at the last Sydney Python meet up, there were showings of how Python interfaces objects.

Consider this for example:

class Blah(object):
    ''' skipping the __init__ and stuff '''
    def __add__(self, other):
        # skips checks and stuff
        return self.value + other

>>> b = Blah(2)
>>> b + 2 

However, it was pointed out by my friend Julian, that the other way wouldn’t work – that operator overloading was only left associative:

>>> b = Blah(2)
>>> 2 + b

Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for +: 'int' and 'Blah'

Last night as I was preparing my slides and code for my PyConAU talk, I accidentally found this. More specifically, I found out about the __radd__, __rmul__ etc methods.

So, if you implement both __add__ and __radd__ interface methods, you can have right associativity:

class Blah(object):
    ''' skipping the __init__ and others '''
    def __add__(self, other):
        # skips checks and stuff
        return self.value + other
    def __radd__(self, other):
        return self.__add__(other)

>>> b = Blah(2)
>>> b + 2 
>>> 2 + b


Here’s Julian’s proof of concept to show that ambiguities don’t matter:

class Multiplier(object):
    def __init__(self, description):
        self.description = description
    def __mul__(self, b):
        print ("__mul__ was called on {0}".format(self.description))
    def __rmul__(self, b):
        print ("__rmul__ was called on {0}".format(self.description))
    def __int__(self):
        return 43
a = Multiplier("a")
b = Multiplier("b")
# Confirm Chew's finding still works.

# Which gets priority in this ambiguous situation? Turns out __mul__ does.

# But, we can force it.

So, there you go… kinda cool, eh?

Writing… Again

This blog has been awfully silent the past year. I guess now that my job has been made redundant, I’m going to return to writing more.

Hah! Here’s to hoping!