I was arguing with a friend about this point today. I'd posit that our economy has been growing in a way where goods that require more human time and natural resources to produce are giving way to goods that are intangible.
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.
I work on systems code that is tricky to write, but with a good test harness. Being able to leave the agent unattended to try several paths when I'm generating the first draft of some code is very helpful.
Of course beating the code into shape for submission requires more manual work. But the draft stage is valuable to find unexpected friction points.
I wonder if it's the same behavior as copilot cli. I dug into it when I got annoyed and found that there's a fundamental tension between rendering the cell based UI and supporting the terminal's native copy paste. At least on copilot cli there were extra zero width characters being copied.
I disagree. For example, the Wright brothers did air foil engineering empirically without full knowledge of the underlying fluid mechanics. Early and innovative engineering will often be less based on existing scientific or mathematical knowledge, while still using some of the methods. It's still absolutely defined as engineering.
I wonder how they ensure durability. Is it possible that a cell going down would roll back a payment after it has occurred. Or do they depend on a non cell database?
I just joined a new team and have been using copilot with opus models.
We have our core code in a weird dialect of C and rust. C I know well, but not rust. Our tests are in Python. The pipeline descriptions are in Yaml.
Outside of the core code there are so many arcana to learn. Writing syntactically and semantically correct yaml/Python test code would be a nightmare. The Agents have flaws, but they provide a huge leg up in improving the tests.
And they are great at providing a first pass review of the core code before bothering a human reviewer. Lastly we run some of our test failures through AI triage, which often enough finds the root cause or rules out simple failures.
This shows up in a higher checkin rate. I'm curious to see whether this will lead to quality end product since we have more support for the more manually written and reviewed core product code.
How does release management work? Are there stable branches for deployed properties with a cheery pick approach for bug fixes? Are all products in google3 on a coordinated set of release trains?
I think intuition is what is developed through calibration, so I personally like the word calibration.
Intuition and other forms of knowledge are stock quantities while calibration and instructions are types of flows which change the stock. I'd love to know if there a better word for learning through trial and evaluation than calibration.
Speculating: local ssds aren't as valuable in the cloud since they're effectively ephemeral. If the instance restarts, it would lose its storage. Trying to keep a workload affinitized to an SSD or to migrate data to a different SSD when an instance moves increases cost prohibitively.
If you want recognize all the common patterns, the code can get very verbose. But it's all still just one analysis or transformation, so it would be artificial to split into multiple files. I haven't worked much in llvm, but I'd guess that the external interface to these packages is pretty reasonable and hides a large amount of the complexity that took 16kloc to implement
From the previous article in the series, it looks like the biggest impediment to just using full llvm to compile the query is that they didn't find a good way to cache the results across invocations.
Sql server hekaton punted this problem in a seemingly effective way by requiring the client to use stored procedures to get full native compilation. Not sure though if they recompile if the table statistics indicate a different query plan is needed.
Yes, they did have the bug with the lock prefix. IOT people at Microsoft got NT booting on the Quark and we ran into that problem. I wound up writing a small tool to patch out all the lock prefixes.
> mean, "not enough data" is an explanation why neural networks can't do a bunch of things... One of the things humans are really good at is learning things from a few examples
I dispute the search space problem for something like folding clothes. Like a lot of human actions in space, folding clothes and other motor tasks are hierarchical sequences of smaller tasks that are strung together, similar to a sentence or paragraph of text.
We can probably learn things from each other from few examples because we are leaning on a large library of subtasks that all have learned or which are innate, and the actual novel learning of sequencing and ordering is relatively small to get to the new reward.
I expect soon we'll get AIs that have part of their training be unsupervised rl in a physics simulation, if it's not being done already.
Reading this code for the first time, this seems to be a consequence of the separation between allocating and fd and "installing" a pointer to a file there. Allocating the fd already needs to acquire a lock. So if the install happens together with allocation, there wouldn't be a need to use synchronize_rcu to kick out other threads. The lock would do that.
> In other words the LLM does not contain the knowledge of what the words represent.
This is probably true for some words and concepts but not others. I think we find that llms make inhuman mistakes only because they don't have the embodied senses and inductive biases that are at the root of human language formation.
If this hypothesis is correct, it suggests that we might be able to train a more complete machine intelligence by having them participate in a physics simulation as one part of the training. I.e have a multimodal ai play some kind of blockworld game. I bet if the ai is endowed with just sight and sound, it might be enough to capture many relevant relationships.
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.