Daily Digest — 2026-07-01

Everyone remembers the Concorde. Almost nobody remembers that by 1975, Aérospatiale and the British Aircraft Corporation had already designed its replacement — the Concorde B — and were within months of cutting metal when the program was quietly strangled in the crib.

The original Concorde, which entered commercial service on 21 January 1976, was a compromise aircraft. Its Olympus 593 engines needed afterburners to break the sound barrier, burning roughly 25% more fuel than cruise required and generating the notorious takeoff noise that got it banned from most American airports. Its range of 3,900 nautical miles left it stranded on Pacific routes. Its cabin held only 100 passengers because the fuselage had been frozen in 1965 to hit the delivery timeline.

The Concorde B fixed all of it. The design was frozen in 1975 by a joint Aérospatiale/BAC team led by Lucien Servanty's successors at Toulouse. The changes were not exotic:

• Olympus 593 Mk 622 engines — a redesigned combustor and larger low-pressure compressor that eliminated the afterburner entirely. Rolls-Royce and SNECMA had run the new burner cans on test stands in 1974 and hit the target: dry supersonic cruise at Mach 2.04.
• Extended wing leading edges with a small droop and a subtle increase in span. This raised lift-to-drag at cruise from 7.5 to about 8.1 — a 15% range improvement on paper, verified in ONERA wind tunnel runs at Modane.
• Higher fuel capacity in reshaped wing tanks, pushing range to roughly 4,500 nautical miles — enough for New York–Los Angeles nonstop, or Paris–Tokyo with one stop instead of two.
• Quieter takeoff — the non-afterburning departure would have cut sideline noise by an estimated 8 EPNdB, potentially opening JFK, LAX, and Sydney.

Development cost was estimated at £250 million — trivial compared to the £1.3 billion already sunk into the original. British Airways and Air France had provisionally ordered 16 airframes between them. First flight was projected for 1980.

Then, on 4 February 1976 — two weeks after Concorde's commercial debut — the British government withdrew funding. The French followed within months. The stated reason was the 1973 oil shock and pessimistic sales forecasts. The real reason was that Boeing had killed the 2707 SST in 1971, and without an American competitor there was no political prize left to win. The B was cancelled before the A had even completed its first year of revenue service.

Why now? Every technical problem the B was solving has since been solved in fragments: variable-cycle engines (GE's XA100), advanced CFD-shaped wings, sonic-boom-shaping fuselages (NASA's X-59), and modern composite fuel tanks. Boom Supersonic's Overture is essentially reinventing the Concorde B airframe with 50-year-newer materials and 40% less fuel burn per seat. The Rolls-Royce archive in Derby still holds the Mk 622 combustor drawings. The ONERA wind tunnel data still exists. A modern reboot would not be a research project — it would be an engineering exercise on a design that was 90% complete when it was shelved.

We spent 27 years flying the compromise aircraft and zero years flying the one that fixed it.

Imagine you're handed a piece of code where every variable is named a1, b2, c3, the control flow has been scrambled into a knot, and dead branches have been sprinkled in to throw you off. That's code obfuscation: deliberately messing up code so it still runs correctly but becomes painful for a human to read. Malware authors use it to hide what their programs do. Companies use it to protect intellectual property. Reverse engineers hate it.

We already know a fair bit about how obfuscation breaks human understanding. But here's a fresh question: do large language models (LLMs) — the same AI systems that increasingly help us read, review, and reverse-engineer code — struggle in the same places humans do? Or do they fail in totally different ways?

This paper takes a recent human study on code comprehension and rerouts the same experiment through several LLMs. The researchers used a framework called the Block Model, which slices "understanding code" into four layers:

• Atom — recognizing individual tokens and statements
• Block — grouping statements into coherent units
• Relational — tracing how blocks depend on and pass data to each other
• Macro — understanding the program's overall purpose

They ran LLMs through five escalating tiers of obfuscation and measured where comprehension broke down at each level.

