I'm hesitant to bring this up since you seem much more informed about this topic, but your statement "Thuen admitted copying at least some components from 'Sophia'" seems to contradict Thuen's statement from the TechCrunch article:
"Visdom is not a translation of Sophia from C to the languages in which Visdom is written. We did not have the Sophia code when we created Visdom."
There was another reading list that I remember seeing, I think it was from Stanford's TCS website, but I no longer can find it.
Self-teaching is fun because you get to choose your own curriculum, but it's often frustrating too because if you get stuck, there is no professor or TA to unstick you. This issue can somewhat mitigated via the internet.
I've always thought that math books should in digraph rather than linear form. What would be interesting is to combine this with a wiki. You could have alternate proofs of the same lemma, or even entirely different presentations (starting from different axioms, for instance)
This article has way too many words and not enough math. There is, in fact, nothing scary about big O notation once you dissect it, and it's a shame that so many people seem to think otherwise.
Here's the definition: if f and g are functions (let's say real-valued functions defined on the positive reals), then we say that f is big O of g, written f = O(g), if there exists a real number y and a real number K, K > 0, such that
f(x) <= K * g(x)
for every x > y.
If that makes sense, then done.
Else:
The first thing to do when meeting any mathematical definition that you don't understand is to throw away parts of the definition until you do understand it, then add them back in one by one. In this case, let's forget about the constant.
New definition: For functions f, g, f is blorb of g, denoted f = blorb(g), if there is a y such that
f(x) <= g(x)
for every x > y.
"f is blorb of g" actually just means that there comes a point after which g is never smaller than f. This gives us the first ingredient of big O: we are concerned only with asymptotic behavior. f could take on immense values for small x and still be O(g) as long as f eventually becomes always smaller than g.
The reason for caring about asymptotic behavior is that we often don't care about the time complexity of an algorithm for very small problem sizes. Even the traveling salesman problem is solvable on Raspberry Pi for very small problem sizes.
Okay, I hope we understand the above definition. Now we add the constant back into the fold and see if we can make sense of it. From what I can see, the constant is there for computer scientists who want to paint with broader strokes. There can be a huge practical difference between f1(n) = 2n and f2(n) = 2000n (the difference between a computation taking a day and taking 3 years), but they're both O(n) because complexity theorists are more concerned with O(n^2) versus O(2^n) than they are with O(n) versus O(5n). (Also could be because in practice algorithms with wildly varying constant factors out in front are rarely seen?)
For an alternative to big O notation, you should check out Sedgewick and Wayne's Algorithms, 4th ed. They use something they call "tilde notation" which preserves the leading constant factor. (See: http://introcs.cs.princeton.edu/java/41analysis/)
It first clicked for me when reading Barr and Wells' Category Theory for Computing Science [0], but I don't know about your mathematical background. Category theory is algebra, so it's probably advisable to study basic group theory before tackling category theory. (I have a hard time seeing how functors make sense until you've understood the general concept of a homomorphism, which is perhaps easiest to do in the context of groups).
Instead of 5 swaps, I only do the first three (K/E, J/O, F/T). According to their scoring function, it gets you most of the way there anyways. (Whatever that's worth).
> Easy-to-use computer systems, as we conventionally understand them, are not what Engelbart had in mind. You might be surprised to learn that he regards today’s one-size-fits-all GUI as a tragic outcome. That paradigm, he said in a talk at Accelerating Change 2004, has crippled our effort to augment human capability. High-performance tasks require high-performance user interfaces specially designed for those tasks. Instead of making every task lie on the Procrustean bed of the standard GUI, we should be inventing new, task-appropriate interfaces. No, they won’t work for everyone. Yes, they’ll require effort to learn. But in every domain there are some experts who will invest that effort in order to achieve greater mastery. We need to do more to empower those people.
The above cites Engelbart's 2004 talk "Large-Scale Collective IQ", so that is probably a good place to look as well.
> Alan Kay: ... If you have ever seen anybody use NLS [Engelbart's 1968 hypertext system for which he invented the mouse and chord key set] it is really marvelous cause you're kindof flying along through the stuff several commands a second and there's a complete different sense of what it means to interact than you have today. I characterize what we have today as a wonderful bike with training wheels on that nobody knows they are on so nobody is trying to take them off. I just feel like we're way way behind where we could have been if it weren't for the way commercialization turned out.
I don't know how extensive Unicode math symbols are, but it's unclear to me how you would display things like matrices and do alignment of multiline equations.
It depends on the type of article. I write a lot of blog posts about math. The most convenient way to do this is using Mathjax. If browsers had native support for mathematical notation then I would be inclined to agree with you, but this is not currently the case.
I had an insight a few months back when I was looking at djb's website (http://cr.yp.to/djb.html). I was spending far too much time playing with toys (static site generators) and not enough time actually producing interesting content. Nobody cares about your pretty blog theme, they care about your ideas.
The hardware content in this book is not sufficiently detailed for computer engineering. It's really for CS students who want to understand roughly how computers are made. (This is evident by counting pages in the book: the first 5 chapters are the hardware chapters and they span only 100 pages. The remaining 200 pages cover the software stack from assembly up.)
For example, one of the assignments is to design a 16-bit adder in their toy HDL, but they never cover carry lookahead adders. The only thing that matters is that your circuit passes the tests, so ripple carry is considered okay.
Similar efficiency/performance issues are glossed over throughout. Propagation delay is never covered, and the sequential circuits use idealized clocks (instant transition between low and high). They also don't describe how to build up flip flops from latches: the D-Flip Flop is given as a primitive and you build up other elements from there.
K-maps are not covered either. Caches are ignored as well.
Still, the book is amazing for its intended purpose. If you don't already know this stuff, this is an easy way to get a somewhat detailed (though abstract) view of how computers work without getting mired in all the concerns that accompany the engineering of actual computers.
It sounds like you have a "fixed mindset" as opposed to a "growth mindset". You worry that you are not as skilled at X as you might like to be, but your focus should simply be consistently improving at X.
The y-offset at t=0 matters a little, but the magnitude of the slope dominates in the long run.
Unfortunately, the overwhelming majority of internships seem to be for current students, which means this advice is of limited utility for those who have already graduated.
It is my understanding that at top schools like MIT at Berkeley, EE and CS are actually combined into a single undergraduate degree.
e.g. "The Berkeley EECS major, offered through the College of Engineering (COE), combines fundamentals of computer science and electrical engineering in one major."
Please correct me if I'm misreading you here, but it appears that your "counter" is incorrect. The GP claims that (IP laws implies lack of innovation). You present a single example of (No IP laws & no innovation). However, the GP did not claim that a lack of IP laws is sufficient for innovation, only that it is necessary.
I don't understand the logic here. An "avid apple user" went with an Android phone despite the apparent strong emotional connection she has with the Apple experience. How is that not something to worry about?
"Visdom is not a translation of Sophia from C to the languages in which Visdom is written. We did not have the Sophia code when we created Visdom."
So I'm interested in what you mean by "copy".