Show newer

Okay, so I figured this part out: a matrix multiplied by its transposition is a covariance matrix. By which I mean: the higher the value in a given (row, col), the more data in those axes were correlated.

en.wikipedia.org/wiki/Covarian

To simplify, consider a 3x3 matrix `A` and multiply `A` by `transpose(A)`.

What each cell of the result is telling you is how likely it is that when you change the value on the row axis, the value on the column axis changes the same way. So the diagonal will always be large, because data on an axis will always correlate with itself (i.e. when you change the value of `x`, the value of `x` changes in *exactly* the same way, `x*x = x^2`), but cell 0,2, for example, tells you how much changing x causes z to change the same way (if it's the same value as cell 0,0, then the points lie on a diagonal in the xz-plane: changing `x` causes the exact same change in `z`).

I still need to cogitate a bit on why the eigenvector with the largest eigenvalue of this matrix is the axis along which the data has the highest variance in the original coordinate space.

Show thread

Hey lazymastodon, I have a linear algebra question.

So I've been thinking a bit about principle component analysis as of late. The way to find the vector of most variance in a multidimensional dataset is to put every datapoint in a column matrix, multiply that matrix by its transpose, and find the eigenvectors of the resulting square matrix.

Here's my question: I don't have a good intuition for what "multiply the matrix by its transpose" is doing. That compares every point to every other point by multiplying the same-dimension components together and summing the result across dimensions, but like... Why does that result in an interesting matrix instead of a pile of noise?

Election day in the US.

It's indicative I think of the modern nature of social interaction that I meet more of my geographic neighbors working the polls than I do any other day of the year.

They're all fine and lovely people, but we spend our lives living next to each other and commuting to thousands of different places to spend most of our waking time.

Hi there. Please if you see this toot boost for helping our new Trans Safety Network instance federate across the 'verse.

Oop, looks like I've been out of the C++ game for long enough that I forgot some fundamentals. ;)

CoderPad does support `unique_ptr`; you have to ` <memory>` to pull it in because C++'s std lib is carved up into a bunch of smaller headers.

It's been awhile!

Show thread

Anyone familiar with the CoderPad environment:

Is there anything special one must do to access `std::unique_ptr`? I'd expect that to be available but it seems to be missing from their C++ environment.

Hypothetically speaking, I can see no obvious reason copyright law cannot be extended to exclude from "fair use" the injection of images into a machine learning engine without consent of the copyright owner of the image.

This will need to be done carefully, because if the goal is to throw a wrench into Stable Diffusion and its siblings, that wrench can easily ping-pong into e.g. banning Google from creating ContentID fingerprints to protect artists from copyright abuse. Some specific dimensions to pin down:

- what is a machine learning engine?

- what does it mean to train one on an artist's work?

- what does 'consent' look like? How explicit must it be?

Implementation will be messy but it's always messy; this is copyright, there's no other kind of implementation of copyright. "...other nations have thought that these monopolies produce more embarrassment than advantage to society" (Thomas Jefferson). But it may be a good idea if we have no alternative that protects the livelihoods of artists in a world where everyone is now a mediocre visual artist.

... And, of course, US copyright law has no bearing on China's law. Nor Russia. Nor dozens of other countries. So we would have to be prepared for our entertainment industries paying top-dollar for human labor competing on the international stage with a sea of mediocre artists that cost electrons and little else.

General thought:

I fear the possibility GraphQL is a trap. I think, in principle, it's a good idea. In practice, I'm concerned that pretending one can offer a pretty flat access to the underlying data in a backend store ignores some irreducible complexity in the question of data storage and retrieval.

How easy is it, in general, to build a GraphQL query that is expensive to answer because it skips all the indexes the backing database supports? I don't know; I've only worked with one or two GraphQL APIs. But one advantage to REST and RPC is that since you have to be intentional about creating new procedures or new resources, you have to be intentional about creating indexes.

Can modern DB engines compute those indexes based on usage patterns or is it still a very manual process?

I think full-stack engineers consistently underestimate the benefit of the entire stack being in as few programming languages as possible.

Fortunately, now that TypeScript exists that doesn't place an onerous burden on the backend architecture.

Followup on previous thoughts.

When I speak of "Test-driven development," I'm usually thinking of unit tests and integration tests. I think building those out before you have a concrete implementation tends to be putting the cart before the horse. They're most useful as regression tests to make sure you haven't broken something important when you make changes in the future.

Test-driven development can be quite valuable for end-to-end tests if you can get the client to agree on what the software is supposed to do in the form of a walkthrough of the behavior. I still tend to put this alongside or slightly after the initial design (most clients I work with aren't abstract system thinkers, so it's real hard to get them to understand a design they can't see and touch), but getting the client to agree that their initial ask matches to a test script of the form "User goes to A, clicks B, enters C, should see D happen" is a form of test-driven development when you implement a program to satisfy that script.

... but I still tend to keep that script hand-written before wasting the cycles on automating it in code.

Broadly speaking, a few principles guide my software engineering these days:

* Automated tests: Great, must-have, let you make guarantees about what your software will do, write them and have them.

* User stories: Great, must-have, make sure you're writing the correct thing, make them and implement to them

* Test-driven design: Terrible, big waste of time, borderline anti-human practice, assumes omniscience. Don't stress about this; just write code.

The story of College Technology University part 2, where plans are slightly derailed because people are involved. personal-blog.fixermark.com/po

It's weird / funny to me how comfortable I've gotten in TypeScript, to the point that I prefer it over Java consistently. Not an outcome I would have predicted, but Microsoft does have a knack for building and maintaining good languages.

It's the hundred little things, like the fact that TypeScript constructors are (a) named "constructor" (one fewer thing to change in a refactor that renames the class) and (b) have a syntactic shortcut for passing in arguments that do nothing but get retained in the object state. Every time I write Java and I have to pass in a Foo named 'f' so I can write 'foo=f' in the constructor body, I die a little inside.

Mark's principle of sufficient comments: Any meta-programming demands comments to demonstrate how to use it in the language you are meta-programming on top of.

Show older
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.