The key finding: LLMs and humans don't fail in the same way. Humans tend to stumble first at the local, low-level details — once variable names and structure are scrambled, working memory gets overwhelmed and everything downstream collapses. LLMs, by contrast, are surprisingly resilient at the atom and block levels (they can chew through weird identifiers just fine) but tend to fall apart at the relational and macro layers — the "what is this program actually doing, end to end" reasoning that requires holding a mental model together across the whole file.

That mismatch matters for anyone leaning on AI to help with reverse engineering, malware analysis, or auditing minified/obfuscated code. It suggests LLMs are useful for the tedious surface-level cleanup work — renaming variables, un-tangling a function — but shouldn't be trusted alone for the big-picture "what does this malware do?" question. And it points to a real weakness: obfuscation techniques designed to defeat humans by exhausting local working memory may not fool an LLM, while techniques that shred cross-function relationships will.

You spent months picking primary tube diameter, merge angle, and collector length. Then you bolt a 3-inch exhaust to a 2.5-inch collector exit and undo half your work. The collector exit pipe — that short stub of tubing between the merge cone and your exhaust flange — is the handoff point where header tuning meets the rest of the exhaust system, and getting the diameter wrong bottlenecks everything upstream.

Why exit diameter matters: After the merge collector diffuses spent gases and drops velocity, the exit pipe carries that flow to the downpipe or X/H-pipe. Too small, and you create backpressure that stalls scavenging at the merge point — the vacuum wave never fully forms because gases can't evacuate downstream fast enough. Too large, and gas velocity crashes below the ~240–300 ft/sec sweet spot needed to maintain momentum, killing low-end torque and creating a lazy, boomy exhaust note.

The sizing rule of thumb: Collector exit area should roughly match the sum of primary tube areas divided by 1.4 to 1.6. For a 4-into-1 with 1.75" primaries (2.405 sq in each = 9.62 sq in total), divide by 1.5 and you need ~6.4 sq in — that's a 2.85" exit, so you round to 3-inch. Twin-turbo V8s with 1.625" primaries typically land on 2.5" exits per bank.

Real-world example: The C6 Corvette Z06 (LS7, 7.0L, 505 hp) uses 1.875" primaries into a merge collector with a 3-inch exit — feeding directly into 3-inch X-pipe. GM's dyno data showed that shrinking the exit to 2.5" cost 12 hp at peak and 18 lb-ft at 3,500 rpm. Bumping it to 3.5" cost 8 lb-ft below 3,000 rpm and added nothing up top. The 3-inch exit was the compromise that kept both scavenging velocity and top-end flow.

The transition matters too: A sudden step from a 2.5" collector to a 3" exhaust creates a turbulent expansion zone that reflects pressure waves backward. Best practice: gradually transition inside the collector's diffuser cone itself, or use a 2–3" long tapered adapter. Straight step-flanges cost 3–5 hp on most builds.

• Undersized exit: bottleneck, hot EGTs, lost top-end
• Oversized exit: velocity crash, weak torque, droney note
• Matched exit + smooth transition: preserves everything the merge collector built

This function builds a URL by chaining snprintf calls into a fixed-size buffer, advancing a cursor after each write. It looks defensive — every return value is checked, and there's a final overflow guard.

#include <stdio.h>
#include <string.h>

/* Append base + "?key=value" into buf. Return 0 on success, -1 on overflow. */
int build_url(char *buf, size_t bufsize,
              const char *base,
              const char *key, const char *value) {
    size_t used = 0;
    int n;

    n = snprintf(buf + used, bufsize - used, "%s", base);
    if (n < 0) return -1;
    used += n;

    n = snprintf(buf + used, bufsize - used, "?%s=", key);
    if (n < 0) return -1;
    used += n;

    n = snprintf(buf + used, bufsize - used, "%s", value);
    if (n < 0) return -1;
    used += n;

    if (used >= bufsize) return -1;   /* the "safety net" */
    return 0;
}

Fuzz it with a 32-byte buffer and a 100-byte value, and you get a heap corruption crash — sometimes. Other times it silently writes a mile past the buffer. The final if (used >= bufsize) check does fire, but only after the damage is done.

The Bug

