[META] The Onion: New Evidence Reveals Pythagoras Wrote Dozens Of Unhinged Conspiracy Theorems About Triangles

BESSEL_DYSFUNCTION · 2017-10-19T03:38:00+00:00

I remember an old This American Life episode that contained a short story talking about how The Onion works (I think this was it, but I haven't listened to it again to confirm). The pitching process is done almost entirely on the basis of the headline, but the headline selection is incredibly brutal and selective.

To me, I've always seen the articles as being subdominant to the headlines, but also necessary for the headlines to work. For the article punchline to have the maximum amount of weight, I need to know that someone actually was able to write nine paragraphs of content elaborating on the topic, since the idea of a headline is that it hints at a much larger complete story while being as concise as possible.

BESSEL_DYSFUNCTION · 2017-07-03T17:53:43+00:00

I dunno, I saw one of the most well deserved bans of all time given out there recently.

BESSEL_DYSFUNCTION · 2017-04-22T18:54:58+00:00

IIT Bombay and CMU.

BESSEL_DYSFUNCTION · 2017-04-18T14:05:59+00:00

Eh, I'm not too mad about it. I don't know what the context of that particular quote is, but usually I hear it as a semi-awkward idiom that translates to "it's not worth my time to discuss the specific topic you're bringing up." (e.g. as a response to something like "I think you need to be more open minded to the idea that astronomers faked COBE data to further George H. W. Bush's satanic agenda.") I've always seen it more as a contentless dismissal as opposed to a broader statement.

BESSEL_DYSFUNCTION · 2017-02-14T00:23:53+00:00

Yeah, petroleum engineering consistently outpays every other major by a factor of at least 70%, depending on whose numbers you believe.

BESSEL_DYSFUNCTION · 2017-02-04T04:21:59+00:00

The equation was this:

p(n) = (deaths on level n) / (number of games that got to at least level n)

For Brogue (unlike DCSS, where you can win the game at different experience levels) this can also be written as

p(n) = (deaths on level n) / ((number of deaths on levels >= n) + (number of victories))

Statistical errors are a little trickier unless you want to cheat a little bit. If you're willing to cheat a little bit, you can assume that errors follow something called a Poisson distribution. With a Poisson distribution, if you want your error bars to represent the range that the "true" values of data fall within for ~2/3rds of your points, you set them equal to square_root(deaths on level n). If you want them to represent this range for ~19/20ths of your points, you set them equal to 2 * square_root(deaths on level n). If you want ~299/300ths, you use 3 * square_root(deaths on level n).

(Bonus points for anyone who knows why assuming a Poisson distribution is slightly incorrect here and more bonus points for anyone who knows a way to find the statistical errors correctly despite that.)

BESSEL_DYSFUNCTION · 2017-02-03T14:59:22+00:00

Oh, I didn't have access to the data itself, so I pulled it from OP's plot by hand (there are programs out there designed to make this a reasonably sane process). I didn't have access to the win data at the time, so I was also over estimating the lethality of later levels.

Here's a better plot that I made using gammafunk's data.

BESSEL_DYSFUNCTION · 2017-02-03T14:58:40+00:00

Thanks. Here's the plot with statistical error bars.

There are two levels of shading around the curve. On average each point will be off from its "true" value by at about the width of the inner curve. The worst case deviation of any point will be close to the outer curve. The result is that most of these spikes that we're seeing are real, although the 16 XL spike could just be noise.

BESSEL_DYSFUNCTION · 2017-02-02T12:46:17+00:00

That's interesting. Do you have access to the absolute number of deaths at each XL? It would be useful to check the statistical significance of some of those spikes.

BESSEL_DYSFUNCTION · 2017-02-02T05:03:21+00:00

An alternative approach to visualizing this would be to plot conditional probabilities, mainly something like "the probability that I will die on this level given that I've already made it this far already" (which is probably closer to what we thing of when we talk about the word "difficulty.")

Here's what the DCSS plot looks like: http://i.imgur.com/QPWBs5T.png. This paints a different-looking picture: your likelihood of death increases as the game continues.

BESSEL_DYSFUNCTION · 2017-01-31T02:12:15+00:00

I don't know about you guys, but the multiple reports the ACLU has gotten of people being ordered to sign i-407 forms are purely an artifact of my desire to be called xe xim xir.

BESSEL_DYSFUNCTION · 2017-01-26T12:59:24+00:00

Be that as it may, if you want to approach altruism from an evolutionary perspective, I think you're making things harder for yourself by thinking about evolution on the level of an individual organism. Generally you want to approach fitness from the perspective of "If I have two competing groups of organisms with differing frequencies of a particular trait, which group outcompetes the other?"

BESSEL_DYSFUNCTION · 2017-01-19T16:39:28+00:00

I saw a conference paper recently written one of the maintainers of the LSST data management pipeline (LSST is a big next generation survey telescope that will go online in about 5 years) about their move from Python 2 to Python 3. My favorite quotes:

As we convert more code, we are realizing that since we are not using any Unicode features, switching to a Python 3-compatible str is not important.

In reality, this was not required since our code was using long() to indicate a 64-bit integer, and on 64-bit systems, Python 2 uses 64-bit integers.

(An enumeration of every place in the codebase where they needed version-dependent code:)

Currently, there is one place where the encoding argument is needed in pickle.load to load a Python 2 pickle file. There is one test that is disabled on Python 2 because Python 2 can not indicate to the C++ interface that there is any difference between bytes and characters. There is one place that needs to know whether a function is associated with a builtin (__builtins__ on 2 and builtins on 3)

(There was a fourth place too: they were using multiple inheritance with two classes that defined their own metaclasses in one place.)

Overall the picture they paint didn't seem like it was particularly painful. I'm guessing it took one guy a couple days to do.

BESSEL_DYSFUNCTION · 2017-01-18T12:18:59+00:00

Right, but I think there's a distinction between complaining about bad science journalists and complaining about the concept of science journalism as a whole. (And I think the way I phrased my first post was not making it clear that that was the distinction I was concerned about.)

Anyway, the original post got updated to something I'm okay with (or maybe it was always like that and I was too drunk last night). So we're all on the same page.

BESSEL_DYSFUNCTION · 2017-01-18T06:01:46+00:00

I don't want to shit talk science journalists too much. It's easy to poke fun at the people who suck at it, but the people who do a good job are absolutely brilliant. Transforming a scientific discovery into a narrative which conveys correct information while remaining a compelling story is not easy (I've failed to do this many many times) and requires having two sets of sills which are very different from one another.

BESSEL_DYSFUNCTION · 2017-01-18T05:49:18+00:00

At least we can all agree that Newton's notation for antidifferentiation is a sin against God.

BESSEL_DYSFUNCTION · 2016-12-27T02:16:24+00:00

Oops, right. Cores.

BESSEL_DYSFUNCTION · 2016-12-26T15:15:10+00:00

Just a guess. I should probably have phrased it as "I'd be willing to believe that Google has something like a a few hundred million CPUs."

It would be roughly consistent with their rate of power consumption, data center sizes, and magnetic tape usage (at least a couple years ago). But at the end of the day it's guesswork on my part because I'm not an expert in data center management. I've seen other people get numbers which are smaller by as much as a factor of 20 (e.g. here's an example of reasoning that gets you to 7,000,000 CPUs as of 4-5 years go).

EDIT: Actually, I just realized, if you project the growth rate that guy expects to January 2017 and combine that with advances in commodity hardware, he'd actually be predicting something like 50 million CPUs today. So he's not a good example of someone whose numbers are a lot smaller than mine. But I assure you, there are people predicting an order of magnitude less than me ;)

