The Universe of Discourse

It's our language now!

A while back I related how I had been mocked by an English person for using the word “burglarize”. I ended by saying:

Okay, whatever. Brits have been mocking the American language for centuries now. Let them go ahead. We all know who won that argument.

Since then I've been comforted by that thought. I smile to myself and say “It's ours now, we have you outnumbered.”

But for the last few years this has always been followed by another thought: On that logic, it actually belongs to the Indians. And yes, it probably does and we just haven't noticed yet.

But we will.

[Other articles in category /lang] permanent link

I owe my life to a 1913 road rage incident

This is my great-grandfather, born Dominusz Andor in Szeged, Hungary in 1886. In the picture he is in Brooklyn, New York, probably sometime in the early 1950's.

By 1911 Andor had moved from Hungary to Vienna and had changed the spelling of his name to “Dominus” to save confusion. He worked as a goldsmith, and owned his own jewelry shop, so he must have been doing OK.

There's a family legend about why Andor left Vienna for the USA, and I was never sure whether I believed it. But thanks to the Wonders of the Internet, I was able to find out the details, which were all over the Viennese papers in the spring of 1913, and were even reported as far away as Budapest.

In 1913, Andor owned a motorcycle with a sidecar. On March 24 he was driving around Vienna with his wife Rosa when the sidecar came detached. Andor stopped to repair it, and a crowd gathered to watch. Some local youths offered to “help”, rocking the motorcycle and honking its horn.

After the sidecar was re-attached, The youths demanded a tip, which Andor refused to pay. But he also asked the boys to push the motorcycle forward. This they did, but they also hit him and Rosa in the back of their heads; Rosa responded by punching one of them in the face. The boys jeered and shouted insults. As Andor started to drive away, some people in the crowd threw rocks.

Andor, frightened or angry, took out his Browning pistol. He later claimed to have fired two warning shots into the air. Whatever he meant to do, one of his shots his a 22-year-old butcher's assistant in the chest. Fortunately the bullet lodged in the young man's breastbone. The second shot went through the hat brim of a 12-year-old boy without hurting him. Andor fled the scene.

The police caught up with him that evening at his home, having traced the owner records of the motorcycle, whose license plate number had been noted by people in the crowd. He was arrested and, as he was a foreigner, was deemed a flight risk and jailed pending trial.

In May he was tried. His claim of self-defense was rejected, since by the time he had fired his gun he and Rosa were already about twenty paces from the crowd. He found guilty of assault, mitigated by the circumstances, and sentenced to a week of prison time, which he had already served several times over. However, the butcher's assistant, by then out of the hospital, announced his intention to sue in civil court for lost wages and for pain and suffering.

I haven't yet found the ship manifest that says exactly when Andor arrived in the U.S., but it was no more than four months later. He either fled to avoid the suit, fled to avoid paying the judgement, or, perhaps, just decided he had had enough of Vienna. (I would have been a bit annoyed too, after serving two months of a one-week sentence. Also, his goldsmith shop had been robbed two years before, by thieves who used the shop's own electric drill to break through the back of the safe.)

Rosa and their son Sándor, then four years old, arrived in October 1913 and the family settled in Brooklyn. Andor was naturalized in 1920, and his mother came over in 1921.

Sándor's parents changed his name to the more American-sounding “Samuel”. Samuel remained in Brooklyn until he retired in the early 1970s, by which time he was my paternal grandfather.

It's a good thing for me that the second bullet didn't hit the little boy in the head, or I wouldn't be here to tell you about it.

[Other articles in category /history] permanent link

Deciphering basmala

Making the rounds last week was this magnificent article on the complications of Arabic typesetting, An interactive introduction to the terrific experience of rendering Arabic typography and its technical debt. The author, Saleh, promises:

The reply took and the closure of the ticket took half an hour or so. The reasons behind it took five hundred years to pile up, and they involve a twice-mutilated vizier, a Qurʾān that vanished for four centuries, a Beirut newspaperman with a deadline, and an Egyptian physician who taught himself font engineering for fun (or that what I imagine about him). Walking through these, ended up to be the most enjoyable couple of weeks in that job, and I want to go through it here too.