snprintf returns the number of characters that would have been written if the buffer were large enough, excluding the null terminator — not the number actually written. C99 was explicit about this to let callers size buffers by probing. But it means used += n can advance the cursor past bufsize.

Now watch what happens on the next call: bufsize - used. Both are size_t, which is unsigned. Subtracting a larger unsigned from a smaller one wraps around to a value near SIZE_MAX. So the next snprintf is told: "you have 18 quintillion bytes at buf + used, go wild." It obliges, writing far past the end of the allocation. By the time the trailing used >= bufsize check runs, you've already scribbled across the heap.

The seductive part: on small inputs everything works. Tests pass. The overflow only surfaces when the middle field truncates — the first-and-last-field cases behave. And the checked return values feel like belt-and-suspenders safety, which makes the reviewer's eye slide right past.

The Fix

Detect truncation at each step by comparing the return value against the remaining space before advancing:

int build_url(char *buf, size_t bufsize,
              const char *base,
              const char *key, const char *value) {
    size_t used = 0;
    int n;
    const char *parts[] = { base, "?", key, "=", value };

    for (size_t i = 0; i < 5; i++) {
        size_t remaining = bufsize - used;
        n = snprintf(buf + used, remaining, "%s", parts[i]);
        if (n < 0) return -1;
        if ((size_t)n >= remaining) return -1;  /* truncated — bail */
        used += n;
    }
    return 0;
}

The key line is (size_t)n >= remaining. snprintf writes at most remaining - 1 real characters plus a null, so any n >= remaining means truncation occurred — stop before used can overshoot.

Static analyzers rarely catch this because both individual calls look correct. Compile with -fsanitize=address and fuzz the field lengths; ASan will flag the heap-buffer-overflow on the very first oversized input.

A pipelined CPU issues a new instruction every cycle, but sometimes the next instruction literally cannot execute yet — its inputs aren't ready, or a resource is busy. The hardware that detects this and freezes the pipeline is called an interlock. Get it wrong and your CPU silently computes with stale data.

Three classes of hazards trigger interlocks:

• Data hazards (RAW): Instruction N+1 reads a register that instruction N is still writing. Classic example: LOAD R1, [R2] followed by ADD R3, R1, R4. R1 isn't in the register file yet when the ADD reaches decode.
• Structural hazards: Two instructions want the same hardware resource — a single-ported memory, a non-pipelined divider, one write port on the register file.
• Control hazards: A branch is in flight and the front-end doesn't yet know which way it went. (Modern CPUs speculate around this; simpler pipelines just stall.)

The hazard detection unit sits in the decode stage. It compares source register IDs of the instruction being decoded against destination register IDs of every instruction currently in EX, MEM, and WB. If any match AND the producer hasn't written back yet AND no bypass path exists, it asserts stall: PC and IF/ID register hold their values, and the ID/EX register is filled with a bubble (a NOP with all control signals deasserted).

Concrete example — classic MIPS load-use hazard:

• Cycle 1: LW R1, 0(R2) in IF
• Cycle 2: LW in ID, ADD R3, R1, R4 in IF
• Cycle 3: LW in EX (computing address), ADD in ID — hazard unit sees R1 will be written by LW but data won't arrive until end of MEM. No forwarding path from MEM output to EX input exists early enough. Stall.
• Cycle 4: LW in MEM, ADD held in ID, bubble inserted into EX.
• Cycle 5: LW forwards its loaded value from MEM/WB register directly to ADD's ALU input. ADD proceeds.

Rule of thumb: Every load-use pair costs exactly one bubble on a classic 5-stage pipeline (assuming MEM→EX forwarding). Compilers reorder instructions to fill this slot — this is why old MIPS had the "load delay slot" architecturally visible.

The interlock logic itself is trivial in gates: a few comparators (source_reg == dest_reg_in_EX?) ANDed with valid/write-enable bits, ORed together. But getting it wrong is catastrophic — the CPU computes with garbage, and nothing crashes. It just produces wrong answers, silently.

