I have four Twitter accounts that send out one tip per day. One of these might help you with a New Year’s resolution. If you don’t use Twitter, you can follow these Twitter accounts by subscribing to their RSS feeds. [Update: Twitter really doesn’t want to you to use RSS. I’ve posted a couple times on how to subscribe to Twitter via RSS, and the solutions break over time. I’ve given up.]
Windows keyboard shortcuts
If you’d like to become more efficient in using Windows, and reduce your chances of repetitive stress injury, you may want to use your keyboard more and your mouse less. SansMouse is a Twitter account that sends out one keyboard shortcut per day.
I have two mathematical Twitter accounts. These might be useful if you want to review math courses you took a long time ago or if you want a preview of math you might need in the future. Both are eclectic, mixing elementary and advanced topics.
ProbFact sends out one probability fact per day, mostly theorems but sometimes notes on applications.
I just started AnalysisFact a couple days ago. It will cover a wide range of topics from real and complex analysis. AnalysisFact will have a wider range of sophistication than ProbFact, mixing undergraduate and graduate level material.
Update (31 December 2011): Over the last year I’ve added three mathematical Twitter accounts:
I’ve also added two computing accounts:
Here are the Twitter accounts:
New Year’s links
Here are a couple posts from Jon Swanson:
8 ways to end the year
Leave it in 2008 (Just mentally change the “8” to a “9” when you read it.)
And here is a good post from Jurgen Appelo:
Checklist for goals and resolutions.
According to the stereotypes, men fear committing to relationships. I find that hard to relate to. But I can relate to fear of technological commitment. I don’t want to take the time to learn something well that’s going to go away in a year. Like anyone else I want to pick the best tool for the job, but sometimes I’ve invested too much time in evaluation.
In a panel discussion on whether software development has become too complex, one of the major complaints was the bewildering number of options. The implicit assumption is that one must evaluate every option. This is an emotional reaction driven by fear of missing out.
Looking back on technologies that have come and gone, the best option was never orders of magnitude better than the second best option. We expect that the choices facing us now matter a great deal, despite knowing that similar decisions in the past didn’t matter that much.
Not only are some of our choices not so important, they don’t last so long either. We act as if we’re picking the technology we’re going to use for the rest of our lives. In reality, we may be picking the technology we’re going to use for the next year.
Very often it’s not worth the deliberation to pick the “best” technology. Pick a good one and don’t look back.
Countless articles tell us that multitasking makes us less efficient — we’re not as good at multitasking as we suppose. But here is a new criticism: multitasking makes us shallow.
If you don’t want to sink, you learn to surf; you have to. You learn how to go fast, but smooth, through a huge amount of stuff — at work, at home, in the store, in the street. Multitasking means learning how to double back and reshuffle at the least hint of resistance, it means missing most of what goes on around you but learning not to regret it because nothing is that much more valuable than anything else, it means learning how to coast through meetings on zero information … You are compensated for the loss of buffers and boundaries built into the old real world of separated times and spaces, by an overall muffling of experience in general …
From Mediated by Thomas de Zengotita.
The most productive programmers are orders of magnitude more productive than average programmers. But salaries usually fall within a fairly small range in any company. Even across the entire profession, salaries don’t vary that much. If some programmers are 10x more productive than others, why aren’t they paid 10x as much?
Joel Spolsky gave a couple answers to this question in his most recent podcast. First, programmer productivity varies tremendously across the profession, but it may not vary so much within a given company. Someone who is 10x more productive than his colleagues is likely to leave, either to work with other very talented programmers or to start his own business. Second, extreme productivity may not be obvious. This post elaborates on this second reason.
How can someone be 10x more productive than his peers without being noticed? In some professions such a difference would be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. Sales are easy to measure, and some salesmen make orders of magnitude more money than others. If a bricklayer were 10x more productive than his peers this would be obvious too, but it doesn’t happen: the best bricklayers cannot lay 10x as much brick as average bricklayers. Software output cannot be measured as easily as dollars or bricks. The best programmers do not write 10x as many lines of code and they certainly do not work 10x longer hours.
Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on. It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.
The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”
Microsoft’s Solver Foundation is a numerical optimization library capable of solving problems involving millions of variables and millions of constraints. When I listened Scott Hanselman interview Nathan Brixius from Microsoft’s Solver Foundation team, I expected Brixius to say that Solver Foundation was written in C++ at its core and had a thin C# veneer to make it callable from .NET applications. Instead, he said that Solver Foundation is entirely written in managed code.
Even in heavy-duty numerical code the bottlenecks may not be numerical. The inner loops of the software would execute faster if they were written in C++, but Solver Foundation solves optimization problems about as quickly as other packages written in lower-level languages.
A few days ago my family and I went to see a stage performance of Charles Dickens’ A Christmas Carol. For years I’ve glossed over references to money when reading British literature but I’ve intended to figure out how it all worked before decimalization. Watching A Christmas Carol prompted me to finally do it.
Many thanks to my British friend Samuel Jack for helping me sort things out. Any errors in this post are mine and not Sam’s. If you find an error or omission below, please leave a comment.
The most basic denominations were pound, shilling, and penny. The pound and shilling had the nicknames quid and bob respectively. (The plural of “penny” is “pence.” The terms “quid” and “bob” are both singular and plural.) A pound equaled 20 shillings and a shilling equaled 12 pence. Pound, shilling, and pence had the abbreviations “L”, “s”, and “d” which came from the Roman librae, solidi, and denarii.
A florin was two shillings and a crown was five shillings. A guinea was 21 shillings. (The reason a guinea was slightly more valuable than a pound had to do with precious metal exchange rates.)
A few more denominations were self-evident. For example, the half crown and sixpence were worth what you’d think.
My previous post described how to include an Inkscape drawing in a LaTeX document. This post describes how to use LaTeX in an Inkscape drawing, which is probably more useful. The LaTeX output is included not as bitmap but as a vector drawing that can then be manipulated with all the features of Inkscape.
The Inkscape book describes the InkLaTeX extension, but the web site for
InkLaTeX recommends a newer extension textext. Once
textext is installed, you can insert LaTeX into an Inkscape drawing by going to the Extensions menu and selecting “TeX Text”. This launches a window in which to type your LaTeX source.
Before I could install
textext, I had to install
textext extension also requires LaTeX and Ghostscript, but these were already on my computer.
pstoedit has several installation options; I chose the default basic option and that worked. Also,
pstoedit says that it requires two Visual C++ runtime DLLs:
msvcp70.dll. I already had these, but the
pstoedit site gives a link to where you can find these DLLs if you need them.
I had Inkscape running when installed
textext and I had to restart Inkscape to see the “TeX Text” menu.
Related post: Including an Inkscape drawing in LaTeX
The Inkscape drawing package can export to a large variety of vector drawing formats, including LaTeX. If you save your drawing to a file
foo.tex, you can include the file in a LaTeX document as follows.
Testing Inkscape \LaTeX\ output.
Of course you could always export the drawing to an image format and include that image the way you’d include any other image. But you also have the option of directly including the content Inkscape output in your LaTeX file rather than referencing it as an external file using the
input statement. This makes your LaTeX file self-contained and is something you could not do, for example, with a PNG file.
- You must use the
- You must compile the file with
latex and not
pdflatex. To create a PDF file, you must first compile to PostScript.
The next post is a sort of opposite of this one. It explains how to use LaTeX inside an Inkscape drawing.
Why would you want to plot a mathematical function using a drawing package like Inkscape rather than a mathematical package like Mathematica or R? One reason is that you may want plot for its visual properties. For example, you might want to include a sine wave in a drawing.
Another reason is that you may want to have more control (or at least easier control) over your plot. Mathematical packages make it easy to produce a basic plot with default options. But I’ve found it difficult to change the aesthetics of a plot in every mathematical package I’ve used. The things I want to do are often possible but require arcane options that I have trouble remembering. In a drawing program, it’s obvious how to manipulate a plot as an image.
Inkscape provides a couple extensions to include function plots in a drawing. One is “Function Plotter” and the other is “Parametric Curves.” Both are found under Extensions -> Render. The following dialog shows the settings used to produce the graph above.
The first time I tried using these extensions nothing happened. Then I discovered you have to select a rectangle to contain the plot before creating a plot; the plotting tools do not create their own rectangles.
The Function Plotter supports rectangular and polar coordinates. You’re in for quite a surprise if you expect rectangular coordinates when the polar coordinates box is checked.
Bézier curves are very common in computer graphics. They also interesting mathematical properties. This post will give a quick introduction to Bézier curves, describing them first in visual terms and then in mathematical terms.
There are different degrees of Bézier curves: linear, quadratic, cubic, etc. Linear Bézier curves are just straight lines. The most common kind of Bézier curve in drawing programs is the cubic and that’s the one I’ll describe below.
A cubic Bézier curve is determined by four points: two points determine where the curve begins and ends, and two more points determine the shape. Say the points are labeled P0, P1, P2, and P3. The curve begins at P0 and initially goes in the direction of P1. It ends at P3 going in the direction of a line connecting P2 and P3. If you move P1 further away from P0, the curve flattens, going further in the direction of P1 before turning. Similar remarks hold for moving P2 away from P3.
Now for equations. The cubic Bézier curve is given by
B(t) = (1-t)3 P0 + 3(1-t)2t P1 + 3(1-t)t2 P2 + t3 P3
for t running between 0 and 1. It’s clear from the equation that B(0) = P0 and B(1) = P3. A little calculation shows that the derivatives satisfy
B‘(0) = 3(P0 – P1)
B‘(1) = 3(P3 – P2).
Moving the points P1 and P2 further out increases the derivatives and thus makes the curve go further in the direction of these points before bending.
Related post: The smoothest line through a set of points
An integer is either a perfect square or its square root is irrational. Said a different way, when you compute the square root of an integer, there are either no figures to the right of the decimal or there are an infinite number of figures to right of the decimal and they don’t repeat. There’s no middle ground. You can’t hope, for example, that the decimal expansion might stop or repeat after a hundred or so terms.
This theorem came up recently when I was talking to one of my kids about her math class, so I decided to look up the proof. It’s easier than I expected, not much harder than the familiar proof that the square root of 2 is irrational. Here goes.
Suppose a/b is a fraction in lowest terms, i.e. a and b are relatively prime, and a/b a solution to xn = c where n > 0 is an integer and c is an integer. Then
(a/b)n = an / bn = c
an / b = c bn-1.
Now the right side of the equation above is an integer, so the left side must be an integer as well. But b is relatively prime to a, and so b is relatively prime to an. The only way an / b could be an integer is for b to equal 1 or -1. And so a/b must be an integer.
This proof shows that what we said about square roots extends to cube roots and in fact to all integer roots. For example, the fifth root of an integer is either an integer or an irrational number.
Update: Note that there’s another proof in the comments, one that I believe is easier to follow.
Last year I wrote a post about my favorite audio book narrators: John McDonough and Rob Inglis. Here are three more who came to mind lately.