There is a nice simulation game where the goal is to kill all of humanity by evolving a disease:
https://play.google.com/store/apps/details?id=com.miniclip.p...
You can learn a thing or two about the problem space just by playing the game.
589 karma · joined May 22, 2012
https://play.google.com/store/apps/details?id=com.miniclip.p...
You can learn a thing or two about the problem space just by playing the game.
Note that belief revision and various kinds of paraconsistent logics in a way allow to work around the classical requirements for consistency.
Another really interesting related area is http://en.wikipedia.org/wiki/Modal_logic which allows you to reason about statements such as "I know that you know that I know that the sky is blue." and that can be used to analyze the coordinated attack problem (http://en.wikipedia.org/wiki/Two_Generals'_Problem) which is very much related to the http://en.wikipedia.org/wiki/Byzantine_fault_tolerance of distributed systems.
Subjects like that give you a firm grounding in the area of computer science but you could study them for ages especially on your own. These subjects are also not very practical in terms of everyday engineering and on top of that before you even get to that level, a top school would require you to study a bunch of mathematics to gain a certain level of rigor of your thinking. My guess is that this is hard to do on your own.
On the other hand, since you have a related degree already and since you know programming, I would heartily recommend you to study on your own combining two approaches: bottom-up to learn the basics and top-down to immediately start increasing your market value and to start opening doors and to keep yourself motivated to go forward with the more tedious study of the basics.
E.g. say you are interested in distributed systems - you can start reading up on them (top-down) while digressing here and there to learn some of the basics.
Make use of online resources like Coursera for the necessary basics (bottom-up): at least some maths heavy on proofs [1], at least some complexity theory, at least some graph theory, ....
I think a purely bottom-up approach (going to a university) could be a waste of time and money in your case. But you need to emulate it a bit because a purely top-down approach could be too superficial and wouldn't teach you some of the more rigorous thinking you might need.
Whatever you do and learn try to do it in-depth. Superficial knowledge of many things will not benefit you much in the long term while in-depth study of many computer science fields will likely lead you through a series of small enlightenments.
[1] My professor of linear algebra used to insist that we as computer scientists have to know all the proofs of the theorems we were learning - in contrast to mathematicians learning the same subject - simply because we have to know how things are done to the last detail and we have to develop that kind of thinking.
When investing you always have to consider the timeframe and risk you are willing to take. For example, for a long-term rather low risk investment you could buy an index fund - a fund that tries to replicate a market index such as S&P 500 - in that case you will know that your investment will do roughly as good as market does.
btw, I also use clicking the scroll-wheel to paste all the time
I've been looking into Rust during the past few days and I must say I got stuck on the memory model - all the different pointers and their interaction with ownership and mutability, closures capturing their environment (variables outside the closure in the scope where the closure is defined), reference binding, and then things like std::Cell which on the one hand seems to be an alternative to std::Option but on the other hand it's using some unsafe operations in its implementation to change mutability or something... It's quite confusing and it stopped me from writing a simple example application I wanted to write because I wanted to understand what's going on a bit better first.
It is a fun exercise to understand the theorem and its proof (and still probably easier than creating an actual quine).
For others: SDET: Software Development Engineer in Test
http://programmers.stackexchange.com/questions/44623/microso...
Or is she singing a whole song with vocal fry? http://www.youtube.com/watch?v=7ThRVUcmSa0 (Dream a Little Dream of Me)
Algorithms for updates of materialized views exist since at least 20 years but maybe they don't cover all these cases efficiently.
EDIT: there's also this Hacker News Contractors list as an editable google spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AlD_6iEb8Ed9dGs...
Datalog is really almost just a special syntax for Horn-clauses; it is purely declarative. Prolog is much more than that in that it adds features like cuts, arithmetic, built-in functions, and everything else that's needed in a practical programming language.
Also, a Prolog interpreter implements a sophisticated backward-chaining algorithm. So Prolog basically means backward-chaining. In comparison, I would say there is no default evaluation strategy for Datalog. You (resp. the interpreter) can use backward-chaining, forward-chaining, a combination of both (such as the magic-sets method) - the designer of the Datalog-based query language decides what's best.
I agree prolog is quite simple and nice but that is true mostly for the pure prolog subset. The actual programming language with cuts and all the complexity is not so simple anymore - it's not purely declarative (e.g. semantics of the program depends on the order of the clauses).
EDIT: it is Experian (a credit analysis company) that bought Prologia, the Prolog company that was founded by Alain Colmerauer, who designed and implemented the first version of Prolog.
http://www.experianplc.com/news/company-news/2005/25-10-2005...