"broke" is arguably an overstatement. C++20 deprecated some (most?) operations on volatile variables [0] in part because they can misleadingly imply an atomic operation:
> volatile external modifications are only truly meaningful for loads and stores. Other read-modify-write operations imply touching the volatile object more than once per byte because that’s fundamentally how hardware works. Even atomic instructions (remember: volatile isn’t atomic) need to read and write a memory location []. These RMW operations are therefore misleading and should be spelled out as separate read ; modify ; write, or use volatile atomic operations which we discuss below.
This was not received particularly well in the embedded community (e.g., [1]) due to said deprecation affecting compound bitwise operations on volatile variables, which are extremely widely used to interact with hardware registers. This pushback eventually resulted in C++23 un-deprecating compound bitwise operators on volatile variables [2].
Basically on a rare occasion somebody (JF Bastien) was able to land a C++ proposal which warns you if you'd do something stupid, and inevitably C programmers cosplaying as C++ programmers insisted "it's not stupid it's advanced" and so now C++ must not even warn you this is a bad idea.
It still is a bad idea, but being warned would make them feel bad.
Wondering: if the process for the upper part of the sandwich is the complement of the process for the lower part, why was it so much more difficult? What would go wrong if you took one of the earlier lower-sandwich processes, and complemented it in a similar way? I have to assume it's something, but what?
What goes wrong is the accuracy guarantee. Complementing gives an upper graph, but the old guarantee doesn’t establish that it’s close enough to the target graph - which is what the theorem requires…
At least according to this article[1], you're correct; the practice of eating brains that caused kuru to spread was a recent innovation. However, the article doesn't say how recent. I guess I'd need to go read the actual book, since I can't quickly find anything else on how long this was occurring.
So I got a really high score before I signed in, only signed in afterwards, and now, even though my high score displays on the "best wave" display for me, it's nowhere on the global high score board. I'm just going to have to, like, get it again somehow?? That's annoying.
So on reading this comment I was like, "oh, I see, Arby's, like RB, roast beef?" Except on looking it up, that's not the explanation! "Arby's" does come from the initials "RB"... but it doesn't stand for "roast beef", it stands for "Raffel brothers"! Rather less obvious.
>Friends that worked their described the "beef" as being a weird loaf of pressurized mewt-like protein before its sliced
It's just deli meat. Arby's is extremely open that their roast beef is deli meat roast beef. It's no different from what you find at the deli counter in your local krogers.
Have you or your friend never seen deli meat before?
The article mentions at the end the problem of coloring graphs on other surfaces. It's worth noting, it's known, for every surface, what the maximum chromatic number is of a graph on that surface: https://en.wikipedia.org/wiki/Heawood_conjecture
The odd thing about the Ringel-Youngs theorem is that proving the upper bound on the chromatic number is, with the exception of the case of the sphere (i.e., planar graphs, i.e. the four color theorem), not that hard. For the sphere, the lower bound is easy and the upper bound is hard; for other surfaces, the upper bound is easy and the hard part, if any, is the lower bound! (And then also the Klein bottle is an exception and requires only 6 colors instead of 7, so that one also requires a separate more-involved upper bound argument, but nothing on the scale of the four-color theorem...)
Location: New York City
Remote: Yes
Willing to relocate: If it's on the east coast, yeah maybe
Technologies: JavaScript, TypeScript, C, Haskell, Solidity, C#, MUMPS
Resume: https://haltman.neocities.org/resume.pdf
Email: harry.j.altman@gmail.com
Hi, I'm Harry Altman! I was the maintainer of Truffle Debugger (https://github.com/ConsenSys-archive/truffle/tree/develop/pa...), a Solidity smart contract debugger, for 5 years. I eventually ended up writing my own decoding and encoding libraries to support it, as well as a bunch of other things.
I'm good at this sort of nitpicky work, spotting and thinking about edge cases. I like getting things exactly right, even though that obviously isn't always possible due to various constraints. I've been kind of wondering if I should get into embedded development; I find it appealing when things are low-level or similarly constrained. I've beaten Microcorruption. :) (The original levels, I haven't played the new ones.)
I'm also quite interested in unusual or obscure data formats, and working on Truffle Debugger and its associated libraries certainly involved a bunch of having to figure undocumented formats and interfaces. :) I put down above what languages I've worked substantially in but I'd say I'm a generalist and will figure out whatever you give me (I knew approximately no Javascript, Typescript, or Solidity when I started working at Consensys).
I'm a mathematician by background and in my spare time, so after the Truffle Debugger project was shut down I took some time off to focus on my mathematical projects, including old ones I've been shepherding through publication. But now I'm looking for work again! If you need someone like me, I'm available for hire!
reply