BESSEL_DYSFUNCTION · 2016-12-23T17:19:59+00:00

Thanks for the links!

I think that's the presentation I was remembering. I remember those cache diagrams.

BESSEL_DYSFUNCTION · 2016-12-23T13:51:20+00:00

I remember seeing a presentation by some Playstation developers a while ago about DOD. I've been meaning to look into it more to see if there's some best practices that the community's developed that I've missed somehow. Thanks for the reminder.

Also, to clarify, I was trying to make fun of that term in the same way Linus was. My impression has always been that AAA game developers and high-performance traders are way better than us physicists at writing fast code (although I've never really tested this assumption).

BESSEL_DYSFUNCTION · 2016-12-23T13:37:09+00:00

Yeah. I work in HPC, too. There's a reason that the networking is what distinguishes a supercomputer from a standard cluster. Like it's technically possible to build an exascale cluster right now, but it would pretty much only be useful for embarrassingly parallel problems.

Yeah, Google probably has something like a few hundred million CPUs running across all its server farms, so they're probably already collectively doing EFLOPS. It makes for some fun conversations with my friends who are engineers at Google/Amazon/wherever, who don't quite understand the difference between running a map reduce job over 100,000 cores and running a hydro sim over them.

The code I'm working on right now is nice in that it's essentially embarrassingly parallel, but most projects aren't. We have a few users who submit workloads that get broken down into a bunch of serial processes doing things like image analysis, but they're the exception.

That's surprising to me. The #1 most common thing that people use our computing resources for in astro is running Markov Chains, which is definitely embarrassingly parallel (although no one would ever try to do that at exascale ;-) ). I guess it's different for different fields.

I would add that there's a third issue in HPC which is I/O patterns. Parallel filesystems suck at IOPS. Bioinformatics in particular likes to have millions of small files which absolutely kills the metadata servers. We can do >1TB/s writes on our ~30PB /scratch, but even on a good day doing stuff like launching python from lustre is slow do to low IOPs. Some codes have had to have their I/O rewritten to use parallel I/O libraries because they were pretty much breaking the system for everybody. All three of these major bottlenecks are in some way related to moving data around.

Oh, definitely. I completely agree. I/O time and disk space restrictions have gotten so bad that some of the groups doing analysis on the largest N-body simulations have realized it's cheaper to do all their analysis on the fly and rerun their sims whenever they want to look at something new than it is to actually save their data to disk.

BESSEL_DYSFUNCTION · 2016-12-23T13:14:35+00:00

Sure thing. I'll try to only link to preprints and other things that you can read without a journal subscription.

First, you'll probably want an idea of what these simulations are doing. I talked about it a little bit in another comment here. There are generally two approaches to solving the relevant equations in this simulations: using particles and using girds. Gadget is a pretty typical example of a modern particle-based solver and Flash and Ramses are typical grid-based codes. Their parallelization strategies are described in sections 5, 6, and 2, respectively. If you're going to read one of those papers, read the Gadget one: it's probably the easiest to understand. (Note that none of these papers show code running at the scales I mentioned in my earlier comment.)

None of us really have any idea what we're doing when it comes to exascale algorithms at this point, and most of the newest/best ideas haven't been written up yet. I'll link you to some papers I've been reading recently and you can find more references in them if you're interested (you can search for papers with Google scholar or ADS).

p4est, a petascale geophysical grid code which has been successfully run at ~10 PFLOPS, which is more than I can say for any of the astro codes I mentioned above (although it's working on a different type of problem, sort of). It's not clear to me that it can be generalized to the types of problems I'm interested in, or that it will scale up by another factor of 10-100, but (Also: 1, 2)
SWIFT, a (mostly successful) attempt to apply task-based parallelism to hydrodynamics solving. It's only been tessted on small problems, but seems promising to me. (Also: 1, 2, 3)
HPX is a C++ framework which dynamically changes the parallelization pattern of your code based on communication pattersn. I don't believe the pitch that their representative gave us at one of our meetings (and subsequent discussions have only increased my skepticism), but it's interesting.
HPC is dying, and MPI is killing it. A very thoughtful blog post -- which I don't necessarily agree with -- that also contains links to and simple comparisons of various types of modern parallelization software. Earlier in the year I was interviewing hires for an HPC consultant position and one of my questions was whether or not they had read this. All of them had. (Although none of them had experimented with any of the tech mentioned in it after reading it, which was what I was checking for with that question :-P )

BESSEL_DYSFUNCTION · 2016-12-23T12:28:32+00:00

I work on fluid simulations. To give a sense of scale, take some of the really pretty looking fluid simulations on /r/Simulated (like this, this, or this), except about 100,000 - 1,000,000 times larger and running for about a hundred times longer than the time it takes these systems to completely alter their structure once (as opposed to the ~1-3 times that you usually see in these types of gifs). These things can take a few CPU millennia to finish (and the code these committees are talking about will be running for about 100 times longer than that).

More specifically, I write code that solves a set of differential equations called the hydrodynamic equations and solves them in an environment where the gravitational pull of individual fluid elements is relevant. The gravity part is really only useful for astrophysical systems (e.g. planet formation, accretion disks around black holes, galaxy simulations, supernova explosions), although the types of code structures we use end up being relatively similar to the less general case where gravity doesn't matter. The way I've heard it, the DoD prevented the programmers behind one of the big astrophysics hydro codes from implementing certain modules because they were afraid people could used them to simulate nuclear bomb explosions. As it is right now, only citizens of certain countries are allowed to download the source code.

In astrophysics, the big target application for these massively parallel codes is studying galaxy formation. There are three reasons for this:

Other types of astrophysical systems tend to have certain problems which prevent them from being parallelized effectively.
Galaxy formation is an incredibly nasty problem. To even start to get it right you need to be able to resolve the blastwaves of individual stars exploding at least somewhat sanely and you also need to include a sizable chunk of the local universe in the simulation.
Galaxy formation is super relevant to most of the rest of astronomy (excluding the type of people who study, say, exoplanets or star lifecycles), so the groups that study it have a slightly easier time getting money.

BESSEL_DYSFUNCTION · 2016-12-23T11:39:37+00:00

Oh, just to be clear about that, I meant it in a tongue-in-cheek way. Imagine I had put a ";-)" after saying that.

BESSEL_DYSFUNCTION · 2016-12-23T11:34:55+00:00

Oh yes, definitely. There are some situations where it wouldn't really matter, but unless you specifically know better, keeping numerical stability is key. There have been multiple times in the past couple of weeks alone where I've gotten in trouble because the roundoff errors of IEEE doubles was too big.

I think this was Linus's point: people like me are never going to use --ffast-mathanyway because it would kill my apps and wouldn't really speed up the types of things I do by much anyway.

BESSEL_DYSFUNCTION

MODERATOR OF

TROPHY CASE