And then wow, does it deliver. Don't read my article, go read Saleh's instead, or at least read it first.

Still here? Then a disclaimer: I do not know Arabic, not even all the letters, yet. I tried hard to get the details right in this article, but I expect there are misspellings, misstatements of fact, and so on, for which I apologize in advance.

In one of my favorite parts of his article, Saleh discusses how, because Arabic script is always cursive, it is important how the letters are joined to one another. Modern Latin script has only a few ligatures, and omitting them is barely noticeable:

But in Arabic, the ligatures are important. The text looks grossly wrong without the correct ligatures.

Early font engines couldn't render Arabic ligatures properly, and on-screen Arabic text always came out looking ridiculous, with the letters separate like Latin script letters, which is completely wrong for Arabic. Saleh gives this example, which says “hello, world, this is Arabic text”. It should look like this:

مرحبا بالعالم، هذا نص عربي

But early font renderers rendered it like this:

م‌ر‌ح‌ب‌ا‌ ‌ب‌ا‌ل‌ع‌ا‌ل‌م‌،‌ ‌ه‌ذ‌ا‌ ‌ن‌ص‌ ‌ع‌ر‌ب‌ي

The crappy rendering was unfortunate, and only barely tolerable, just barely better than nothing. Even if you don't read Arabic (I don't) you can see the differences. Notice, for example how the elegant and symmetric cluster لعا is mangled to ل‌ع‌ا. Or look at just the first (rightmost) letter. It is the Arabic letter ‘m’, called mīm. It is supposed to connect with the letter next to it, and not to have that hanging tail, which only appears when mīm is written by itself, or at the end of a word.

For the supremely important phrase

بِسْمِ ٱللهِ ٱلرَّحْمَٰنِ ٱلرَّحِيْمِ

the crappy rendering was not tolerable. This phrase is “bismillah al-raḥman al-raḥim”. It means “in the name of God, the gracious, the merciful”, and it appears at the start of each of the 114 surahs (chapters) of the Qur'an (except the ninth for some reason). There is a centuries-long tradition of calligraphic expression of this phrase, in the most perfect possible ways.

“Khalili Collection Islamic Art cal 0154", Ottoman Turkish, 19th century. Public domain, via Wikimedia Commons.

It would be blasphemous to render this phrase, called the “basmala”, this crucial expression of honor for God, as a jumble of letters. Imagine if Exodus 20 had had God introducing the Ten Commandments by saying

The incredible solution to this one problem was the inclusion in Unicode of a special codepoint U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. As a single codepoint, the basmala could be assigned a single glyph, and the single glyph could be designed correctly, so as not to look like trash. Here it is. Remember, this is a single character:

In Firefox, with my fonts, the glyph renders like this, long and narrow:

but on my Android phone there is a very different glyph. Here it is, highly magnified:

What's going on here? It's fun to find out.

The basmala actually has four words (“bismillah” is a contraction):

1. Bismi (بسم, “in the name of”)
2. Allah (اللّٰه, “God”)
3. al-raḥman (الرحمن, “the gracious”)
4. al-raḥim (الرحيم, “the merciful”)

(At some point I should slip in that when the word “al-” (which means “the”) appears before an /r/ sound, its /l/ is assimilated, so that it is pronounced like /ar-/. This is analogous to what happens when the English prefix “in-” is attached to a word like “relevant”. “Inrelevant” is tricky to say. so the /n/ is assimilated and the word is spelled and pronounced “irrelevant”.)

Here are the four words picked out in different colors. To a person literate in Arabic, I suppose this is obvious, but I found it a bit challenging.

