AlotOfReading

Unit mistakes happen all the time, which is why you should be using your units library religiously and still being vigilant even then.

Worst case I've found was off by 15 orders of magnitude.

China has an explicit national policy to build high bandwidth network connections across the arid Western half of the country called the digital silk road. And on the scale of China's other projects in the west (e.g. mining, large scale agriculture, chemical plants), the water usage of a data center or ten is a rounding error.

I don't know if they're actually building AI DCs out there, but it doesn't seem completely unreasonable like you're suggesting.

Obviously I'm under NDA, but the data I've seen at $(OEM) was down to the level of variant tracking and real time geolocation. The commercial fleet management programs can do things like scheduled updates and know what hardware/software is in each component of each vehicle, which the manufacturer has to keep track of anyway for recall purposes.

    Rather than hamstring all software by requiring DOT testing before firmware updates are published...

I don't know how the rules work in the UK or Ireland where the author is, but the US has no such mandatory testing. Also, all manufacturers have telemetry these days and the ones I'm familiar with all do gradual rollouts (to varying levels of competence). You basically can't do immediate rollout given the scales involved.

Please don't take this as suggesting any of them are good at software, mind you.

It seems like it'd be pretty reasonable to get something akin to polonius. I can write up an engine in zig if it'd help?

Downsizing is effectively low pass filtering, so that's expected. Any scheme that transmits different messages in different frequency bands is going to be susceptible to a similar attack.

"Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.

I've noticed that people equate "low level stuff" with unsafe, regardless of whether it's contextually justified.

I suspect we'd see management companies trying out auctions and upgrade bidding not long after a resale prohibition passed. Or they'd reinvent the fare class system airlines use.

There are decades old papers [0] on this subject that explicitly use humans as a analogy and call it "reproduction" because of the need to learn or evolve for local conditions. I don't think using terms in a way they've been used since the first serious analysis of the concept is going to confuse anyone.

    I think it's pretty extreme to imagine their nth descendants caring about the goals of the parent civilization.

It's an example to demonstrate the concept in familiar terms, not a psychohistorical prediction.

[0] https://www.rfreitas.com/Astro/ReproJBISJuly1980.htm

You're making assumptions that the parent isn't necessarily making. Imagine sending humans to other earthlike planets on hypothetical generation ships. Those humans could throw away their technology and rebuild from zero over thousands of years to send more spaceships of humans to yet further planets. Presto, an example of self-replicating biological von Neumann systems.

When the printing press was invented by Gutenberg, it wasn't used to produce finished documents. Printed books had large margins and omitted initial letters to leave space for the manual steps of rubrication and illumination. Plus, the printing itself was a product of huge amounts of manual typesetting effort.

The results speak for themselves. Those early printed works are beautiful to a degree few other books have managed since.

I don't want to rain on discovering a genuinely cool bit of theory, but it's not "new" per se.

The equivalence with Einstein summation was noted in this paper [0]. Sandia labs wrote an SQL database based around graphBLAS called TenSQL a few years back. And something similar to your idea of relational algebra as the basis for AI had a paper published earlier this year [1], naming it Tensor Logic.

    Are all of these common operations secretly relational, just with the wrong data model?

Sadly not, but you can get a long way before you find the limits. Modern databases are very well optimized for their use cases, but there's many other possible points in the design space to explore. If you want to really make efficient use of hardware, there are fundamental scaling problems with natural joins because of the combinatorial explosion that gives us WCO though. If you accept an inability to express triangular queries, you can get something that's embarrassingly parallel and scales really flipping well.

If you want to stick to the full relational model, you might be interested in Differential Dataflow [2].

[0] https://arxiv.org/html/2510.12269v3

[1] https://arxiv.org/html/2601.17188v1

[2] https://github.com/TimelyDataflow/differential-dataflow

Hence the existence of services like The Work Number.

I prefer the maximalist perspective: France is West Asia.

I don't see how Tesla is a serious competitor in that matchup. Their sales have been declining for two years, and Chinese OEMs are clearly on the path to complete dominance in most foreign markets.