When you drive a bipolar junction transistor hard into saturation as a switch, you get a nice low V_CE(sat) — often 100-200 mV — but you pay a brutal price when you try to turn it off. Excess minority carriers pile up in the base region, and until they recombine or get swept out, the transistor stubbornly refuses to turn off. This storage time (t_s) can be hundreds of nanoseconds to microseconds, murdering your switching frequency and dumping heat into your device during the slow turn-off transition.

The Baker clamp is an elegant fix, invented by Richard Baker at MIT Lincoln Labs in the 1950s. The idea: prevent the transistor from ever entering deep saturation in the first place. You clamp V_CB so the collector-base junction can't forward-bias significantly, keeping the BJT in the quasi-saturation region where V_CE is low-ish but stored charge stays minimal.

The classic implementation: put a Schottky diode from base to collector. When V_CE tries to drop below V_BE − V_Schottky (about 0.7 − 0.3 = 0.4 V), the Schottky forward-biases and shunts excess base drive directly to the collector instead of piling up as stored charge. The transistor sits at V_CE ≈ 0.4 V — not as low as true saturation's 0.1 V, but the payoff is dramatic.

Real-world example: A 2N2222 driven hard into saturation with I_B = 5 mA and I_C = 50 mA has a spec'd storage time around 225 ns. Add a 1N5817 Schottky as a Baker clamp and t_s drops to under 20 ns — a 10× improvement. This was the trick that made TTL logic families like 74S (Schottky TTL) and 74LS practical at tens of MHz back when everything was bipolar.

Enhanced Baker clamp with steering diode: Add a series silicon diode in the base drive path and connect the Schottky from the base drive node (before that diode) to the collector. Now the clamp point is V_BE + V_D(Si) − V_Schottky ≈ 0.7 + 0.7 − 0.3 = 1.1 V above collector, giving you tighter control over quasi-saturation depth.

Rule of thumb: If your BJT switch's storage time exceeds ~10% of your switching period, add a Baker clamp. Use a Schottky with V_F at least 300 mV below your BJT's V_BE(on) at operating current — otherwise the clamp never conducts.

Modern designs mostly use MOSFETs to sidestep this problem entirely, but Baker clamps still appear in high-voltage BJT flyback drives, older industrial gear, and anywhere you need a rugged bipolar switch to run fast.

A diaphragm pump moves fluid by flexing a flexible membrane back and forth inside a chamber. On the suction stroke, the diaphragm pulls away from the chamber, creating a low-pressure region that opens an inlet check valve and draws fluid in. On the discharge stroke, the diaphragm pushes back, closing the inlet valve and forcing fluid through the outlet check valve. The pumped fluid only touches the diaphragm, the check valves, and the chamber wetted surfaces — never any shaft, seal, or bearing.

That isolation is the whole point. Because there's no rotating shaft passing into the pumped fluid, there's no dynamic seal to leak. This makes diaphragm pumps the default choice for:

• Hazardous or toxic fluids — chemical dosing, acids, solvents
• Abrasive slurries — mine tailings, ceramic slips, drilling mud
• Shear-sensitive fluids — latex, food products, biological suspensions
• Sanitary applications — pharmaceuticals, dairy (with PTFE or EPDM diaphragms)
• Self-priming duty — they can pump air, so they'll evacuate a suction line on startup

Actuation types: Mechanically actuated pumps use a crankshaft or eccentric — simple but limited to low pressures. Air-operated double diaphragm (AODD) pumps use compressed air alternately on the back side of two linked diaphragms; they're the workhorse of industrial transfer duty because they stall safely against a closed valve (no overpressure, no motor overload). Hydraulically actuated diaphragm pumps use oil behind the diaphragm and can hit 5,000+ psi for metering applications.

Rule of thumb for AODD sizing: Flow rate is roughly proportional to inlet air pressure and inversely proportional to discharge pressure. Air consumption is typically 1 to 1.5 SCFM per GPM of water at moderate discharge pressures. So a pump moving 20 GPM will burn through 20–30 SCFM of compressed air — meaning you often need a much bigger compressor than the pump nameplate suggests. This is why AODD pumps are cheap to buy but expensive to run: compressed air is one of the least efficient energy carriers in a plant.

