Weekly Head Voices #118: Accelerando.

Too much nerdery took place from Monday February 20 to Sunday March 5. Fortunately, be the end of that period, we found ourselves here:

The view from the shark lookout all the way to Hangklip.

bibtex references in orgmode

For a technical report, I thought it would be handy going from Emacs orgmode (where all my lab notes live in any case) to PDF via LaTeX.

This transformation is more or less built-in, but getting the whole machinery to work with citations from a local BibTeX export from my main Zotero database does not work out of the box.

I wrote a post on my other even-more-nerdy blog showing the extra steps needed to turn this into an easy-peasy 38-shortcut-key-combo affair.

Google GCE K80 CPUs available, cheap(ish)!

I’ve been using a cloud-hosted NVIDIA Tesla from Nimbix for my small-scale deep learning experiments with TensorFlow. This has also helped me to resist the temptation of buying an expensive new GPU for my workstation.

However, Google Compute Engine has finally shipped (in beta) their cloud-based GPU product. Using their pricing calculator, it turns out I can get a virtual machine with 8 CPU cores, 30G of RAM, 375GB of local SSD and a whole NVIDIA Tesla K80 GPU (12GB of memory) in their EU data centre for a paltry $1.32 / hour.

This is significantly less than half of what I paid Nimbix!

(That resistance is going to crumble, the question is just when. Having your stuff run locally and interactively for small experiments still beats the 150ms latency from this here tip of the African continent to the EU.)

