The Universe of Discourse

Did Ahmes find the best expansions for 2/n?

A couple of years back I was discussing the Rhind Mathematical Papyrus (RMP). It includes a table expressing !!\frac 2n!! as a sum $$\frac1{a_1}+\frac1{a_2}+\dots+\frac1{a_k} $$ fractions with numerator 1 (“unit fractions”). I said:

Getting the table of good-quality representations of !!\frac 2n!! is not trivial, and requires searching, number theory, and some trial and error. It's not at all clear that !!\frac2{105}=\frac1{90} + \frac1{126}!!.

Today I wondered: did Ahmes (the author) have the best possible expansions for all the !!\frac2n!! values, or were there some improvements the Egyptians had missed?

It turns out, yes! Or rather, maybe!

In On the Egyptian method of decomposing !!2/n!! into unit fractions the author, Abdulrahman A. Abdulaziz, points out that for !!\frac2{95}!! the Rhind Mathematical Papyrus gives the expansion $$\frac2{95} = \frac1{60} + \frac1{380} + \frac1{570}$$

but !!\frac1{380} + \frac1{570} = \frac1{228}!! so it could have been written as $$\frac2{95} = \frac1{60}+\frac1{228}.$$

But wait, maybe that wasn't an error. The Egyptians, like everyone, often had to multiply by 10. (In fact, the RMP itself, right after its !!\frac 2n!! table, has a shorter table of expansions of !!\frac n{10}!!.) And !!\frac1{60} + \frac1{380} + \frac1{570}!! is trivially multiplied by 10, whereas !!\frac1{228}!! isn't. There is some indication that Ahmes preferred fractions with even denominators, because they are easier to double, and the usual Egyptian method of multiplication required repeated doubling. But the Egyptians also sometimes decupled while multiplying, and the !!\frac1{60} + \frac1{380} + \frac1{570}!! expansion would have made both of those easy.

The methods by which Ahmes chose the expansions of !!\frac 2n!!, and the criteria by which he preferred one to another, are still unknown; he doesn't explain them. So it's tough to say that any item was or wasn't “best” from Ahmes' point of view.

[Other articles in category /math] permanent link

Programmers will document for Claude, but not for each other

A couple of days ago I recounted a common complaint:

I keep seeing programmers say how angry it makes them that people are willing to write detailed CLAUDE.md and PROJECT.md files for Claude to use, but they weren't willing to write them for their coworkers.

For larger projects, I've taken to having Claude maintain a handoff document that I can have the next Claude read, saying what we planned to do, what has been done, and other pertinent information. Then when I shut down one Claude I can have the next one read the file to get up to speed. Then I have the Claude !!n+1!! update it for Claude !!n+2!!.

After seeing the common complaint enough times I had a happy inspiration. I'd been throwing away Claude's handoff documents at the end of each project. Why do that? It's no trouble to copy the file into the repository and commit it. Someone in the future, wondering what was going on, might luckily find the right document with git grep and learn something useful.

I'm a little slow so it took me until this week to think of a better version of this: at the end of the project I now ask Claude to write up from scratch a detailed but high-level explanation of what problem we were solving and what changes we made, and I commit that. Not just running notes, but a structured overview of the whole thing.

I review these overviews carefully and make edits as necessary before I check them in. It's my signature on the commit, and my bank account receiving the paycheck, so nothing goes into the repository that I haven't read carefully and understood, same as if Claude were a human programmer under my supervision.

But Claude's explanations haven't required much editing. Claude's most recent project summary was around as good as what I could have written myself, maybe a little worse and maybe a little better. But it took ten seconds to write instead of an hour, and it didn't take anything like an hour to review.

The serious thing I had to fix the last time around was that Claude had used a previous, related report as a model, and the previous report had had a paragraph I had added at the end that said:

# Approved-by

Claude abstracted these notes from our discussions of the issue. Mark Dominus has read, reviewed, edited, and approved these notes.

Claude's new document had an identical section at the end. Oops! Fortunately, by the time I saw it, it was true, so I didn't have to delete it. I had Claude add a sentence to CLAUDE.md to tell it not to do this again.

My advice for the day:

1. If you have Claude write down notes, check them into the repo when you're done. It probably can't hurt and it might help.

2. Have Claude write a project summary, and then check it into the repo.

Maybe this is obvious? But it wasn't obvious to me. I'm still getting used to this new world.

[Other articles in category /tech/gpt] permanent link

How are John Waters movies like James Bond movies?

A number of years ago I wondered how many movies I had seen. The only way I could think of finding out was just to make a list. This I did as best I could. (It turned out to be around 700.)

I found, though, that I could not include all the James Bond movies I had seen, because I couldn't tell them apart from the descriptions. I'd read a plot summary for a James Bond movie, and ask myself “Did I see that? I don't know, it sounds like every other James Bond movie.”

Today I discovered that John Waters movies are like that also. I was trying to remember if I had seen A Dirty Shame:

The people of Harford Road are firmly divided into two camps: the neuters, the puritanical residents who despise anything even remotely carnal; and the perverts, a group of sex addicts whose unique fetishes have all been brought to the fore by accidental concussions. Repressed Sylvia Stickles finds herself firmly entrenched in the former camp.

You'd think that would be something I would remember decisively, or not. But I'm really not sure. All I can do is shrug and say “I don't know, it sounds like a John Waters movie I have seen, but maybe it wasn't that one.”

