ActivePattern

That take’s outdated. In the US/EU, routine antibiotics in fish farming are banned [1]. Growth hormones aren’t used in edible fish. Farmed salmon’s feed changed (more plant oils), but it still delivers high omega-3s and usually less mercury than wild [2].

[1] FDA “Approved Drugs for Use in Aquaculture” — https://www.fda.gov/media/80297/download

[2] Jensen et al., Nutrients 2020 — https://doi.org/10.3390/nu12123665

On the contrary, farmed fish is among the most sustainable protein sources for those not willing to go full vegetarian [1]

[1] https://ourworldindata.org/grapher/ghg-per-protein-poore

Hah, why don't you try implementing your 3 little functions and see how smart your "AGI" turns out.

> not a particularly capable AGI

Maybe the word AGI doesn't mean what you think it means...

I don't think you've understood the paper.

- There are no experts. The outputs are approximating random samples from the distribution.

- There is no latent diffusion going on. It's using convolutions similar to a GAN.

- At inference time, you select ahead-of-time the sample index, so you don't discard any computations.

It doesn't play nice with a lot of popular Python libraries. In particular, many popular Python libraries (NumPy, Pandas, TensorFlow, etc.) rely on CPython’s C API which can cause issues.

Smalltalk JITs make p x * 2 fast by speculating on types and inserting guards, not by skipping semantics. Python JITs do the same (e.g. PyPy), but Python’s dynamic features (like __getattribute__, unbounded ints, C-API hooks) make that harder and costlier to optimize away.

You get real speed in Python by narrowing the semantics (e.g. via NumPy, Numba, or Cython) not by hoping the compiler outsmarts the language.

A “sufficiently smart compiler” can’t legally skip Python’s semantics.

In Python, p.x * 2 means dynamic lookup, possible descriptors, big-int overflow checks, etc. A compiler can drop that only if it proves they don’t matter or speculates and adds guards—which is still overhead. That’s why Python is slower on scalar hot loops: not because it’s interpreted, but because its dynamic contract must be honored.

Ironically, this comment reads like it was generated from a Transformer (ChatGPT to be specific)

It's a OpenAI researcher that's worked on some of their most successful projects, and I think the criticism in his X thread is very clear.

Systems that can learn to play Atari efficiently are exploiting the fact that the solutions to each game are simple to encode (compared to real world problems). Furthermore, you can nudge them towards those solutions using tricks that don't generalize to the real world.

I am quite confident that an LLM will never beat a top chess engine like Stockfish. An LLM is a generalist -- it contains a lot of world knowledge, and nearly all of it is completely irrelevant to chess. Stockfish is a specialist tuned specifically to chess, and hence able to spend its FLOPs much more efficiently towards finding the best move.

The most promising approach would be tune a reasoning LLM on chess via reinforcement learning, but fundamentally, the way an LLM reasons (i.e. outputting a stream of language tokens) is so much more inefficient than the way a chess engine reasons (direct search of the game tree).

I don't think that bidding system really works. If one side is strongly favored in the opening, the optimal bid would be essentially 0.4999999999... so that you can pick the color and win the game by a slim margin. Players then increase the bid with tiny steps ad infinitum.

The other idea works but is essentially just discarding all of the lopsided starting positions, in which case they might as well not be in the game.

Wouldn't the extra stamina have been rewarded, assuming creatine allowed you to perform extra repetitions? All exercises were done to repetition maximum.

The study seems to have controlled for training intensity -- all exercises were done to repetition maximum.

If you read the study, you can see that they controlled for training intensity. All exercises were done to repetition maximum.

Yes, that appears to be another good solution to the castling trickiness! And probably how you assume castling works in Chess960 if you weren't given the rules.

The idea of an asymmetric Chess starting position is very interesting, although it does introduce more risk of one side starting with a big advantage (perhaps this has been analyzed).

I also like that in this variant, castling works like normal -- that is one of the most unintuitive aspects of Chess960.

Who chooses the "correct" use of words? Is it you? Wikipedia disagrees with you: https://en.wikipedia.org/wiki/Gross_margin. Maybe you should make your own encyclopedia.

The answer will likely match what the reasoning steps bring it to, but that doesn’t mean the computations by the LLM to get that answer are necessarily approximated by the outputted reasoning steps. E.g. you might have an LLM that is trained on many examples of Shakespearean text. If you ask it who the author of a given text is, it might give some more detailed rationale for why it is Shakepeare, when the real answer is “I have a large prior for Shakespeare”.

Just want to note that this simple “mimicry” of mistakes seen in the training text can be mitigated to some degree by reinforcement learning (e.g. RLHF), such that the LLM is tuned toward giving responses that are “good” (helpful, honest, harmless, etc…) according to some reward function.

Doing a single modulo 9 operation is much faster than summing a d-digit number, which requires d modulo 10s, d divide 10s, and d sums.

I'm simply pointing out the limitations of LLMs as code writers. Hybrid systems like ChatGPT-o1 that augment LLMs with tools like Python interpreters certainly have the potential to improve their performance. I am in full agreement!

It is worth noting that even ChatGPT-o1 doesn't seem capable of finding this code optimization, despite having access to a Python interpreter.

Because otherwise we are talking about LLMs augmented with external tools (i.e. Python interpreters). My original comment was pointing to the limitations of LLMs in writing code by themselves.

I suspect that it would be unlikely to come up with it because it requires execution of a fairly lengthy algorithm (or sophisticated mathematical reasoning) to find the smallest/largest valid numbers in the range. You can verify this for yourself with the following ChatGPT prompt: "What is the smallest number in the range (1, 100000) whose digits sum to 30? Do not execute separate code."

Correct, this optimization no longer works when you change the problem.

This is actually a great example of an optimization that would be extremely difficult for an LLM to find. It requires a separate computation to find the smallest /largest numbers in the range with digits summing to 30. Hence, an LLM is unlikely to be able to generate them accurately on-the-fly.

I've observed this with ChatGPT. It seems to be trained to minimize changes to code earlier in the conversation history. This is helpful in many cases since it's easier to track what it's changed. The downside is that it tends to never overhaul the approach when necessary.

The bot has a point...

Yeah, it does demonstrate that you can use compression to measure similarity of two images.

But it also demonstrates that it's a pretty poor similarity measure. Something as simple as counting % of matches between the black and white pixels performs much better.

The goal is to have Mojo be fully compatible with Python, so that you should eventually have access to all of the libraries offered in Python. How many libraries will be written in Mojo remains to be seen, depending on whether it catches on or not.

Yeah, a lot of folks don't seem to be aware of the people behind this, and their history. Swift was originally closed source too. He's explained that this sort of "incubation period" is helpful for working out the kinks with a small core team.