sum((np.sin(np.cos(np.sin(np.cos(x + i)))).sum()
        for i in range(n_loop)))

   release GIL
      # i = 0
      compute y = x + 0     (numpy broadcasting sum)
      compute z = np.cos(y) (elementwise)
      ...
      add to running total
      # i = 1
      compute y = x + 1
      ...
   reacquire GIL

   # i = 0
   look up "+" operation
   release GIL
      compute y = x + 0
   reacquire GIL
   look up "np.cos" operation
   release GIL
      compute z = np.cos(y)
   reacquire GIL
   ...
   # i = 1
   look up "+" operation
   release GIL
      compute y = x + 1
   reacquire GIL
   ...

Of course, without free threading, the lock contention would be way worse, but this time the GIL is the lock being contended. Numpy has to reacquire the GIL whenever it returns from a function call, and this expression is made up of multiple calls. To multithread effectively with numpy (in non-freethreading) you'd normally aim to vectorise into a small number of calls in big arrays.

The composition of +, then np.cos, etc. is not too bad if these are big arrays, but the problem is the pure Python iteration over the range which is, presumably, quite large. You could vectorise over the range:

   x[..., None] + np.arange(n_loop, dtype=np.float64)

I now realise that sounds a bit like a contradiction. I said I could copy on autopilot but also I had to focus on it. I suppose it was more like the second one: I was so focused on copying verbatim (as furiously as I could as there was barely time to do it before it was rubbed out!) that I didn't have a chance to think about the content.

> > Or summarising notes in your words.

> Which is what you do, if you take down notes.

I certainly disagree with this. No one I knew was rephrasing the lecturer's notes in their own terms. There was no time for that. That is something you'd have to do in your own time afterwards, at a much slower pace.

> > but there were no typed notes to start with so it was just out of necessity

> The necessity was created by the teachers in order to get the students to learn.

I assure you, the main reason those maths lecturers didn't spend countless hours typing up their handwritten notes in LaTeX was not the best interests of the students!

You can't just defer this decision to the three.js program because you need to understand this sort of relationship yourself if you're going to suitably place objects (and your own view) in a three.js scene in the first place. Building a complex scene involves making hundreds, or more, of decisions about where to place coordinates in 3d space.

This example is underspecified (e.g. what are the shapes and sizes of the objects and what is the angular width of your view) but it illustrates the problem. Even with a good intuitive understanding of 3d space, we would struggle with this. LLMs are not calculators, so it's surprising if they manage it.

This is a poor analogy because:

* Multiplying numbers has a single objective answer. Whether a code is good (sometimes even just whether it's correct) can be quite subjective.

* LLMs certainly do some level of composition between the data sources they were trained on i.e. they are more than just lookup tables.

* We have calculators that actually do multiply large numbers accurately. We don't have anything that automatically writes code that is definitely correct and "good".

To address only the last point: imagine you had a device that would quickly factor large numbers used in modern criticality, but occasionally got it wrong. You could waste a lot time debating whether it's a "calculator", but it's still certainly useful to have one.

But being able to decode the blobs that subagents returned in a conversation I've already forgotten about? That doesn't affect my ability to switch at all! I can't even imagine what trivial detail of an operating system this is analogous to. Maybe an undo buffer of a document that gets cleared on exit anyway?

I can still pass all my code, and any associated documentation, to any other agent at any time. What am I missing?

I remember using a Kalman filter many years ago and getting confused when a measurement was fairly far from the current estimate, and the uncertainty still went down. Surely the uncertainty should go up if a measurement shows that our previous estimate was unreliable? I spent a lot of time debugging my code before someone pointed out to me that the Kalman filter does not adjust its uncertainties (and therefore the effective value of alpha) at all based on the data.

But a Kalman filter does not converge to EMA if either:

* Measurements occur at irregular intervals

* Measurements can have different errors (which you can meaningfully estimate)

These are exactly the situations when it's worth using a Kalman filter instead.

Word has a feature literally called "hidden text". Select some text, go to the font properties dialog, click "hidden" and OK, and watch the text disappear.

Edit: actually, this is white text on a white background as others have said, not true hidden text.

I believe you would see hidden text by default (but this was a long time ago and I may have misremembered) when in "normal mode" (later "draft mode" and now removed entirely), which was the default view and showed a long continuous stream of text without the computation expense of calculating page break locations. But when you switch to "print layout mode" (now the usual view unless you're in reading mode) it would be hidden, so you could see what the document would be like printed, unless you explicitly turned on the display of hidden text in that mode.

Probably you're focusing too much on the parent comment's mention of nuclear family. Even that, despite only being named a few decades ago, is likely to exist to some extent. Even in some ancient tribe or village, most people would favour their spouse (or equivalent) or child over a cousin or niece/nephew if some dispute formed. That hardly seems controversial.

nuitka is a bit better (in the sense of not running executables from a temporary path) in that it really compiles your code into an executable in "standalone" mode.

The difference between scrawl on a chalk board and a glossy menu with photos is not really the visual effect, it's the amount of effort and the virtue signalling - "my food is so amazing I don't need to make more effort than this".

But that applies to AI menus too. "Why are these horrible AI slop photos on your menu?" "Because I'm too focused on food to hand create a perfect American Psycho minimalist menu"

The article suggests using 8 bits (=256 values) to pack 5 trits (=243 values).

If you use 16 bits (=65536 values) then you can pack at most 10 whole trits (=59049 values). 11 trits (=177147 values) won't fit.

The current top comment, by JoshTriplett, analyses what you would need to beat the efficiency.