Real-world example: A paint manufacturing plant transfers thick pigment dispersions from mixing tanks to filling lines. An AODD pump with EPDM diaphragms handles the shear-sensitive paint without damaging it, self-primes when tanks run low, and safely dead-heads when the filling line pauses — no controls, no VFD, no seal maintenance. When operators want more flow, they open the air regulator.

Diaphragm life is the failure mode to watch. Every stroke flexes the membrane; fatigue eventually cracks it. PTFE lasts longest chemically but flexes poorly; elastomers like Santoprene flex well but have narrower chemistry compatibility. Expect 10–100 million cycles depending on material, pressure, and temperature.

Buried in the parts list of a wartime Signal Corps darkroom manual is a single item that hides an entire lost craft:

12 Plates PH-152 or PH-152-A, ferrotype.

This was the standard field-darkroom kit issued to Army photographers in 1943, printed by the War Department to teach soldiers how to develop, fix, and finish photographic prints under combat conditions. Twelve ferrotype plates traveled with every kit. Why twelve? Because in 1943, if you wanted a glossy photograph, you had to make it glossy — the paper alone would not do it.

A ferrotype plate was a sheet of chromium-plated steel (or japanned tin) polished to a mirror finish. After a print was washed, the photographer would squeegee it face-down onto the plate and let it dry. As the emulsion contracted against the polished surface, it took on a perfect physical replica of that mirror. When the print popped free — often with an audible tick — it had a shine no modern inkjet can match. The gloss you were looking at was not paint or coating. It was the reflection of the steel, transferred into the gelatin itself.

The technique demanded near-religious cleanliness. A single fingerprint or fleck of dust on the plate would be reproduced, in glossy relief, on every print pressed against it. Photographers waxed their plates with beeswax or a proprietary "ferrotype solution," buffed them to a haze, and stored them wrapped like fine silverware. When a plate got scratched, it was ruined — hence the Army packing a dozen spares.

What killed the ferrotype plate?

• Resin-coated (RC) paper, introduced by Kodak in the late 1960s, baked the glossy surface into the paper itself. No pressing required.
• Ilfospeed and similar products in the 1970s made glossy prints available to any home darkroom hobbyist without the ritual.
• The rise of digital printing finished off any lingering use.

By 1985, ferrotype plates had vanished from photo supply catalogs. Today, a photographer under fifty has likely never seen one. Yet those glossy black-and-white portraits you find in grandparents' albums — the ones with the impossibly deep blacks and a shine like wet ink — almost all owe their look to a piece of polished steel that the Army thought important enough to issue in dozens.

There is a modern echo: fine-art printers using platinum-palladium or silver gelatin still occasionally hunt down old ferrotype plates on eBay because nothing since has produced quite the same optical effect. The gloss of a 1943 print is not a coating you can buy. It is a fossil of a mirror.

Buried inside a routine 1966 CIA Research & Development Catalog Form — the kind of dry, mimeographed budget paperwork that filled Langley's filing cabinets — sits a reference to a color reproduction technology that has almost entirely vanished from public memory: Electrocolor.

The form describes a study, budgeted for fiscal year 1967, aimed at "Evaluation and determination of potential improvements of present electrocolor system." The document lays out why the National Photographic Interpretation Center (NPIC) cared:

The electrocolor process shows potential for producing color reflection prints for exploitation use. Its unique characteristic of individual color contrast control of the three basic colors, red, green and blue, indicates that this product would be extremely usef[ul]...

And earlier in the form:

The increasing use of color reconnaissance photography necessitates thorough investigation of all color reproduction systems to determine those advantages which can be applied to Center requirements.

The categories of effort listed are telling: "Electrocolor Plating — Materials — Equipment — Reproduction Techniques and Materials." This wasn't ordinary chemical dye-transfer printing. Electrocolor was an electrochemical process — sometimes called electrolytic color anodizing — in which colors were deposited into a porous, anodized metal surface (typically aluminum) via electrical current controlling the migration of metal salts into the pores. The color wasn't a dye layer on top; it was inside the oxide.

