One of the key value is that it forces some thinking about what is the task you want to solve in the first place. In many cases, it is difficult if not impossible to do it, which implies the underlying product should not be built at all. But nobody wants to hear that.

Doing eval only makes sense if making the product better impacts something the business cares about, which is very difficult to do in practice.

Concretely, managing 12 ICs on a well defined platform team w/ a single PM is much easier than managing 6 people working across 6 businesses, as is more common when managing a team of data scientists.

My sense is that unless actively managed against, any org big enough to have a financial department and financial planning will work under assumption of fungibility.

Concretely, it made distributing OSS VST plugins a pain. Especially for Linux which generally will want to build their packages.

But MCP has at least 2 advantages over cli tools

- Tool calling LLM combined w/ structured output is easier to implement as MCP than CLI for complex interactions IMO.

- It is more natural to hold state between tool calls in an MCP server than with a CLI.

When I read the OT, I initially wondered if I indeed bought into the hype. But then I realized that the small demo I built recently to learn about MCP (https://github.com/cournape/text2synth) would have been more difficult to build as a cli. And I think the demo is representative of neat usages of MCP.

E.g. according to https://www.samdumitriu.com/p/infrastructure-costs-nuclear-e..., UK/US is ~10 millions GBP, France ~4.5, and China/Korea/Japan around 2.5.

I don't know much about nuclear plan, but I doubt UK are much safer in practice than French ones, or even Korean/Japanese ones. I suspect most of the cost difference across countries of similar development to be mostly regulation. And it is a nice example that sometimes EU can be better than the US at regulations :) (I don't know how much nuclear-related regulations are EU vs nation-based though).

Another minor inconvenience is that it is memory hungry for large libraries. In my case, for ~1 TB of flac, the docker takes 5-6 GB RAM on my debian NAS. Limiting it at 4 GB definitely crashed w/ OOM, at 8Gb never had issue.

The ELI5 explanation of floating point: they approximately give you the same accuracy (in terms of bits) independently of the scale. Whether your number if much below 1, around 1, or much above 1, you can expect to have as much precision in the leading bits.

This is the key property, but internalizing it is difficult.

While not OSS, roon 1) can run on linux 2) supports large local libraries (I have > 2k albums in FLAC, and it supports much more) 3) have roon arc that allows you to listen from phone anywhere 4) has a very good system to link metadata and recommendation within your library.

The metadata support is truly wonderful, you can easily browse your music like wikipedia, can find music per composer, performer, discover related musicians, etc. I strongly recommend people serious about music to try it out.

I've happily replaced spotify with it a few years ago, and will never go back.

[edit] I should have said "basic big O complexity" makes assumptions that break down. You can ofc decide to model memory access as part of "big O" which is a mathematical model

This is what differentiates python from other "morally equivalent" scripting languages.

What made sense to me is to start from the definition of derivative (the best linear approximation in some sense), and then everything else is about how to represent this. vectors, matrices, etc. are all vectors in the appropriate vector space, the derivative is always the same form in a functional form, etc.

E.g. you want the derivative of f(M) ? Just write f(M+h) - f(M), and then look for the terms in h / h^2 / etc. Apply chain rules / etc. for more complicated cases. This is IMO a much better way to learn about this.

As for notation, you use vec/kronecker product for complicated cases: https://janmagnus.nl/papers/JRM093.pdf

It may be explained by integer vs float performance, though I am too lazy to investigate. A weak data point, using a matrix product of N=6000 matrix by itself on numpy:

  - SER 8 8745, linux: 280 ms -> 1.53 Tflops (single prec)
  - my m2 macbook air: it is ~180ms ms -> ~2.4 Tflops (single prec)

Once it became clear Nazi were about to be defeated, there were discussions from the scientists about sharing the knowledge w/ all countries. But at that point, the scientists had long lost control over the project.

Taking examples I am familiar w/, it is key that you can add a scalar 1 to a rank 2 array in numpy/matllab without having to explicitly create a rank 2 array of 1s, and numpy somehow generalizes that (broadcasting). I understand other array programming languages have more advanced/generic versions of broadcasting, but I am not super familiar w/ them

Like any advice, it is contextual. Especially when working for large organizations, the OT is the right default. If you're leaving because things are bad, it will be a mix of 1) people know but did not care/could not do anything about it and 2) people did not know about specific issues. Younger me thought it was often 2), but actually it is almost always 1).