Hm, if I query the LLM it tells me about cognitive hierarchy theory, and the Keynesian beauty contest. But my point is, humans are not perfectly rational beings, and sometimes for a reason. (Like assuming that there is more uncertainty than the stated rules imply. Or altruistic behaviour that benefits the group as a whole. And we also have a default to imitate each other, see Joseph Henrich's 2016 Book.) Some of those defaults are culturally learned and leak into pure mathematical games (see e.g. the ultimatum game).
People also keep knitting clothes despite how cheap they are to buy. They solve math problems that have been solved before, to get better at math, instead of starting with an unsolved problem. They write about things they are enthusiastic about, maybe to remember the experience, maybe to get better at writing, or to dip their toes into publishing.
Some people also seem to like reading such articles, given the upvotes. I guess it's about sharing the experience of something that interests you. Learn how it might turn out.
You can convert any energy form into thermal energy. When you boil water with an immersion heater, what happens if you use two heaters? Right, they add up. But not if you think in Squenergy. Or you can measure the effect (in heat) that a ball impact has. In Squenergy two balls don't add up add up, so it's less natural to think that way.
The article scrutinizes the viral headline. They conclude that it is mostly true, despite major statistical blunders.
As you'd expect from any viral headline there are things that invite misinterpretation. From the article:
> when [...] expressing both figures as rates per 100,000 people, the picture shifts. “Gun deaths in the US are now slightly larger than European heat death rates,” she wrote.
> What the data is actually showing, she argued, is something simpler: status quo bias. [...] Europe would never absorb tens of thousands of annual gun deaths without demanding legislative action. America would never absorb tens of thousands of annual heat deaths without demanding someone install a thermostat. [...] Things don’t have to be this bad. It’s a choice.
Not sure if that's fair. Sometimes the sun actually does shine, and while you won't get rich selling energy during that time, having electricity available essentially for free during some of the peak hours is worth something. Someone will eventually find a use for free energy. If nothing else, at least we can turn off all coal, gas and oil plants while the sun shines.
They do and it's a problem, but it's a minor issue compared to, say, cars or rat poison. Both kill lots of birds, but somehow when it's wind turbines people suddenly care about the birds. See also: https://www.zmescience.com/feature-post/technology-articles/...
Sure, if you're working on problems that are trivial to evaluate. If your goal is to find good algorithms or parameters then you can pick a problem that evaluates fast.
But for many interesting problems evaluation will be the bottleneck, and it doesn't matter if the evolution algorithm fits into L2. It is more important to make use of distributed computing, e.g. it shouldn't have to stop all evaluations to make progress, or alternatively it should work well with very large population sizes.
I recently saw a reportage about emergency call-takers. As you watch them work you'll notice they get an automatic call from the crashed car long before any human calls them, presumably from that modem.
I'm not arguing that the modem should be mandatory, or that you shouldn't be able to control what it does. But forcing car vendors who want to built in a modem to make this modem do an automatic emergency call by default, that seems quite sensible. Even more sensible would be if the modem did nothing unless you allow it, except when it detects that crash, but... profits.
> of course, emacs does not work reliably in windows, so that is another issue
No, it's the same issue. In a Linux shell (say, bash or fish) ctrl-c is not "copy" but "terminate program". Most emacs editing keys (copy-paste, motion) work in the shell as they do in emacs, at least in fish and bash (and probably other places in Linux).
Not quite, at least 50% of rescue costs will be paid via normal mandatory health insurance (just like when you need an ambulance car). Or 100% if you have a supplementary health insurance for transport.
For CHF 40 you can become a Rega patron and then they will usually pay whatever the insurance didn't cover, I think, but technically they don't have to.
I found this a bit odd. The intro seems to assume the reader doesn't know what "I/O" stands for. Okay, everyone has to learn this from somewhere, but... what is the audience for a "deep dive" article?
It goes on to assert how everything is I/O bound, and how bad threads are for that. Fair. What follows an intro to tokio, with focus on how you span a CPU-bound task, how work stealing works, and then how you should use SIMD for your CPU-bound tasks. Huh.
I mean, if you have a mostly CPU-bound task and also the occasional I/O socket, you can keep things much simpler by using threads and std::sync. Especially if you are in the audience of that article, then you don't know yet how much more complicated things can get when you need to use async in Rust. And how much Rust's safety model actually changes the past wisdom of "threads are evil, period" in favour of threads again.
You'd think removing friction on the software side for someone who already bought their hardware would be in their interest. Especially for students and hobbyists, who will want use what they already know once they enter the industry.
Why care about continuous sync? When I was in small robotics startup we had a separate motor controller driving each axis. A customers complained that the precision was getting worse after running for a few days non-stop. Guess what? Each axis had its own CPU clock based timer defining how long a segment should take. The difference is negligible but it accumulates over time. It was no issue for other customers who had a pause somewhere in their motion.
Why nanoseconds though? Usually a sub-microsecond sync is good enough. I can only think of some specialized phase measurements, really, like when you need to know from which direction a radio signal is coming based on timing of two antennas.