As long as the raw proofs, potentially ai generated, are available a lot of less funded mathematicians can still use them to generate understanding and created new programs to be resolved with new ai aided mathematical experiments.
290 karma · joined October 9, 2017
As long as the raw proofs, potentially ai generated, are available a lot of less funded mathematicians can still use them to generate understanding and created new programs to be resolved with new ai aided mathematical experiments.
I believe the new enabling technology for better codegen is tiered compilation, which has only been around for a couple years.
I hope we'll have some kind of good paradigm to do lora style learning or maybe an output subagent or something so we can better calibrate the output style in a fuzzy way. In context learning (instructions, memories) doesn't currently seem that effective.
Apparently a ctz solution is a bit longer, but doesn't cross from the floating to integer domain at all, so might be better in the overall algorithm. There are hidden implicit floating to int convert instructions.
This was a really cool little problem!
In a large multi-dll build like Windows or Office, the import/export information across modules is computed without doing codegen, so ltcg codegen can be done in parallel regardless of the module dependency graph.
I never worked deeply in the build systems for Linux based OSes or other unixes, but I gather that some symbol visibility choices make the build situation worse in Unix systems than Windows.
JIT is important to Apple platforms, and they seem to manage to make it work well enough even with the need for explicit invalidation.
The main problem I see with public economists is Goodharts law: When the predictive model becomes visible to the agents in the economy, there are stable strategies to counteract those models. So if economists want to remain good predictors of real outcomes, they have to collect massive amounts of data to feed the model but then remain mostly invisible afterward, so that the agents being analyzed don't change behavior too much.
In some sense, a known bad model that is used to set central policy may be good because the rest of the economic agents can work on a diversity of better models without correlating as much with each other and the known central model.
At the bus/inter agent communication level, the CPU has sent a read request and is expecting a response. These protocols are usually synchronous with no clear cancellation semantics. There are probably core resources tracking then expected response and if you just freed one of those up and ended the instruction with an exception, you could later have what appears to be an unsolicited response.
This dynamic probably repeats between the core and the pci root complex and then again between the root complex and the device implementing the mmio. Severing the request from the response is probably too complicated for such an unusual case.
On NT, this style of problem would be slightly less likely. The job object, which is NT's memcg equivalent, is a handle based object that naturally goes away when the owning process dies.
I also bet systemd would have native mechanisms to clean this memcg state up if it was used for this purpose. Seems like a bug in the AWS ecs code.
Responding to the actual article: it seems like the author simply has a different set of values than what is assumed by the conventional incentives that he sees around him. If you choose your values then you can also choose your incentives.
Still I think their solution is a bit weird. I'd want to commit the reservation transaction with inventory decrement along with a payment key and then use a different transaction to drop the reservation when the transaction completes. If the transaction does not complete in a timely manner you probably need to query external systems anyway to resolve whether the payment actually occurred or not.
They talk about lock contention in this case, but I also wonder about latch contention since these rows are adjacent. If it's a small transaction that's not interactive, does mysql resolve it with just the latches on the needed tables?
The internal representations of this state and its projection back out to human language wouldn't be as concise as that of a practitioner or team that develop their own verbiage and ontology over time molded to their system.
This verbosity might get better as we figure out better ways for agents to learn long term and use that knowledge to adapt to the users and projects over time.
There might also be some good harness improvements we could consider like forked output streams or multiple long lived filter subagents to ensure that output appropriate for thinking is separate from code output and separate from output given to the user driving the session.
However the general idea of using hysteresis for signal conditioning seems transferrable to other non physical control systems. I suspect that people who think about what the article is saying rather than reflexively declaring it to be slop could learn something useful.
The ai doesn't have the same incentives as a human. It can also be applied to the repro where it exists.
Your mechanic analogy is a bit inapt. Sure they're experts and can replace your engine much better than you can. But tracking down a non obvious system level bug like this one is much less repeatable and much harder because the problem has already been filtered through a lot of reviews and testing. As a system becomes mature, the bugs become harder and harder individually to track down.
Claude is probably not right about the root cause here and is probably bsing, I agree. But it's collected enough raw data to point some expert humans at the right interaction. I'd take this bs bug report and start asking Claude some questions that would guide it to a more plausible actual answer, but that requires a little more experience in kernel development.
Once we've met our basic material needs, we're tending to consume things that are replicable with low marginal costs, and which do not interfere with the production of other goods. So maybe we can actually support a continually growing digital and entertainment economy, at least for a few more generations.
Maybe these mathematical contributions will also impact the efficiency and capabilities of our material production systems as well, which is another way to keep the economy growing.
I'm optimistic that we'll do more with our resources rather than trying to optimize for doing the same more efficiently with less resources.
Of course beating the code into shape for submission requires more manual work. But the draft stage is valuable to find unexpected friction points.