slowking2
Joined 4 years ago
Joined 4 years ago
There’s an interesting question of if the distributor misrepresented the deal to Mora as he claims, but from the summary it appears nothing related to that is recorded that the court finds legally relevant.
Additionally, you're using the average software engineer salary in the US but then picking California for rent. The article you linked says country wide you'd expect $1950 for renting a 1-bedroom not the $2500 number you are picking for a studio in the bay area.
So you're off by something like $1000 per month (edit: I admit I am simply looking at what I pay for HMO, it's possible that is somehow unrepresentative but I doubt it) by picking the most expensive health plan and mixing up national salaries vs very expensive areas.
The gun violence risk is vastly overblown. The page you are linking to cites a study where gun deaths are being accumulated for ages 1 to 24 years old. Gun deaths are highly non-random and concentrated in older ages and in very specific areas (largely related to gang activity). The average software engineer with family is not going to run into any of that unless they are in the habit of leaving loaded weapons around the house.
Disease factors were probably the biggest factor in selection until very recently (and maybe now is just a temporary blip before a return to the historical pattern). Disease almost wiped out the Native Americans and strongly held sub-Saharan Africa back.
Especially with kids, it's difficult since you don't control how much they decide to eat making pre-bolusing meals challenging (part of why reducing carbs tends to be helpful for people is it reduces the need to pre-bolus and makes it less risky since you need less up front meal insulin).
It would be odd for a faulty sensor to cause an otherwise bad day into dka and death though. The sensor would need to be wildly off for hours and the user to not notice. Insulin delivery would need to be paused or greatly reduced for many hours. There are additional therapies like SGLT-2 that could make this more likely but they usually aren’t used with T1D precisely because they break the normally very strong correlation between inadequate insulin levels (leading to dka) and high blood glucose.
Even though I can’t think of an easy way for a false low(s) to turn into lethal DKA, that doesn’t mean it didn’t happen. Abbott sells a lot of CGMs. It could have been a contributing factor to several deaths even if the fault would almost always not be a significant issue.
In some cases, an excellent researcher even has cogent papers but is absolutely abysmal at lecturing and in person teaching skills.
Peers are very important, but from talking to others, it's harder to know where you will get good peers than you would think. Even 1st tier universities will have majors dominated by students whose primary interest is in maximum grades with minimum work and where cheating is rampant. You've got to either get lucky (I did) or put in some leg work to find smart students who are actually interested in learning and doing things right.
I think how much rote memorization is encouraged or required is strongly dependent on the field. Pre-med students will sometimes memorize their way through calculus; a professor I knew once described it as "grimly impressive".
For scientific simulations, I almost always want invalid state to immediately result in a program crash. Invalid state is usually due to a bug. And invalid state is often the type of bug which may invalidate any conclusions you'd want to draw from the simulation.
For data analysis, things are looser. I'll split data up into data which is successfully cleaned to where invalid state is unrepresentable and dirty data which I then inspect manually to see if I am wrong about what is "invalid" or if I'm missing a cleaning step.
I don't write embedded software (although I've written control algorithms to be deployed on it and have been involved in testing that the design and implementation are equivalent), but while you can't exactly make every invalid state unrepresentable you definitely don't punch giant holes in your state machine. A good design has clean state machines, never has an uncovered case, and should pretty much only reach a failure state due to outside physical events or hardware failure. Even then, if possible the software should be able to provide information to intervene to fix certain physical issues. I've seen devices RMA's where the root cause was the FPU failed; when your software detects the sort of error that might be hardware failure, sometimes the best you can do is bail out very carefully. But you want to make these unknown failures be a once per thousands or millions of device years event.
Sean is writing mostly about distributed systems where it sounds like it's not a big deal if certain things are wrong or there's not a single well defined problem being solved. That's very different than the domains I'm used to, so the correct engineering in that situation may more often be to allow invalid state. (EDIT: and it also seems very relevant that there may be multiple live systems updated independently so you can't just force upgrade everything at once. You have to handle more software incompatibilities gracefully.)
There is no royal road. If all your kids are biologically yours and you and all your family are good at math and you marry someone from a similar family, you can stack the deck maybe 95/5 in favor or your kid being good at math? But that option is already off the table if you lack that talent. And there are other things you should probably prioritize first!
If the main failure of British companies is that they don't have U.S. company market caps, it seems more off base to blame this on government science funding policy instead of something else. In almost every part of the economy, U.S. companies are going to be larger.
The article mentions but underrates the fact that post-war the British shot themselves in the foot economically.
As far as I'm aware, the article is kind of wrong that there wasn't a successful British computing industry post war, or at least it's not obvious that it's eventual failure has much to do with differences in basic research structure. There was a successful British computing industry at first, and it failed a few decades later.
And then there's a subtlety where units might be preserved, but x may be "absolute" where as (x - x) is relative and you can do operations with relative units you can't with absolute units and vice versa. Like the difference between x being a position on a map and delta_x being movement from a position. You can subtract two positions on a map in a standard mathematical sense but not add them.
It's fine for individuals to be motivated by curiosity or glory, but I think the probably incorrect on the individual motivation level idea that "we do math because it often turns out to be useful for other things; sometimes in obvious ways, sometimes not" is better if you want to argue why others (usually a government) should be paying for professional mathematicians. Otherwise, it's just a hobby and no one who isn't a mathematician should care if AI replaces 99.99% of professional mathematicians.
I hope AI causes enough of a shock to the field that more mathematicians become interested in finding problems outside of mathematics that can be modeled by problems with known solutions in mathematics and what sort of problems outside of mathematics suggest new mathematical problems. This is a real bottleneck in both directions in scientific and engineering work. Although AI can help with this, my experience with software, math, and science is it helps a lot to have a human in the loop who understands what to ask the AI to do and who are able to dig into the AI output when needed.