In the US market, I think Hyundai (and to a much lesser extent Kia) is probably the most interesting OEM. EV sales that aren't declining, the highest American-made percentage vehicles (relevant given recent policy changes), a manufacturing partnership with Waymo, widespread consumer awareness, and relatively lower prices than their competitors. It'd be nice if they provided a better repair situation than Tesla, but that's the current industry I guess.

I don't know much about real query planners, but if I understand what you're saying there may be ways to improve the situation.

If you stick to the safe bits I've been discussing elsewhere in this thread and your platforms implement IEEE floats, float math will also be commutative + associative and you won't have to deal with precision loss. That means your usable range will be narrower than the same size fixed type (because it's limited by the mantissa) but it's large enough to still be useful.

Totally agreed that f32s can be awkward. I'm really just arguing that most of the time, you're better off starting with floats and seeing if there are issues. If there are, you can often take advantage of float tooling (e.g. fpchecker [0]) to make better choices about how to proceed, since virtually no one does numerical analysis on commercial codebases in my experience. Sometimes you can skip that if there's an obvious reason (e.g. no float HW, FPGAs), but the general direction of software seems to be towards universal availability.

You're right about that particular constraint, though I'd question why the achievable 2-4mm precision at 32 or 64km are meaningfully different. Covering up unstable collision code and adaptive methods would be a rewrite?

[0] https://fpchecker.org/

    - Transcendental functions (exp, sin, etc.) are really hard (multiple literal PhDs) to implement according to the rules I’ve just described (“correct rounding”), so you’ve only been able to get such implementations in the last few years, and I believe no stock libm has completely switched so bring your own if you need them.

This is right, but it's useful to point out how important the "correct rounding" qualification is to the difficulty of the problem. Writing a "good enough" function with floats is easy even for non-experts. exp can be efficiently implemented in hardware with a 4 element lookup table and polynomial interpolation. Sin/Cos are range reduction + a minimax polynomial from sollya. But the standard [rightly] doesn't prescribe specific implementations, so you need fully correct rounding to have cross-platform determinism.

Correct transcendentals are also difficult in fixed point. When pigweed was implementing them for their fixed impl, they got help from from an ex. Mathworks floating point expert on the LLVM team with a relevant PhD to do it correctly [0].

[0] https://pigweed.dev/blog/04-fixed-point.html

I'm sure it would, but my argument is centered around the world we actually live in right now.

    First, a point I didn't make, is that if you have 32 bits of fixed, you get way more precision than with a 32 bit float.

That's true, but I already responded to it. If you step up to the next size of float (e.g. f64), you have more precision than the fixed32. You can do exactly the same computation in f64 with equivalent inputs, and you'll get better precision than doing it in fixed32. Or you can round at every step like fixed does and get a bit-equivalent value if you don't want the precision. It's less memory efficient, but my point is that the remaining use cases for fixed point are exceptional/situational and getting increasingly niche.

Maybe using a bigger float type is cheating, but it's basically free because of the ubiquitous support for floats.

    In contrast, with floats, you can lose precision.

This only happens with values outside the range of your fixed point type if you use larger floats as mentioned above. I consider that a different argument. You can alternatively view this as the float handling a situation more gracefully than fixed point would have.

    Afaik finance people don't even use floats for things like account balances, because you can't represent something like 0.1$ exactly.

Finance types typically use decimal types from what I understand. This is really just the result of using a decimal syntax to initialize/output a binary representation. Fixed point has exactly the same problem. Decimals have an analogous issue with the value 1/3.

    It has other advantages, like your calculation running the exact same regardless of CPU and/or compiler, which I'm sure a lot of analysts care about.

I wrote a library that makes floats more practically deterministic across platforms for very little cost (linked at [0] so you can see the limitations and numbers), and the underlying problem is [maybe] getting a standardized solution in C++29. You can get the same thing today just by changing compiler flags. If you need the special, non-reproducible float functions, your options are mainly to import a library or implement it yourself, same as fixed point.

    Not trying to be antagonistic, just figure out where you're coming form.

I work in safety-critical automotive/robotics, used to do audio DSP, contributed a bit to the aforementioned standardization, etc. I also have a talk on this topic I've been working on for the last few weeks. It's a bit of a pet subject.

    Fixed point has basically no language support, and is very hard to get right, but sometimes you need to do that.

There are absolutely situations for it, but that's exactly it: it's situational. And those situations are increasingly uncommon these days, now that hardware with good IEEE support is essentially ubiquitous and compilers/standard libraries are improving their implementations.

[0] https://github.com/J-Montgomery/rfloat

As I said, floats can provide results that are no worse than a specified fixed point type. So if you want uniform absolute precision, just round down to the required precision.

Floating point is generally deterministic in practice with a fairly minor amount of effort, the major remaining issue being library rounding. I actually wrote a library that guarantees this for arbitrary code, with some small, obvious caveats like standard library precision. And the conference talks linked above note, the standard library issues are an increasingly solved problem for modern toolchains. The remaining cases are mostly things you won't do in fixed point. Let me know if you're aware of anyone computing erfc in fixed point for determinism though.

I'm not saying there aren't any situations where other systems are justified, but you probably won't know if you fall into any of them without the kind of numerical analysis that most codebases will never receive.

I recommend pretty much everyone avoid fixed point and other float alternatives, barring exceptional cases after you've done your own numerical analysis, or you lack floating point hardware (rare these days).

Yes, fixed point can use simpler hardware. That's also a completely irrelevant consideration for software. The vast majority of processors are optimized for floats now and some operations (e.g. division) are actually faster.

The precision argument also falls apart. Any float with mantissa >= X+Y can get exactly the same results as a QX.Y fixed point. The float will actually perform better across the same range because you have to round it to perform like the fixed point. That means more precision, lower error, automatic normalization, better overflow behavior, a larger working range, etc. And it'll probably be just as fast, unless you're bottlenecked on memory bandwidth of inputs (unlikely). When you inevitably want an exp() or another special function, it's a heck of a lot easier to call libm than implement your own and it will perform better.

Floats are also much easier to get right for your coworkers that aren't numerical analysts.

This is one of my favorite pieces of internet writing, up there with the SR-71 speed check and the Story of Mel. Every time I see it, I have to read it again and end up giggling through the whole thing.

Grass doesn't prove it's fertile before modern fertilizers. Natural grasslands are often resource-poor places that most other plants can't tolerate. We sometimes replace one for the other because our main crops (wheat, maize, rice, sorghum) are all grasses, but e.g. Versailles probably would have had more forests, lakes, or a vineyard if it didn't have the gardens and lawns.

I wonder if it's as much of an issue with those big boats at sea. The wavelength gets pretty long off the continental shelf, so I imagine it's a lot less adjustment than lake waves, with the exception being storm conditions you should probably avoid anyway.

Come on. Her comment was

   "What’s up Outragers, just dialing in from my NBA team’s headquarters to yell at the people whose careers I’ve just pummeled"

In a water cooler channel, while the CEO was calling in from his NBA team headquarters to announce layoffs...

It's mildly dramatized, bordering on milquetoast satire of exactly what he was doing.

That's a monkey's paw desire because nowhere is Hyrum's law more true than programming languages. Alternatively you just end up with something like C++ where no one understands the whole thing.

The somewhat abbreviated answer is that the "state" is formalized into the concept of fields. All the physical properties we can observe are from coupling with the relevant fields. The speed at which changes can propagate in fields is C, hence the speed of light being the same value.

Programming skill is similar to driving skill. You can hire the best people in the world and there'll still be incidents. The people who are most skilled may even be more incident-prone because they have the skills to take more risks.

Don't bet the company on no one ever making a mistake. Set up a system where the unintentional risks are minimized and the consequences of inevitable failures are mitigated by seatbelts and insurance policies.