I think there cannot be an objectively most correct punishment for a given crime. The closest we could maybe get is "undo the harm that you have caused", but some harm cannot be undone.

Hence morality and ethics, I guess.

Right, and that's the point.

The law isn't a moral benchmark, because morality shifts over time, both for what constitutes a crime, and what constitutes appropriate punishment. At various points in time, it's been legal to own slaves, illegal to be homosexual, and illegal for certain groups to vote (and I consider voting at all to be a subset of this); those laws (and ideas) were eventually updated, largely on moral grounds.

Similarly, most western countries no longer execute criminals.

But those ideas aren't universal, even today. Assuming that they are is imo, extraordinarily foolish, because there's ample evidence to show that they're not.

Re: Max dimensions: You can truncate your input vector specifically for the index, and then when querying, you can query the index via a truncated vector and perform an additional full-length comparison as well.

For example: (taken from a project I'm currently working on)

```

SELECT *

FROM report_embeddings a

INNER JOIN report_embeddings b

    ON (

        subvector(a.embedding, 1, 768)::vector(768) <-> 

subvector(b.embedding, 1, 768)::vector(768)

    ) < $1

    AND b.id != a.id

WHERE a.id = $2

    AND a.embedding <-> b.embedding < $1

```

In this example, I truncate the embedding to 768 dimensions for the index and the lookup, (see the INNER JOIN) but do an additional full vector comparison as well. (in the WHERE clause)

This performs a fast but less accurate lookup into the index, and then only does the non-indexed full vector check for the matched results.

That’s only going to work on an MRL embedding.

Also works fairly well for Hadamard-rotated embeddings, as demonstrated here: https://embeddings.info/

The police are like vampires. So long as you don't invite them, they can't come in. (with some exceptions of course, but that's not as pithy)

It's not that it's optimized away, it's that the authors have done a bad job translating their pseudo code into Rust etc.

In Rust, if you do not `await` a future, it does not run - so in their example where only C is printed, they must have translated this into some Rust code that does not await the call to print AB.

This is simply not something you would ever do in real life, and in fact the Rust compiler emits a warning if you create a future but do not await it.

A more "correct" approach would be to call `tokio::spawn` with the future to print AB. This would result in AB always being printed, usually in the order ACB, but with no hard guarantees on that order because of the semantics of the `sleep` call. (specifically, it will wait at least the amount of time specified, but possibly more)