Totient

Scott Aaronson argues that, based on what we know about quantum mechanics, Wolfram's "long-range thread" cannot reproduce special relativity and Bell inequality violations:

www.scottaaronson.com/papers/nks.ps

I'm reminded of the classic Charles Baggage quote:

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

I'd argue for a pretty high level of transparency in the process - I would like to see whatever classifiers being used open-sourced, for example. And I'd want to know where people are drawing the training data from.

But the nice thing is that the tech industry has a large population of people very sympathetic to transparency, and with a history of a culture supporting it. Quite frankly, I think the legal community has a lot more to learn from the open-source community than the other way around.

This makes perfect sense. I know people who would be terrified of the thought that their organs could be harvested while they might yet recover, but also people who be horrified that their perfectly good organs are just laying there, unused, after their brain has died, but with artificial respiration/circulation keeping some of the rest of their body going.

I think a sane default is to require opt-out for organ donation after brain death (what Europe does now, I believe) with an opt-in "sliding-scale" for the rest of the possibilities.

I agree, and disagree with the author.

"Vision 1: CONNECT KNOWLEDGE, PEOPLE, AND CATS."

This is the correct vision.

I would say this is a correct vision, which I happen to be in favor of.

But I don't understand why it has to be an "us vs. them" dynamic between this and the "BECOME AS GODS, IMMORTAL CREATURES OF PURE ENERGY LIVING IN A CRYSTALLINE PARADISE OF OUR OWN CONSTRUCTION" vision.

Even in strawman form, I'm unapologetically in favor of it. I do want it to go right. I don't think it's going to happen anytime soon - I think human-level AI by 2075 [1] is wildly optimistic - but I hope it does happen eventually, without wiping out everything we hold dear.

I'm a little embarrassed to talk about it, because it's so stupid.

My first thought was "Try describing the internet to someone 100 years ago - your claim that there is going to be an interconnected global network of electricity-powered adding machines that transport pictures of moving sex by pretending they are made of numbers is going to sound stupid."

But if you want to make fun of Elon Musk because "Obama just has to sit there and listen to this shit", what about:

Shane Legg: "If there is ever to be something approaching absolute power, a superintelligent machine would come close. By definition, it would be capable of achieving a vast range of goals in a wide range of environments. If we carefully prepare for this possibility in advance, not only might we avert disaster, we might bring about an age of prosperity unlike anything seen before."

Stuart Russel: "Just as nuclear fusion researchers consider the problem of containment of fusion reactions as one of the primary problems of their field, it seems inevitable that issues of control and safety will become central to AI as the field matures."

Or freaking Alan Turing: "There would be plenty to do in trying to keep one’s intelligence up to the standards set by the machines, for it seems probable that once the machine thinking method had started, it would not take long to outstrip our feeble powers…At some stage therefore we should have to expect the machines to take control."

But you all need to pick a side.

I don't want to pick a side. I'm in favor of connecting the world now, making it better for everyone. I'd also like to see the world get much better in the more (hopefully not too) distant future.

[1] http://www.nickbostrom.com/papers/survey.pdf

Satire, aside, I think a very short addition to the last line holds a lot of truth:

"A hash is simple. A hash is fast. A hash is all you need to start with".

I can think of plenty of good reasons to stop using a map/hash/associative array in code, but I can't think of very many good reasons not to start coding with associative arrays as your default data structure. If there's a performance/memory problem, fix it later. I've seen a lot more code suffer from premature optimization than I've seen suffer from using data structures that were a little too inefficient.

(Theoretically, at least) The ability to exercise a line-item veto would help. The rider to build an new bridge to nowhere would get vetoed, and the rest of the bill would go through.

I agree. It would be nice if everyone was exposed to programming, just to get a feel for what is possible/plausible - plus the benefits of learning how to think through a problem logically.

But just as I don't consider someone fatally unknowledgeable about biology if they can't quite remember what, say, the liver does, I don't consider someone fatally unknowledgeable if they don't know how to write a computer program.

