One of the “fun” things about living in MA (besides the obvious fun of “the weather” and “the people”) is that you can’t get wine shipping directly to your house anywhere in the state. Until 2005 it was illegal; until very recently it was effectively illegal; and now, thanks to a district court decision overturning a state law, it’s merely uncertain.
But uncertainty is a positive step in this state. If you read the “factual background” section of the text of the decision itself, you’ll get a fun overview of how, in typical Massachusetts fashion, the current situation is the result of a culture of cronyism and old-boys-club-ism, with wine wholesalers in the state controlling the legislative process and protecting their own monopoly at the expense of both wineries and consumers, typically while justifying their actions by appealing to the state’s deep-seated Puritan anti-alcohol sentiment.
The specifics of the legislation that was just overturned should give you an idea of the crass, absolutely unsubtle gerrymandering the state legislature is willing to stoop to, in this case to circumvent another state law that was overturned as unconstitutional in 2005 (by the US Supreme court, no less!):
The detailed account sheds light on a fact that we known all along—that the 30,000 gallon capacity cap was set conveniently above the production capacity of the largest winery in Massachusetts (24,000 gallons). This cap was designed to allow the Massachusetts wineries to ship directly to consumers, while simultaneously protecting Massachusetts wholesalers by prohibiting out-of-state medium and large wineries from doing the same.
Of course, we’re still a ways away from being able to join the Screaming Eagle wine-of-the-month club: MA still has a host of other regulations that make delivery services like Fedex and UPS either unable or unwilling to deliver wine, like requiring a special permit for each vehicle that might have wine on it. But maybe we’re getting closer. If nothing else, we can hope the increased attention will have a “sunlight is the best disinfectant” kind of effect on the issue.
Found a good, old, post on a Scheme mailing list which explains the historical context behind the very confusing terms “closure”, “downwards funargs problem”, and “upwards funargs problem”:
Max Hailperin in 2001.
The reason is that [the term] “closure” only makes sense in a particular
historical context, where procedures had previously been left “open”,
that is with free variables not associated with any particular
binding. This was the case in various pre-Scheme Lisps, and lead to
what was known as the “funarg problem,” short for “functional
argument”, though it also was manifested when procedures were used in
other first-class ways than as arguments, for example, as return
values, where it was confusingly called the “upward funarg problem”
(by contrast to the “downward funarg problem,” where the arg was
genuinely an arg). The “funarg problem” is what logicians had been
calling “capture of free variables,” which occurs in the lambda
calculus if you do plain substitution, without renaming, in place of
proper beta-reduction.
So anyhow, an evolutionary milestone in the development of the Lisp
family of languages was the realizations that procedures should be
“closed”, that is, converted into a form where all the variables are
bound rather than free. (The way this is normally done, as others
have written in this thread, is by associating the procedure text,
which still has free variables, with a binding environment that
provides the bindings.)
Because this was such a big deal in terms of the languages’ evolution,
Lisp hackers took to using the word “closure” rather than just
“procedure” to emphasize that they were talking about this great new
lexically scoped kind of procedure.
Some git-fu I’ve been finding particularly useful recently:
- Untangling concurrent changes into multiple commits:
git add -p is the
greatest thing since sliced bread. But did you know it features an ‘s’
command which allows you to split a hunk into smaller hunks? Now you can
untangle pretty much anything.
- Splitting a previous commit into multiple commits: I’ve been finding this one
useful for quite a while. Start with a
git rebase -i, mark the commit(s) as
edit, and once you get there, do a git reset HEAD^. All the changes in
that commit will be moved out of the staging area, and you can git add/git
commit to your heart’s content. Finish with a quick git rebase --continue
to the throat.
- Fixing your email address in previous commits: I often make a new repo and
forget to change my email address. (For historical, and now silly, reasons, I
like to commit to different projects from different addresses, and I often
screw it up.) Here’s how to do a mass change:
git filter-branch --env-filter
"export GIT_AUTHOR_EMAIL=your.new.email.address" commit..HEAD, where
commit is the first commit to be affected. Of course, changing the email
address of a commit changes its id (and the id of all subsequent commits), so
be careful if you’ve published them. (Also note that using --env-filter=...
won’t work. No equal sign technology.)
- A
git log that includes a list of files modified by each commit: git log
--stat, which also gives you a colorized nice histogram of
additions/deletions for each file. This is a nice middle ground between git
log and git log -p.
- Speaking of
git log -p, here’s how to make it sane in the presence of moves
or renames: git log -p -C -M. Otherwise it doesn’t check for moves or
copies, and happily gives you the full patch. (These should be on by
default.)
- Comparing two branches: you can use
git log --pretty=oneline one..two for
changes in one direction (commits that ‘two’ has that ‘one’ doesn’t); and
two..one for the opposite direction. You can also use the triple-dot
operator to merge those two lists into one, but typically I find it useful to
separate the two. Or you can check out
git-wtf, which does this for you.
- Preview during commit message:
git commit -v will paste the diff into your
editor so you can review it while composing the commit message. (It won’t be
included in the final message, of course.)
gitk: don’t use it. You’ll get obsessive about merge commits, rebasing,
etc., and it just doesn’t matter in the end. It took me about 4 months to
recover from the bad mindset that gitk put me into.
Just read a great Stephen Pinker article about
morality that
appeared the in NY times earlier this year. Being the curmudgeonly contrarian
that I am, I most enjoyed the identification and dissection of the moralization
so prevalent but so rarely recognized in my peer group:
[W]ith the discovery of the harmful effects of secondhand smoke, smoking is
now treated as immoral. Smokers are ostracized; images of people smoking are
censored; and entities touched by smoke are felt to be contaminated (so hotels
have not only nonsmoking rooms but nonsmoking floors). The desire for
retribution has been visited on tobacco companies, who have been slapped with
staggering “punitive damages.”
And:
[W]hether an activity flips our mental switches to the “moral” setting
isn’t just a matter of how much harm it does. We don’t show contempt to the man
who fails to change the batteries in his smoke alarms or takes his family on a
driving vacation, both of which multiply the risk they will die in an accident.
Driving a gas-guzzling Hummer is reprehensible, but driving a gas-guzzling old
Volvo is not; eating a Big Mac is unconscionable, but not imported cheese or
crème brûlée. The reason for these double standards is obvious: people tend to
align their moralization with their own lifestyles.
There’s also the compelling idea that we’re not actually less moral than we
were in the past (a claim that old people have been making since time
immemorial), but rather, our morality has simply shifted to other things:
This wave of amoralization has led the cultural right to lament that
morality itself is under assault, as we see in the group that anointed itself
the Moral Majority. In fact there seems to be a Law of Conservation of
Moralization, so that as old behaviors are taken out of the moralized column,
new ones are added to it. Dozens of things that past generations treated as
practical matters are now ethical battlegrounds, including disposable diapers,
I.Q. tests, poultry farms, Barbie dolls and research on breast cancer.
I’m reminded of one of my favorite Paul Graham essays, <i>What You Can’t
Say</i>, the thesis of which is that the
powerful ideas that define the modern age are often ideas that were completely
verboten in earlier times (e.g. Copernicus’s claim that the earth revolves
around the sun); thus, if we want to identify powerful ideas that will shape
the future, we should look to things that are taboos today.
I released a new version of Trollop with a
couple minor but cool updates.
The best part is the new :io argument type, which uses open-uri to handle
filenames and URIs on the commandline. So you can do something like this:
require 'trollop'
opts = Trollop::options do
opt :source, "Source file (or URI) to print",
:type => :io,
:required => true
end
opts[:source].each { |l| puts "> #{l.chomp}" }
Also, when trying to detect the terminal size, Trollop now tries to `stty
size` before loading curses. This gives better results when running under
screen (for some reason curses clears the terminal when initializing under
screen).
I’ve also cleaned up the documentation quite a bit, expanding the examples on
the main page, fixing up the RDoc comments, and
generating the RDoc documentation with
a modern RDoc, so that things like constants actually get documented.
If you’re still using OptParse, you should really give Trollop a try. I
guarantee you’ll write much fewer lines of argument parsing code, and you’ll
get all sorts of nifty features like help page terminal size detection.
On the topic of numeric
paradoxes, here’s another
one that drove a lot of work in economic and decision theory: the St.
Petersburg paradox.
Here’s the deal. You’re offered a chance to play a game wherein you repeatedly
flip a coin until it comes up heads, at which point the game is over. If the
coin comes up heads the first time, you win a dollar. If it takes two flips to
come up heads, you win two dollars. The third time, four dollars. The fourth
time, eight dollars. And so on; the rule is, if you see heads on the th flip,
you win dollars.
How much would you pay to play this game?
The paradox is: the expected value of this game is infinity, so according to
all your pretty formulas, you should immediately pay all your life savings for
a single chance at this game. (Each possible outcome has an expected value of
50 cents, and there are an infinite number of them, and expectation distributes
over summation, so the expected value is an infinite sum of 50 cents, which
works out to be a little thing I like to call infinity dollars.)
Of course that’s a paradox because it’s crazy talk to bet more than a few bucks
on such a game. The paradox highlights at least two problems with blithely
using positive EV as the reward you’ll get if you will play the game:
- It assumes that the host of the game actually has infinite funds. The
Wikipedia article has a very striking breakdown of what happens to the St.
Petersburg paradox when you have finite
funds.
It turns out that even if your backer has access to the entire GDP of the
world in 2007, the expected value is only $23.77, which is quite a bit short
of infinity dollars.
- It assumes you play the game an infinite number of times. That’s the only way
you’ll get the expected value in your pocket. And the St. Petersburg paradox
is a great example of just how quickly your actual take-home degenerates when
subject to real-world constraints like finite repetitions. It turns out that
if you want to make $10, you’ll have to play the game one million times; if
you’re satisfied with $5, you’ll still have to play a thousand times.
The classical answer to the paradox has been to talk about utility, marginal
utility and things like that; i.e., people with lots of money value more money
less than people without very much money. And recent answers to the paradox,
e.g. cumulative prospect
theory, are along the
lines of modeling how humans perceive risk, which (unsurprisingly) is not
really in line with the actual probabilities.
But it seems to me that these solutions all involve modeling human behavior and
explaining why a human wouldn’t pay a lot of money to play the game, either
because money means less as it gets bigger or because they mis-value risks. But
the actual paradox is not about human behavior or psychology. It’s the fact
that the expected value of a game is not a good estimate of the real-world
value of a game, because expected value can make assumptions about infinite
funds and infinite plays, and we don’t have those.
So my solution to the St. Petersburg paradox is this: drop all events that
have a probability less than some small epsilon, or a value more than some
large, um, inverse epsilon. That neatly solves both of the infinity
assumptions. (In this particular case one bound would do, because the
probabilities drop exponentially as the values rise exponentially, but not in
general.) I’ll call this the REV: the realistically expected value.
In this case, if you set the lower probability bound to be .01, and the upper
value bound to be one million, then the REV of the St. Petersburg paradox is
just about three bucks. (The upper value bound doesn’t even come into play.)
And that’s about what I’d pay to play it.
So there you go. Fixed economics for ya.
My wife, who knows more about corporate structure than the average joe, points
out that the AIG executives who spent $440k at a lavish
retreat
shorty after the federal government granted AIG a $85b bailout were, in fact,
executives of the profitable, non-bailout-requiring life insurance group, and
were unrelated to the bailout-requiring investment insurance and bond-rating
companies, except to the extent that both companies are held by the same
holding company.
The nature of a holding company corporate structure is fairly strict. Money
can’t be transferred around between them arbitrarily, so it’s very possible for
one held company to be successful while another is completely bankrupt. I found
a good analogy in the (cough) Reddit comments for the above
article:
A family is going through some financial troubles because the dad gambled
the money away and is getting welfare checks. However, the son who has been
successful in his job is still going to Europe because he paid for it months
before and to cancel it would incur penalty fees.
You’re blaming the family for going on vacation when they need money for their
monthly expenses, when in reality, it’s only the son, and he paid for it using
his own earnings, not the welfare check.
Of course the desire to act hysterical far outweighs any kind of informed
analysis, as usual.
Is there really a difference between saying, “I don’t know anything, a priori, about the parameters of this distribution”, and using a uniform prior?
What about, “I don’t know anything about that value” versus “As far as I’m concerned, every possibility for that value is equally likely”?
I found a neat little example in one of my introductory stats books about
Bayesian versus maximum-likelihood estimation for the simple problem of
estimating a binomial distribution given only one sample.
I was going to try and show the math but since Blogger is not making it
possible to actually render MathML I’ll just hand-wave instead.
[Fixed in Whisper. —ed.]
So let’s say we’re trying to estimate a binomial distribution parameterized by
, and that we’ve only seen one estimate. For example, someone flips a coin
once, and we have to decide what the coin’s probability of heads is.
The maximum likelhood estimate for is easy: if your single sample is a 1,
then , and if your sample is 0, . (And if you go through the laborious
process of writing the log likelihood, setting the derivative equal to 0, and
solving it, you come up with the general rule of (# of 1’s) / (# of 1’s + # of
0’s), which is kinda what you would expect.)
In the coin case it seems crazy to say, I saw one head, so I’m going to assume
that the coin always turns up heads, but that’s because of our prior
knowledge of how coins behave. If we’re given a black box with a button and two
lights, and you press the button, and one of the lights come on, then maybe
estimating that that light always comes on when you press the button makes a
little more sense.
Finding the Bayesian estimate is slightly more complicated. Let’s use a uniform
prior. Our conditional distribution is and , and if you work
it out, the posterior ends up as and .
Now if we were in the world of classication, we’d take the MAP estimate, which
is a fancy way of saying the value with the biggest probability, or the mode of
the distribution. Since we’re using a uniform prior, that would end up as the
same as the MLE. But we’re not. We’re in the world of real numbers, so we can
take something better: the expected value, or the mean of the distribution.
This is known as the Bayes estimate, and there are some decision-theoretic
reasons for using it, but informally, it makes more sense than using the MAP
estimate: you can take into account the entire shape of the distribution, not
just the mode.
Using the Bayes estimate, we arrive at if the sample was a 1, and
if the sample was a zero. So we’re at a place where Bayesian logic and
frequentist logic arrive at very different answers, even with a uniform
prior.
Up till now we’ve been talking about “estimation theory”, i.e. the art of
estimating shit. But estimation theory is basically decision theory in
disguise, where your decision space is the same as your parameter space: you’re
deciding on a value for , given your input data, and your prior knowledge, if
any.
Now what’s cool about moving to the world of decision theory is that we can
say: if I have to decide on a particular value for , how can I minimize my
expected cost, aka my risk? A natural choice for a cost, or loss, function, is
squared error. If the true value is , I’d like to estimate in such a way
that is minimized. So we don’t have to argue philosophically about
MLE versus MAP versus minimax versus Bayes estimates; we can quantify how well
each of them do under this framework.
And it turns out that, if you plot the risk for the MLE estimate and for the
Bayes estimate under different values of the true value , then MOST of the
time, the Bayes estimate has lower risk than the MLE. It’s only when is
close to 0 or to 1 that MLE has lower risk.
So that’s pretty cool. It seems like the Bayes estimate must be a superior
estimate.
Of course, I set this whole thing up. Those “decision-theoretic reasons” for
choosing the Bayes estimate I mentioned? Well, they’re theorems that show that
the Bayes estimate minimizes risk. And, in fact, the Bayes estimate of the mean
of the distribution is specific to squared-error loss. If we chose another
loss function, we could come up with a potentially very different Bayes
estimate.
But my intention wasn’t really to trick you into believing that Bayes estimates
are awesome. (Though they are!) I wanted to show that:
- Bayes and classical approaches can come up with very different estimates,
even with a uniform prior.
- If you cast things in decision-theoretic terms, you can make some real
quantitative statements about different ways of estimating.
In the decision theory world, you can customize your estimates to minimize
your particular costs in your particular situation. And that’s an idea that I
think is very, very powerful.
It really seems like this should display some kind of equation:
I can’t make it work despite all my xhtml’ing. Blogger fail.
[Fixed in Whisper. —ed.]