I rencently read a book that touches on such social simulation - "An Introduction to Multiagent systems / Michael Wooldridge".
He mentions p.214-218 such a grid like social simulation that was done in the EOS project, undertaken at the University of Essex in the UK. The goal of the EOS project was to investigate the causes of the emergence of social complexity in Upper Palaeolithic France and they were using a 10000x10000 grid.
You could also be interested in "Simulating Societies using Distributed Artificial Intelligence / Jim Doran"
I wonder what is a good hardware setup for following this kind of course and seriously play with deep learning in general (outside of an enterprise context where the enterprise would provide the hardware). What kind of budget should be considered ?
Regarding YQL, I found this github repo - https://github.com/yql/yql-tables that seem to describe some of the external tables that used to be available through YQL.
"We started Asana because our co-founders experienced firsthand the growing problem of work about work. While at Facebook, they saw the coordination challenges the company faced as it scaled. Instead of spending time on work that generated results, they were spending time in status meetings and long email threads trying to figure out who was responsible for what. They recognized the pain of work about work was universal to teams that need to coordinate their work effectively to achieve their objectives. Yet there were no products in the market that adequately addressed this pain. As a result of that frustration, they were inspired to create Asana to solve this problem for the world’s teams."
I can only imagine that the complexity of the coordination inside Facebook continued to grow after Asana was created.
So is Facebook a client of Asana to solve this problem ? How does a company like Facebook handle the "coordination problem" ? Do they have one tool that solves all the issues or a myriad of project management tools ?
It is nice to see that CockroachDB's team keep their original vision of creating a long term open source "commons" of their database.
What I don't totally understand when I take my developer's hat is why the split between "enterprise" features under CCL and core features under APL/BSL is kept. Without the "enterprise" features, CRDB does not feel like beeing totally open source and open source users are sort of second-zone users.
Are open-source fans supposed to write clean-room implementations of the features (would it even make sense in the licencing model CRDB uses) ?
It would also be nice to have a licencing clause where a change of ownership of CockRoach Labs or the bailout of the company would trigger a licence change for the enterprise features (maybe even after N years).
But as I said congrats on the product and all the best in your commercial endeavour ! may this licence change open new cloud opportunities !