It would be nice if everyone tried programming at some point, but the idea that everyone should know how to is kind of silly.

Looks like a system to setup up assurance contracts for funding software. Glad to see more people trying to make this sort of thing work.

What's interesting is that you can actually make pledging a dominant strategy, if you find someone willing to put up enough capital. Roughly speaking, dominant assurance contracts work along the lines of "Everyone who pledges will receive X amount of money if the fundraising fails to hit the appropriate threshold." For anyone who would stand to gain from public good, the outcomes are now "Pledge: either the project will be funded or I will get money vs Don't Pledge: either the project will be funded or I will get no money"

http://mason.gmu.edu/~atabarro/PrivateProvision.pdf

There was a followup using actual shocks on a puppy. Similar results: http://www.holah.co.uk/files/sheridan_king_1972.pdf

Hmm... I kind of want to figure out a way to make CAPTCHA-coin work now. Cryptocurrency mining for the people!

I just can't think of a good way to generate CAPTCHAs (or something similar) from a block in a fashion that would give human beings a significant edge over computers.

Speaking analogously, "If we gave everyone one in the world a device that randomly shot paint at the wall, I would be more surprised if no one ended up with an interesting pattern."

I agree, but whatever that pattern (or patterns) turned out to be is still an interesting question.

I love this description of quantum. The paper Aaronson links to, "Quantum Theory from Five Reasonable Axioms" (http://arxiv.org/abs/quant-ph/0101012), is also a great read.

The "probability in L^2" cleared up a lot of confusion for me, although I still have a very poor intuition for what the Born probabilities are probabilities of. If you believe the MWI story, it seems like it's the probability you will "find yourself in the universe where this outcome happened" but even that sounds odd to me.

Had Java been not so broken for numeric stuff

I'm curious, what makes Java an especially poor choice for numerically intensive computing? Is the JIT penalty too high, or is it something else entirely?

You don't need a validation set. I'm pretty sure you still want a test set.

Instead of "rest" (which the author mentions is a core function), the Clojure convention for getting the remaining items appears to be "more"; e.g. [x y & more]

I really like this tutorial.

I don't understand the difference between fn and fn* . After some brief experimenting in the REPL, they seem to behave exactly the same, the only difference being that fn* is what comes out of macro expanding the #( macro

Is there a reason that the #( macro doesn't expand to plain old fn?

The problem is that pretty much the entire standard library isn't thread safe. It would take some serious work to get OCaml ready, unless you stick to message passing between distinct processes.

The guy I work for really has no idea how easy certain tasks are once you automate them. I have done nothing to correct his misconceptions.

(I'm a CS grad student, working under a professor who somehow got tenure despite being unable to program his way out of a cardboard box. I swear, half of this job is tricking him into thinking I'm doing his work, so I can focus on doing actual research. ...I really need to find a new advisor.)

Clojure feels like a 'compromise' Haskell, but I mean that in a good way. Haskell really wants to pretend that everything is a pure function. But I think this is a case where the conceptually simpler thing (i.e. no state) is just too hard to reason about.

Clojure backs off the 'referential transparency ONLY' philosophy, and merely discourages mutability. In my (limited) experience, this gives almost all of the advantages of Haskell, but an environment that's easier to program in.

So yeah, I'm excited about Clojure too. I just wish we could port it off the JVM...

I wonder where things like classic rock / broadway musicals / opera / etc. fits on this spectrum.

I really appreciate including Shakespeare and Moby Dick on the spectrum, but I'd still like some more perspective. For that matter, I wonder how many unique words I use every day.

I really like this idea and it got me thinking about a lesser, but still bad, disaster:

If all computers were to disappear tomorrow (let's say a super-EMP, or something) how could we quickly restart the digital age? As in, what source code/chip designs would we really wish we had on paper somewhere, so a relatively small team could get modern computing going quickly?

From the source code side, I'm thinking the opcodes necessary for a Forth compiler, a compiler for some restricted version of C in Forth (to keep the source code size down), a quality C compiler written in the simple-C and the source code for some vaguely POSIX compliant system (MINIX, maybe?)

I'm curious if it's at all feasible to put that much source code on paper...

The Fourier transform .gif was gorgeous. Anyone know of a similar one for Laplace transforms? (I'm still having trouble building up intuition for the Laplace transform.)

I think this article is side-stepping an important philosophical point as to what randomness is.

Suppose we lived in a deterministic universe (e.g. one that actually ran on Newtonian mechanics and classic electromagnetism).

If you're of a mildly Bayesian persuasion, you 'believe' in randomness - even in a deterministic universe - because probability represents your knowledge. Sure, all the rules for the universe's evolution over time are deterministic, but you don't know the initial conditions, so you consider some probability distribution over initial conditions. Thus, the results of future events are 'random.'

The counterargument might go something along the lines of "that's not really random the way quantum mechanics is, because Bell's inequality demands violating either hidden-variables or locality and violating locality is worse. Without local variables, you can't meaningfully talk about having a 'underlying' deterministic universe."

Except you (sort of can). Bell's inequality implies that we can't have a theory with local laws of physics for single universe. But we can have a theory with local laws of physics for a multiverse which is the approach many-worlds takes.

"...they boil down to that choice being more useful than the alternative choices, leading to simpler theorems, or feeling more “natural” to mathematicians."

Along these lines, my preferred definition of the natural numbers" is "the set of all the positive integers and, when convenient, 0".

Smugness aside, I am actually concerned about this implementation and Telegram's response:

The rest looks like matters of taste as opposed to objective reasoning. Can you name an actual attack?

The response to that is, "I shouldn't have to!" Anything that replaces a proven secure component with something that we haven't (yet) found an attack on is grounds for suspicion at the very least.

SHA-1 isn't a MAC. It's not that hard to make it so (HMAC), but Telegram hasn't.

Again, we do not use MAC-then-encrypt. Our scheme is closer to MAC-and-encrypt with some essential modifications.

Out of the three options: MAC then encrypt, encrypt then MAC, and MAC and encrypt, only encrypt then MAC is secure (http://cseweb.ucsd.edu/~mihir/papers/oem.pdf) I don't care if they've made "essential modifications", they're replacing a component that is provably secure, with one that may or may not be secure.

This story kind of reminds me of this:

http://www.bbc.co.uk/pressoffice/pressreleases/stories/2007/...

For most of the Cold War, the RAF's nuclear bombs were armed by turning a bicycle lock key.

"The Royal Navy argued that its officers could be trusted and: 'It would be invidious to suggest... that senior Service officers may, in difficult circumstances, act in defiance of their clear orders.'"

Patent trolls are certainly a problem, but realistically you can't have laws without someone trying to abuse them.

I think it might be more effective to attack the problem from the other end: making sure patents like don't get issued in the first place. Maybe it's not reasonable to expect every jury to understand the basics of encryption. But it is reasonable to expect the patent office to understand prior art in cryptography.

I think that was Rich Hickey's "Simple Made Easy" talk: http://www.infoq.com/presentations/Simple-Made-Easy

I think one of his most important points is that objects are good for representing, well, actual objects. As in, you have a mouse, or screen or some little robot that you are controlling through code. And that's all they are good for.

Need a way to define a bunch of static methods and avoid name collisions? - you want a namespace.

Need a place to store a bunch of data about something? - you want a associative array.

Need a way to call the same function on different types? - you want an interface.

I'm not sure about this, but I suspect part of the problem stems from the fact that object-oriented languages (usually Java these days) are the first language that students are exposed to. Once you start thinking in OO abstractions, it takes some effort to break out of the mindset.

My problem with the online course idea (aside from the fact that this is pretty much already available) is that it lacks interactivity. The only reason I went to half of my lectures as an undergrad was because I could ask questions and get an near instant, expert response.

And sure, it's possible to pause a video lecture and look something up, but in my experience, it's just not the same. If I'm trying to understand something for the first time, and a part of the lecture just doesn't quite make sense, I want the transaction cost of clarifying a point to be as low as possible.