tristanz

Having started companies in both 2000 and 2012, I just don't think this is true. It was easy to put something in front of users in 2000 for less than $1000. We started with a $20/month shared host, PHP and MySql, and easily scaled to hundreds of thousands of users just by renting some dedicated machines. Google, Yahoo, ViaWeb, Facebook, and Ebay all started the same way. Yes, there were crazy $2M funded startups that bought Sun hardware and Oracle software, but this was absolutely not required.

Many parts of startups today are harder. Users' expectations for design and functionality is much higher. The internet was also much smaller in 2000, which made startups like Google possible.

The explosion in seed deals seems much more driven by the funding landscape, the rise of mobile and the social web, and cultural recognition of startups like Facebook.

Are these feature plans documented somewhere? Private networks, in the spirit of EC2 security groups or VPCs, would help simplify many distributed computing scenarios where securing services with passwords isn't an option.

Definitely a big need for this stuff. Nice job!

Another approach that uses WebGL only and scales to billions of linked points at 50fps is the inMems project by the Stanford Visualization Group: http://vis.stanford.edu/papers/immens. The key idea there is binning and data tiles.

Is there a hard dependency on WebCL? I believe the Chrome team recently said they have no existing plans to adopt it.

Some of the best advanced statistical visualizations I've seen are by Theory: http://theory.info/visuals.

Bayes Theorem can be implemented as an if statement:

  posterior = []
  [observables, unknowns] = simulate_from_model(priors)
  if observables == observed
     posterior.push(unknowns)

posterior now includes random draws from the posterior p(unknowns|observed).

This is my favorite explanation of Bayes statistics since it implements Bayes Theorem without math. It also is the underlying intuition behind the probabilistic programming approach to Bayesian statistics. Rubin (1984) has a great explanation: https://twitter.com/tristanzajonc/status/325120025428119552

One thing that's not entirely clear from the article is that probabilistic programming is Bayesian modeling and inference. Probabilistic programming isn't a new machine learning technique it's a more flexible way to do Bayesian statistics.

The new term "probabilistic programming" stems from the recognition that stochastic programs can be automatically interpreted as defining a joint probability model and Bayesian inference on this model equates to sampling execution traces that are consistent with the observed data. This is an extremely powerful idea. It enables one to quickly build and compose both the standard Bayesian models you'd find in textbooks, and innovate easily to build new models tailored to particular application domains, often by composing more standard models with more exotic ones. Probabilistic programming provides a natural way to specify these complex models and has the potential to hide the computational difficulties that plague applied Bayesian modeling.

Making all this practical is the real challenge. Performant sampling of execution traces for a broad class of models is an unsolved problem, which is part of the motivation for DARPA's new project.

For those interested in this area, we're working on one effort alone these lines at Sense: https://www.senseplatform.com.

While the line isn't sharp, I would distinguish somewhat between older BUGS like languages, where the underlying analogy is typically a directed graph, and more recent probabilistic programming languages like Church, where the underlying analogy is an execution trace. The excitement around this newer form of probabilistic programming comes from the fact that they really are programming languages. Unlike BUGS, they inherit all the flexibility, composability, and encapsulation of the underlying language. Inference is viewed as sampling execution traces, so the connection with a programming language is quite tight.

The notational part of this debate is definitely not agreed upon. Andrew Gelman and Christian Robert both argue for p(data|H_0) in comments on those blog posts.

This is exciting for Hinton I'm sure, but also somewhat worrying for broader community. Hinton has always been very open with his research:

http://www.nytimes.com/2012/11/24/science/scientists-see-adv...

One of the most striking aspects of the research led by Dr. Hinton is that it has taken place largely without the patent restrictions and bitter infighting over intellectual property that characterize high-technology fields.

“We decided early on not to make money out of this, but just to sort of spread it to infect everybody,” he said. “These companies are terribly pleased with this.”

It's rather pedantic in this context, but "probability 0" and "impossible" actually aren't the same thing:

http://nolaymanleftbehind.wordpress.com/2011/07/13/the-diffe...

On the denormalization front, is it possible to do transactions without locking / syncing the entire tree. I'm thinking friendship modeling like:

  user1.friends = ['user2']
  user2.friends = ['user1']

In the top example blurCallback references the current $scope object, which is a powerful feature of AngularJS that helps keep things modular. In the second you are referencing a global blurCallback function, which is definitely a bad idea.

If you're talking about the general idea of binding events in HTML, they are the same, but combined with Angular's design the choice has a lot of advantages. From the docs (http://docs.angularjs.org/guide/concepts):

"The separation of the controller and the view is important because:

1. The controller is written in JavaScript. JavaScript is imperative. Imperative is a good fit for specifying application behavior. The controller should not contain any rendering information (DOM references or HTML fragments).

2. The view template is written in HTML. HTML is declarative. Declarative is a good fit for specifying UI. The View should not contain any behavior.

3. Since the controller is unaware of the view, there could be many views for the same controller. This is important for re-skinning, device specific views (i.e. mobile vs desktop), and testability."

Google described their process here:

http://static.googleusercontent.com/external_content/untrust...