That's precisely the problem though. You cannot still read and understand an AI written proof at the current skill level of the AI being applied, because they're orders of magnitude longer than human written proofs even when they don't need to be, and spend most of that length on the parts that aren't important. This has been really thoroughly documented by expert mathematicians who are engaging with AI in public like Terence Tao and showing in detail how much work it takes working alongside AI to figure out how to understand AI generated proofs. With human generated proofs that process is forced to happen before publishing the proof because the new style of AI generated proofs validated only by formal verification is supplanting the old human peer review process that forced the burden of understanding onto the publisher and not the reader.
> You cannot still read and understand an AI written proof at the current skill level of the AI being applied, because they're orders of magnitude longer than human written proofs even when they don't need to be, and spend most of that length on the parts that aren't important.
That doesn't seem to be true. The OpenAI NS paper was 166 pages. Wiles-Taylor proof of Fermat's last theorem is 129 pages. The length is not unprecedented for a difficult unsolved problem.
To be honest, I feel like the difficulty of reading AI proofs is due to the fact that we are on the verge of being beyond human comprehension. This is a demonstrable fact as no human has figured this out despite the problem being open for almost 100 years.
> To be honest, I feel like the difficulty of reading AI proofs is due to the fact that we are on the verge of being beyond human comprehension.
I can see where that's coming from, but I really don't think it's the case. Even with Astra, the proofs you get are just off in a way that doesn't signal superhuman comprehension. As 9question1 says, a common theme is that they dwell on insignificant steps. Another one is that they'll often be full of terminology that either doesn't exist, or has this weird quality where it looks like it is trying to make some minor insight seem much greater than it is. At first glance, that'll often make it look like it knows more than you, but when it's really just doing the same thing but in a more complicated and worse fashion, that to me isn't a signal of comprehension at all. The bizarre thing is that despite all the "stochastic parrot" style nonsense you'll get in individual proof steps, they still often combine to something valid.
In either case, what all of this means is that the working mathematician still needs to go through, and generally completely rewrite, any proof output by an LLM. Otherwise you are passing the burden of unreadability onto the reader.
Yeah, that mirrors what I've seen throwing some of the leading models at a set-theory problem that's stumped me (https://mathoverflow.net/q/511601): in this case, the problem does not easily yield to the standard tools, but the LLMs do not recognize it as a major open problem they should give up on. So they seriously try it, but typically end up in a loop of inventing certain classes of simple solution or counterexample attempts, defeating them, and trumpeting each one as a major result, each time inventing some new terminology.
It's definitely quite curious that the AI labs are able to push these results through seemingly with pure brute force. Perhaps it's largely a function of how many monkeys you have attempting various constructions on top of the known results and strategies the models have memorized.
> This is a demonstrable fact as no human has figured this out despite the problem being open for almost 100 years.
That's not true. Alpoge and Buckmaster's related LLM-assisted blowup result (https://news.ycombinator.com/item?id=49605915) utilized a strategy developed recently by Cordoba and Martinez-Zoroa.
That depends. Inflation is a measure of the cost of living in terms of currency. It can be high either if goods and services required for living become scarce, or if currency supply increases. Currency supply increasing does affect asset prices.
Yes, but they're not directly correlated. Of course events can affect them both! Going to war would both increase the cost of living and (some) asset prices would go way up. But that doesn't mean they should be measured together like that.
`it's technically possible to pass the blame to other people` presupposes that the blame belongs to the reporter unless effort is taken to "shift" it. This is just an inaccurate worldview as many people have pointed out clearly in this discussion. If there's a vulnerability in software the blame lies with people who wrote and maintain the software, not someone who finds and discloses a vulnerability. The person who should `check in on the status of the fixes` is the person who owns the thing being fixed, which is very much the kernel and distro maintainers and not the security researcher. It is you who are willfully shifting blame to an innocent party
You're mentally stuck in 2009-2015. The world has moved on and Spain is now significantly outperforming Germany in growth (obviously not yet in wealth, which is the integral of growth over much longer time periods). https://www.youtube.com/watch?v=V-YZeqk8NCQ&t=456s
The problem with this argument is that pharmaceutical companies are private businesses trying to make a profit, not charities. If it were truly unprofitable to sell drugs in, say, Canada or France, pharmaceutical companies would just not sell their drugs in those countries. It is _less_ profitable to sell drugs in those countries than America but still profitable, which is why they still try to capture those markets. If America fixed this imbalance by forcing a lowering of drug prices in the American market, there's no reason to believe that this would cause raising of prices elsewhere. The only way this would be possible is if it were truly unprofitable to sell the drugs elsewhere, which can't be the case since these are corporations not charities. The real impact would be to slow down new drug development, since existing drugs are already profitable to sell everywhere in the world even in countries with more regulation, but if America fixed its market by lowering drug prices for Americans, the total profitability of pharmaceuticals would decrease, decreasing the incentive to create new pharmaceuticals. That's a totally different and very plausible impact. Rising drug prices for existing drugs in other countries is not a plausible impact.
> If it were truly unprofitable to sell drugs in, say, Canada or France, pharmaceutical companies would just not sell their drugs in those countries
You’re confusing capital and operating costs. Once you’ve developed the drug, selling everywhere you can makes sense. When considering whether to develop a drug or invest in something else, America’s biotech market absolutely turns keys. (But not as uniquely as we think. Europe has a thriving R&D market, it’s just directly subsidised.)
So basically if this true, you prove my point. If Americans weren’t paying these high costs then R&D would slow down and the whole world wouldn’t get these drugs.
America subsidizes these drugs for the rest of the world, which does not pay its fair share into R&D costs. If we’re to fix our healthcare system, this kind of thing can’t continue.
I think they are not saying it's unprofitable, but rather that the current government should shape the market so the environment levels more over US vs the rest. (of course please in a laissez-faire change the market style not the bad socialist stuff)
I think it's likely that both the blog poster and the maintainer are being perceived as more negative in tone than the intent / reality. They both included disclaimers "I must be doing something wrong. And if I am, I'm sorry." and "whatever, it’s their blog so they can do what they want." They're also both giving critical feedback "But, if I'm not, this is a problem right?" "Kinda wish the author would attempt to collaborate rather than write stuff like this" but in both cases the criticism is extremely mildly worded compared to most toxic online discourse. This seems... great? Isn't it good we're able to disagree so politely? It's not toxic to have a disagreement or to give critical feedback. We don't need to all pretend to agree with each other all the time or be happy with each other in order to have a civil discourse.
Yes, you can have Claude Code go through the code and make an .md file with documentation for all the public APIs. I do that for everything that doesn't provide llms.txt.
If you want to not reliably know anything about the code, sure. But if you want to have useful knowledge, using a stochastically unreliable tool isn't going to cut it.
I love Typescript but I think I disagree with this. The point of the post seems to be that features of the Rust compiler help enforce that you use certain runtime / environment / domain semantics in ways that eliminate common classes of errors. That's never going to prevent all errors, but preventing large groups of common errors so that you only have to manually remember a smaller set of runtime/environment/domain semantics could have some value.
It isn't typescript's fault. Borrow checker won't save you from bugs in your SQL queries that you send to the DBMS. Typescript doesn't care about the browser just like rust doesn't care about SQL
The problem is not with TypeScript or even JavaScript but an odd Browser API where mutating some random value of an object results in a redirect on the page, but not synchronously.
Even if the language of the browser were Rust, there's nothing about the type system specifically that would have caught this bug (as far as I can tell, anyways. Presumably there's something in the background periodically reading the value of `href` and updating the page accordingly, but since that background job only would have needed read and not write access to the variable, I don't think the borrow checker would have helped here)
> Setting the value of href navigates to the provided URL [0]
It would have been caught because this API (setters) is impossible with Rust. At best, you'd have a .set_href(String).await, which would stop the thread until the location has been updated and therefore the value stabilized. At worst, you'd have a public .href variable, but because the setter pattern is impossible, you know there must be some process checking and scheduling updates.
But the OP did implement a fully featured app as the Nue comparison half of the benchmark. I have never used Nue and don't know if I ever would. I just think to be fair to the OP, even if incremental cost declines as you keep adding stuff in React, there's no way it is negative, which means the benchmark you asked for logically must have a similar result?
reply