Correlation is evidence of causation

I've been bringing the title line out frequently for the past few years in response to people saying the somewhat true phrase "correlation does not imply causation", or the true phrase "correlation is not causation" which they've been indoctrinated by fraudsters protecting Big Tobacco.

When asked for a proof, I often just link to this page: http://oyhus.no/CorrelationAndCausation.html It's the simplest and easiest to understand version I've come across. But I think it's sort of missing a final step, and a longer proof will fill that in.

In order to prove the title statement, we have to back up a bit and ask about what evidence is, and before we do that we have to ask about what belief is. Or rather, we don't really need to define what they are so much as how to measure them. Bets are a way of measuring your confidence and certainty of your beliefs, and odds ratios and other aspects of betting can be expressed through probability theory, so your beliefs being true can be expressed using probability theory as well. (If you're interested in non-betting-based foundation for probability theory governing beliefs, see Jaynes. If you're interested in representing uncertainty of several "flavors", see Goertzel.) So if we have a probability for a belief, and we encounter a new piece of evidence, then that will either raise or lower the probability of the belief depending on whether it's evidence for or against. Formally, if some fact A is evidence for belief B being true, that means that the probability of B being true is greater if A is true than if A is false. In math, $$P(B|A) \gt P(B|\overline{A})$$ means A is evidence of B.

See Full Post and Comments

My preference for dynamic typing

Alternatively: why I lost all excitement about Clojure's core.typed library after learning it makes no speed improvements.

There's a little-known paper published a few years ago called "An experiment About Static and Dynamic Type Systems: Doubts About the Positive Impact of Static Type Systems on Development Time".

Go read the paper, it's short. But since I know you're lazy, I'll give a brief overview of the experimental setup and its results in my own biased words. The authors made a programming language and IDE and had two versions of it: one with static typing and one with dynamic typing. They took a group of students and separated them into dynamic/static groups and trained them respectively -- the training for the static version took a little longer since they had to cover the type system. Then they were asked to implement a scanner and parser.

See Full Post and Comments

Mixing Python with C

A common point of rhetoric up the sleeve of any Pythonista is this: "...and you can always write the slow parts in C if you have to!" It's typically said off-to-the-side and rarely elaborated on.

It's not a bad piece of rhetoric, I even use it from time to time. But it's only useful on programmers who haven't stepped much beyond their own narrow interest in technology--anyone who's done work across a variety of languages ought to realize that "can interface with C" isn't a feature that's supposed to be marketable, it's a hard requirement. They may have never had to do this themselves, but they should at least know in principle it can be done. In practice it's often a lot more difficult than it should be. If Python's C-interfacing capabilities were as slick as Clojure's Java interfacing ones, I wouldn't want to write about it.

What do I mean by "can interface with C"? A language that can interface with C is a language that can directly call functions in a compiled shared object that was written in C, and also where C can get at the language's internals as well to call its code and have interactions. This is distinct from using the other language to instruct the operating system to run a compiled C program and give it the results, and vice versa. Java interfaces with C, and Python interfaces with C.

See Full Post and Comments

An attempt at a practical exploration of Python for newcomers

In open office format here. (I know, I know, LaTeX heresy!) This post may be more up to date if I corrected anything though.

This document isn't explicitly about the syntax and 'overview of language features' of Python. Figure out the syntax of Python yourself from examples, Google, guessing, or error messages. Some features will be mentioned in passing when they're not obviously inferred from the example.
If you're looking for a style guide (sometimes the best way to learn syntax): check out “PEP 8”: http://www.python.org/dev/peps/pep-0008/ (I disagree with some of it, of course, but PEP 8 explicitly is fine with that.)

Pro tip 1: never use tabs.
Pro tip 2: read what an error message actually says before asking for help. They're very unlike C++ compilers' vague template-related errors over which people tend to get glazed eyes.
Pro tip 3:
“Very often it will be faster for you to try something out on the computer than to look it up in the manual. Besides, the computer is always right, and the manual could be wrong.”
--Apple II Basic Programming Manual

See Full Post and Comments

Answers to two questions about government

I just sent out an email answering two questions, I'm going to copy them here because they're a good reference point for my current views going into 2014. Previously in the email I had mentioned http://www.raikoth.net/libertarian.html as a decent source of anti-libertarianism, though not without its own problems. The first question, referencing that link:

Some of his arguments are worth thinking about, but It seems to me that many of his argmumetns can be turned on their head fairly easily. What do you think of his marginal utility argument using the movie ticket example?

I think the concept of marginal utility is sound, but by itself it does not justify progressive taxes. So what if I'm so wealthy that an extra dollar is more or less useless for me personally because I already have everything I desire materially? It's still my dollar. What was left unjustified is that 'burden' should be the basis of a taxation policy. But the real problem with the movie ticket metaphor is that it ignores a crucial power of money: the power to create more of it through investing.

See Full Post and Comments

Basic Income and borrowing from the future

When I look at economic growth numbers for the United States over the past century, I sometimes get the sense that we as a country have stumbled and for a while now have been trying to sprint faster and faster so that we can avoid doing a face-plant. The face-plant isn't inevitable, if we can just pick up enough speed, and if we don't run into anything...



One non-show-stopper obstacle that affected us has been the introduction of the standard 40-hour work week, whereas in previous times working much longer than that wasn't uncommon. Also getting rid of a lot of child labor affected us. But we've compensated with adding women to the workforce, and the tremendous amount of power the computing and automation ages have given us. Individuals have also compensated by going deeply into debt, borrowing from the future that in theory will have access to more resources than the present. But it still seems like we're barely capable of sustaining our incredible growth, and recessions like the kind we're more or less out of have almost ended us.

See Full Post and Comments

User testing ought to include extra dimensions on the User attribute

Disclaimer: I'm not a designer, but I wear the hat from time to time. I think by now in 2013 a majority of interface designers have arrived at the conclusion that user testing is really important to help shape an interface and designers who don't do user testing are met with "wat?" as the response. This user testing can take many forms: from hallway usability testing with an actual web mockup, or paper and sticky notes, or a whiteboard, to live A/B testing, and beyond. Designers try to find the best interface for everyone, and that's what gets deployed.

There's a problem, though: some users are different in important ways. Is the user young and presumably knowledgeable about modern UI idioms (like pinch-to-zoom), or is the user old and this is their first time with a touch device? Is the user English-speaking or alternate-language-speaking? Is the user introverted or extroverted? Is the user an active user or infrequently-active user? Is the user a "technical/power user" or a "non-technical user"? Don't you think it's worth exploring alternate designs for each of those alternate categories? You should be exploring alternate designs anyway, but if you have some theory driving some of your choices, you can apply what theories say about different user groups.

For instance, generally "flat" designs work better for technical users who are willing to spend some time learning and remembering where everything is on the screen, and "nested" designs work better for non-technical users where they are presented with only a very limited set of choices. Sometimes you might want to support just one or the other: for instance, who would design an airplane cockpit for someone who's not a pilot? And who would design an installation wizard with all sorts of power user features and a single screen when almost every user just wants to install the thing and go through the steps as quickly as possible, with the only choice they want to have being the "Next" button?

See Full Post and Comments

Older Posts Newer Posts