alextp

When claire stopped writing the tgif emails I was very sad, among others I talked to. When I heard, years later, about all this bs she went through, it helped crack the illusion for me. So sad.

The flip side is redistributive pensions require an ever growing population and most European pension systems will go bankrupt within a couple of decades given current birth and immigration rates.

Choose the top N according to the proxy objective and then use the real objective to choose the best out of those N candidates.

Claire deWitt and the city of the dead, by Sara Gran is a good example. Very colorful language.

Also the first volumes of the Berlin Noir "trilogy".

How is brain separate from the rest of google?

The historic picture makes a little more sense (though this is not something a 5yo would understand).

We call these things embeddings because you start with a very high dimensional space (image a space with one dimension per word type, where each word is a unit vector in the appropriate dimension) and then approximate distances between sentences / documents / n-grams in this space using a space with much smaller dimensionality. So we "embed" the high dimensional space in a manifold in the lower dimensional space.

It turns out though that these low dimensional representations satisfy all sorts of properties that we like which is why embeddings are so popular.

I've contributed to autograph and would love to answer any questions.

Cool! Did you try using tensorflow's eager execution?

I think Keras is a real deal framework. It provides a higher-level API than most other frameworks, but it has pretty sweet portability of models across frameworks and platforms and most research papers are implementable in Keras without too much trouble.

We're still fairly early in the project, so for now threading is the only supported way.

We can do better, however, and we're working on ways to leverage the hardware better (for example, if you have no data-dependent choices in your model we can enqueue kernels in parallel on all GPUs in your machine at once from a single python thread, which will perform much better than explicit python multithreading).

Stay on the lookout as we release new experimental APIs to leverage multiple GPUs and multiple machines.

Ah, I didn't know SavedModel didn't work in android. I think freezing is still the way to go there? I'm sorry, I don't personally work on the mobile side of things.

Did you try using SavedModel? It should be seamless to use downstream with tensorflow serving and it's not that hard to get estimators to spit those out.

You can read out more about it in the blog post ( https://research.googleblog.com/2017/10/eager-execution-impe... ) or the README ( https://github.com/tensorflow/tensorflow/tree/master/tensorf... ). This is still a preview release, so you may hit some rough edges.

Looking forward to your feedback as you try it out.

I write tests not to convince myself my code is correct (it often is, and repl and ad-hoc testing are more than enough to make sure it does the right thing now) but to prevent myself & future others from breaking it as they maintain it in the future.

The averaged perceptron is the one to which the proof applies :-)

Regarding the perceptron, most modern texts also have a regret analysis for the perceptron, which coupled with an online-to-batch conversion tells you how well do you expect a perceptron to perform on unseen data after a single pass, and it's usually a very good estimate (the answer is on average about as well as it did on the examples in the training data).

ML PhD student here. The reason why this is different is that the parallel monte carlo simulations are running on different subsets of the data in each machine, and then averaged.

It is not obvious that this can work at all in some cases. Think, for example, a clustering model. If there are two clusters, but one machine calls them A B and the other machine calls them B A, averaging will give you useless results.

So the contribution of this paper is finding a set of models on which naive averaging works, and showing an efficient mapreduce implementation of it.

That said, I don't find the paper particularly interesting.

Honestly, more people should use stabilizer http://plasma.cs.umass.edu/emery/stabilizer . The best can still be an outlier.

Fun fact: this is pretty much the same dynamic program as CKY, the parsing algorithm that can parse any context-free language in the appropriate normal form (only productions looking like A->BC or A->a) in time cubic on the length of the sentence.

The fallacy behind arguments like this is that when someone says that we're "proposing to push people to speak at conferences who aren't necessarily the most knowledgeable speakers" it is implicitly assumed that it is known how to rank the speakers, and that doing so is easy.

In practice, however, while one can often tell a really bad speaker and a really good speaker apart there are plenty of bordeline cases and the variance is big, so using minority-biased criteria to "break ties" will not necessarily lead to worse speakers on average, as long as these criteria are uncorrelated with actual skills.

(and I'm not sure they are, as the mean quality of a woman-presented talk in conferences I've attended has been consistently higher than the mean man-presented talk)

A foot a second is off by several orders of magnitude. It's closer to 300 thousand km per second in vacuum, and around 200 thousand km per second in fiber.

The above construction is a not a breakthrough and it is how I was taught in my approximate algorithms class. Also the way the optimization problem is usually defined is not as "give a circuit with minimal cost" but "what is the cost of the minimal-cost circuit?", which is easier to reason about in an approximate way.

A temp agency?

Regarding finding the higgs boson, regardless of whether you agree that it's what they're actually doing, the main people actually building the first quantum computer are D-Wave, a private company.

It's not about splitting the task into smaller pieces. It's about factoring out the parts of the task that need synchronization among all machines into one specific subroutine (groupBy) which makes mapreduce so powerful.

If you speak with people experienced in multithreaded and distributed programming you will see that synchronization with fault-tolerance is _hard_, and mapreduce provides a widely-applicable set of sufficient conditions for an algorithm to be executable with implicit fault-tolerance and implicit synchronization.

Without mapreduce-like abstractions eveyr piece of software has to be responsible for its own (1) checkpointing (to recover from errors), (2) checksumming (to ensure that no errors happened), and (3) distributed communication (to make sure the global state becomes global and the local state becomes local).

Mapreduce as a concept goes beyond lisp implementations. On the surface it might seem like the point of mapreduce is expressing computations in terms of map and reduce functions. It isn't.

The point of mapreduce is reducing the problem of high-throughput fault-tolerant distributed systems to a very efficient and reliable distributed sorting algorithm (the shuffle phase, which is implemented by the implementations of mapreduce and not by the user code). If you can express all synchronization in your algorithm in terms of sorting, then whatever you do before sorting (map) or after it (reduce) is kind of trivial, as the hard part is taken care of by the framework.

This abstraction is novel, and profoundly useful, and that's the point of mapreduce, not so much the actual map() and reduce() functions.

But using personally identifiable data for targeting (which facebook seems to be doing) is entirely different from doing personally identifiable targetting (which no one is doind). If all the information that leaves facebook servers is which ads to show then it's really difficult to argue that privacy is being breached.

I wonder if cheating could be entirely solved with machine learning like TrueSkill that matches you with people with similar performance. Then matching cheaters with cheaters is almost guaranteed to happen, and a bad player cheating a little can still be a good adversary.

Giving students close access to a program that evaluates essays many times would be the worst possible thing to do. People are generally very good at adapting to systems, and the algorithm would break down pretty quickly as people find out which factors it favors and which ones it penalises (while human graders are arguably less strict in their criteria and can hence recognize these attempts at writing to the letter).

It's actually a more subtle problem: if you test a radical redesign, there's a higher likelihood it will fail even if a subsequent series of small changes to it would have produced something better, just because the incumbent is so well optimized.