Looking into it further I discovered that I also wasn't sure if I had seen Multiple Maniacs. In it, Divine's character is raped by a giant lobster. On the one hand, that seems like the sort of thing I would remember. And I think maybe I do? But again I'm not sure I'm not just imagining what it would be like!

[Other articles in category /movie] permanent link

Documentation is a message in a bottle

Our company is going to a convention later this month, and they will have a booth with big TV screens showing statistics that update in real time. My job is to write the backend server that delivers the statistics.

I read over the documents that the product people had written up about what was wanted, asked questions, got answers, and then turned the original two-line ticket into a three-page ticket that said what should be done and how. I intended to do the ticket myself, but it's good practice to write all this stuff down, for many reasons:

• Writing things down forces me to think them through carefully and realize what doesn't make sense or what I still don't understand.

• I forget things easily and this will keep the plan where I can find it.

• I might get sick, and if someone else has to pick up the project this might help them understand what I was doing.

• If my boss gets worried that all I do is post on 4chan all day, this is tangible work product that proves I did something else that might have enhanced shareholder value.

• If I'm tempted to spend the day posting on 4chan, and then to later claim I spent the time planning the project, I might fool my boss. But without that tangible work product, I won't be able to fool myself, and that's more important.

• Conversely if I later think back and ask “What was I doing the week of March 2?” I might be tempted to imagine that all I did was post on 4chan. But the three pages of ticket description will prove to me that I am not just a lazy slacker. This is a real problem for me.

• In principle, a future person going back to extend the work might find this helpful documentation of what was done and why. Does this ever really happen? I don't know, but it might.

• I like writing because writing is fun.

A few days after I wrote the ticket, something unexpected happened. It transpired that person who was to build the front-end consumer of my statistics would not be a professional programmer. It would be the company's Head of Product, a very smart woman named Amanda. The actual code would be written by Claude, under her supervision.

I have never done anything like this before, and I would not have wanted to try it on a short deadline, but there is some slack in the schedule and it seemed a worthwhile and exciting experiment.

Amanda shared some screencaps of her chats with Claude about the project, and I suggested:

When you get a chance, please ask Claude to write out a Markdown file memorializing all this.  Tell it that you're going to give it to the backend programmer for discussion, so more detail is better. When it's ready, send it over.

Claude immediately produced a nine-page, 14-part memo and a half-page overview. I spent a couple of hours reviewing it and marking it up.

It became immediately clear that Claude and I had very similar ideas about how the project should go and how the front and back ends would hook up. So similar that I asked Angela:

It looks like maybe you started it off by feeding it my ticket description.  Is that right?

She said yes, she had. She had also fed it the original product documents I had read.

I was delighted. I had had many reasons for writing detailed ticket descriptions before, but the most plausible ones were aimed back at myself.

The external consumers of the documentation all seemed somewhat unlikely. The person who would extend the project in the future probably didn't exist, and if they did they probably wouldn't have thought to look at my notes. Same for the hypothetical person who would take over when I got sick. My boss probably isn't checking up on me by looking at my ticketing history. Still, I like to document these things for my own benefit, and also just in case.

But now, because I had written the project plan, it was available for consumption when an unexpected consumer turned up! Claude and I were able to rapidly converge on the design of the system, because Amanda had found my notes and cleverly handed them to Claude. Suddenly one of those unlikely-seeming external reasons materialized!

On Mastodon I keep seeing programmers say how angry it makes them that people are willing to write detailed CLAUDE.md and PROJECT.md files for Claude to use, but they weren't willing to write them for their coworkers. (They complain about this as if this is somehow the fault of the AI, rather than of the people who failed in the past to write documentation for their coworkers.)

The obvious answer to the question of why people are willing to write documentation for Claude but not for their coworkers is that the author can count on Claude to read the documentation, whereas it's a rare coworker who will look at it attentively.

Rik Signes points out there's a less obvious but more likely answer: your coworkers will remember things if you just tell them, but Claude forgets everything every time. If you want Claude to remember something, you have to write it down. So people using Claude do write things down, because otherwise they have to say them over and over.

And there's a happy converse to the complaint that most programmers don't bother to write documentation. It means that people like me, professionals who have always written meticulous documentation, are now reaping new benefits from that always valuable practice.

Not everything is going to get worse. Some things will get better.

Addendum 20260208

A corollary: You don't have to write the rocumentation yourself. You can have Claude write a detailed summary based on your ongoing chats about the work, and then you can edit it and check it in.

If you're good at editing, anyway. I wonder if part of the reason Claude is working so well for me is that I'm really good at editing and at code review?

[Other articles in category /tech/gpt] permanent link

Bo Diddley

Bo Diddley's cover of "Sixteen Tons" sounds very much like one of my favorites, "Can't Judge A Book By Its Cover". It's interesting to compare.

Thinking on that it suddenly occured to me that his name might have been a play on “diddley bow”, which is a sort of homemade one-stringed zither. The player uses a bottle as a bridge for the string, and changes the pitch by sliding the bottle up and down. When you hear about blues artists whose first guitars were homemade, this is often what was meant: it wasn't a six-string guitar, it was a diddley bow.

But it's not clear that Bo Diddley did play his name on the diddley bow. "Diddly" also means something insignificant or of little value, and might have been a disparaging nickname he received in his youth. (It also appears in the phrase "diddly squat"). Maybe that's also the source of the name of the diddley bow.

[Other articles in category /lang/etym] permanent link