Author: alchemyst

  • You cannot say my running caused my weight loss

    It’s been almost four years since I started actively controlling my weight.  I had gained a significant amount of weight during my Master’s studies, primarily due to the ease of having a Steers burger for lunch every day when you’re right across from Steers in your lab. I estimate that my peak weight was about 100 kg, but my first proper measurement is 95 km.  I am 1.87 m tall and these two stats put me in the “overweight” category, on the bad end of the histogram.

    So, I started calorie restriction, as documented in my previous post on data gathering.  I lost a lot of weight in a pretty short amount of time and have kept the weight off.  A little later the same year (2008) I also started running.  When I tell people I run, many nod sagely and say “ah – so that’s how you lost your weight”.  I have good data that belie this idea, and I have now taken the time to graph the stuff together.  Here is my weight (smoothed with an exponential moving average filter) and my weekly running distance.  I have been tracking my running with a GPS enabled device since the very first walks around the block.

     It is clear from this graph that the majority of my weight loss happened before I started running.  I feel that this is probably why I could run at all.  I cannot imagine running with a 20 kg weight strapped to my back now!  It is also pretty clear that there is no significant correlation between my running distance and my weight.  Put a different way, I control my weight by varying the amount I eat, not by varying the amount I run. I’ve recently started tracking the calories I eat again – hopefully I can produce a graph next year that shows that my food intake is my dominant handle on my weight.

  • The impact of environment: how much do IDEs contribute?

    Those who know me will know this is a much-beloved topic of mine. I am setting this stuff down in an attempt to purge some of these thoughts from my brain.

    During a conversation with a colleague yesterday, the idea of language productivity came up. It’s an old argument: sure, you can write less lines of code in say Python than in Java (see my post on this topic), but with a modern IDE, you’ll end up ahead as the IDE will be doing a lot of that typing for you. This forms part of a bigger conversation about the relative power of different languages, the relative merits of various IDEs and the way the brain works, before and after exposure to various models of computation. So, I’ve been maintaining a variety of links to research on these topics, and I’ll try to state my current understanding succinctly in the next couple of paragraphs. I would really value any feedback that you could give me (for the handful of people who actually read this). Although I enjoy reading anecdotes of personal experiences, I would appreciate most if you could point to proper scientific studies on the topic.


    So, this study, from 2000, compared C, C++, Java, Perl, Python, Rexx, and Tcl for a particular programming task: in this case a program to find which words could be spelled with particular phone numbers using the normal keypad letter mappings. They found that the “scripting language” programs were significantly shorter and took less time to write, but did not perform significantly poorer than the compiled languages. An interesting feature is that the compiled languages (C, C++ and Java) required considerably longer programs and took longer to write. The lines/hour for all languages were roughly comparable. They don’t mention which IDEs the programmers were using, but one assumes that at least some of them were using “modern” IDEs. A 2003 interview with Guido van Rossum, highlights this idea of Python requiring less “finger typing”. He’s obviously biased as the creator of Python, but considering that he also wrote the Python interpreter (in C) and has a large realm of experience in various languages, one would think he has had some time to experience the differences.
    Another study, from 2009 may explain a part of this. They found that reading code was largely a function of the number of tokens. This is important, because it implies that less tokens can aid in understanding already written code and have an effect on writing it. Importantly, they also find that simple domain mappings are easier to comprehend than complicated ones.
    I have not been able to find much quantitative research on the benefits of IDEs. Although I acknowledge that environment makes a big difference, I tend to think about code in my head without an IDE, which makes the actual language quite important for me. To some extent one must acknowledge that there is a personal aspect as well – some people prefer a particular kind of approach, as shown in this article about language mavens vs tool mavens, which I’ve linked to before. I’ve slowly been learning Eclipse, and it is quite amazing how much of the mundane Java stuff it can automate. I’m also a great believer in refactoring tools (I use rope, with bindings for Emacs). At the same time it is clear to me that much of the stuff you get in Eclipse could be addressed by streamlining the language a bit.
    Finally, the larger picture about fitting into an environment. This is where the established languages have the upper hand. Popular languages are more widely known, have more books and environments available and have the corporate OK. Also, if the libraries of the operating system you are using have been crafted for a particular language, there is a clear advantage to aligning yourself with that. As a researcher, though, it is often a bit of a conundrum: the real publishable results are more important than the interface, so you find the majority of computational research code has no GUI, and is only lightly coupled to the host OS. This is especially true of parallel code which inevitably has to run on headless cluster boxes.
    I don’t want to make this another post about choosing a programming language, but I will restate my final strategy: use the most expressive language available for prototyping – this will inevitably be a dynamically typed language with a REPL. For me, this is Python. This hooks into the constant lines per hour result of before. When the program produces the correct output and the algorithm is set, re-implement the slow bits in a lower level language. For me this is Fortran, but it could be C++ or whatever has good support for your problem domain. This strategy has placed me a in a poor position to benefit from IDE support. For that, you typically want to do everything in a combination of IDE and well-supported language (this is the classic Java/C++/C# for everything approach).
    Anyone with links to proper quantifiable research on programmer productivity (especially the effect of IDEs)?
  • Unchecking heard podcasts in iTunes via AppleScript

    Because I have a small 16 GB iPhone which is way less than the size of my music library, I use the “sync only checked items” approach. However, I want podcasts I have listened to already be unchecked as well. For that reason I’ve written this little Applescript which runs through all the podcasts and unchecks the ones I’ve listened to.

    tell application "iTunes"
    set thetracks to every track of library playlist 1 whose podcast is true and enabled is true and unplayed is false and bookmark is 0
    repeat with currentTrack in thetracks
    set enabled of currentTrack to false
    end repeat
    end tell

    This was slightly harder than it looks due to the fact that iTunes uses the “unplayed” property to indicate it has never been played, ever. When you’re halfway through, though, a tracks’ “unplayed” is false, but you don’t want to uncheck it. In the iTunes GUI a blue dot indicates played, a half-filled blue dot played but not finished and no blue dot is played and finished. The breakthrough is in the “bookmark” field, which gets set to the position in the file you last listened to. Kindly, Apple sets this to 0 when a track is completely listened all the way, leading to the conditions above.

    You can use the AppleScript editor to create this file and save it as “Uncheck heard podcasts.scpt”, then save it in your Library/iTunes/Scripts folder. When you restart iTunes, it will show up in the script menu.

    This is a good example of how knowing a scripting language can help you out.

  • The fallacy of the general purpose tool

    I carry a Leatherman on my belt every day wherever I go. It has become a bit of an extension of my body, which I only really notice when I have to fly somewhere and I’m forced to take it off for the flight. Then I get to my destination and I can’t open the cable ties on my luggage. At the same time, I have a whole pinboard of tools up in my garage, which overlap somewhat with my Leatherman: a dedicated set of pliers, some dedicated screwdrivers and scissors and so on. This is because the is not as good as any of these dedicated tools.

    I think the same goes for programming languages, and therefore I have learned quite a few, just like I have stocked my pinboard with tools that do one thing very well. Many people find learning new languages onerous and will try to find the one language that does everything they want to do well. Their arguments against learning a new language often involves something like “but I can do that just fine in my language, and then I don’t have to learn a new language”. Here’s an example from real life that illustrates the advantages of special purpose languages.
    My father approaches me with this problem. He uses an accounting package which can import OFX files (they’re an SGML/XML format for financial records), but there is a slight problem. The ZAR needs to be changed to USD and the dates (which are tags of the form 20111201 – yes, no closing tag as it’s SGML) have to be changed from YYYYMMDD to YYYYDDMM. Now, turns out that Python has a nice OFX module. So does Java. But the fastest way to make the changes to his files is probably sed:
    sed -r -i -e 's/ZAR/USD/' -e 's/<DT(.*)>
    ([0-9]{4})([0-9]{2})([0-9]{2})/<DT1>243/' filename.ocx

    This does the replacement in-place, is really fast and is quick enough to throw together. This is the kind of thing that sed shines at. In fact, it is exactly what it was designed to do, so it is unsurprising that it does it so well.

    To do the same thing in Python (even without using the OFX module) requires a bit more effort:

    import os
    import re
    from tempfile import mkstemp

    filename = "test.txt"
    patternStrings = ["ZAR", r"<TD([^>]+)>([0-9]{4})([0-9]{2})([0-9]{2})"]
    replacements = ["USD", r"<TD1>243"]

    # Compile patterns
    patterns = [re.compile(p) for p in patternStrings]

    # Create temporary file to hold outputs
    _, tempfile = mkstemp()

    # Process file
    outfile = open(tempfile, 'w')
    for line in open(filename):
    for pattern, replacement in zip(patterns, replacements):
    line = pattern.sub(replacement, line)
    outfile.write(line)

    outfile.close()

    os.rename(tempfile, filename)

    Needless to say, the difference is even more pronounced in Java due to the large amount of boilerplate needed.
    import java.io.File;
    import java.io.FileReader;
    import java.io.FileWriter;
    import java.io.IOException;
    import java.util.Scanner;
    import java.util.regex.Pattern;

    public class Fixer {
    static File infile = new File("test.txt");
    static String[] patternStrings = {"ZAR", "<TD([^>]*)>([0-9]{4})([0-9]{2})([0-9]{2})"};
    static String[] replacementStrings = {"USD", "<TD$1>$2$4$3"};

    public static void main(String[] args) throws IOException {
    Pattern[] patterns = new Pattern[patternStrings.length];
    Scanner in = new Scanner(new FileReader(infile));

    // Compile patterns
    for (int i=0; i<patternStrings.length; i++) {
    patterns[i] = Pattern.compile(patternStrings[i]);
    }

    // Create temporary file to hold outputs
    File tempfile = File.createTempFile("tmp", "tmp");

    // Process file
    FileWriter outfile = new FileWriter(tempfile);
    while (in.hasNextLine()) {
    String line = in.nextLine();
    for (int i=0; i < patterns.length; i++)
    line = patterns[i].matcher(line).replaceAll(replacementStrings[i]);

    outfile.write(line + System.getProperty("line.separator"));
    }
    outfile.close();

    // move temp file back to filename
    tempfile.renameTo(infile);
    }
    }
    Now, at this point someone is bound to say “but wait, people don’t write desktop apps in sed!”. But that’s quite the point – Java was designed with programming in the large in mind, but it is really tedious for short programs. In many cases, learning a small domain specific language and using it to solve your small problem is faster than learning how to do the same thing in your “one language”.
    I wish I had more time to put examples together, but this situation just presented itself and got me thinking.
  • Moral ergonomics

    It is quite hard to design a comfortable chair. The task is made more difficult by the variety of the human anatomy. While ergonomics has done some great things for our workplace comfort, it will never be able to come up with a truly one-size-fits-all chair.

    Perhaps it is because the physical differences are so easy to perceive that the above statement seems so obvious. However, rephrase the whole paragraph substituting systems of ethics for chair, and perhaps include something about moral feelings being at least as variable as our limb measurements and you’ve got a big philosophical argument on your hands. It appears that there is renewed interest in a formal study of morality, from many camps. People like Sam Harris are trying to say that science can say something about our moral urges. He is being fought by people that feel that a deity or a book should be the final authority. Whichever way we turn, however, I am sure that everyone has felt the feeling of conflict that arises when your stated ethics lead to an uncomfortable conclusion.
    As a moral noncognitivist I hold that moral statements like “X is wrong” can most appropriately be interpreted in a similar way to “I do not like X”, perhaps with an additional “and I think you shouldn’t like X either” thrown in for good measure. To borrow from a recent Facebook argument on a similar topic, it means that at the bottom of each moral statement lies a feeling. If you hold that killing people is wrong, it may be because that thing in itself feels wrong or because you have some connection to doing things against people’s will. Keep asking yourself “and why is X wrong” for every answer like “X is wrong because Y is wrong, and X is like Y”, and you’ll end up saying “because Y feels wrong” at some point.
    Of course, there are people who have tried to derive a consistent ethic. Is it so strange that none of them has really gained universal acceptance? Is it strange that no single chair design has been mass produced and rolled out all over the world? That our cars have adjustable seat backs? It’s a question of ergonomics, not of logic.
    I believe that we have to admit two things to go forward in the scientific exploration of morality:
    1. There is no universally acceptable set of moral rules. No, not even consequentialism or human rights or the golden rule or anything like that. People feel differently just like they have different sized feet.
    2. It may be more prudent to work on systems that don’t terribly offend a critical number of people rather than to try to argue that they should just come around. I don’t mean that we should coddle the extremists, but I do think it could be more productive to understand which feelings are causing the problem rather than to try to employ logic.
    Unfortunately, many rational people fall into the trap of believing that anyone who reaches a different conclusion from them is irrational, neglecting the possibility that they may simply be shaped differently.