I understand your confusion, because the author didn't properly cover what he's talking about. It appears to be written to teach people who already know the material.
In the previous article, the closest thing to an explanation or definition of a loop invariant is, "We can make it less so by writing down a specific claim that applies to our particular loop. Such a claim is called a loop invariant." Not a very good description, and he doesn't try to do any better elsewhere.
I ended up having to do a bunch of googling after reading the articles to piece together what is trying to be explained, since I had never heard of loop invariants in that terminology either.
Simply put, a loop invariant is a condition or set of conditions that is true through the loop. This makes it akin to inductive proofs. The loop invariant must prove true for n and n+1 for it to be true for the entirety of the loop. Noting how similar this is to inductive reasoning, you can apply an inductive proof to a loop invariant to prove it.
The easiest way I've seen to explain it is in the body of the executing loop you ask yourself, "What has the loop done so far." An answer to that question should yield a loop invariant.
I think your thinking is right, machine learning is probably a good area as far as jobs go. Depending on your CS interests you'll find what areas of math they use most. AI / machine learning, learn lots of probability and statistics. High-performance, scientific computing, graphics, maybe more of a focus on linear algebra. Algorithms or theory or programming languages, lots of discrete math, logics, algebraic structures, etc. Of course it's good to get a good grasp of the basics of all these, since they're definitely not exclusive, and which you'll get from your degree, and beyond that, well explore, and enjoy!! Good luck!
It depends on what side of AI/ML you end up on, though. The research-heavy side involves lots of math and requires a PhD (or a MS + experience, in industry); the data engineering & infrastructure side is almost solely coding (and distributed systems design).
And even in machine learning, the vast majority of the work is in feature engineering, which is applying domain-specific knowledge (e.g. linguistics) to generate discriminative features.
You can only get paid for doing research on the mathematical side of ML if you work in academics or for e.g. Google. The rest will just use an off-the-shelf machine learning software.
Thanks for the comment. High performance and scientific computing jobs seem a lot rarer than AI / machine learning jobs, which is why I think the latter is a better choice for me (I have no preferences between those areas right now).
I'm also fairly interested to see how AI / machine learning develops in the future, and I think it will involve more math, so it definitely seems to be a good choice.
If there's "every reason to believe" it's the opposition forces and not the Syrian government in control of and using chemical weapons, what good does it do for the Syrian government to "place its chemical arsenal under international control"? How can these two statements be reconciled?
Putin says:
No one doubts that poison gas was used in Syria. But there is every reason to believe it was used not by the Syrian Army, but by opposition forces, to provoke intervention by their powerful foreign patrons, who would be siding with the fundamentalists.
Then later:
A new opportunity to avoid military action has emerged in the past few days. The United States, Russia and all members of the international community must take advantage of the Syrian government’s willingness to place its chemical arsenal under international control for subsequent destruction.
Maybe to satisfy the stupid Americans? I am not sure what you are getting at, offering up your chemical weapons when some country that can crush you is about to attack you because they suspect that you used them even if they don't provide any proof is not admitting guilt.
Its almost like you think people who plea guilty in court are actually always truly guilty.
I guess it must be a joke, but that's a fun review. "I accidently bought this book thinking I was buying a traditional calculus book in order to prepare for a standardized test I had to take. After a few chapters I realized this was no ordinary Calculus book."
There are two universal properties in the sense that a universal property is either defined in terms of a "terminal morphism" or (dually) an "initial morphism" (see the Formal Definition in the wiki article) -- the examples are particular instantiations of this general definition.
The way I like to think of it is that a large component of PL design is making something pleasant for humans to use, which is more of an art than a science: inherently subjective (not everyone likes the same things), holistic (it's not any one feature of Python that makes it Pythonic, it's the whole philosophy), and hard to quantify. So it's no surprise that rigorous design is not the prime factor in popularity of programming languages.
I don't think, however, that really explains why research languages these days have very little in common with popular languages - why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted. There are a few reasons why this might be the case (not just "FP is hard and most programmers aren't very good at programming", although that is one factor), but their sum seems to be something fundamental about software design - perhaps changeable, but identifiable as a unit, not simply a consequence of the limitations of rigorous design.
I don't think the divide between research and industry languages is as deep as you imply. Take your examples: purity and strict typing. Purity has been adopted wholesale by Clojure and has influenced C++11 (constexpr implies purity in addition to many other things). Go, the subject of the post, is stricter about type conversions than the C family languages are. Java's type-safe implementation of generics was influenced by ML.
> why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted.
I am guessing is it mainly due to the inertia of the current popular languages (C, C++, Java, Python, etc.), and that none of them offer such guarantees. There are tons of libraries written in them, and so it is hard to move away from them. I am hoping that Scala and Rust will change things.
Many great films are made on a fraction of the budget required to produce something like Toy Story. And anyway I don't think it's hard to imagine Pixar artists saying they were more motivated by the pure joy of creating something than by their paychecks. There are bad movies that are created specifically to be monetized -- that people need money is beside the point that often those who create the really good stuff are probably doing it more for fun than for money. I think I see what you're saying, but it seems like an overreaction to what didn't strike me as a controversial comment by the parent.
I skimmed documentation of Python after people told me it was fundametally similar to Lisp. My conclusion is that that is not so. When you start Lisp, it does `read', `eval', and `print', all of which are missing in Python.
Could someone explain what he means? (Did Python not have a repl when he wrote that?)
Python's read doesn't return a s-expression, nor does its print take one; they just use strings. It's eval likewise takes a string. The part missing that lisp has is the inspectable data structure containing an arbitrary parse tree and function result.
