2025-06-29 19:33:57
The exponential sum of the day page on my site draws an image every day by plugging the month, day, and year into a formula. Details here.
Today’s image looks almost solid blue in the middle.
The default plotting line width works well for most days. For example, see what the sum of the day will look line on July 1 this year. Making the line width six times thinner reveals more of the detail in the middle.
You can see even more detail in a PDF of the plot.
The post Zooming in on a fractalish plot first appeared on John D. Cook.2025-06-27 21:26:41
All integers are real numbers, but most computer representations of integers do not equal computer representations of real numbers.
To make the statement above precise, we have to be more specific about what we mean by computer integers and floating point numbers. I’ll use int32 and int64 to refer to 32-bit and 64-bit signed integers. I’ll use float32 and float64 to refer to IEEE 754 single precision and double precision numbers, what C calls float and double.
Most int32 numbers cannot be represented exactly by a float32. All int32 numbers can be represented approximately as float32 numbers, but usually not exactly. The previous statements remain true if you replace “32” everywhere by “64.”
The int32 data type represents integers −231 through 231 − 1. The float32 data type represents numbers of the form
± 1.f × 2e
where 1 bit represents the sign, 23 bits represent f, and 8 bits represent e.
The number n = 224 can be represented by setting the fractional part f to 0 and setting the exponent e to 24. But the number n + 1 cannot be represented as a float32 because its last bit would fall off the end of f:
224 + 1 = (1 + 2−24) 224 = 1.000000000000000000000001two × 224
The bits in f fill up representing the 23 zeros after the decimal place. There’s no 24th bit to store the final 1.
For each value of e, there are 223 possible values of f. So for each of e = 24, 25, 26, …, 31 there are 223 representable integers, for a total of 8 × 223.
So of the 231 non-negative integers that can be represented by an int32 data type, only 9 × 223 can also be represented exactly as a float32 data type. This means about 3.5% of 32-bit integers can be represented exactly by a 32-bit float.
The calculations for 64-bit integers and 64-bit floating point numbers are analogous. Numbers represented by float64 data types have the form
± 1.f × 2e
where now f has 52 bits and e has 11.
Of the 263 non-negative integers that can be represented by an int64 data type, only 11 × 252 can also be represented exactly as a float64 data type. This means about 0.5% of 64-bit integers can be represented exactly by a 64-bit float.
Python’s integers have unlimited range, while its floating point numbers correspond to float64. So there are two reasons an integer might not be representable as a float: it may be larger than the largest float, or it may require more than 53 bits of precision.
2025-06-27 08:58:26
Years ago I wrote about a fast way to test whether an integer n is a square. The algorithm rules out a few numbers that cannot be squares based on their last (hexidecimal) digit. If the the integer passes through this initial screening, the algorithm takes the square root of n as a floating point number, rounds to an integer, and tests whether the square of the rest equals n.
The algorithm described above works fine if n is not too large. However, it implicitly assumes that the integer can be represented exactly as a floating point number. This is two assumptions: (1) it’s not too large to represent, and (2) the representation is exact.
A standard 64-bit floating point number has 1 bit for the sign, 11 bits for the exponent, and 52 bits for the significand. (More on that here.) Numbers will overflow if they run out of exponent bits, and they’ll lose precision if they run out of significand bits. So, for example, 21024 will overflow [1]. And although 253 + 1 will not overflow, it cannot be represented exactly.
These are illustrated in Python below.
>>> float(2**1024)
OverflowError: int too large to convert to float
>>> n = 2**53
>>> float(n) == float(n + 1)
True
The following algorithm [2] uses only integer operations, and so it will work exactly for arbitrarily large integers in Python. It’s a discrete analog of Newton’s square root algorithm.
def intsqrt(N):
n = N
while n**2 > N:
n = (n + N//n) // 2
return n
def issquare(N):
n = intsqrt(N)
return n**2 == N
The function issquare will test whether N is a square. The function intsqrt is broken out as a separate function because it is independently useful since it returns ⌊√N⌋.
The code above correctly handles examples that the original algorithm could not.
>>> issquare(2**1024)
True
>>> issquare(2**54)
True
>>> issquare(2**54 + 1)
False
You could speed up issquare by quickly returning False for numbers that cannot be squared on account of their final digits (in some base—maybe you’d like to use a base larger than 16) as in the original post.
[1] The largest allowed exponent is 1023 for reasons explained here.
[2] Bob Johnson. A Route to Roots. The Mathematical Gazette, Vol. 74, No. 469 (Oct., 1990), pp. 284–285
The post Test whether a large integer is a square first appeared on John D. Cook.2025-06-26 21:38:09
What does an eighteenth century French mathematician have to do with the Ethereum cryptocurrency?
A pseudorandom number generator based on Legendre symbols, known as Legendre PRF, has been proposed as part of a zero knowledge proof mechanism to demonstrate proof of custody in Ethereum 2.0. I’ll explain what each of these terms mean and include some Python code.
The equation x² = a mod p is solvable for some values of a and not for others. The Legendre symbol
is defined to be 1 if a has a square root mod p, and −1 if it does not. Here a is a positive integer and p is a (large) prime [1]. Note that this is not a fraction, though it looks like one.
As a varies, the Legendre symbols vary randomly. Not literally randomly, of course, but the act random enough to be useful as a a pseudorandom number generator.
Generating bits by computing Legendre symbols is a lot more work than generating bits using a typical PRNG, so what makes the Legendre PRF of interest to Ethereum?
Legendre symbols can be computed fairly efficiently. You wouldn’t want to use the Legendre PRF to generate billions of random numbers for some numerical integration computation, but for a zero knowledge proof you only need to generate a few dozen bits.
To prove that you know a key k, you can generate a string of pseudorandom bits that depend on the key. If you can do this for a few dozen bits, it’s far more likely that you know the key than that you have guessed the bits correctly. Given k, the Legendre PRF computes
for n consecutive values of x [2].
One reason this function is of interest is that it naturally lends itself to multiparty computation (MPC). The various parties could divide up the range of x values that each will compute.
The Legendre PRF has not been accepted to be part of Ethereum 2.o. It’s only been proposed, and there is active research into whether it is secure enough.
Here’s a little Python scrypt to demonstrate using Lk(x).
from sympy import legendre_symbol
def L(x, k, p):
return (1 - legendre_symbol(x + k, p)) // 2
k = 20250626
p = 2**521 - 1
print([L(x, k, p) for x in range(10)])
This produces the following.
[1, 1, 1, 1, 0, 0, 1, 0, 0, 1]
[1] There is a third possibility: the Legendre symbol equals 0 if a is a multiple of p. We can safely ignore this possibility for this post.
[2] The Legendre symbol takes on the values ±1 and so we subtract this from 1 to get values {0, 2}, then divide by 2 to get bits {0, 1}.
The post Legendre and Ethereum first appeared on John D. Cook.2025-06-25 23:44:58
The previous post looked at a function formed by patching together the function
f(x) = log(1 + x)
for positive x and
f(x) = x
for negative x. The functions have a mediocre fit, which may be adequate for some applications, such as plotting data points, but not for others, such as visual design. Here’s a plot.
There’s something not quite smooth about the plot. It’s continuous, even differentiable, at 0, but still there’s sort of a kink at 0.
The way to quantify smoothness is to count how many times you can differentiate a function and have a continuous result. We would say the function above is C¹ but not C² because its first derivative is continuous but not differentiable. If two functions have the same number of derivatives, you can distinguish their smoothness by looking at the size of the derivatives. Or if you really want to get sophisticated, you can use Sobolev norms.
As a rule of thumb, your vision can detect a discontinuity in the second derivative, maybe the third derivative in some particularly sensitive contexts. For physical applications, you also want continuous second derivatives (acceleration). For example, you want a roller coaster track to be more than just continuous and once differentiable.
Natural cubic splines are often used in applications because they patch cubic polynomials together so that the result is C².
You can patch together smooth functions somewhat arbitrarily, but not analytic functions. If you wanted to extend the function log(1 + x) analytically, your only choice is log(1 + x). More on that here.
If you patch together a flat line and a circle, as in the corners of a rounded rectangle, the curve is continuous but not C². The second derivative jumps from 0 to 1/r where r is the radius of the circle. A squircle is similar to a rounded rectangle but has smoothly varying curvature.
2025-06-24 22:38:13
I saw a post online this morning that recomended the transformation
I could see how this could be very handy. Often you want something like a logarithmic scale, not for the exact properties of the logarithm but because it brings big numbers closer in. And for big values of x there’s little difference between log(x) and log(1 + x).
The function above is linear near the origin, literally linear for negative values and approximately linear for small positive values.
I’ve occasionally needed something like a log scale, but one that would handle values that dip below zero. This transformation would be good for that. If data were equally far above and below zero, I’d use something like arctangent instead.
Notice that the function has a noticeable bend around 0. The next post addresses this.
The post Log-ish first appeared on John D. Cook.
