Programming Leftovers

posted by Roy Schestowitz on Jan 20, 2026

• Russ Cox ☛ research!rsc: Floating-Point Printing and Parsing Can Be Simple And Fast (Floating Point Formatting, Part 3)

  A floating point number f has the form f=m·2e where m is called the mantissa and e is a signed integer exponent. We like to read numbers scaled by powers of ten, not two, so computers need algorithms to convert binary floating-point to and from decimal text. My 2011 post “Floating Point to Decimal Conversion is Easy” argued that these conversions can be simple as long as you don’t care about them being fast. But I was wrong: fast converters can be simple too, and this post shows how.

  The main idea of this post is to implement fast unrounded scaling, which computes an approximation to x·2e·10p, often in a single 64-bit multiplication. On that foundation we can build nearly trivial printing and parsing algorithms that run very fast. In fact, the printing algorithms run faster than all other known algorithms, including Dragon4 [30], Grisu3 [23], Errol3 [4], Ryū [2], Ryū Printf [3], Schubfach [12], and Dragonbox [17], and the parsing algorithm runs faster than the Eisel-Lemire algorithm [22]. This post presents both the algorithms and a concrete implementation in Go. I expect some form of this Go code to ship in Go 1.27 (scheduled for August 2026).

  This post is rather long—far longer than the implementations!—so here is a brief overview of the sections for easier navigation and understanding where we’re headed.

• Russ Cox ☛ research!rsc: Fast Unrounded Scaling: Proof by Ivy (Floating Point Formatting, Part 4)

  The unrounded form of x∈ℝ, ⟨x⟩, is the integer value of ⌊x⌋ concatenated with two more bits: first, the “½ bit” from the binary representation of x (the bit representing 2−1; 1 if x−⌊x⌋≥½; or equivalently, ⌊2x⌋mod2); and second, a “sticky bit” that is 1 if any bits beyond the ½ bit were 1.

  These are all equivalent definitions, using the convention that a boolean condition is 1 for true, 0 for false: [...]

• [Old] Russ Cox ☛ research!rsc: Floating Point to Decimal Conversion is Easy (Floating Point Formatting, Part 1)

  Floating point to decimal conversions have a reputation for being difficult. At heart, they're really very simple and straightforward. To prove it, I'll explain a working implementation. It only formats positive numbers, but expanding it to negative numbers, zero, infinities and NaNs would be very easy.

  An IEEE 64-bit binary floating point number is an integer v in the range [252, 253) times a power of two: f = v × 2e. Constraining the fractional part of the unpacked float64 to the range [252, 253) makes the representation unique. We could have used any range that spans a multiplicative factor of two, but that range is the first one in which all the values are integers.

  In Go, math.Frexp unpacks a float64 into f = fr × 2exp where fr is in the range [½, 1). (C's frexp does too.) Converting to our integer representation is easy: [...]

• Adam Silver ☛ Design in code, get praise

  One product manager suggested I upskill some of the other designers on the programme who are less familiar with the Prototype Kit.

  But she also pointed out that it would probably take up too much of my time.

  Luckily, I’ve been preparing for this moment for 2 years. I told her:

  I have a course that teaches designers how to use the GOV.UK Prototype Kit to unlock the many benefits of prototyping in code.

• Tomas Tomecek: Ambient Code followup: PR merged

  This is a followup to my previous post about how I tried Ambient Code.

  TL;DR: I opened a PR (#specfile/508) and had to take over in the end.

• Andrew Nesbitt ☛ importmap.lock: a lockfile for the web

  The web is the only major software platform without a native dependency manifest. The web runs on URLs and runtime resolution; npm runs on filesystems and build steps. Bundlers have been papering over that mismatch for a decade. Lea Verou’s recent post on web dependencies nerd sniped me.

  There’s a security angle too. The EU Cyber Resilience Act and US Executive Order 14028 increasingly mandate SBOMs for software. But if you’re loading JavaScript from CDNs without a bundler, there’s no manifest for SBOM tools to read. The web has no native way to declare what dependencies a site uses. That’s a problem as compliance requirements tighten, and “manually document your CDN dependencies” is a non-compliance trap waiting to happen.

  Import maps seem like an interesting starting point for both problems, at least for sites that skip the bundler and load modules directly in the browser.

• Futhark Programming Language ☛ Are arrays functions?

  While I do not think that Futhark is the right language in which to do the experiment, I would like to see what it would be like for a language to fully exploit the array-function correspondence. I do not think the best way to do this is to have only a single type, as the performance implications of the choice of representation are too dramatic to be left to a compiler. Rather, I imagine a language that allows shared abstractions that work for both arrays and appropriate functions. One starting point could be the observation that a -> b and the array type a => b are both functors in the Haskell sense, with element type b, meaning they support a “functorial map” (fmap) operation. When the parameter type of a function is isomorphic to a contiguous subset of the integers, then it is also easy to define scan and reduction operations. We can then start defining functions that operate on anything “array-like”. It is also conceivable that the idea behind AUTOMAP could be extended to “AUTOFMAP”, which would allow operations such as f + g when f and g are functions with the same domain - mirroring normal mathematical conventions. Other things also become possible - I do not yet know when it might be useful to perform a matrix multiplication of functions, but I’d certainly like someone to figure it out and tell me about it.

• UNIX.Dog ☛ some C habits I employ for the modern day

  in any case, C is an interesting language without much standardization on the whole “style” or “practices” part. most other languages have very clear “this is the best way to use X” messages, either subtly embedded in the syntax itself or through “official” documentation channels. C doesn’t have an official documentation channel, nor does it have syntax or standard library constructs that encourage one particular way of doing things. from this, there’s a bunch of inconsistencies in how people do things, and–especially in the early days of the language and standard library–the landscape and general practice is quite error prone. as such, I’ve developed my own habits when writing C, usually picked up from blog posts, writing C# or rust, or just out of perfectionist brain.

  I’m not saying you should write stuff this way, nor am I claiming it is the best way to write C all the time. I break some of these practices when working with embedded systems or when I’m writing things to be as fast as they can possibly be. but it is the baseline I tend to start with for most projects, and if I don’t write it down, I’ll never be consistent with it.

• Perl / Raku

  • Rakulang ☛ Rakudo Weekly 2026.03 Lamentable

    FOSDEM Community Dinner Information TPRF sponsor the FOSDEM Perl and Raku community dinner which is is traditionally held on the Saturday evening. All food is included and guests are free to purchase their own drinks.

• R / R-Script

  • Dirk Eddelbuettel ☛ RApiDatetime 0.0.11 on CRAN: Micro-Maintenance

    RApiDatetime provides a number of entry points for C-level functions of the R API for Date and Datetime calculations. The functions asPOSIXlt and asPOSIXct convert between long and compact datetime representation, formatPOSIXlt and Rstrptime convert to and from character strings, and POSIXlt2D and D2POSIXlt convert between Date and POSIXlt datetime. Lastly, asDatePOSIXct converts to a date type. All these functions are rather useful, but were not previously exported by R for C-level use by other packages. Which this package aims to change.