You are quoting the lab which is all about doing stuff in numpy. Probably if you want to critique the definitions used you should switch to the book.
That said, it doesn't lead with a notion of vector that is as general as I'd like. Readers might be later surprised to find that there are vectors which are not lists of numbers. But I only looked at the first few pages so I assume the vector space axioms show up eventually.
I find it very disrespectful towards a project with such popularity to contributors ratio.
It takes long hours to produce a working notebook, a synergy between concept descriptions and theorical explanations alongside code, comments of code and markdown for the theory here and there is an artistic coupled with engineering stunt you should try to accomplish yourself before criticizing. Perhaps you have, in which case a contribution as the other comment points out is the courteous thing to do.
That book must have taken months to author and is one of the best read on the subject I've ever come across.
Edit: removed incorrect fact about scalars.. they don't have a direction they have polarity.
Readers might be later surprised to find that there are vectors which are not lists of numbers
I see this sort of thing as being similar to how physics is taught. Year 1: Atoms are indivisible. Year 2: Well, no, actually, we lied, they consist of elementary particles called electrons, protons, and neutrons. Year 3: Well, technically the protons and neutrons aren't indivisible either. ... Year 10: OK, fine, we have no idea. Your turn, help us figure this out.
Nobody starts rambling about quarks and gluons in grade school, and few practitioners will ever need to deal with them at all. Likewise, for most people looking to get their feet wet in ML, vectors are a 1D list of numbers, matrices are a 2D list of numbers, and tensors are lists of numbers with any number of dimensions. Definitions that are incomplete at best, but good enough to get started.
I tried to build intuition before going into the formal definitions.
Personally, I've always liked Bourbaki's books, but they're too formal for learning - especially in linear algebra, which I see as something meant for applications rather than pure math research.
Maybe I just oversimplified things or made them feel less "math".
And precisely this is the risk of teaching "mathematics" using a programming language. Unfortunately, I think quite a few people don't actually know the abstract mathematical definitions and use concrete implementations as definitions in their heads in the first place.
At least using a theorem prover would get you closer to doing actual maths and proving.
It's probably more accurate to say courses like these teach mechanics/calculation more than they teach the theory.
There are already an uncountable number of linear algebra textbooks on the market. This is not meant to be a formal math textbook, but is instead aimed at those looking to pick up practical application-level insights and skills. (The "Why this matters" sections in the book are a worthy improvement on the state of the learning art by themselves, IMHO.)
This collection of lab exercises seems far better suited to the purpose than the abstract proof-based resources that some of you seem to have in mind. Fortunately, those resources are still available to those who want to go further into the theory.
And if you feel you have something to add to linear-algebra pedagogy yourself, well... what's stopping you?
>A vector has:
>A symbol (we might call it v, w, or even →AB in geometry).
>Components (the individual numbers, like 2 and 3 in [2, 3]).
>An arrow picture (a geometric way to see the vector as a directed line segment).
None of these are properties of all vectors. They are properties of how vectors are represented in numpy.