mreid

I'm guessing that what they meant by "proper harmony" is just intonation: where thirds and fifths are expressed by small, integer ratios of frequencies (e.g., a fifth is 3:2 and a major third is 5:4).

A just intoned major third is about 14 cents flatter than a major third played on a 12 tone equal temperament tuned instrument (e.g., piano).

I'm not sure how much this matters in terms of having or not having perfect pitch though. Some people with perfect pitch can hear the difference between JI and 12TET and correctly their singing accordingly.

From the article:

> Without fully endorsing all their ideas, I’m now in the LeCun/Marcus camp on LLMs.

I'm pretty sure he means "Yann LeCun and Gary Marcus" not "Yann LeCun and Marcus Hutter".

Thanks for sharing that link. My GitHub ID is 484.

I had no idea that I joined so early. It says I joined in 20/2/2008. I guess I was following some of the founders' work in Rails when GitHub was announced and must have signed up shortly after it got started.

> When my partner goes to the store I get periodic text messages from them asking how much X we have and to check I look in the fridge or pantry in the kitchen and then go downstairs to the fridge or pantry in the basement.

We used to have a similar problem until we made a policy that if you use something up you add it to our shared shopping list, usually with a voice command to Siri. Whenever someone is at the store we just check the list, making sure we mark off things that are purchased.

On your site you make the claim that: "Our thesis is that there is 100 years of physics and math research that has gone unnoticed by the CS/ML communities and we intend to rectify that."

Extraordinary claims require extraordinary evidence. Especially considering that a decent fraction of the CS/ML researchers that I know have solid physics and math backgrounds. Just of the top of my head, Marcus Hutter, David MacKay, Bernhard Scholkopf, Alex Smola, Max Welling, Christopher Bishop, etc. are/were prominent researchers with strong math and physics backgrounds. More recently Jared Kaplan and Dario Amodei at Anthropic also have physics backgrounds, as well as plenty of people at DeepMind.

To claim that you have noticed something in "100 years of physics and math research" that all of those people (and more) have missed and you didn't is pure hubris.

Is it concerning to anyone else that the "Simple & Reliable" and "Reliable on Longer Tasks" diagrams look kind of like the much maligned waterfall design process?

I also had to convince my parents to buy me books about fractals. My prized possession as a 15 year old was a copy of Mandelbrot's "Fractal Geometry of Nature". A lot of it went over my head but it had some gorgeous colour plates and interesting sections. I still have it at home some 35 years later.

That also inspired me to write IFS code for ferns, Sierpinski gaskets, and Menger sponges in 68k assembler (after realizing AmigaBASIC was too slow).

Thanks, I hadn't seen that term before.

Just to be clear, I wasn't claiming that "communicating clearly" is a new idea in software engineering, I'm mainly commenting on how effective embracing it can be.

When doing math, pretty much every term is "load-bearing" in that arguments will make use of specific aspects of a concept and how it relates to other concepts.

If you look at most graduate-level math textbooks or papers, they typically start with a whole bunch of numbered definitions that reference each other, followed by some simple lemmas or propositions that establish simple relationships between them before diving into more complex theorems and proofs.

The best software projects I've seen follow a roughly similar pattern: there are several "core" functions or libraries with a streamlined API, good docs, and solid testing; on top of that there are more complex processes that treat these as black-boxes and can rely on their behavior being well-defined and consistent.

Probably the common thread between math and programming is both lean heavily on abstraction as a core principle.

Another thing I learnt from my math degree that I find helps a lot when programming and software engineering more generally is *defining your terms*.

So many communication issues on teams occur when people are using the same words to mean different things.

As someone who taught myself 68000 assembler as a kid in order to render Mandelbrot and Julia sets quickly it still blows my mind a little that fairly hi-res versions of these can be rendered basically instantaneously in a browser using an interpreted language.

A lot of those skills come from thinking about development in a team as a system and ask where do things frequently go wrong or take too long?

Practice clearly and concisely expressing what you understand the problem to be. This could be a problem with some code, some missing knowledge, or a bad process.

Check to see whether everyone understands and agrees. If not, try to target the root of the misunderstanding and try again. Sometimes you’ll need to write a short document to make things clear. Once there is a shared understanding then people can start taking about solutions. Once everyone agrees on a solution, someone can go implement it.

Like any skill, if you practice this loop often enough and take time to reflect on what worked and what didn’t, you slowly find that you develop a facility for it.