The most annoying ambiguity I can remember of that kind was the time I wanted to garbage-collect a PDF file: I had hand-edited it to remove a reference to one object in the file from another, and I wanted to make a smaller PDF with the now-unreferenced object completely removed.

If you search for "pdf garbage collection", you feel very foolish, because _all_ the hits are academic articles about garbage collection in general, published as PDFs.

(The answer to that one turns out to be "mutool clean".)

Got lucky with a web search just now.

I wanted to debug a crash in LLVM. For other programs I'd start by compiling with Address Sanitizer. LLVM's build process is tricky enough that you might not do that the obvious way, so I websearched "build llvm with address sanitizer".

Foolish me! That can also be interpreted as "build an LLVM toolchain that includes ASan for end users to use on the programs they build with it". Most of the hits were about that, and not about the thing I wanted.

But lucky me! I found a Stack Overflow post that recognised the ambiguity and answered _both_ questions. Top marks, that poster.

(The answer is "-DLLVM_USE_SANITIZER=Address".)

3e8

My code describes a tile as having 'edges': parts of the tile's boundary where it can meet other tiles. They're called edges because normally they're edges of a polygon. Here, they're really faces of a polyhedron, but that _shouldn't_ make a difference.

Or _parts_ of faces, because it's simplest to consider Chair44 as having 24 small square faces, most of them coplanar with some of their neighbours to create the larger 'true' faces of the polyhedron.

