It is interesting to compare this with 3Blue1Brown's linear algebra introduction on YouTube. He seems to have been the only mathematician who has actually mastered the medium; linear algebra lends itself very well to animations. The mathematicians don't understand how badly they need to animate some of these concepts.
Mathematicians and teachers aren't all computer programmers, so creating animations isn't their forte.
Books have pictures that do a pretty good job.
Animations are pretty and interestit but that isn't the same as teaching all the math.
my linear algebra professor began his first lecture with a 5 minute rant informally titled “how you could have gotten an A in differential equations last semester without ever having taken calculus”
That certainly got our attention. I’ve always found linear algebra to be kind of ... almost soothing.
It's ridiculous how much random college-level linear algebra textbook material I stared at before things clicked in the course of just jumping in and exploring 3D graphics and writing my own 3D vector, matrix multiplication and 3D transform headers and using them in making some games in plain C. At some point it's like "Wait, is linear algebra really just about heaps of multiplication and addition? Like every dimensi…
I guess a mathematician might look down upon sticking with 2d and 3d stuff because it leaves out all the interesting things that happen at 92382 or negative infinity. But yea, matrices are basically just a convenient way to write rows and rows of "ax + by + cz...". In linear algebra, you just do it so often, people made up their own syntax. And nothing can visualize it like transforming graphics, IMO. You don't even…
I think these are good examples, but to me "linear algebra thinking" lies in it's generality. For example, the derivative is a linear operator, so how do you write it down as a matrix? Google's PageRank is a solution of a matrix equation, what does that matrix represent? Etc.
Start with a container. M a Then add a way to put things in the container. a -> M a Then add a way to use the thing in the container. M a -> (a -> M b) -> M b
Well, you see, that's one of the problems... monad implementations don't have to be "containers", or at least not the way most people mean. This was one of the critical errors in many of the aforementioned "tutorials". IO, the quintessential monad, is not a container, for instance. (A nearly-exact parallel can be seen in the Iterator interface. You can describe it as "a thing that walks through a container presenting…
I wouldn't over-think it and over-describe it.
The "aha" realization that the "container" can be an ephemeral concept and not resident at run time can come later.
FWIW, I think of IO as a container: it contains the risk of side-effects within. All the examples you gave are containers in their own way.
It's ridiculous how much random college-level linear algebra textbook material I stared at before things clicked in the course of just jumping in and exploring 3D graphics and writing my own 3D vector, matrix multiplication and 3D transform headers and using them in making some games in plain C. At some point it's like "Wait, is linear algebra really just about heaps of multiplication and addition? Like every dimensi…
Is it the same issue as the infamous "monads tutorials" problem, where the understanding takes a lot of time to infuse but looks obvious in retrospect when it finally clicks?
LA is one of those topics that, to an extent, is built on a handful of core capabilities and concepts. Once you master those much of what follows are logical extensions or combinations of the previous. It goes on from there, but the value returned from the core material is wide reaching.
Another good Linear Algebra book is "Linear Algebra Done Right", which Springer is giving for free right now. Link: https://link.springer.com/book/10.1007/978-3-319-11080-6
Thanks for this -- do you know if there's a consolidated list anywhere of other books Springer is making available for free right now?
Well, you see, that's one of the problems... monad implementations don't have to be "containers", or at least not the way most people mean. This was one of the critical errors in many of the aforementioned "tutorials". IO, the quintessential monad, is not a container, for instance. (A nearly-exact parallel can be seen in the Iterator interface. You can describe it as "a thing that walks through a container presenting…
I wouldn't over-think it and over-describe it. The "aha" realization that the "container" can be an ephemeral concept and not resident at run time can come later. FWIW, I think of IO as a container: it contains the risk of side-effects within. All the examples you gave are containers in their own way.
The problem is telling people it's a container is "over describing" it. We don't need to hypothesize about that. We have the space suits and burritos to prove it is not a good didactic approach. It is not removing from the definition to simplify, it is adding to the definition, exactly as I carefully showed in my description of "Iterator". An Iterator is "a thing that presents a series of items". It does not simplify the discussion of Iterator to say "It's a thing that presents a series of items out of a container, but also, it doesn't have to be a container". It's not the first definition that's "overdescribing", it's the second.
It's ridiculous how much random college-level linear algebra textbook material I stared at before things clicked in the course of just jumping in and exploring 3D graphics and writing my own 3D vector, matrix multiplication and 3D transform headers and using them in making some games in plain C. At some point it's like "Wait, is linear algebra really just about heaps of multiplication and addition? Like every dimensi…
Do you have any recommendations on videos/tutorials with graphics stuff that would help me grasp some of the linear algebra and basics about 2D/3D graphics? Your comment about 'staring at random college-level linear algebra' stuff resonated deeply with me, and I've always felt like I'm just not understanding how it all connects.
I wouldn't over-think it and over-describe it. The "aha" realization that the "container" can be an ephemeral concept and not resident at run time can come later. FWIW, I think of IO as a container: it contains the risk of side-effects within. All the examples you gave are containers in their own way.
The problem is telling people it's a container is "over describing" it. We don't need to hypothesize about that. We have the space suits and burritos to prove it is not a good didactic approach. It is not removing from the definition to simplify, it is adding to the definition, exactly as I carefully showed in my description of "Iterator". An Iterator is "a thing that presents a series of items". It does not simplify…
Containers make sense.
Abstract computer science doesn't.
Part of why Haskell appears like such an implacable curmudgeon is the predilection of its community to believe that users must grasp type and logic theory to use it.
They don't.
Just like they don't need to have a mental model of their computer to write software for it.
I wouldn't over-think it and over-describe it. The "aha" realization that the "container" can be an ephemeral concept and not resident at run time can come later. FWIW, I think of IO as a container: it contains the risk of side-effects within. All the examples you gave are containers in their own way.
The problem is telling people it's a container is "over describing" it. We don't need to hypothesize about that. We have the space suits and burritos to prove it is not a good didactic approach. It is not removing from the definition to simplify, it is adding to the definition, exactly as I carefully showed in my description of "Iterator". An Iterator is "a thing that presents a series of items". It does not simplify…
I'll just point out that neither of you have managed to really take a single step towards actually explaining monads.