Hacker News Reader

Comment by Koshkin | Hacker News Reader

More specifically, this is about “reimagining matrices in the context of a pure functional language.” To be honest, as much as I appreciate the functional paradigm, I have been haunted by the impression that trying to apply it to some things makes them unnecessary complicated. Speaking of matrices, their “first principles” come from solving systems of linear equations; the (abstract) linear algebra reduces their role to being mere representations of linear maps in a given basis, which makes matrices look like some sort of technicality and thus hides their intrinsic beauty, complexity, and huge importance in their own right.

View on HN

How are matrices important in their own right besides as representations of linear maps (taking that to mean module homomorphisms)?

Funny enough a couple years back I implemented matrices as representations of linear maps for fun (I think I fixed the dimension to 3. I don't remember whether being generic on dimension makes it more complicated), and while that's not going to win any awards for performance, I found that it's the exact opposite of unnecessarily complicated: a "matrix" is just a way to "print"/serialize a function as an array of its values on a basis, addition is literally `f + g = x -> f(x) + g(x)` and multiplication is literally `f * g = x -> f(g(x))`. The code almost writes itself.

Don't forget duality. A matrix can represent a linear map (or, if you prefer, a module homomorphism) but if you think of it as a map from V to W* instead of to W, it represents instead a bilinear form on VxW.

And of course an array doesn't need to be a matrix, and there are many many purposes for which a rectangular array of numbers is a useful thing to have. (I don't know whether those purposes are relevant to the OP, because at the moment what the OP says is "Error establishing a database connection".)

There are also kinda-intermediate situations. Consider linear least-squares regression. You have a bunch of things that at first sight are mere arrays. Let's say you're trying to predict house prices on the basis of floor areas, bedroom counts, and average income in the area, so you have a big array: one row per house, one column for each of those quantities. Call this A. You reckon the house price might be well predicted by some sort of low-order polynomial thing, so you build another array, also one row per house, with columns containing things like "floor area times average income squared". Call this one D. And you know the actual prices of the houses, which you put in a column vector, again one row per house. Call this v. On the face of it, none of these things looks much like a linear map, but it turns out that linear least-squares regression is just linear algebra and e.g. the regression coefficients are computed as (Dt D)^-1 Dt v where Dt is the transpose of D (though in practice you shouldn't just literally do that calculation).

(Of course you can interpret these things as linear maps on vector spaces. That's not a bad way to organize the proof that the regression coefficients are what I said they are. But e.g. I don't think there's any particular significance to the linear map represented by Dt.D, or to the vector Dt.v .)

> Don't forget duality. A matrix can represent a linear map (or, if you prefer, a module homomorphism) but if you think of it as a map from V to W* instead of to W, it represents instead a bilinear form on VxW.

Okay, but why does that need a matrix to conceptualize? Given any linear map L: V → W, and another map φ: W → W* (which is equivalent to assuming a basis for W*, i.e. what you're doing when treating L as a map from V to W* instead of to W), then you can construct a bilinear form 〈v,w〉 = L(v)φ(w).

You don't need matrices to conceptualize these things, you need them to represent them for purposes of calculation. If you want to do calculations on linear maps V -> W, you usually do it with matrices. And if you want to do calculations on bilinear forms on VxW, you also usually do it with matrices.

> A matrix can represent a linear map (or, if you prefer, a module homomorphism) but if you think of it as a map from V to W* instead of to W, it represents instead a bilinear form on VxW.

If you mean that it's also a bunch of other things like an element of V* tensor W or a linear form on V tensor W*, and none of these are the most "natural"/better than the others, then I guess that's true. Matrices still seem like the least natural to me though.

For your least squares example, on the face of it it's not linear until you choose to use a linear least squares model :)

It's been a decade or so since I've thought much about this stuff, so I'm not highly confident in this answer, but I think the reasoning goes something like this:

You're trying to solve f(x)=y, but the problem is y is outside of the image of f. The next best thing is to say you at least want <f(x'),f(x)> = <f(x'),y> for all x'. i.e. f(x)=y up to dot products with all possible test vectors in the image of f, which forces their projections onto im(f) to be equal. Then <x',ft(f(x))> = <x',ft(y)> for all x', so ft(f(x))=ft(y), or x = (ft f)^-1 ft y.

It's not obvious to me that this minimizes the square norm of f(x)-y, (or that (ft f) is necessarily invertible) but I guess the point is that that the only nonzero part is in the orthogonal complement of im(f), so you can't do any better.

> How are matrices important in their own right besides as representations of linear maps

they can also represent groups

So then there must be some isomorphism between linear maps and groups?

Making it too slow for production use is one hell of a complication.

Simple, obviously correct implementations that mirror the problem definition are super useful for tests though! Write both, and then you can property test that the two implementations produce the same outputs on random inputs.

Reply on news.ycombinator.com