2026-04-25 07:53:29
The equation of motion for a pendulum is the differential equation
where g is the acceleration due to gravity and ℓ is the length of the pendulum. When this is presented in an introductory physics class, the instructor will immediately say something like “we’re only interested in the case where θ is small, so we can rewrite the equation as
This raises a lot of questions, or at least it should.
First, sine is a nonlinear function, making the differential equation nonlinear. The nonlinear pendulum equation cannot be solved using mathematics that students in an introductory physics class have seen. There is a closed-form solution, but only if you extend “closed-form” to mean more than the elementary functions a student would see in a calculus class.
Second, the approximation is justified because sin θ ≈ θ when θ is small. That’s true, but it’s kinda subtle. Here’s a post unpacking that.
The third question doesn’t have a simple answer, though simple answers are often given. An instructor could make up an answer on the spot and say “less than 10 degrees” or something like that. A more thorough answer requires answering the fourth question.
I addresses how nonlinear affects the solutions in a post a couple years ago. This post will expand a bit on that post.
The primary difference between the nonlinear and linear pendulum equations is that the solutions to the nonlinear equation have longer periods. The solution to the linear equation is a cosine. Solving the equation determines the frequency, amplitude, and phase shift of the cosine, but qualitatively its just a cosine. The solution to the corresponding nonlinear equation, with sin θ rather than θ, is not exactly a cosine, but it looks a lot like a cosine, only the period is a little longer [1].
OK, the nonlinear pendulum has a longer period, but how much longer? The period is increased by a factor f(θ0) where θ0 is the initial displacement.
You can find the exact answer in my earlier post. The exact answer depends on a special function called the “complete elliptic integral of the first kind,” but to a good approximation
The earlier post compares this approximation to the exact function.
Since the nonlinear pendulum equation is roughly the same as the linear equation with a longer period, you can approximate the solution to the nonlinear equation by solving the linear equation but increasing the period. How good is that approximation?
Let’s do an example with θ0 = 60° = π/3 radians. Then sin θ0 = 0.866 but θ0, in radians, is 1.047, so we definitely can’t say sin θ0 is approximately θ0. To make things simple, let’s set ℓ = g. Also, assume the pendulum starts from rest, i.e. θ'(0) = 0.
Here’s a plot of the solutions to the nonlinear and linear equations.
Obviously the solution to the nonlinear equation has a longer period. In fact it’s 7.32% longer. (The approximation above would have estimated 7.46%.)
Here’s a plot comparing the solution of the nonlinear equation and the solution to the linear equations with period stretched by 7.32%.
The solutions differ by less than the width of the plotting line, so it’s too small to see. But we can see there’s a difference when we subtract the two solutions.
Here’s a plot of the solutions to the nonlinear and linear equations.
[1] The period of a pendulum depends on its length ℓ, and so we can think of the nonlinear term effectively replacing ℓ by a longer effective length ℓeff.
The post How nonlinearity affects a pendulum first appeared on John D. Cook.
2026-04-23 23:56:02
The previous post gave a simple and accurate approximation for the smaller angle of a right triangle. Given a right triangle with sides a, b, and c, where a is the shortest side and c is the hypotenuse, the angle opposite side a is approximately
in radians. The previous post worked in degrees, but here we’ll use radians.
If the triangle is oblique rather than a right triangle, there an approximation for the angle A that doesn’t require inverse trig functions, though it does require square roots. The approximation is derived in [1] using the same series that is the basis of the approximation in the earlier post, the power series for 2 csc(x) + cot(x).
For an oblique triangle, the approximation is
where s is the semiperimeter.
For comparison, we can find the exact value of A using the law of cosines.
and so
Here’s a little Python script to see how accurate the approximation is.
from math import sqrt, acos
def approx(a, b, c):
"approximate the angle opposite a"
s = (a + b + c)/2
return 6*sqrt((s - b)*(s - c)) / (2*sqrt(b*c) + sqrt(s*(s - a)))
def exact(a, b, c):
"exact value of the angle opposite a"
return acos((b**2 + c**2 - a**2)/(2*b*c))
a, b, c = 6, 7, 12
print( approx(a, b, c) )
print( exact(a, b, c) )
This prints
0.36387538476776243 0.36387760856668505
showing that in our example the approximation is good to five decimal places.
[1] H. E. Stelson. Note on the approximate solution of an oblique triangle without tables. American Mathematical Monthly. Vol 56, No. 2 (February, 1949), pp. 84–95.
The post Approximation to solve an oblique triangle first appeared on John D. Cook.2026-04-23 20:13:35
Suppose you have a right triangle with sides a, b, and c, where a is the shortest side and c is the hypotenuse. Then the following approximation from [1] for the angle A opposite side a seems too simple and too accurate to be true. In degrees,
A ≈ a 172° / (b + 2c).
The approximation above only involves simple arithmetic. No trig functions. Not even a square root. It could be carried out with pencil and paper or even mentally. And yet it is surprisingly accurate.
If we use the 3, 4, 5 triangle as an example, the exact value of the smallest angle is
A = arctan(3/4) × 180°/π ≈ 36.8699°
and the approximate value is
A ≈ 3 × 172° / (4 + 2×5) = 258°/7 ≈ 36.8571°,
a difference of 0.0128°. When the angle is more acute the approximation is even better.
Where does this magical approximation come from? It boils down to the series
2 csc(x) + cot(x) = 3/x + x³/60 + O(x4)
where x is in radians. When x is small, x³/60 is extremely small and so we have
2 csc(x) + cot(x) ≈ 3/x.
Apply this approximation with csc(x) = c/a and cot(x) = b/a. and you have
x ≈ 3a/(b + 2c)
in radians. Multiply by 180°/π to convert to degrees, and note that 540/π ≈ 172.
It’s unmotivated to say “just expand 2 csc(x) + cot(x) in a series.” Where did that come from?
There’s a line in [1] that says “It can been seen, either from tables or from a consideration of power series that the radian measure of a small angle lies approximately one-third of the way from the sine to the tangent.” In other words
3x ≈ 2 sin(x) + tan(x).
You can verify that by adding the power series and noting that the cubic terms cancel out.
But that’s just the beginning. The author then makes the leap to conjecturing that if the weighted arithmetic mean gives a good approximation, maybe the weighted harmonic mean gives an even better approximation, and that leads to considering
2 csc(x) + cot(x) ≈ 3/x.
See the next post for an extension to oblique triangles. Not as simple, but based on the same trick.
[1] J. S. Frame. Solving a right triangle without tables. The American Mathematical Monthly, Vol. 50, No. 10 (Dec., 1943), pp. 622-626
The post Simple approximation for solving a right triangle first appeared on John D. Cook.2026-04-22 04:14:40
AI coding agents improved greatly last summer, and again last December-January. Here are my experiences since my last post on the subject.
The models feel subjectively much smarter. They can accomplish a much broader range of tasks. They seem to have a larger, more comprehensive in-depth view of the code base and what you are trying to accomplish. They can locate more details in obscure parts of the code related to the specific task at hand. By rough personal estimate, I would say that they helped me with 20% of my coding effort last August and about 60% now. Both of these figures may be below what is possible, I may not be using them to fullest capability.
This being said, they are not a panacea. Sometimes they need help and direction to where to look for a problem. Sometimes they myopically look at the trees and don’t see the forest, don’t step back to see the big picture to understand something is wrong at a high level. Also they can overoptimize to the test harness. They can also generate code that is not conceptually consistent with existing code.
They can also generate much larger amounts of code than necessary. Some warn that that this will lead to explosion of coding debt. On the other hand, you can also guide the coding agent to refactor and improve its own code—quickly. In one case I’ve gotten it to reduce the size of one piece of code to less than half its original size with no change in behavior.
I use OpenAI Codex rather than Claude Code. I’m glad to hear some technically credible people think this a good choice. Though maybe I should try both.
My work is a research project for which the code itself is the research product, so I can’t give specifications of everything in advance; writing the code itself is a process of discovery. Also, I want a code base that remains human-readable. So I am deeply involved in discussion with the coding agent that will sometimes go off to do a task for some period of time. It is not my desire to treat the agent as what some have called a dark software factory.
Some say they fear that using a coding agent will result in forgetting how to write code without one. I have felt this, but from having exercised this muscle for such a very long time I don’t think it is a skill I would easily forget. The flip side of this argument is, you might even learn new coding idioms from observing what the coding agent writes, that is a good thing.
Some say they haven’t written a line of code in weeks because the coding agent does it for them. I don’t think I’ll ever stop writing code, any more than I will stop scribbling random ideas on the back of an envelope, or typing out some number of lines of code by which I discover some new idea in real time while I am typing. Learning is multisensory.
My hat’s off to the developers who are able to keep many different agents in flight at the same time. Personally I have difficulty handling the cognitive load of thinking deeply about each one and doing a mental context switch across many agents. Though I am experimenting with running more than one agent so I can be doing something while another agent is working.
I continue to be astounded by productivity gains in some situations. I recently added a new capability, which normally I think would’ve taken me two months to learn a whole new algorithmic method and library to use. With the coding agent, it took me four days to get this done, on the order of 10X productivity increase. Though admittedly things are not always that rosy.
In short, the tools are getting better and better. I’m looking forward to what they will be like a few months or a year from now.
The post An AI Odyssey, Part 4: Astounding Coding Agents first appeared on John D. Cook.2026-04-20 21:50:33
A few days ago I wrote a post on Newton’s diameter theorem. The theorem says to plot the curve formed by the solutions to f(x, y) = 0 where f is a polynomial in x and y of degree n. Next plot several parallel lines that cross the curve at n points and find the centroid of the intersections on each line. Then the centroids will fall on a line.
The previous post contained an illustration using a cubic polynomial and three evenly spaced parallel lines. This post uses a fifth degree polynomial, and shows that the parallel lines need not be evenly spaced.
In this post
f(x, y) = y³ + y − x (x + 1) (x + 2) (x − 3) (x − 2).
Here’s an example of three lines that each cross the curve five times.
The lines are y = x + k where k = 0.5, −0.5, and −3. The coordinates of the centroids are (0.4, 0.9), (0.4, -0.1), and (0.4, -2.6).
And to show that the requirement that the lines cross five times is necessary, here’s a plot where one of the parallel lines only crosses three times. The top line is now y = x + 2 and the centroid on the top line moved to (0.0550019, 2.055).
2026-04-18 22:49:27
The previous post looked at the FP4 4-bit floating point format. This post will look at another 4-bit floating point format, NF4, and higher precision analogs. NF4 and FP4 are common bitsandbytes 4-bit data types. If you download LLM weights from Hugging Face quantized to four bits, the weights might be in NF4 or FP4 format. Or maybe some other format: there’s a surprising amount of variety in how 4-bit numbers are implemented.
LLM parameters have a roughly Gaussian distribution, and so evenly spaced numeric values are not ideal for parameters. Instead, you’d like numbers that are closer together near 0.
The FP4 floating point numbers, described in the previous post, are spaced 0.5 apart for small values, and the larger values are spaced 1 or 2 apart. That’s hardly a Gaussian distribution, but it’s closer to Gaussian than a uniform distribution would be. NF4 deliberately follows more of a Gaussian distribution.
The QLoRA formats [1], unlike FP4, are not analogs of IEEE numbers. The bits are not interpreted as sign, exponent, and mantissa, but rather as integers to be used as indexes. An NFn number is an index into a list of 2n real numbers with Gaussian spacing. To put it another way, the numbers represented by NFn have uniformly distributed z-scores.
That makes sense at a high level, but the paper [1] is hard to follow in detail. It says
More formally, we estimate the 2k values qi of the data type as follows:
where QX(·) is the quantile function of the standard normal distribution N(0, 1).
The paper doesn’t give the range of i but it says there are 2k values, implying that i runs from 0 to 2k −1 or from 1 to 2k. Either way runs into infinite values since Q(0) = −∞ and Q(1) = ∞. We could avoid infinities by letting i run from 1 to 2n − 1.
The next sentence is puzzling.
A problem for a symmetric k-bit quantization is that this approach does not have an exact representation of zero, which is an important property to quantize padding and other zero-valued elements with no error.
I understand the desire to represent 0 exactly, but the equation above has an exact representation of 0 when i = 2n − 1. Perhaps the authors had in mind that i takes on the values ½, 1 + ½, 2 + ½, …, 2n − ½. This would be reasonable, but a highly unusual use of notation. It seems that the real problem is not the lack of a representation of 0 but an unused index, with i running from 1 to 2n − 1.
To be fair, the first sentence quoted above says “we estimate the 2k values …” and so the equation above may not be intended as a definition but as motivation for the actual definition.
The authors give a procedure for using 2n values of i and obtaining an exact representation of 0, and they give a list of NF4 values in Appendix E. I was not able to get the two to match. I implemented a few possible interpretations of the procedure described in the paper, and each approximates the list of values in the appendix, but not closely.
The following code, written with the help of ChatGPT, reverse engineers the NF4 values to 8 decimal places, i.e. to the precision of a 32-bit floating point number.
from scipy.stats import norm
Q = norm.ppf
α = 0.9677083
Z = Q(α)
δ1 = (α - 0.5)/7
δ2 = (α - 0.5)/8
q = [0]*16
for i in range(7):
q[i] = -Q(α - i*δ1)/Z
for i in range(8):
q[i+8] = Q(0.5 + (i+1)*δ2)/Z
# Values given in Appendix E
NF4 = [
-1.0,
-0.6961928009986877,
-0.5250730514526367,
-0.39491748809814453,
-0.28444138169288635,
-0.18477343022823334,
-0.09105003625154495,
0.0,
0.07958029955625534,
0.16093020141124725,
0.24611230194568634,
0.33791524171829224,
0.44070982933044434,
0.5626170039176941,
0.7229568362236023,
1.0
]
# Compare
for i in range(16):
print(i, NF4[i] - q[i])
The magic number α = 0.9677083 is a mystery. I asked ChatGPT to look into this further, and it said that bitsandbytes uses α = 929/960 = 0.9677083333333333. When I use this value for α the precision is about the same, which is fine. However, the values in the paper were given to 16 decimal places, so I thought it might be able to match the values to more precision.
Quibbles over the exact values of NF4 aside, the NF4 format works well in practice. Models. quantized to 4 bits using NF4 perform better than models quantized to other 4-bit formats on some benchmarks.
[1] QLoRA: Efficient Finetuning of Quantized LLMs by Tim Dettmers, Artidoro Pagnoni, Ari Holtzman, and Luke Zettlemoyer. https://arxiv.org/abs/2305.14314.
The post Gaussian distributed weights for LLMs first appeared on John D. Cook.
