AlotOfReading

     Don't get me started with bike helmets

Bike helmets mitigate one of the most serious and common forms of injury while riding bikes. You can fall or be hit by a car/tree branch anywhere. They don't prevent you from doing anything you would otherwise do.

I'm someone who advocates for rolling back helmet laws because they decrease ridership, but helmets are a fantastic example of reasonable PPE, not overactive safetyism.

Let's imagine you're drilling oil instead. You have to spend billions of dollars over years finding and developing a new oilfield to make any profit back. And once you have it, you have to continuously spend enormous amounts of money to keep producing it, which means your effective price floor is higher than the current stable price.

Now it's 2021 and someone gets a tanker stuck in the Suez, sending the price of oil sky-high. How long does the ship have to be stuck before you spend those billions of dollars on a bet that it'll recoup before someone gets the ship out?

There's another way to view this that I think is even more elegant:

You start with facts, which are composed by rules. The current state at any given instant is the fixed point of the derived facts. Provenance is the path through the derivation graph. The whole thing is relational algebra, like SQL or datalog.

A helpful side effect of this perspective is that it can adjust our performance expectations. For example, You can do an in-memory, in-process relational query in microseconds for thousands or millions of rows, way more than any realistic game scene. Incremental updates, etc are nice optimizations, but just let'er rip first and see how fast it goes.

You can even do these kinds of queries fast enough to end up memory bottlenecked if you restrict yourself to queries with fixed graph degree, which is admittedly a mouthful to say (and understand).

I've never met a company I could convince to buy an Ada toolchain. Someone at Nvidia managed the feat and it's a pretty good measure of their enthusiasm that they seem to be pushing the hard work off onto adacore instead of spreading it internally.

Both. Though it's a bit hard to meaningfully distinguish the two when the president is showing up for photoshoots and regular meetings are held on what government official X thinks on topic Y.

> It is not part of the core library. It is certainly not meant as a reference-level implementation of math functions. It's there so you can write an easing function for a game without pulling in libc.

I saw the note and ignored it because it's not actually a repackaging of HHM. It simply happens to define a few vaguely similar functions. It doesn't reuse the naming conventions (MulVec3f vs vec3_scale), it doesn't reuse the interface (see SP_MATH_IMPLEMENTATION), and it's missing genuinely useful bits like the matrix functions.

Moreover, the quality of what's been added is significantly worse. Look at sp_sys_expf:

    f32 sp_sys_expf(f32 x) {
      f32 result = 1.0f;
      f32 term = 1.0f;
      for (int i = 0; i < 20; i++) {
        term *= x / (f32)(i + 1);
        result += term;
      }
      return result;
    }

I can't imagine a good reason why anyone (even an LLM) would ever write a 20th order taylor series for expf. A single FMA can improve on this and have capped relative error to boot, and that's not even a good way to do it. See what happens with your function at +-10 for comparison. At the f32 limit of 88, you achieve an honestly impressive 100% relative error.

Also, because sp_math doesn't use FMAs, your library isn't reproducible. Different compilers will produce different values. Reproducibility is a pretty nice property in games.

The natural comparisons are libraries like glibc and newlib, which do support lots of architectures and more importantly make porting to new architectures or taking advantage of platform features pretty straightforward.

That seems to be a pretty consistent quality level for the entire library. Look at the implementations in sp_math, yikes.

SAW/Cryptol are amazingly easy to use compared to other formal methods tools. It's a shame that C++ is still popular in high assurance spaces, because the tooling for it and the ability to write safe code is so much worse than C these days.

Not really sure how you got either of those, but you do you.

I've worked for an American megacorp and the branch office of a Japanese company. The Japanese company felt a lot more humane on balance, though it doesn't express as well when I write it.

The Japanese company had some rituals were a bit weird, but harmless/charmingly quaint like mandatory volunteer days, keeping a copy of the founder's precepts on my desk for executive walkthroughs. They also had some bad tendencies, like praising employees for being there at 6AM/8PM. If something didn't work, they'd give it a bit of runway to see if it could pull through before cutting back. When there were layoffs, it was the whole division failing (each division competed with the others). It's hard to imagine what kind of political statements would have been offensive to that employer, it was just a neutral job. Really, the worst part was subpar compensation (and I still felt spoiled compared to Japanese coworkers).

My next job was at an American megacorp. The executives would give a holiday speech about "social responsibility" and how well we were doing, then layoff a factory. The employer was constantly involving themselves with US national politics, but employees were expected to refrain from having political opinions of their own.

The vehicles have enough information to make the determination. Ground data is available in the point cloud and usually labeled as such. Water sometimes shows up in point clouds, sometimes it doesn't depending on conditions and wavelength.

If the apparent road surface is higher than the mapped ground surface, probably a puddle. If your point cloud has a big hole, also probably a puddle.

This assumes you aren't doing ground plane removal, of course. But it's quite likely that Waymo is using a heavily ML approach these days, and I can imagine the poor thing getting very confused if it's not an explicit training goal.

Human societies already have solutions to this problem. There's a proposed explanation for why strict religious groups (like the Amish) survive so well: costly signaling. There are benefits to remaining in the community, so you have to demonstrate adherence to the group by constant, expensive signaling to keep receiving them.

In a union context, that could be anything from dues, to volunteering for shitty work, to community service obligations. Unions don't really exercise the power to expel members though, because it reduces their own leverage.

That's Intel. Probably IBM too, though they've been doing mass manufacturing with TSMC (and GloFo before) for years instead of their fabs. I wouldn't be surprised if HP did similar things back in the 80s.

Would you be happier if they had cast the trans actor as the trans character (Tiresias), or would that also be a bridge too far?

