allenlavoie

We already have a much more liquid terrorism futures market, i.e. the regular stock market. Worrying about incentives for a large attack from a prediction market is missing the ocean for a hypothetical raindrop.

Incentives in smaller markets (e.g. local elections, or personal car crashes as you say) are super interesting though.

It's a nice xor swap, but I think you reversed your list twice. And xor swapping with x=y=2 is likely not ideal. Seems like exactly what I'd do in an interview too :p

It's just a small Cython-compiled utility throwing the warning, it works fine. Everything else is pure Python and so doesn't care about 3.5 vs 3.6. We will fix the warning, though (disclaimer: I work on TF and added fast_tensor_utils--sorry!).

A lot of the best practices for initializing/saving/restoring/etc. are handled automatically if you wrap your model in an Estimator[1] using a model_fn. It also enforces a "clean" model specification (in a new Graph) and decoupling of the input pipeline from the model.

However, Estimators are not in TensorFlow core, which means the API isn't fixed quite yet.

[1] https://www.tensorflow.org/extend/estimators

Like https://www.google.com/settings/ads ?

You could, but you would be wrong, as the remainder of the paragraph you started quoting argues quite convincingly. Fiddle with the free parameters of the contest and it "demonstrates" whatever you want it to.

The waiting time distribution is actually the geometric distribution (with expectation 1/p = 1/0.021 = 47.6, so about what they got).

One solution would be for Netflix to modify their clients to send useless and quickly discarded UDP packets back to balance out the traffic. Verizon then has tons of data to push back to Level3 and everyone's happy.

This is essentially the goal of probabilistic programming[1]: let the programmer specify and tweak the model, and have the analog of a compiler handle inference. Finding a good model is then analogous to debugging.

You are mostly stuck with Bayesian models, since that's what we have general-purpose inference algorithms for. And in practice an understanding of Bayesian statistics is a prerequisite for writing useful probabilistic programs.

[1] e.g. http://probabilistic-programming.org/

>Yep, because now you've just got your air rushing into the vacuum through the cracks, instead of water.

Fair enough. I imagine there's a trade-off between the quality of the tunnel materials and the number of pumps needed along the way, assuming an imperfect vacuum is good enough.

I'd be worried about flexibility too. Skyscrapers do pretty well in high winds and earthquakes, so I'm not completely convinced that a similar effect isn't possible with an underwater tube. Any bending would have to be extremely gradual, though, if there's any hope of shooting something through it at high speeds. I agree that glass isn't going to cut it.

Is there some reason that sandwiching air between the evacuated tube and the water wouldn't work? Granted it would add to the cost.

The ocean depth point is interesting. The article says "engineers would tether the tunnel at a fixed depth." I take this to mean tethering to the bottom and relying on buoyancy to keep the tunnel floating at the right depth, which presumably could be 30m or so.