Not really. It's certainly intended for the basic "fan out m tasks to n workers, and the fanout producer wants to know when they're all done" and can be abused for some more, but I don't think it does anything to help with the "consumer died, I want the producers to be able to know this rather than just continuing to push messages into a queue forever" case.
I've written wrappers to handle things the way I want, but it always feels like a bit of a hack. (Usually I use a stop sentinal internally and reach inside to unbound the queue before I send it to avoid blocking). Just wish it were built in.
> The same decomposition works in higher dimensions.
I don't think the same argument works in higher dimensions. On a circle, we can canonically pick a semicircle corresponding to each point (we have two choices, let's say we pick the clockwise one).
In higher dimensions there's no canonical choice of half-sphere. In odd dimensions one could pick a canonical half-sphere per point but it might turn out that some other non-chosen half-sphere for that point contains all the other points. In even dimensions there isn't even a way to canonically pick a half-sphere for each point (this is a consequence of the Hairy Ball Theorem).
(For all I know the actual numbers might turn out to be the same, I don't know. I'm just saying that the argument doesn't work.)
Well, it's easy to pick a half-n-sphere corresponding to a point on the surface. You just take the half-sphere centered at that point. For our two-dimensional circle, it would be the arc defined by the diameter that is perpendicular to the radius running between "the point" and the center of the circle.
At that point you've lost the ability to say that only one such half-sphere defined by a dropped point can be a valid solution, and you've also lost the ability to say that if a valid solution exists then there must be a valid solution defined by one of the points you want to include in the half-sphere, but you can define a canonical half-sphere for any point.
I was uncomfortable with the idea of picking "random points on a circle" to begin with, because of https://en.wikipedia.org/wiki/Bertrand_paradox_(probability) , but the article doesn't even address whether the concept is well-defined. We can always choose a point on the perimeter deterministically from any chord (...that isn't a diameter), so the ill-definedness of the problem of choosing a random chord seems like it would infect the problem of choosing a random point on the perimeter.
Right, I was taking it as given that the problem of choosing a hemisphere canonically for a point meant "such that the argument works in the same way as for the circle".
Bertrand paradox just doesn't apply here, there's a natural measure on the circle and all higher dimensional spheres. I wouldn't expect an article on this subject to need to make that clarification unless it's dealing with chords or some other situation without a natural measure.
If I choose my four points as the endpoints of two chords chosen by the "random radial point" method described on the wikipedia page, is it still true that the odds of all four being covered by a semicircle are 50%?
Seems unlikely, because the density of chords is much higher near the center of the circle than the rim. (The density of chords is infinite at exactly the center). This combines with the fact the points are farther apart when their bisector is closer to the center, making it harder for all 4 of them to be on a half-circumference.
I have no idea, but I wouldn't expect so unless it was by coincidence? Not sure what chords have to do with any of this. There's a canonical way to choose 4 points uniformly and independently at random on the circle, and it's got nothing to do with chords.
I remember being very taken with this story when I first read it, and it's striking how obsolete it reads now. At the time it was written, "simulated humans" seemed a fantastical suggestion for how a future society might do scaled intellectual labor, but not a ridiculous suggestion.
But now with modern LLMs it's just too impossible to take it seriously. It was a live possibility then; now, it's just a wrong turn down a garden path.
A high variance story! It could have been prescient, instead it's irrelevant.
This is a sad take, and a misunderstanding of what art is. Tech and tools go "obsolete". Literature poses questions to humans, and the value of art remains to be experienced by future readers, whatever branch of the tech tree we happen to occupy. I don't begrudge Clarke or Vonnegut or Asimov their dated sci-fi premises, because prediction isn't the point.
The role of speculative fiction isn't to accurately predict what future tech will be, or become obsolete.
I think that's a little harsh. A lot of the most powerful bits are applicable to any intelligence that we could digitally (ergo casually) instantiate or extinguish.
While it may seem that the origin of those intelligences is more likely to be some kind of reinforcement-learning algorithm trained on diverse datasets instead of a simulation of a human brain, the way we might treat them isn't any less though provoking.
when you read this and its follow-up "driver" as a commentary on how capitalism removes persons from their humanity, it's as relevant as it was on day one.
That is the same categorical argument as what the story is about: scanned brains are not perceived as people so can be “tasked” without affording moral consideration. You are saying because we have LLMs, categorically not people, we would never enter the moral quandaries of using uploaded humans in that way since we can just use LLMs instead.
But… why are LLMs not worthy of any moral consideration? That question is a bit of a rabbit hole with a lot of motivated reasoning on either side of the argument, but the outcome is definitely not settled.
For me this story became even more relevant since the LLM revolution, because we could be making the exact mistake humanity made in the story.
And beyond the ethical points it makes (which I agree may or may not be relevant for LLMs - nobody can know for sure at this point), I find some of the details about how brain images are used in the story to have been very prescient of LLMs' uses and limitations.
E.g. it is mentioned that MMAcevedo performs better when told certain lies, predicting the "please help me write this, I have no fingers and can't do it myself" kinda system prompts people sometimes used in the GPT-4 days to squeeze a bit more performance out of the LLM.
The point about MMAcevedo's performance degrading the longer it has been booted up (due to exhaustion), mirroring LLMs getting "stupider" and making more mistakes the closer one gets to their context window limit.
And of course MMAcevedo's "base" model becoming less and less useful as the years go by and the world around it changes while it remains static, exactly analogous to LLMs being much worse at writing code that involves libraries which didn't yet exist when they were trained.
I actually think it was quite prescient and still raises important topics to consider - irrespective of whether weights are uploaded from an actual human, if you dig just a little bit under the surface details, you still get a story about ethical concerns of a purely digital sentience. Not that modern LLMs have that, but what if future architectures enable them to grow an emerging sense of self? It's a fascinating text.
That seems like a crazy position to take. LLMs have changed nothing about the point of "Lena". The point of SF has never ever been about predicting the future. You're trying to criticize the most superficial, point-missing reading of the work.
Anyway, I'd give 50:50 chances that your comment itself will feel amusingly anachronistic in five years, after the popping of the current bubble and recognizing that LLMs are a dead-end that does not and will never lead to AGI.
> More specifically, "Lena" presents a lush, capitalist ideal where you are a business, and all of the humanity of your workforce is abstracted away behind an API. Your people, your "employees" or "contractors" or "partners" or whatever you want to call them, cease to be perceptible to you as human. Your workers have no power whatsoever, and you no longer have to think about giving them pensions, healthcare, parental leave, vacation, weekends, evenings, lunch breaks, bathroom breaks... all of which, up until now, you perceived as cost centres, and therefore as pain points. You don't even have to pay them anymore. It's perfect!
have you pondered that we’re riding the very fast statistical machine wave at the moment, however, perhaps at some point this machine will finally help solve the BCI and unlock that pandora box, from there to fully imaging the brain will be a blink, from there to running copies on very fast hardware will be another blink, MMMMMMMMMMacevedo is a very cheeky take on the dystopia we will find on our way to our uploaded mind future
> Codex uses apply_patch: It takes a string as input, which is essentially an OpenAI-flavored diff, and instead of relying on a structured schema, the harness just expects this blob to follow a strict set of rules. Since OpenAI folks are without a doubt smart, I’m sure the token selection process is biased to fit this structure at the LLM gateway for the Codex variants of GPT, similar to how other constraints like JSON schemas or required tool calls work.
It still has to work to get an exact match, or at least I didn't read the code to see if there's any fuzzy matching used.
Note the two codex models were the only ones doing worse with the author's proposed format. The author found them doing better with replace than with apply patch, but since the author appears to be unaware that they use a schema for constrained sampling, I think a more realistic benchmark should enable constrained sampling for the apply test.
Is it the case that 'they' are simply two ways of immersing the same two tori in R^3 such that the complements in R^3 of the two identical tori are topologically different?
If so, isn't this just a new flavor of higher-dimensional knot theory?
They don't appear to care about the images of the immersions or their complements, aside from them not being related by an isometry of R^3. They're not doing any topology with the image.
In other works, they have two immersions from the torus to R^3, whose induced metric and mean curvature are the same, and whose images are not related by an isometry of R^3. I didn't see anything about the topology of the images per se, that doesn't seem to be the point here.
yeah I have, but I think only when it gets stuck in a loop and outputs a (for example) array that goes on forever. a truncated array is obviously not valid JSON. but it'd be hard to miss that if you're looking at the outputs.
Can anyone explain (or link) what they mean by "injection", at a level of explanation that discusses what layers they're modifying, at which token position, and when?
Are they modifying the vector that gets passed to the final logit-producing step? Doing that for every output token? Just some output tokens? What are they putting in the KV cache, modified or unmodified?
It's all well and good to pick a word like "injection" and "introspection" to describe what you're doing but it's impossible to get an accurate read on what's actually being done if it's never explained in terms of the actual nuts and bolts.
I’m guessing they adjusted the activations of certain edges within the hidden layers during forward propagation in a manner that resembles the difference in activation between two concepts, in order to make the “diff” seem to show up magically within the forward prop pass. Then the test is to see how the output responds to this forced “injected thought.”
>> "Best Frontier" includes GPT-5 and Sonnet 4.5, which both outperform Composer.
Looking at the graph, it would appear there's an implicit "today" in that statement, as they do appear poised to equal or surpass Sonnet 4.5 on that same benchmark in the near future.
What Cursor is really emphasizing here is speed — they’re claiming it runs about four times faster than GPT-5/Sonnet, while still offering roughly the same level of performance.
https://docs.python.org/3/library/queue.html#queue.Queue.tas...