AlotOfReading

Not really. The precolonial southwest was fairly densely populated, with some areas exceeding their modern density. Population density grew sparser for various reasons after the mid-14th century until Spanish colonialism created some dramatic demographic changes. The southwest remained a pretty lawless place on the frontiers of empires where armed conflict was commonplace for the next few hundred years, until after the turn of the 20th century. Would you want to move into a civil war even if it had AC?

AC was coincidentally invented as all of this was clearing up, but it wouldn't become ubiquitous until decades later after the major cities had been established with large populations. And even then, I'd blame cheap accessibility of long distance transportation more than AC for the modern state.

Imagine you have two blackbody radiators with the same bulk properties, except one has surface area shenanigans like aerogels. In the far field as a whole, it seems like both should radiate essentially the same regardless of the internal details. You can shape emissive direction, or improve efficiency of non-ideal materials, but even ideal materials don't fix the issues pointed out by the parent.

There's perfectly legitimate ways to argue against the existence of natural rights (see Bentham), but this strawman ain't it.

You can do whatever you want to your car in the US as long as it remains roadworthy, which is basically compliance with FMVSS and state laws. Want to guess what rules don't have much to say about driver assistive technologies?

    Otherwise they would have the appropriate insurance, like any company that trades in any dangerous business.

What is "appropriate insurance"?

As far as I'm aware, virtually every state with an AV pilot program requires insurance (either commercial or self-insured, as typical for commercial vehicles) in order to be permitted. Several major markets (e.g. California) also require an additional bond to cover issues and have a gradual expansion process to better understand unknown risks.

Humans have a remarkable ability to be apparently cognizant and engaged with tasks, without actually using higher level awareness. One example of this is distracted driving while talking handsfree or lost in thought.

Driver monitoring is better than nothing, but it's not the same thing as an engaged driver.

I've yet to see any form of certification or paid code review I'd be willing to bet critical infrastructure on. And working in safety critical software, that's not for lack of trying. Good review is usually harder than building a working system and the asymmetry of offense and defense applies to anything you miss.

    floating point arithmetic, as used today, foregoes determinism, and this results from the very ethos of the foundational IEEE754 data type

This was somewhat true in the past, but the situation has been improving dramatically in recent years to the point where FP determinism is completely feasible. The remaining hurdles are primarily on the toolchains/kernel side. I have a library called rfloat that you can drop into most C/C++ code for practical determinism without thought (subject to documented caveats), for example. You can do the same thing manually with some more careful attention.

I'm in a very remote corner of the world on bad Wi-Fi though, so you'll have to forgive omitted links.

A neat trick many people aren't aware of is that you can treat binary floats as saturating fixed point, subject to some qualifications (generally the next larger float type can represent any given fixed). Float operations internally are "just" fixed point ops with some normalization steps and rounding bits on each side, so if we use a float type with enough mantissa bits to hold the fixed point value all we have to do is mask off the extra precision to get back to fixed point. This similarity to fixed point is exploited in some modern NPU hardware by storing only one exponent for an entire block of floats, with a wide fixed point unit doing the actual work, a.k.a block floating point.

This hack has some interesting advantages. Float to integer is still only a few cycles, the masking is one line of libm functions, you get better (and dynamically selectable!) precision, it has gradual underflow and overflow, you can write numeric code like usual, and normalization is automatic.

Floats are deterministic, but I get what you mean. Let's discuss what's meant by the result of a complex calculation. 0.1+0.2, or sqrt(2), or whatever.

1. Do you want your result to exactly encode the answer without rounding error? No fixed precision type can provide this in general, so you're stuck with symbolic approaches. If you can bound things (usually difficult), maybe you can get away with non-symbolic approaches.

2. Do you want a sensible numeric answer? This is what floats (and many other systems) give you. The definition of "sensible" is inherently tricky here and there's not a definition universally appropriate to every possible computation.

So let's return to 0.1+0.2=0.3000...1 specifically. There's two common ways to think of an encoded float. One is as the directly encoded value, as you're doing. Another way is to think of it as an interval of real numbers between the next lowest and highest intervals. Under this latter interpretation, it makes sense to discuss shortest decimal string within the interval, 0.3 in this case. There's no ambiguity because each real lives in exactly one interval. This is what algorithms like dragon box do for float to decimal string conversion.

What decimal floats give you is an encoding that tracks significant digits, where every decimal string exactly corresponds to a midpoint of an interval of reals. They do this at the cost of space, speed, and complexity. You don't get an escape from the fundamental issues of fixed precision types like rounding error, numerical sensitivity, precision loss, etc. I don't think that tradeoff makes sense for most algorithms in most contexts.

The benefit of sticking with floats is that lots of smart people have spent countless hours trying to give non-experts a "good enough" path through the untamed wilds of numerical analysis, tooling to help them when they get lost, tribal knowledge to point out the edge cases, and it's almost universally supported in hardware. By all means you should go wandering off the trail, but fully understand what you're doing and why beforehand.

Usually, if you know enough about your algorithms to select an appropriate float alternative, you also know enough to fix your float code and that's what you should actually do.

That said, some of these aren't alternatives. Symbolic computation is a different thing entirely. Interval arithmetic can be built atop floats (e.g. IEEE-1788) and has its own zoo of unintuitive behaviors. BCD is better called a historical artifact than an alternative these days.

It's really just rationals and decimal floats in this list, which probably don't solve the issues you have if you're considering float alternatives.

This is a thinly disguised broken window parable.

If everyone goes around mowing lawns for each other, the economy is richer in lawn mowing at the expense of all the other things that would have been funded had everyone mowed their own lawns and purchased different services instead.

Most non-CS hashes should have two parts:

