Hacker News new | past | comments | ask | show | jobs | submit login
The Mathematics Behind xkcd: A Conversation with Randall Munroe (maa.org)
192 points by ColinWright on Nov 4, 2012 | hide | past | favorite | 20 comments



A lot of his comments remind me of the spate of xkcd-style graphing programs around here. The problem with trying to imitate Randall with a program seems to be that he isn't interested in making things repeatable. He's just very determined and imaginative, and willing to spend a weekend drawing a graph. The charm of something like the movies graph is that it's incredibly detailed, but in a very human way that implies an understanding and appreciation of those works. You could use fancy NLP on a script, but it wouldn't have any character.

I suppose this is the closest I've felt to understanding the distinction between art and just drawing.


Previous submission:

http://news.ycombinator.com/item?id=4567065

(by me, no comments--it feels seriously weird to tell ColinWright about a previous submission)


Huh - bizarre.


That's awesome.


> When people look at these comics, they always assume, oh, the guy that drew this must have done all that. But for me, I just found a cool way to get to the result that skips all that, even if it’s not as general or satisfying. People tend to assume that I’ve done whatever the most expert way of getting to it is, and so they assume that I know a lot more about the subject than I do.

This reminds me of Penn Jillette's comments on magic. Oftentimes a trick really is as banal as "he practiced that every day for months and months", but the audience will never believe someone has that much time/patience.


>For example, there was one that involved combining different restaurant menu items to get a certain total. But because I didn’t know something about how Perl’s libraries handle floating-point comparison, the puzzle in the comic actually has a really simple solution in addition to the one I meant, that the code missed because of this bug. Most people didn’t notice, but it’s always bugged me.

Oh wow, he got really unlucky, too. It's just 7 of the first item.


He really should have used fixed-point arithmetic.


Why? If I found out that the library that I was using didn't have good fixed-point support (i.e., "doesn't do what I expect"), and if I didn't need the values to be infinitely precise, I'd just use a multiplier. It's always worked well for me in the past.

e.g., 7 * 215 = 1505.


Yep, that's called "fixed point arithmetic". The multiplier is called a "scaling factor". You typically have to "rescale" after each multiply operation by dividing the result by the scaling factor, but you've done that implicitly by not scaling integer values like 7.


Luckily, I've never had to write any database code that deals with money. If I had, though, I would have insisted on integers where a penny is 1 like this - it just doesn't make any sense to store an exponent for a bunch of values that are all the same order of magnitude anyway.

(I assume that this is how "fixed point" algebra works, although what I assume computers do with floats and what they actually do ain't exactly ever been similar.)


(I assume that this is how "fixed point" algebra works, although what I assume computers do with floats and what they actually do ain't exactly ever been similar.)

You might enjoy reading about IEEE-754, then: https://en.wikipedia.org/wiki/IEEE_754-1985


This would, however, totally miss the point that a penny actually isn't the smallest meaningful unit of money used in systems tracking actual money.

Assuming that the order of magnitude is fixed, this is of course doable, but according to my experience the order of magnitude does not converge.


Ah, but it would work fine on a website where you're selling things to humans (whose bank accounts can't store ha-pennies). I don't think anyone would be foolish enough to let the physicists near financial markets - there would be heavy losses on both sides.


Don't do that. All of the major database players have built in fixed point decimal types with user specified precision. You'd be reinventing the wheel.

As far as doing mathematical operations on the values, if you're using double precision floats, you have 15 digits of precision before you run into problems. In most situations, you're going to be dealing with values considerably less than 10 trillion dollars, so that will be totally sufficient. That's good news if you're using a language like JavaScript or Lua, where there is no built in integer type.


I've found (having written too much physics code for my own good) that floats give you 0 digits of precision - I ask for 4.0 and it gives me 3.999999999998 .. ;)

The solution is, of course, to use rational numbers ( http://gmplib.org/ ) if you have time to debug why GMP doesn't compile on your processor.


He really should have used plain integers and calculated in cents.


That is the definition of fixed point.

(Although, if you do it for anything else than currency, you probably would do it in base 2 instead of 10. And yes, I know every base is base 10.)


I know it's just an off-the-cuff remark, but the last comment annoys me. Implying that sociologists are responsible for the existence of society is as silly as implying that biologists are responsible for that of biology.


As discussed in the comments of http://plover.net/~bonds/purity.html, a loop of importance/purity rather than a straight hierarchy makes more sense (or assuages more people).


He mentions that xkcd is his job. Does anyone know how he makes a living off of it? Selling T-Shirts and Posters?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: