Also if you are training on a database of code.
203 karma · joined February 2, 2010
Also if you are training on a database of code.
> Anders Sandberg, Stuart Armstrong, and their co-author Milan Cirkovic published a paper outlining a potential strategy for advanced civilizations to postpone computation until the universe is much colder, and thereby producing up to a 10^30 multiplier of achievable computation. This might explain the Fermi paradox, although a future paper from FHI suggests there may be no paradox to explain.
Possible solution to the Fermi paradox: there is no paradox. The normal approaches find that there should be a very large number of civilizations by plugging point estimates into the Drake Equation, but multiplying point estimates (as opposed to probability distributions) with each other gives you misleading results.
As a toy example, if you multiply nine factors together to get a probability of life per star, each of the factors a random real number drawn uniformly from [0, 0.2] and the point estimate for each being 0.1, then the product of the point estimates is 1 in a billion. This would translate to an expected 100 life-bearing stars, given 100 billion stars. But if you instead combine the probability distributions, you get a median number of 8.7 life-bearing stars (the mean is still 100).
Going through the literature to estimate reasonable prior distributions for different values in the Drake Equation, you get much more pessimistic estimates for the probability of life in the universe; the priors chosen by the authors suggest a 40% a priori chance for life only emerging once. We really might just be alone.
The article's description makes it sound complicated, but the fact is that a lot of the techniques are pretty simple when it comes down to it. And that's the problem: they're so simple that it's hard to get people to realize how useful they are. Most people will hear a description, shrug, go "makes sense I guess", and then forget all about it.
Take TAPs (Trigger-Action Plans) that are mentioned in the article. They're basically pretty much what it sounds like: plans of the form "when [trigger], then [action]". "When I see stairs, I'll take them (rather than using the elevator)". Not something that'd sound very revolutionary. But if you dig into the psychological literature, when people are instructed to set goals and use TAPs (the psych literature calls them "implementation intentions") to plan out how exactly they'll achieve those goals, people get better success rates than people who don't. (if you want a reference, google e.g. [1])
There's a bunch stuff about what makes for a good TAP and how you should use them to get the best results, but even if you include all of that, it's still not very complicated. The guidelines are stuff like "make your trigger a concrete specific thing such as 'when I see the stairs', not vague ones such as 'before dinner'". Not rocket surgery.
So here we have a simple, straightforward technique that has research support behind it - and getting people to use it is hard. It just doesn't sound exciting enough, or obviously useful enough. Heck, I too often just forget that I could use TAPs for something.
Most of their techniques are kinda like this. Simple, useful, and not terribly exciting by themselves.
So - I don't know if this is their explicit motivation for having a three-day workshop, but I think that this is a big part of the reason why the format works - instead of trying to make the individual techniques exciting, they instead throw everything and the kitchen sink at you within a short time period. Rather than relying on any single one of them making you go "wow", they rely on the sheer amount of them to make you go "wow" - and then, hopefully, actually adopt at least some of them. As well as to internalize the mode of thought that lets you come up with your own.
It seems to work okay.
[1] Gollwitzer, P. M., & Sheeran, P. (2006). Implementation intentions and goal achievement: A meta‐analysis of effects and processes. Advances in experimental social psychology, 38, 69-119.
I'm thinking of something like a return to the Unix philosophy. Piping together stuff from grep to cat to whatever is pretty great, but mostly only useful if you're dealing with text-ish files. We don't have much in the way of small tools that would be similarly designed for being chained together, but which would work well for say video files. In part because you'd want better OS-level support for that kind of information sharing (though maybe on 'nix you could just pipe stuff from one application to another?), but also to a large part because you'd need to have people making tools that didn't do much by their own and then convince users to download them and build stuff out of them. And telling people to "download this program which doesn't do much by itself, but which is useful if you download some other programs and then combine them" is hard. People want to minimize the amount of hassle, so mostly people bundle lots of different features into a single application that you can just download once.
On the other hand, if you had a platform where everything ran in the cloud, and there was no need to separately buy, install, or download things... if any application could call any other application made for the platform, then you could just start making your little specialized programs and making them available for anyone else to use. Any user might chain several of them together, or a programmer making their own application could use them as part of their application, maybe as easily as calling a library. That could open up huge possibilities. With the revenue sharing, there would even be a financial incentive for people to make small tools that were maximally useful for everyone, even if they mostly remained invisible for normal end-users.
That said, I'm seeing nothing in Solu's public presentation suggesting that they'd have thought of this angle, or would be invested in it. Which is a pity.
I wonder if the whole hardware part might be just a marketing thing. Tangible, pretty-looking products are easier to get people enthusiastic about and preorder than "we're offering a new kind of cloud service you can run in your browser". Possibly they mainly just intend to use this to generate a bunch of publicity and hype. Then after a while unveil their browser interface that you can use on any device, and get to market that separately as something new and totally exciting that opens up the system for more people, pulling off another hype wave that might work better than if they'd gone with the software-only approach right from the beginning.
If you have an iOS or Android tablet, they also have a new game called DragonBox Elements up that teaches geometry. After playing it for a while, I'd see triangles everywhere.
If DragonBox gets them hooked on algebra, another fun algebra game is Algeburst (currently only available for iOS platforms AFAIK), which employs a basic get-three-of-the-same-color-in-a-row mechanic, but requiring you to interpret simple algebraic expressions in order to figure out which tiles are of which color. E.g. if there's a tile called 3X + 2X, you can recognize it as being a 5X tile and give it whatever color 5X tiles happen to have on that particular level. (I was only going to try this game to see whether it was any good, but then ended up losing several hours to it.) They also have a "topics in arithmetic" version which doesn't have algebra but rather focuses on basic arithmetic.
10 might be getting a little old for it, and it teaches the basics of programming not math, but in general I would also recommend the Robot Turtles board game. On the topic of games teaching programming, I've also heard good things about the CodeSpells computer game, in which you're exploring a world and can cast spells by writing Java code, but I haven't tried it myself.
It's not that this is a problem with applying Bayesianism in science, it's that our thought is Bayesian on a fundamental level. And it couldn't be otherwise, at least not for beings as intelligent as humans.