1. A permutation that does as much as possible of the actual bit-mixing and

2. The simplest compression rule possible, though combining can be tricky.

Good permutations are much easier to design than good hashes, and one of the main ways hash functions are used is consuming integers smaller than the state space. May as well take advantage of provably ideal behavior.

My middle school had a reading program where the monthly winner would get a book of their choice from the scholastic catalog. This was a very enticing prize to a poor, voracious reader like me.

After winning my way through the Hobbit/LOTR series, they changed the rules specifically for me to require oral exams on each of the books I was reading, and later book reports. I was eventually banned completely so there could be an actual competition.

You only have to assume that some instances of piracy would have led to an actual sale and adjust the lost present value to p*price on average.

Reminds me of Michelson's (of Michelson-Morley) famous statement in 1900 that all of physics had essentially already been discovered, so the only remaining work was to apply what was known to new experiments. Similar statements were made about chemistry after Mendeleev and history after the cold war.

There's deprivation of future value and deprivation of present value. The owner can continue to sell a digital apple, but it's not clear to me that "theft" inherently deprives the owner of future value. For example, I could steal your car for a night of joyriding and return it unharmed the next day. You might reasonably say that a theft occurred even though you retain the car afterwards. Note that I'm aware this example isn't perfectly analogous to digital goods.

Is that a serious question? Many people would consider Potala palace, the Milan Duomo, Neuschwanstein, etc more beautiful than anything designed by Zaha Hadid and Gehry. Myself included, even as someone who likes their work. Limiting ourselves only to the category of modern event centers, I'd still put the Harbin Grand Theater ahead of it.

Or have a cut in the outer ring with an insert filling the gap. A partial ring is easiy to bend outwards, but difficult to bend inwards.

There's a fair bit of overlap and people who work in both, but yes, they're distinct specialties. I wouldn't say upset though, except in the sense that grocery store clerks are upset by "if it doesn't scan it's free" jokes.

I've been developing a suspicion that many people simply aren't looking at what their agents produce and can't speak to the quality of it in a fully informed way.

For context, I've set up harnesses with recursive automated review loops, spec driven development, explicit lists, better models, better harnesses, formal methods tooling, etc. All of it helps, but they don't eliminate output issues. Those become very apparent when I go through the slow, manual work of deeply comprehending / validating LLM code.

And that leads me to one of three conclusions. Either my standards are achievable only by hyperintelligent programming gods, I have a skill issue using LLMs, or others aren't applying the same level of attention.

The first is obviously untrue. I meet my own standards and I'm an idiot. The second seems unlikely because I can see my competent coworkers and well-regarded people in the community discussing the same issues. So that leaves the third.

It's not known for certain how it was done and we've never found a sketch as far as I know, but some form of master plan is generally suspected for figure mosaics. The customers purchasing the mosaics to be constructed would have selected the images and motifs depicted beforehand and would have lacked the skills of the artists to imagine them in tile. Some of the fancier mosaics also involved custom tiles that had to be manufactured beforehand, and knowing how many are required is valuable.

It seems likely that some simpler mosaics and patterns were done straight from the artist's mind though.

It's the problem of the banality of evil. Stopping someone from dramatically pressing a big red button doesn't solve humanity's largest problems because that's not what caused them. We need to stop millions "boring" actions done by systems blindly following instructions without regard for the consequences.

If the buttons are incompatible with the absence of the feature, I'd expect the buttons not to exist when the feature is disabled. Anything else seems like a straight up footgun. I guess it'd also be acceptable to pop up a scary warning box asking "are you sure?"

You could have looked up the collisions instead of making vague accusations of bad faith. In one, a Tesla going 98MPH collided with a line of vehicles (including a Waymo) stopped at a light. In the other, a motorcyclist hit a Waymo from behind and fell off their bike, where they were struck and killed by another vehicle (that fled).

There's no legislated standard in the US, nor pre-sale verification that a vehicle has met most of the other automotive standards. That's just not how the US regulatory environment works.

There's the beginnings of a standard for L2/L3 vehicles in Europe, and ongoing discussions about what L4 standards could look like, but neither addresses "adversarial" situations.

An ADAS would be L4 if it was designed to be truly autonomous. If it's not designed to be truly autonomous, you have to somehow address the attention problem. Even a good attention monitoring system isn't sufficient, because people have the ability to appear superficially attentive by all external metrics, while not engaging with the driving task mentally.

The data to differentiate these levels is pretty limited for a variety of reasons, and the problem only worsens when you conflate AEB with ADAS as the IHS/IEEE do in this article rather than use an OEDR-based definition.

    using C safely is 99% just using Valgrind and some specific GCC or llvm flags and you’re done

I wish that were the case, but it's not. Dynamic analyzers are fantastic and everyone should be using them constantly, but they don't solve the problem of UB. They tell you whether your code, as translated by a specific compiler using a specific set of flags today has detectable problems. There are still gaps, and what's true today might not be true even for the same source code built tomorrow, or given different inputs. Asserting my safety-critical code does X or Y is important to me, and neither C nor C++ have standard tooling that fully addresses that need.

Other languages are much farther along than this. You can in theory take a pile of Rust and isolate exactly the points where undefined behavior might occur, or eliminate them entirely in Ada/Spark.

Your house has walls to attenuate photons.

    I don’t even know what “see the file system” means.

It just means they want to see the hierarchy that the filesystem exposes. Here's a useful diagram [0] from the Wikipedia page on hierarchial file systems [1]. There are ways to show paths and directory structure in finder, but you're fighting against the intended usage.

[0] https://upload.wikimedia.org/wikipedia/commons/thumb/2/2c/Fi...

[1] https://en.wikipedia.org/wiki/Hierarchical_file_system