How do you propose to predict the behavior of a true race condition with only the binary, faithfully translated by the compiler?

Moreover, this is at best an incredibly pedantic point, not something that changes how programmers need to approach UB. You can't review the source code of a compiler that hasn't been written yet.

In practice, both GCC and Clang consider pointers to these unaligned members to be UB and will flag them in UBSAN.

This isn't an answer. UB is not only code dependent, but in many cases value-dependent as well. Changing anything about a program has the potential to cause UB anywhere in the code graph affected. So even the smallest possible change requires you to fully understand that entire graph, as well as the entire compiler history and how it interacts with your program. Remember, UB isn't diagnostic and runtime sanitizers don't catch everything, nor does exhaustive testing and static analysis.

Emissions regulations are a balancing act. Industrial processes are inherently filthy. If you want copper, gold, lithium, or anything else that makes up the modern world, somewhere on earth was dirtied for that to be possible, and some of the pollution will get into the surroundings because zero emissions simply isn't possible. So we set certain levels of "acceptable emissions" as a balancing act.

I also agree that emissions should be tighter, but the location question is more interesting, because we can also choose where emissions happen.

For example, we might choose them to happen near cities/factories so the products are close to where they're used. We've mostly stopped doing that since the industrial revolution for pretty good reasons though. We could place them in the pristine landscapes not otherwise used by humans, like national parks. That's unpopular for hopefully obvious reasons. We could place them in sparsely inhabited deserts abroad, as Europeans did [0], before we collectively decided colonialism was a bad thing.

And lastly, we could place them in figurative deserts away from conservation land and people like monoculture farmland, but then we get to your question.

So, what's left? What are you suggesting as a better alternative?

[0] https://en.wikipedia.org/wiki/Bou_Craa

You still wouldn't be about to distinguish the output from noise unless you know the key or you've broken the cryptography, even if you know every bit of the message. Isn't it neat?

And yes, as the other comment points out it's only one source among multiple.

Smashing the glass wouldn't make it less effective. The sensor itself has noise, and the camera output is fed into an HMAC with a key based on the current nanosecond before being combined with a traditional entropy source before it ever went anywhere. Even then, it was only used as a seed for the entropy pool on the actual server.

I was confused and thinking that streaming mode and CNT were in separate extensions, but they're both in SME. My bad.

Anyway, essentially yes. My previous comment didn't mention all of the context. The join enforces that the result set is the intersection of the individual column sets, so it gets increasingly sparse as individual columns are computed. So I just maintain a bit tree that says which columns could populate the result set and skip computing the other lanes, which depends on the vector width and benefits from knowing it at compile time.

Other than databases, program analysis. The polonius borrow checker in rustc uses datalog internally.

But you can use it for lots of things. Whenever I'm frustrated with graph based tools being slow (like build systems), I run the graph through a datalog engine for comparison. It's usually much, much faster.

You can get Turing completeness by wrapping your datalog query in a while loop, so that's not particularly restrictive.

    Such as?

I have a database that has big columns that get functions applied to them to compute the result set. This is a perfect case for length agnostic instructions, except out ends up horribly memory bound. A nice optimization is to only compute those lanes containing rows that might actually be in the result set by keeping track of a sparse record that depends on the lane size. But the cnt instructions are optional, and this also inhibits compiler optimizations in that lookup.

Trying to abstract over SVE with a SIMD library is a bit of a fool's errand. The intended programming model is just too different from traditional ISAs, and there are algorithms that are nearly impossible to write efficiently for it. All the ones I've seen wrap it up as a bastardized fixed length ISA, and even ARM's own guidance basically recommends that approach.

Frankly, the length agnostic stuff is a mistake that I hope hardware designers will eventually see the light on, like delay slots.

That certainly convinced me. When I was doing my taxes recently and had to watch those forced loading animations, I kept asking myself "why can't my compiler do this?" Thanks to std::simd, now it can!

That's not teleoperation. Teleoperation has a human directly in the control loop, so latency and stability of the connection directly impacts the vehicle system's ability to maintain safety, because the input has to go vehicle<->network<->human to produce an output.

What those blog posts are talking about is a different strategy called remote assistance where the vehicle remains the only thing in the control loop, but a human provides guidance to help the computer navigate itself. This makes the latency and stability of the connection much less important for maintaining safety.

It's not unheard of for companies in the industry that use remote assistance to also have an local option for remote control (for things like lot operations and vehicle rescue events), but that's not part of routine on-road operations and it's usually limited to a <5mph limp mode where the operator is physically present.

Tesla's setup are a bunch of desks with steering wheels crammed together in a normal call center [0]. Waymo doesn't do teleoperation, but other companies exist that have like Vay. Compare their setup [1].

[0] https://pbs.twimg.com/media/GuE3ie2WcAAyeWs?format=jpg&name=...

[1] https://imageio.forbes.com/specials-images/imageserve/6828f0...

Every language has defined behavior. It's what you expect to happen through a program's execution. Sometimes there will be multiple possibilities, but you can still define them regardless. Laying this out explicitly is the purpose of a standard.

Undefined behavior is everything else. C and C++ are relatively unique in that their standards explicitly say "combining these constructs in this way is undefined", and we call those cases explicit UB. There's also a larger universe of implicit UB that standards omit. Most (all?) languages have implicit UB, even if they lack the explicit stuff. What happens when you get ENOMEM is a common one.

Rust does something similar to C/C++ and lists a bunch of UB that's only possible with incorrect code in unsafe blocks. Correct code placed in an unsafe block remains defined, as does code without unsafe (up to compiler/language bugs).