I consider these scenarios:

1) We stumble onto an algorithmic improvement in intelligence. This isn't just "what humans do but faster", its "better than what humans do". I've got no idea what that might mean (it could be fundamentally different heuristics, it could be that we've got some intellectual blind spot that they cast off). It doesn't matter, the instant this happens AI is smarter than us and we won't be able to keep up. We're intelligencing at O(n^2) and they're doing O(n log(n)).

2) AI gets good enough at physics and engineering that they can really quickly use up all "the room at the bottom" as Feyman put it. They design and build a factory that produces a mystery metal amalgam that computes at some small percentage of the minimum predicted by the Landauer principle, within a few percent of Bremermann's limit. It's not "smarter" its just suddenly tens-of-orders of magnitude faster. But those orders of magnitude matter: there's only 8 billion of us, and there's plenty more than a factor of 10 billion "at the bottom".

3) It turns out that this is a "sum is greater than the parts" situation. No human can be an expert in all subjects, but we eventually build a big enough AI that it is. Turns out, you don't need extreme speed or different algorithms, just knowing everything all at once is enough to catapult AI dramatically beyond our grasp. Always knowing the best statistical test to apply, the best mathematical techniques, and relevant physics means that AI never makes a mistake, and can learn with maximum efficiency.

A system which will just randomly decide to give the legal team reasons to not back you up is:

* A system whose output will get brought up in lawsuits and make legal's job harder.

* A system that will make the dev team perpetually chase its tail while it oscillates between the several different valid interpretations of the rules.

The lab tested for chromium in two ways: one test (ICP) measures all chromium of any kind, and the other measures hexavalent chromium specifically. The ICP test returned a concentration that was an order of magnitude smaller than the hexavalent test (0.0003 vs 0.0104 mg/L). That is to say, the tests contradict each other (because the whole is smaller than the part).

https://www.documentcloud.org/documents/28055380-j2673-1-uds...

The lab tested for chromium in two ways: one test (ICP) measures all chromium of any kind, and the other measures hexavalent chromium specifically. The ICP test returned a concentration that was an order of magnitude smaller than the hexavalent test. That is to say, the tests contradict each other (because the whole is smaller than the part), and are both at the bottom of range for the tests performed.

https://www.documentcloud.org/documents/28055380-j2673-1-uds...

I look at some truly impressive projects like CLASP which sprang into existence not because of someone noodling around, but because they had a bigger goal which required the team build it.

So my advice to any mathematician who feels lost, like they don't know what to work on, would be to go collaborate with someone who has an actual goal, to look for inspiration in the kinds of math they need.

Today, there are a lot of opportunities to jump forward that only get capitalized on through coincidence (e.g. two people bump into each other at a conference, or researcher happens to have a colleague working on a related problem through the lens of a different discipline). If AI does nothing but guarantee that everyone will have such a coincidence by serving as that expert from a different discipline, that will still be a massive driving force for progress.

The question of "whats a mathematician to do" is still clear: you need to find and curate and clearly express interesting and valuable problems.

Where do these "application errors" occur if neither on a server nor a client?

I think the reality is that management sees "5xx means server error, so our team's KPI is now server error rate, the lower the better!" Then the team just stops using 500 errors as much as possible. They probably justify it with things like "well, such and such problem isn't our fault so its not really a server error." This kind of thinking is perverting the intent of 5xx messages. They are supposed to indicate any failure to handle the request that happens on the server, NOT measure whether the dev team is making a good application.

I work with a team that does stuff like this, returning a 200 and a body containing "error: I didn't do what you said because _insert error here_"

The problem is that you returned OK instead of ERROR when things were not OK and there was an ERROR.

Its a design that smells of teams trying to hit some kind of internal metrics by slightly deceptive means.

Everyone was going around acting like this meant 50% of 2nd graders were stupid with terrible parents. (Or, conversely, that 50% of 2nd graders were geniuses for "knowing" it was potatoes at all)

But I think that was the wrong conclusion.

The right conclusion was that all the kids guessed and they had a 50% chance of getting it right.

And I think there is probably an element of this going on with the small models vs big models dichotomy.

You could in principle design systems with enough fouling mitigations that you'd be fine, but its likely that the cost of those mitigations is roughly the same as just purifying the water up-front.

https://github.com/taichi-dev/taichi_benchmark

So the right way to handle the carbon accounting isn't to assume that all the CO2 produced by the refinery processes count against the hydrogen produced, but rather that the energy that refineries get from burning the hydrogen would be replaced by them burning natural gas instead.

The per-kg energy value of burning H2 is ~2.5x the value of natural gas (refineries generally use LHV for this accounting). But each kg of natural gas that gets burned produces ~2.8 kg of CO2 (because burning replaces the puny hydrogen with relatively larger oxygen atoms).

2.5*2.8 = 7kg of CO2 per kg of H2 taken out of the refinery. Which isn't as big a difference from the 10kg reported in the article as I expected when I set about writing this comment.

They're doing it because people are buying clothes based on superficial appearance, and most people prefer the aesthetics of the hourglass shape.

Rectangular clothing doesn't sell as well because it doesn't look as good on a mannequin even if it fits better.

Normalize going to a tailor, instead of grumbling about how you aren't benefiting enough from the sweatshops mass retailers are running.

I queried said database... it was slow.

I looked to see what indexes they had set up... there were none.

That team should have just used postgres and spent all the time and money they poured into this fancy database tech on finding someone who knew even a little bit about database design to help them.