Sure but... this is the technology at the most expensive it will ever be. I'm impressed that o3 was able to achieve such high performance at all, and am not too pessimistic about costs decreasing over time.
Even at 100x cost decrease this will still cost $10,000 to beat a benchmark. It won't scale when you have that amount of compute requirements and power.
GPT-3 may massively reduced in cost, but it's requirements were not anyway extreme compared to this.
It's funny; I spent a couple of hours last week helping some students debug out-of-bounds indices in their Rust code.
I've written bugs that would have been caught by the compiler in a memory-safe language. I think the last time was maybe in 2012 or 2013? I still write plenty of bugs today but they're almost all logic errors that nothing (short of AI tools) could have caught.
I think it's simply that the blog author and commentators have an unrealistic threat model when it comes to how the legal profession uses MD5s.
After the first high-profile case where authenticity of evidence gets called into question because a seized electronic document was deliberately doctored to allow for a hash collision (if that ever happens), there will be a will to change to something new.
I doubt it, legal types won't see this as a math problem[1], but a legal problem (forging documents)
[1] unless I'm missing something, this boils down to: "given f(x: string) => y, how can I minimize the odds that you can generate an X for a desired Y"
The situation is now counterintuitive in the other direction: if Monty Hall had opened those 48 doors at random and they just happened to not contain the car, then there is no advantage to switching, though many people would insist otherwise.
> if Monty Hall had opened those 48 doors at random
The fact that Monty Hall opens the doors deterministically (not randomly) is KEY.
In the original problem, Monty ALWAYS opens a door with a goat. In using 50 doors, Monty would ALWAYS open doors containing goats, and not the car. It's not random.
Knowing it's not random, it should be very intuitive.
But the doors weren't opened at random. You know he won't open the car, because that's part of the rules of the game.
Let's demonstrate with a slightly different construction: You're no longer playing with monty, but with a demon. This demon wants you to lose, but also picked a very bad game for themselves. You pick a door, then the demon opens all-but-one of the remaining doors. Then, you can pick any door, open or closed, and you get what's in it.
If the demon opens doors at random, nearly all the time (with 100 doors) you'll see the car and be able to pick it directly. In this situation, switching between the closed doors doesn't really matter, but you'll usually know exactly which door to pick, because you can see the car.
So instead, the demon only opens doors that don't have a vehicle behind them. You only ever see goats. At this point, he's not opening doors at random. If he were, you'd see the car 98% of the time, but you never do. At this point, since he's using additional information, it is in your best interest to switch.
1. It's easy enough for a lone entrepreneur with no investors to make principled long-term decisions. It's not so trivial when you owe a fiduciary duty to a board of venture capitalists.
2. Your team of engineers (which has grown steadily as you've scaled up) have built The Thing and everyone loves it. Now what? You only need 5% of the team to maintain the software. You could fire 95% of the team, which will make your company mighty unpopular to future hires, and moreover your best developers won't want to stay and do maintenance for the next decade. Easier to have them work on gratuitous frontend redesigns, bloated features that increase engagement metrics, etc. In a restaurant the contractors who build and furnish the place aren't your employees.
I've spent hours helping my students debug their Rust programs of incorrect array-indexing logic, incorrectly-reasoned loop invariants, incorrect conditional logic, and everything in between. They're not double-deleting raw pointers, but then again, most C++ programs don't use raw pointers these days either...
"Rust makes a few classes of bugs impossible to write by construction" is a very nice feature of the language. But I'm really turned off by how insufferable the Rust community is (which shines through in the OP's blog post and several comments elsewhere in the responses): it's never the quote at the start of this paragraph; it's always "writing software in anything but Rust is fundamentally irresponsible!" or "if a Rust program compiles, it must be correct!" No, not even close.
The store may or may not be telling the truth. Either way, it's undeniable that SF has changed dramatically over the last several years, with dramatic upswing in property crime and complete unwillingness on the part of law enforcement to fight it.
Because after your lean, highly-productive startup team creates the app that everyone loves, you get a bunch of funding and hire thousands of extraneous software developers and then have to find something for them to do.
Thousands of engineers and managers and product designers who can only get promoted if they look successful, and who can only look successful if they can add features.