nvpy leaves the nest :`(

My most successful open source project to date is probably nvpy, the cross-platform (Linux, macOS, Windows) Simplenote client. 600+ stars on github is not A-list, but it’s definitely also nothing to sneeze at.

nvpy stats right before the hand-over

Anyways, I wrote nvpy in 2012 when I was still a heavy Simplenote user and there was no good client for Linux.

In the meantime, Emacs had started taking over my note-taking life and so in October of 2014, I made the decision to start looking for a new maintainer for my open-source baby nvpy.

That attempt was not successful.

By the end of 2015 / early 2016 I had a bit of a Simplenote / nvpy revival, as I was using the official client on my phone, and hence nvpy on the desktop.

Emacs put a stop to that revival also by magically becoming available on my phone as well. I have to add that the Android Simplenote client also seems to have become quite sluggish.

I really was not using nvpy anymore, but I had to make plans for the users who did.

On Saturday March 4, I approached github user yuuki0xff, who had prepared a pretty impressive background-syncing PR for nvpy, about the possibility of becoming the new owner and maintainer of nvpy.

To my pleasant surprise, he was happy to do so!

It is a strange new world that we live in where you create a useful artifact from scratch, make it available for free to anyone that would like to use it, and continue working on improving that artifact for a few years, only to hand the whole thing over to someone else for caretaking.

The handing-over brought with it mixed feelings, but overall I am super happy that my little creation is now in capable and more active hands.

Navel Gaze

Fortunately, there’s a handy twitter account reminding us regularly how much of 2017 we have already put behind us (thanks G-J van Rooyen for the tip):

That slowly advancing progress bar seems to be very effective at getting me to take stock of the year so far.

Am I spending time on the right things? Am I spending just the right amount of effort on prioritising without this cogitation eating into the very resource it’s supposed to be optimising? Are my hobbies optimal?

I think the answer is: One deliberate step after the other is best.

Weekly Head Voices #117: Dissimilar.

The week of Monday February 13 to Sunday February 19, 2017 might have appeared to be really pretty boring to any inter-dimensional and also more mundane onlookers.

(I mention both groups, because I’m almost sure I would have detected the second group watching, whereas the first group, being interdimensional, would probably have been able to escape detection. As far as I know, nobody watched.)

I just went through my orgmode journals. They are filled with a mix of notes on the following mostly very nerdy and quite boring topics.

Warning: If you’re not an emacs, python or machine learning nerd, there is a high probability that you might not enjoy this post. Please feel free to skip to the pretty mountain at the end!

Advanced Emacs configuration

I finally migrated my whole configuration away from Emacs Prelude.

Prelude is a fantastic Emacs “distribution” (it’s a simple git clone away!) that truly upgrades one’s Emacs experience in terms of look and feel, and functionality. It played a central role in my return to the Emacs fold after a decade long hiatus spent with JED, VIM (there was more really weird stuff going on during that time…) and Sublime.

However, it’s a sort of rite of passage constructing one’s own Emacs configuration from scratch, and my time had come.

In parallel with Day Job, I extricated Prelude from my configuration, and filled up the gaps it left with my own constructs. There is something quite addictive using emacs-lisp to weave together whatever you need in your computing environment.

To celebrate, I decided that it was also time to move my todo system away from todoist (a really great ecosystem) and into Emacs orgmode.

From this… (beautiful multi-platform graphical app)

I had sort of settled with todoist for the past few years. However, my yearly subscription is about to end on March 5, and I’ve realised that with the above-mentioned Emacs-lisp weaving and orgmode, there is almost unlimited flexibility also in managing my todo list.

Anyways,  I have it setup so that tasks are extracted right from their context in various orgfiles, including my current monthly journal, and shown in a special view. I can add arbitrary metadata, such as attachments and just plain text, and more esoteric tidbits such as live queries into my email database.

The advantage of having the bulk of the tasks in my month journal, means I am forced to review all of the remaining tasks at the end of the month before transferring them to the new month’s journal.

We’ll see how this goes!

Jupyter Notebook usage

Due to an interesting machine learning project at work, I had a great excuse to spend some quality time with the Jupyter Notebook (formerly known as IPython Notebook) and the scipy family of packages.

Because Far Too Much Muscle-Memory, I tried interfacing to my notebook server using Emacs IPython Notebook (EIN), which looked like this:

However, the initial exhilaration quickly fizzled out as EIN exhibits some flakiness (primarily broken indentation in cells which makes this hard to interact with), and I had no time to try to fix or work-around, because day job deadlines. (When I have a little more time, I will have to get back to the EIN! Apparently they were planning to call this new fork Zwei. Now that would have been awesome.)

So it was back to the Jupyter Notebook. This time I made an effort to learn all of the new hotkeys. (Things have gone modal since I last used this intensively.)

The Notebook is an awe-inspiringly useful tool.

However, the cell-based execution model definitely has its drawbacks. I often wish to re-execute a single line or a few lines after changing something. With the notebook, I have to split the cell at the very least once to do this, resulting in multiple cells that I now have to manage.

In certain other languages, which I cannot mention anymore because I have utterly exhausted my monthly quota, you can easily re-execute any sub-expression interactively, which makes for a more effective interactive coding experience.

The notebook is a good and practical way to document one’s analytical path. However, I sometimes wonder if there are less linear (graph-oriented?) ways of representing the often branching routes one follows during an analysis session.

Dissimilarity representation

Some years ago, I attended a talk where Prof. Robert P.W. Duin gave a fantastic talk about the history and future of pattern recognition.

In this talk, he introduced the idea of dissimilarity representation.

In much of pattern recognition, it was pretty much the norm that you had to reduce your training samples (and later unseen samples) to feature vectors. The core idea of building a classifier, is constructing hyper-surfaces that divide the high-dimensional feature space into classes. An unseen sample can then be positioned in feature space, and its class simply determined by checking on which side of the hypersurface(s) it finds itself.

However, for many types of (heterogenous) data, determining these feature vectors can be prohibitively difficult.

With the dissimilarity representation, one only has to determine a suitable function that can be used to calculate the dissimilarity between any two samples in the population. Especially for heterogenous data, or data such as geometric shapes for example, this is a much more tractable exercise.

More importantly, it’s often easier to discuss with domain experts about similarity than it is to talk about feature spaces.

Due to the machine learning project mentioned above, I had to work with categorical data that will probably later also prove to be of heterogeneous modality. This was of course the best (THE BEST) excuse to get out the old dissimilarity toolbox (in my case, that’s SciPy and friends), and to read a bunch of dissimilarity papers that were still on my list.

Besides the fact that much fun was had by all (me), I am cautiously optimistic, based on first experiments, that this approach might be a good one. I was especially impressed by how much I could put together in a relatively short time with the SciPy ecosystem.

Machine learning peeps in the audience, what is your experience with the dissimilarity representation?

A mountain at the end

By the end of a week filled with nerdery, it was high time to walk up a mountain(ish), and so I did, in the sun and the wind, up a piece of the Kogelberg in Betty’s Bay.

At the top, I made you this panoroma of the view:

Click for the 7738 x 2067 full resolution panorama!

At that point, the wind was doing its best to blow me off the mountain, which served as a visceral reminder of my mortality, and thus also kept the big M (for mindfulness) dial turned up to 11.

I was really only planning to go up and down in brisk hike mode due to a whiny knee, but I could not help turning parts of the up and the largest part of the down into an exhilarating lope.

When I grow up, I’m going to be a trail runner.

Have fun (nerdy) kids, I hope to see you soon!

The Apple TV 4 Remote, nickname “Achilles”!

It turns out that when you, or one of your offspring, accidentally drop an Apple TV 4 remote from about a metre, the lovely touch surface shatters almost exactly like the screen of a smartphone:

Unfortunately, you now have to purchase a new remote, which over here is going to cost more than half of what the whole Apple TV unit, including remote, cost initially.

Weekly Head Voices #116: Nothing much to see here, please move on.

This WHV is all about the weeks from Monday January 30 to Sunday February 12, 2017. I’ve mostly been in heads-down mode on two projects, so this post will be shorter than is usually the case.

I had my very first beer after the 30-day long Experiment Alcohol Zero (EAZ) on Friday, February 3. It was a good one:

EAZ has taught me that it would not be the worst idea to limit alcohol consumption slightly more.

As with many other enjoyable things, there is a price to be paid for this enjoyment. If paying that price interferes with the other enjoyable habits in your collection, it makes sense to evaluate and adjust the balance.

That reminds me of one of my favourite electronic music productions of all time: Balance 014 by Joris Voorn. He blew everyone’s minds when he decided to paint these fantastic soundscapes by mixing together more than 100 tracks, often 5 or 6 at a time.

Right at this point, just after that not-quite non sequitur, I wrote a far too long section on the relative performance of Android and iPhone, with a big “nerd content ahead” warning on it. Fortunately for you, I came to my senses before publishing and copied it out into its own little blog post: Android vs iPhone performance: A quick note.

Last weekend I dusted off my trusty old mu4e, an unbelievably attractive email client, again. This means I’m reading your mail and sending you beautifully UNformatted plain text emails right from my Emacs. As an additional bonus, I put all of the boring details about my configuration into a completely separate blog post, which you don’t have to read, titled: mu4e 0.9.18: E-Mailing with Emacs now even better.

What I will mention here and not in the other post, is that the current situation is subtly different from my previous adventure with mu4e: Where I previously synchronised all 60 thousand emails to process locally with mu4e, I am now following a more mellowed approach where I’m only synchronising the current year (and perhaps the previous year, still considering) of email. I use the fastmail web-app for searching through longer term storage.

I’m happy to report that so far it’s working out even better than the previous time. I really enjoy converting HTML emails (that’s what everyone sends, thanks GMail!) to well-behaved plain text when I reply.

Finally, after the Nth time that someone shared a clearly bogus science news post on Facebook, instantly bringing my blood to the boil, I decided to write a handy guide titled: Critical Thinking 101: Three super easy steps to spot poppycock on the internet.

This guide is 100% free, and really easy to send to your friends when you think this is necessary. Please let me know if you have any suggestions for improvement.

Ok kids, that’s it from me for now. I wish you a great week ahead. In the words of Yo-Play: Come on Mitch, don’t give up. Please try again.

Android vs iPhone performance: A quick note.

I’ve been spending some time doing research on the relative (perceived) performance of flagship Android phones compared to iPhones. I will probably not write the extended post I was planning to, as it seems that it’s hard to answer this question scientifically, and, perhaps more importantly, it makes people Very Very Angry.

I would still like to leave you with some interesting reading material. Hence this quick note.

From this discussion post (December 2016) by CodingHorror, aka Jeff Atwood, one of the two founders of the whole StackOverflow empire, where he measures the relative performance of his discourse web-app, the following choice quote:

Some Android users report up to about 29 score on very new late
2016 Android devices, depending on the vagaries of the browser
used. Still below the 2013 iPhone 5s which can be purchased used for about $150 these days.

That’s pretty amazing: Based on the browserbench speedtest, which is supposed to reflect quite realistically real-world web-browsing performance, the 2013 iPhone 5s outperforms 2016 Android flagships. Ouch.

My Snapdragon 808 does a measly 14.7 on browserbench. The iPhone 5s which is a year or two older does more than double that.

There are more sites where this discussion / flamewar is being continued. Google is your friend.

The core argument is that Apple long ago made the call that fewer, more high performance CPU cores would give the best subjective performance. In other words, to a user the phone would feel more responsive.

This does make sense: As a user, when I tap a button, I would like to see an instantaneous response. A single really fast core is going to help more with this than a higher number of slower cores.

Furthermore, programming single-threaded apps is significantly easier than programming robust and efficient multi-threaded apps. You can guess what the apps in the various stores look like in this regard.

The iPhone 6s had only two cores, whereas most mid- to high-range Androids had 6 or more cores when the 6s was released.

The iPhone 7 A10 chip has finally made the jump to 4 cores, two of which are lower power cores. Still, it turns out this chip again crushes all of its Android (read: Qualcomm) competition.

Here’s another relevant demo on YouTube where the same set of apps are started up in the same sequence, which is repeated, on both the iPhone 7 and the Samsung S7. All in all, the iPhone manages to get through the exercise more than twice as fast as the S7. This is definitely some indication of how users will perceive the responsivity of these devices.

The argument that multi-core was not a good choice for Android is weakened to an extent by this recent AnandTech analysis showing that these phones are actually pretty good at utilising all of their cores:

In the end what we should take away from this analysis is that
Android devices can make much better use of multi-threading than initially expected. There’s very solid evidence that not only are 4.4 big.LITTLE designs validated, but we also find practical
benefits of using 8-core “little” designs over similar single-cluster 4-core SoCs.

My personal experience with the Snapdragon 808 (6 core big.LITTLE) in my BlackBerry PRIV (late 2015 flagship) has been less than stellar. I love the phone for its screen, physical keyboard and other little idiosyncrasies, but the fact that I often have to wait more than a second after tapping an icon or a button before it responds, combined with the terrible Android security story (where the PRIV paradoxically does quite well), makes me wonder about the future smartphone landscape for Android enthusiasts.