“Allah” الله is at the top. (I'm told this is traditional.) I've colored it green because green is said to have been Muhammad's favorite color.

The two marks above it, the W-shaped mark and the vertical stroke above it, are diacritic marks (one called a shaddah and other other indicating the vowel). I'm not sure how optional they are, but in an earlier draft of this article I tried to explain them in detail and got bogged down in a multi-paragraph digression about the morphology of the word “Allah”, so I'm just going to move on without commenting on them further.

Below “Allah”, in red, is “bismi”. In Arabic this has three letters, /b/ + /s/ + /m/, since the vowels are omitted. At the right we have بس which is /b/ + /s/; the letters are named bā' and sīn. Then there's a horizontal stroke, called a kashida, under “Allah”; this is just for layout, analogous to white space, and is not pronounced. Finally the م (/m/, called mīm) over on the left. Mīm م has a long tail when it appears at the end of a word, as here, and the designer has decided to attach the tail to the ن (/n/, nūn) at the end of al-raḥman. You can see the same final م mīm and its tail at the end of the purple word al-raḥim, and in the middle of the blue word al-raḥman without the tail.

(Khaled Hosny, designer of the widely used Amiri font, told me that the design of Android basmala glyph is very bad. One of his criticisms was “the bizarre fusion of the letters” and I suppose the attachment of the م and the ن is one of the things he had in mind. He also objected to the insertion of “Allah” into the middle of “bismi”.)

The third word, in blue, is al-raḥman الرحمن which as you can see starts with the same letters as al-raḥim الرحيم. You can also see the same first two of those letters at the start of “Allah” الله. As I mentioned before, “al-” means “the”, so you see it at the beginning of many Arabic words. It also survives in many English words that are descended from Arabic, such as alcohol, alcove, algebra, algorithms, and alchemy.

(Not, however, “alligator”, where the “al-” is the Spanish word for “the”.)

The /r/ sound in al-raḥman and al-raḥim is made by the letter rā', which is written as the down-hanging hook to the left of the ال, as here: الر. The designer has connected the hook of the blue rā' with the upper part of a purple letter called ḥā'. (I suppose Hosny also dislikes this.) When written by itself ḥā looks like this: ح but when it's in the middle of a word it loses its fancy tail. The ḥā is of course the common ḥ in both al-raḥman and al-raḥim.

Let's see, what else? The only letter I haven't mentioned is the fifth letter in al-raḥim الرحيم, just before the mīm and its tail, called yā'. When by itself, it is written ي, but in the middle of a word like al-raḥim, it is the upward-pointing spike with two dots below.

Arabic writing is very beautiful, isn't it? Last time I tried to learn the alphabet I got stuck because I was trying to learn the sounds at the same time, and Arabic sounds are very different from English sounds. Arabic has three sounds that resemble English /h/. One is very soft, one is very rough, and one is in between. Ḥā' ح is the in-between one, represented in English as ‘ḥ’. The soft one, hā', is the last letter in الله Allah. Arabic also has a glottal stop, which is a sounds rarely used in English, but I have some practice saying it because it's the apostrophe in “Hawai'i”.

Wikimedia Commons has a gallery of basmalas, and web search produces thousands more. I am looking forward to understanding more of them.

[Other articles in category /lang] permanent link

My 1992 view of the problems of computer programming in 1992

While cleaning out my office today, I found this, which I wrote in 1992:

In the middle 1970's, the IBM corporation did (and perhaps still does) most of their in-house programming in a computer language called FORTRAN. They had a pretty good FORTRAN compiler, called the FORTRAN G compiler. It was fast at translating FORTRAN into machine instructions, and the machine instructions it produced implemented the desired behavior fairly efficiently. Nevertheless, IBM decided to write a new compiler.

This was very daring in the middle 1970's, because compilers were quite complicated programs, and are difficult to write, and it was surprising that IBM was willing to invest the vast resources that a new compiler would require when an adequate compiler was still available. IBM spent millions of dollars and hundreds of programmer-years, and produced the FORTRAN H compiler, which was fast, efficient, and full of nice features. It was an excellent compiler and is still the one that they use.

Here is the first punch line: Compiler programs are no longer difficult to write. The past fifteen years have seen an enormous increase in our understanding of compiler technology and how to write a compiler. Compilers are so easy to write now that third-year undergraduate computer science majors are expected to be able to turn out passable compilers in one semester.

Now a question: Since we're obviously thousands of times better at producing compilers than we were fifteen years ago, so much so that a single undergraduate can write a passable one in four months, why hasn't IBM invested millions of dollars and hundreds of programmer-years to produce a super FORTRAN I compiler that's thousands of times better than the FORTRAN H compiler?

The answer is that compiler program quality is no longer the limiting factor on our ability to write computer programs. The problems that programmers face no longer have to do with how good the compiler is. Instead, they are problems of method and language. We don't really know how to program yet, or how to manage our programs. We don't really know what we want to say or how to say it. We don't have good computer languages for expressing what we want to computer to do. We don't know how to think about programming. In short, the reason IBM doesn't bother with a super FORTRAN I compiler, is that no matter how good it was, it would still be FORTRAN.

Computer programming is still a black art. It's less than fifty years old, and nobody is very good at it yet. We can make better tools than we know how to use.

[Other articles in category /prog] permanent link

Egyptian fraction multiplication

(Very much previously: Egyptian Fractions)

Back in March, I had been reading On the Egyptian method of decomposing !!2/n!! into unit fractions by Abdulrahman A. Abdulaziz, and I reported that:

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.

Although I had long ago written an article about why the Rhind mathematical papyrus (RMP) has a table of Egyptian fraction expansions of !!\frac23, \frac25, \frac27\ldots!! but no similar table for any other numerator. I had proposed a very reasonable algorithm for how the table of !!\frac2n!! would give you the ability to compute !!\frac mn!! for any !!n!!, but for some reason I never connected this in my head with how the Egyptians actually did multiplication. The Egyptian multiplication algorithm makes my original surmise very plausible, but a little bit inside-out.

Also, this blog has somehow never discussed the ancient Egyptian method of multiplication, which reduces multiplication to addition without a need for multiplication tables. You don't have to remember complicated facts like !!7×8=56!!, only simple facts like !!7+7=14!!.

Egyptian multiplication

Let's say we'd like to multiply !!364!! by !!41!!. First let's observe that it's quites easy to double a number like !!364!!, significantly easier than to multiply it by anything else. First, !!4+4=8!!, so write down an !!8!! under the !!4!!:

$$ \begin{array}{} 3 & 6 & 4 \\ & & {\bf 8} \end{array} $$ Now !!6+6=12!! so write down a !!2!! under the !!7!! and note a carry in the next column. Or just remember it until the next step — when doubling, the carry is never bigger than !!1!!, so we don't have to remember how much it is, just that there is one:

$$ \begin{array}{} 3{\bf {}^\bullet} & 6 & 4 \\ & {\bf 2} & 8 \end{array} $$

The little mark by the !!3!! means that we are remembering there was a carry from the previous column.

Now !!3+3!! plus the carry is !!7!!, so write the !!7!! under the !!3!!:

$$ \begin{array}{} 3^1 & 6 & 4 \\ {\bf 7} & 2 & 8 \end{array} $$

And yes, !!364+364=728!!, quick and easy. Between each step and the next we only need to remember one thing: is there a carry? And someone can do the whole thing with minimal training, knowing only that !!1+1=2, 2+2=4, 3+3=6,\dots, 9+9=18!!.

Let's double again:

$$ \begin{array}{} 7 & 2{\bf {}^\bullet} & 8 \\ & & {\bf 6} \\[10pt] 7 & 2^\bullet & 8 \\ & {\bf 5 } & 6 \\[10pt] 7 & 2^\bullet & 8 \\ {\bf 14} & 5 & 6 \end{array} $$

When the Egyptians wanted to multiply !!364×41!!, they would do a series of these doublings, and label each one (perhaps just mentally) with the corresponding power of 2:

$$ \begin{array}{rr} 1 & 364 \\ 2 & 728 \\ 4 & 1456 \\ 8 & 2912 \\ 16 & 5824 \\ 32 & 11648 \\ \end{array} $$

Then they'd find the numbers in the left-hand column that added to 41, and mark them. This is easy to do, using the greedy method: !!32 < 41!!, so mark the !!32!!, then subtract !!41-32=9!! and proceed up to the next line. !!16\not\lt 9!!, so don't mark the !!16!!, but do mark the !!8!!, and so on:

$$ \begin{array}{rrr} 1 & 364 & ✅ \\ 2 & 728 & \\ 4 & 1456 & \\ 8 & 2912 & ✅ \\ 16 & 5824 & \\ 32 & 11648 & ✅ \\ \end{array} $$

Now just add up the middle column of numbers, but ignore the lines with no check marks:

$$ \begin{array}{rrr} 1 & 364 & ✅ \\ 8 & 2912 & ✅ \\ 32 & 11648 & ✅ \\ \hline & {\bf 14924} & \end{array} $$

And that's the answer, !!364 \times 41 = 14924!!. Isn't that cute?

The algorithm is really quite practical. It is often known as the Russian Peasant algorithm, apparently because it was also used by actual Russian peasants.

Once again, with fractions

Now fractions. Say we want to multiply !!4+\frac{1}{35}!! by !!29!!. The !!4!! we already know how to do and it is easy enough, we just do it like above, doubling !!4!! repeatedly and adding the correct doubles. Or if we're even a little clever we realize we can do it by doubling !!29!! twice, which is quicker.

But Egyptian notation for fractions was terrible. They had a notation for !!\frac1{35}!!, and a special notation for !!\frac 23!!, but no general quotient operation like the fraction bar. Instead they wrote fractions as sums of “unit fractions” with numerator !!1!!, and they had tables like the one in the Rhind Mathematical Papyrus, for converting non-unit fractions to sums of unit fractions, for example $$\frac2{35} = \frac1{30} + \frac1{42}.$$

!!\def\uf#1.{\frac1{#1}}\def\u#1.{\uf#1.}!!

So now we want to multiply !!19\times \frac1{35}!!. Per the algorithm we need to double !!\frac1{35}!! four times until we get !!\uf35. \times 16!!. For the first doubling we go to the table for !!\frac2{35}!!:

$$ \begin{array}{} 1 & \uf35. \\ 2 & \uf30. + \uf42. \\ \end{array} $$

For the next doubling, we don't have to go to the table, because the double of !!\uf30.!! is just !!\uf15.!! and the double of !!\uf42.!! is !!\uf21.!!. That's why the table prefers expansions with even denominators.

$$ \begin{array}{} 1 & \uf35. \\ 2 & \uf30. + \uf42. \\ 4 & \uf15. + \uf21. \\ \end{array} $$

For the third doubling we do go back to the table to find !!\frac2{15}!! and !!\frac2{21}!!:

$$ \begin{array}{} 1 & \uf35. \\ 2 & \uf30. + \uf42. \\ 4 & \uf15. + \uf21. \\ 8 & \uf10. + \uf30. + \uf14. + \uf42. \\ \end{array} $$

Since the denominators in the fourth row are all even, we don't need to consult the table to write the fifth row:

$$ \begin{array}{} 1 & \uf35. \\ 2 & \uf30. + \uf42. \\ 4 & \uf15. + \uf21. \\ 8 & \uf10. + \uf30. + \uf14. + \uf42. \\ 16 & \uf5. + \uf15. + \uf7. + \uf21. \\ \end{array} $$

Now we wanted !!29\times\uf35.!!, so add rows !!16, 8,4,!! and !!1!! because !!16+8+4+1=29!!. We get this:

$$ \begin{array}{rl} \frac{29}{35} = & \u35. \\ & + \color{darkgreen}{\u15.} + \color{purple}{\u21.} \\ & + \u10. + \u30. + \u14. + \u42. \\ & + \uf5. + \color{darkgreen}{\uf15.} + \uf7. + \color{purple}{\uf21.} \\ \end{array} $$

Oh no…

There are duplicates of !!\color{darkgreen}{\u15.}!! and !!\color{purple}{\u21.}!! and that's not allowed, so we use the !!\frac2n!! table to replace the !!\color{darkgreen}{\u15.+\u15.}!! with !!\u10.+\u30.!! and the !!\color{purple}{\u21.+\u21.}!! with !!\u14.+\u42.!!:

$$ \begin{array}{rl} \frac{29}{35} = & \u35. \\ & + \u10. + \u30. + \u14. + \u42. \\ & + \u5. + \u7. \\ & + \u10. + \u30. \\ & + \u14. + \u42. \end{array} $$

Now we have duplicate !!\u10., \u14., \u30.!! and !!\u42.!!. Fortunately all the denominators are even:

$$ \begin{array}{rl} \frac{29}{35} = & \u35. \\ & + \u5. + \u7. \\ & + \u5. + \u7. + \u15. + \u21. \end{array} $$

Now we go again to the table to eliminate the two !!\u5.!!'s and !!\u7.!!'s:

$$ \begin{array}{rl} \frac{29}{35} = & \u35. \\ & + \u3. + \u15. + \\ & + \u4. + \u28. + \\ & + \u15. + \u21. \end{array} $$

Once again we have two !!\u15.!!'s:

$$ \begin{array}{rl} \frac{29}{35} = & \u35. \\ & + \u3. \\ & + \u4. + \u28. + \\ & + \u21. \\ & + \u10. + \u30. \end{array} $$

and we are finally done, having discovered that !!\frac{29}{35} = \u3. + \u4. + \u10. + \u21. + \u28. + \u30.!!. Wow.

A slightly cleverer method would be to observe that !!29\times\u35. = \u35. + 28\times\u35. !!, and that !!28\times\u35. !! is simply !! 4\times \u5.!!. I imagine that a competent Egyptian scribe would have noticed this.

Did they really do this?

Wikipedia hints that perhaps the Egyptian didn't actually do go through all of this trouble, that perhaps they computed !!\frac{29}{35}!! first the way we did, as a vulgar fraction, and then only converted to the awful sum-of-unit-fractions notation when they needed to record the final answer.

This would have been analogous to how for hundreds of years Europeans would convert awful Roman numerals into an arrangement of counting board tokens (an abacus, essentially), do the calculation on the counting board, and then convert back to awful Roman numerals to record the answer.

While prearing this article I wondered: how can we even be sure that the algorithm will terminate? It's not clear to me. There was that point where we got rid of a !!\frac2{15}!! and then it came back and we had to get rid of it again.

I had Claude implement the algorithm, using the actual RMP !!\frac2n!! table, and run it for every product up to !!100\times \u101.!! to see if it would get stuck in any loops. It didn't.

It's possible that it would have looped if the !!\frac2n!! table I used had been a little different, and it would be very interesting to learn if the table itself had been somehow constructed so as to prevent the algorithm from looping. But I think it's more likely that it terminates for any reasonable !!\frac2n!! table, because the algorithm has some invariant that always decreases — one which I'm not yet clever enough to see.

I mentioned in the previous article:

The Egyptians, like everyone, often had to multiply by 10.

Most of the really big denominators in the !!\frac2n!! table are multiples of !!10!!. For example it has !!\frac2{47} = \u30. + \u141. + \u470.!! and if you're multiplying by !!2!! or even by !!10!!, only the middle part of this is any trouble. I wouldn't want to multiply !!10\times\u141.!! by the algorithm above, though — the !!\frac2n!! table doesn't even go that high. But maybe they would have done something like: !!10\times \u141. = 10\times(\u3. \times \u47)

$$ \begin{array}{rl} 10\times \u141. & = 9\cdot\u141. + \u141. \\ & = 9\left(\u3. \times \u47.\right) + \u141. \\ & = \frac2{47} + \u47. + \u141. \end{array} $$

which doesn't seem too awful.

This whole thing raises a big question for me. To have useful numbers, you need three things:

1. Addition
2. Multiplication
3. Comparison

People often forget #3, but it is crucial, because in the real world you are using the numbers to answer questions like “do we have enough bread to feed 119 laborers for 21 days?” or “will the bridge hold if I drive two loaded ox-carts across it” or similar questions that involve comparisons.

Say we're trying to figure out how to divide nine heaps of grain among !!99!! workers. Supposing that you had somehow failed to notice that the answer was !!\u11.!!, you might use the multiplication algorithm above, and after some grinding it would tell you that:

$$\frac9{99} = \u22. + \u33. + \u99. + \u198.$$

This is a useless answer because the !!\u198.!! means that you should start by taking half of one heap and dividing it into !!99!! equal shares of !!\u198.!! heap for each worker. This is impractical to say the least. So there must be some way to recognize that !!\u22. + \u33. + \u99. + \u198.!! is ⸢actually⸣ !!\u11.!!.

[Other articles in category /math] permanent link

Update: Here I am at the Sagrada Família

(Previously)

In 2003 I visited Barcelona and spent all day wandering around the mighty Basilica de la Sagrada Família, the architectural masterpiece of Antoni Gaudí. It had been under construction since 1882, and at the time only four of its 18 planned spires had been built. In the basement there was a museum with plans, renderings, and so on, and I discovered the plans for what it would look like when it was finished.

Then I waited 23 years, and now the moment has come. The largest and best of the spires is finished, and it does follow the plans I saw so long ago. Here's what it looks like:

Let's focus in on the detail I waited so long to see:

It was worth the wait.

[Other articles in category /art] permanent link

Egyptian fractions for 2/105

!!\def\u#1{\frac1{#1}}!!

The ancient Egyptians had a terrible notation for fractions. They had notations for !!\u n!! for each !!n!!, for !!\frac23!!, but everything else was written as a sum of these, with repeats forbidden, so that for example !!\frac25!! had to be written as !!\u3 + \u{15}!!. (Wikipedia)

In an older article about Egyptian fractions and the Rhind Mathematical Papyrus, I said:

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

I think I see now where this comes from. !!105 = 3·7·5!!, so two of the summands must have denominators divisible by !!5!! and by !!7!! respectively. The first thing you should do is consider $$\u5 + \u7 = \frac{12}{35} = \frac{36}{105}.$$

But you don't want !!\frac{36}{105}!!, you want !!\frac{2}{105}!!, so you multiply by !!\u{18}!!:

$$\u{18}\left(\u5 + \u7\right) = \u{90}+\u{126} = \frac 2{105}$$

and there it is.

Why pick !!\u5!! and !!\u7!! rather than, say, !!\u3!! and !!\u5!!? I suspect the answer is probably: Ahmes (or someone earlier) tried it both ways and picked the result they liked best. Remember Ahmes is compiling a reference table here, so he does these calculations once, writes down the best result, and throws the others away.

If you do the same trick with !!3!! and !!5!! instead you get !!\u3+\u5 = \frac8{15} = \frac{56}{105}!!. Then you multiply everything by !!\u{28}!! producing $$\u{84} + \u{140} = \frac2{105}$$ which seems a little worse than the other one. Using the !!3!! and the !!5!! produces $$\u{75} + \u{175} = \frac2{105}$$ which seems much worse.

Of course this only works when the denominator is composite.

Here's another approach, which doesn't work too well in this case but might be useful for other examples. Consider that !!\frac23 = \u2 + \u6!!. We want !!\frac2{105} = \u{35}\cdot\frac23!!. So

$$ \begin{align} \frac2{105} & = \u{35}\cdot\frac23 \\ & = \u{35}\left(\u2+\u6\right) \\ & = \u{70} + \u{210} \end{align} $$

The denominators here are a lot bigger than the first expansion, but they do at least have the advantage of being multiples of !!10!!. The Egyptians like this because they, like us, often need to multiply numbers by !!10!!, and whereas a fraction like !!\u{126}!! is hard for them to multiply by !!10!!, it's trivial to multiply !!\u{210}!! by !!10!!.

[Other articles in category /math] permanent link

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