What made it attractive for spy photography was exactly what the CIA form flags: independent, granular contrast control over each of the three primaries. In an era when a U-2 or CORONA satellite might return a canister of color negative that had to be interpreted for a general's briefing the next morning, a print process that let an analyst pull green foliage down while pushing red vehicle paint up was genuinely valuable.

So where did it go? A few threads survived:

• Electrolytic coloring of anodized aluminum is still the industry standard for architectural window frames — those bronze, black, and champagne facades on 1970s office buildings are electrocolor.
• The photographic version, however, was essentially outcompeted by improvements in dye-coupler chromogenic prints (Kodak's Ektacolor, later inkjet), and by the digital revolution that made per-channel contrast control a slider rather than a chemistry problem.

The modern parallel is striking: what a 1966 CIA contractor was trying to build with plated metals and electrical current is now the "Curves" tool in Photoshop, or the per-channel tone mapping in Lightroom. Every phone photographer casually adjusts red, green, and blue contrast independently — a capability that once required a classified R&D program.

The document is also a reminder that Cold War intelligence quietly bankrolled a huge amount of imaging science. The National Photographic Interpretation Center's need to squeeze more information out of a frame of film drove real chemistry, real optics, and real engineering — most of which was declassified only decades later, by which time the digital sensor had made the underlying problem obsolete.

In October 1938, a British engineer working at ITT's Paris laboratory quietly filed a patent that described, in complete detail, how to turn any analog signal — voice, music, video — into a stream of numbers, transmit those numbers, and reconstruct the original signal at the far end with essentially zero cumulative noise. He called it Pulse Code Modulation. His name was Alec Harley Reeves, and the patent was French Patent 852,183, followed by US Patent 2,272,070 (filed November 1939, granted February 1942) and British Patent 535,860.

The idea is the one that runs every phone call, streaming service, Blu-ray disc, and Zoom meeting today:

• Sample the analog waveform at regular intervals (Nyquist's 1928 theorem said how often).
• Quantize each sample to the nearest value from a finite set.
• Encode that value as a binary pulse train — literal 1s and 0s sent as on/off pulses on a wire or over the air.
• At the receiver, decode back to samples, then smooth the samples back into a waveform.

Reeves's patent drawings show exactly this: a sampler, a quantizer producing 5-bit codes, a serial pulse transmitter, and a decoder at the far end reading the pulses off a rotating commutator. He even understood the killer feature: because a receiver only has to distinguish pulse present from pulse absent, noise accumulated along the line can be regenerated away at every repeater. Analog signals degrade with distance. Digital ones don't.

The problem was that nothing on Earth could actually run it. A telephone-quality PCM signal needs about 64,000 bits per second. In 1938, the fastest practical electronics were mechanical commutators and slow vacuum tubes. Reeves built a proof-of-concept using gas-discharge tubes, but a real PCM telephone system would have required thousands of tubes running hot enough to melt themselves. The patent sat on the shelf.

Then the transistor arrived (1948), then the integrated circuit (1959), and suddenly Reeves's 1938 blueprint became buildable. Bell Labs' T1 carrier system (1962) — the first commercial digital telephone trunk line — is Reeves's patent implemented in silicon, 24 voice channels multiplexed as PCM at 1.544 Mbit/s. That same T1 line rate is still the atomic unit of telecom billing today.

From there PCM ate the world:

• Compact Disc (1982): 16-bit PCM at 44.1 kHz — Reeves's algorithm, just with more bits.
• Every WAV file, every AAC stream: AAC is PCM with a perceptual codec bolted on top; the underlying samples are Reeves.
• GSM, VoIP, Zoom, FaceTime: all sample-quantize-encode at the microphone.
• HDMI, DisplayPort, Ethernet: the "regenerate at every repeater" insight is what makes gigabit signals survive noisy copper.

Reeves lived until 1971 and watched his patent become the foundation of the digital age. He also spent his later career at Standard Telecommunication Laboratories in Harlow, where — in a delightful bit of continuity — his colleague Charles Kao would win the 2009 Nobel Prize for figuring out how to send Reeves's PCM pulses down glass fiber instead of copper wire.

Reeves's patent is the rare filing that was fully correct and completely unbuildable at the same time. The math was right in 1938. The transistors just hadn't been invented yet.

This little repo tackles a classic problem from linear algebra and 3D geometry: given three planes in space, find the single point (if one exists) where all three intersect. It's the kind of exercise that shows up in first-year engineering courses, computer graphics classes, and computational geometry tutorials — but rarely gets a clean, dedicated implementation you can just drop into a project.

Under the hood, the math is straightforward: each plane is defined by an equation of the form ax + by + cz = d, and three such equations form a 3×3 linear system. Solve it (Cramer's rule, Gaussian elimination, or a matrix inverse) and you have your point. The interesting edge cases are what make this worth writing:

• Parallel planes — no intersection exists
• Planes meeting in a line — infinite solutions along that line
• Coincident planes — an entire plane of solutions
• Near-singular systems — numerically unstable and need careful handling

A well-written solver for this problem needs to check the determinant, handle degenerate configurations gracefully, and return meaningful results rather than crashing or silently producing garbage.

Who would benefit? Students working through linear algebra homework who want to check their answers. Game developers computing corner points where three collision surfaces meet. CAD and 3D modeling hobbyists building constraint solvers. Robotics folks doing kinematics or sensor fusion involving planar constraints. And anyone teaching computational geometry who wants a minimal reference implementation to point students at.

The repo is tiny and focused — exactly the kind of single-purpose utility that's easier to understand and audit than a monolithic geometry library. Even if you end up rewriting it in your language of choice, it's a nice starting point for thinking through the edge cases.

IEEE 754 defines a class of numbers called denormals (or subnormals): values so small that the exponent is zero and the mantissa loses its implicit leading 1. They exist to give gradual underflow — the gap between the smallest normal number and zero gets filled with progressively less precise values instead of a hard cliff. This is mathematically elegant. It is also a performance disaster.

The floating-point unit's fast path assumes normalized inputs: the hidden bit is 1, the exponent is in range, alignment shifters have bounded work. When a denormal shows up, most CPUs cannot handle it in the pipelined FPU. Instead, the operation gets kicked out to a microcode assist — a slow path that takes tens or hundreds of cycles, stalls dependent ops, and often drains the pipeline behind it.

Concrete numbers on Intel Skylake and later: a normal FMUL is 4 cycles, fully pipelined. Feed it a denormal input and you get a microcode assist costing roughly 150-200 cycles. That's a 40x slowdown per operation. Producing a denormal result triggers the same penalty on the store side.

Real-world example: audio processing. A reverb tail decays exponentially toward zero. Once samples drop below ~1e-38 (single precision) or ~1e-308 (double), every subsequent multiply hits the denormal path. A reverb plugin that runs at 2% CPU during a loud signal can spike to 60% CPU when the tail decays — the classic "denormal storm." The fix is Flush-to-Zero (FTZ) and Denormals-Are-Zero (DAZ) mode bits in MXCSR (x86) or FPCR (ARM). Set them, and the hardware treats denormal inputs and outputs as zero, bypassing microcode entirely.

Rule of thumb: if your workload can produce values below ~1e-38 (float) or has any decaying signal touching zero, enable FTZ/DAZ. In gcc: _mm_setcsr(_mm_getcsr() | 0x8040). Cost: you lose gradual underflow (values below the normal range snap to zero). Benefit: guaranteed constant-time FP.

Rounding modes matter too. IEEE 754 defines four: round-to-nearest-even (default), toward zero, toward +∞, toward -∞. Changing the mode via MXCSR forces a pipeline flush on most x86 cores — the FPU caches the mode in its scheduler. Games and DSP code that toggle rounding modes per-operation (for fast float-to-int conversion, historically) paid huge hidden costs. This is why SSE cvttss2si (truncate) exists: it bakes the rounding mode into the opcode, no MXCSR change needed.