(The numbering in this diagram is completely arbitrary, and different from what I have in my code, which is also completely arbitrary. If I wanted to publish this properly I'd make up a more sensible numbering system.)

(2/6)

So, there's been a 3D aperiodic monotile discovered. I have software for handling aperiodic tilings computationally, but only tested so far in 2D. Can it cope?

My system works in a purely combinatorial manner, not relying on the geometry of the tiling: it only depends on what tiles exist, which are adjacent via what part of their boundary, and which ones are subtiles of which in the hierarchy of substitutions. So it _ought_ to handle 3D tilings as easily as 2D.

This seemed like a good moment to test that claim! Can I write down, or generate, a combinatorial description of the Chair44 substitution system which my code can handle?

I gave this a try, and found that the answer was yes, _eventually_. But I had missed something subtle, and had to fix it, or rather, bodge it.

(1/6)

It would _almost_ work to turn '-n' into an option that says: first sort by length, and then sort lexicographically within strings of the same length. That would correctly sort non-negative integers in any number base at all without needing to be told which base, as long as the digits are represented by characters whose ASCII ordering matches their semantic ordering. It would even correctly ignore 0x prefixes on hex numbers, if there were any.

Not quite, though. That policy wouldn't handle negative numbers, so you'd still have to make a special case for a leading minus sign. And if you were sorting non-integers, then you'd have to spot a decimal point, separate that and everything after it, and use that as a tertiary sort criterion. Ugh.

I've just run into a situation where I wished that 'sort -n' had an option to treat the numeric sort field as being hex, rather than decimal.

Now that I think about it, this seems like such a natural thing to want that I'm surprised I've never had a need for it before!

You can implement this procedure by only a small change to the obvious technique. Choose a starting exponent in the obvious way I suggested; then choose a random mantissa, but invent one _more_ bit than you needed; finally, use that extra bit to decide whether to round up or down. In a small number of cases, you'll round up to the next exponent, implementing the low end of the catchment area of the next higher power of 2.

For once, you don't have to worry about the round-to-even tie breaking rule, because with a real random variable, ties occur with probability zero!

(The simple rule I originally suggested is correct if you're rounding _down_. It's the default option of rounding to nearest that makes things harder.)

What's the right way to generate a floating-point number representing a sample of a uniformly random variable in the range [0,1]?

You might think: choose the exponent to be 2⁻¹ with probability 1/2, 2⁻² with probability 1/4, etc (with some fudge when the range runs out). And then, once you've chosen an exponent, choose uniformly at random from the mantissas.

Wrong!

The #IEEE754 ethos is to calculate the mathematically perfect result, and then round that to the nearest representable number. So you must choose each floating-point number x with probability in proportion to its rounding 'catchment area': the range of real numbers above and below x that will round to x.

Well, isn't that what I just said?

No, it isn't – because powers of 2, at the boundary between two exponents, have a catchment area half as big on the left as on the right. So you must choose _most_ numbers with probability 2⁻ⁿ where n varies with the exponent, except that powers of 2 are chosen with probability 2⁻ⁿ + 2⁻ⁿ⁺¹. Arrgh!

#TIL that in #SageMath you can accidentally write a comparison expression that doesn't do a comparison. (Reposted after the previous version was subtly wrong)

x = QQbar(UniversalCyclotomicField().gen(3))
if x == (-1 + sqrt(3)*i) / 2:
print("All is well")
if x != (-1 + sqrt(3)*i) / 2:
print("Disaster!")

The canonical primitive cube root of unity really is (−1+i√3)/2. So we expect "All is well" and not "Disaster". But in fact we get both:

$ sage z.sage
All is well
Disaster!

Turns out this is because when you compare a QQbar value with some more general algebraic expression, it doesn't do a comparison. It constructs a symbolic expression object that just represents the _notion_ of equality or inequality:

sage: print(x != (-1 + sqrt(3)*i) / 2)
(-0.500000000000000? + 0.866025403784439?*I) != 1/2*I*sqrt(3) - 1/2

And those expression objects can evaluate true in a boolean context, simply because they aren't None or False. But they don't _always_. The == comparison seems to work OK, but the != evaluates true unconditionally. #wat

(The workaround is to coerce the RHS of the expression to QQbar too: 'if x != QQbar(...)'. Then you're comparing elements of the same field and Sage is happy.)

Always a good moment when you get to type, incredulously,

git commit -am 'OMG WTF IT ACTUALLY WORKED?!'

Our father, who art in source control,
hallowed be thy `main`.
Thy merges come, thy builds be done,
downstream as it is upstream.
Give us each day our detached HEAD,
And forgive us our rebases,
as we forgive those who rebase against us.
And lead us not into submodules,
But deliver git-send-email.
For thine are the commits, the trees and the blobs,
For ever and ever, --amend.

See also: 'ninja -t urtle'

Always worth looking at the source code of tools, because you find their easter eggs.

According to the man page for 'xrandr', it has an option --properties, also abbreviated --prop.

In the source code, it turns out that you can also spell it --props …

… and, surely because someone thought it was funny, --madprops.

Just found a machine in my house that was still running Debian 11, which went out of support recently. Upgraded it to 12, and for good measure, straight to 13 (trixie).

The best thing about this is that I'm no longer running any of the three consecutive releases that begin with b. No more struggling to remember which of buster, bullseye and bookworm is older and which is newer!

Do not meddle in the affairs of C compilers, for they are subtle, and *very slow* to anger.

That's worse than being quick to anger. They'll cause your code to fail catastrophically in the field many years after you've finished running tests and left the code to it.

New quasi-blog post: "Analysing 2048 on a 3×3 board"

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/small2048/

A rather late writeup of a project I did some years ago, to scale down the puzzle game 2048 to a smaller board, allowing it to be analysed exhaustively, and learn from the results.

Includes a Javascript implementation inline in the article, and a second much more evil version that chooses the tile drops maliciously.

I occasionally think someone ought to make squashy physical representations of the logos / icons of major pieces of software, so that when one has been frustrating you all day, you can relieve your feelings by jumping up and down on its logo, or punching it, or throwing it across the room, or whatever.

But I suppose the problem is that the manufacturer of the software would make a profit from sales of those, whether directly or via licensing the trademark. And any piece of software you're motivated to beat up the logo of, you surely _don't_ want to give extra money to its manufacturer!

A couple of weeks ago I showed a preview of a new mode for Mines, in my puzzle collection. I'm pleased to say that the new Mines is now completed and live! You can now play Minesweeper on a wide range of tilings in your browser
https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/mines.html
or download a desktop version from the parent page which supports the same set of grids.

As well as the support for lots of grid types, there's also a new user preference (off by default) to make it easier to play on them. When you click on a clue square to potentially clear around it, the existing flags adjacent to the square light up, to make it easier to count them and work out how many more mines you're still expecting. Particularly useful in the hat tiling, where it's easy to mistake exactly what is adjacent to what!

I expect different people will prefer different grids. Personally I think the triangular grid is particularly tricky and puzzly; the hexagonal honeycomb makes a gentle introduction; the Cairo, Floret and Kites tilings are a nice set in between those extremes; and of course the aperiodic tilings are there to keep you on your toes and ready for anything.

Many thanks to Anders Höglund for this excellent piece of work.

Some details:

This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn't do this.

It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn't look at PRIMARY, the selection used for trad X11 "just select in this window then middle-click in the other" copy-paste.

It looks as if it's detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.

I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam. But today, after an apt update, it doesn't work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.

(Regular readers might recall that around this time _last_ year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)