Matthew van Eerde's web log : Math

Rules for making change

Maurits — Wed, 25 Nov 2009 18:40:00 GMT

It happens a million times a day. Somebody pays cash for something and gets change. But there are rules, and Raymond's friend seems to like to break those rules. Luckily for Raymond's friend, one of the rules is the customer is always right... or as Mr. Krabs would say, the money is always right. This blog post is about a couple of the more mathematical rules.

Rule for the cashier: you must give "canonical" change.

Whether to honor requests for non-canonical change is a complicated morass I will not attempt to tackle in this blog post as too much depends on context. But the initial offering must be canonical.

By "canonical change", I mean the cashier must give change using the smallest possible number of canonical coins and bills. For example, (one quarter + one nickel) is a rendering of $0.30 using only two coins, while (three dimes) is three coins, so a cashier must never give change that includes three dimes.

By "canonical coins and bills" I mean (in the U.S.) this precise list:

penny

nickel

dime

quarter

$1 bill

$5 bill

$10 bill

$20 bill

I discuss usage of non-canonical (unusual) coins and bills later.

Rule 1 for the customer: "Tap, tap, no takebacks"

The tender and canonical change cannot intersect.

Don't give the cashier anything they would just hand back to you directly.

This is the rule that Raymond's friend broke - it just wastes everyone's time to play musical chairs with the money.

Actually, this rule is just a corollary of the more general rule:

Rule 2 for the customer: "No side transactions."

No subset of the tender can have the same value as any subset of canonical change for that tender.

Don't give the cashier anything that they would just hand back to you in coalesced form.

If you want to consolidate your change, go to a bank or use one of those big machines.

Corollary 1: it is always OK to pay with a single large bill.
Corollary 2: it is always OK to give exact change.

Unusual denominations:

The two-dollar bill, the dollar coin (in any of its forms), the half-dollar coin, and bills higher than $20 are "unusual" denominations that complicate the situation slightly.

Rule for the cashier: Unusual denominations stay in the drawer.

Accept them (unless there are security rules at your place of business) but they are explicitly not part of any canonical change.

Rule for the customer: Go right ahead.

You can pay with an unusual denomination provided that you do not break the "no side transactions" rule or any large-denomination security rule at the business in question.

Examples:

In the following examples, "total" is the amount owed; "tender" is the amount the customer gives to the cashier; and "change" is what the cashier gives back to the customer.

Total	Tender	Change	Notes
$5.20	$5 bill + $2 bill	$1 bill + three quarters + one nickel	OK - cashier correctly accepted the $2
$5.20	$5 bill + $1 bill	two quarters + three dimes	Cashier gave out more coins than necessary
$5.20	$5 bill + $1 bill	half-dollar + one quarter + one nickel	Cashier gave out non-canonical half-dollar
$5.20	$5 bill + four quarters	three quarters + one nickel	Customer gave three "takeback" quarters
$5.20	$5 bill + quarter + nickel	dime	OK
$5.20	$5 bill + quarter + five pennies	dime	OK
$5.20	$5 bill + quarter + ten pennies	dime + nickel	Customer got nickel for five pennies in "side transaction"

In the last row, you can think of the "side transaction" as either five pennies for a nickel or ten pennies for a dime. I prefer the former.

How to calculate a sine sweep - the right way

Maurits — Sat, 08 Aug 2009 01:12:00 GMT

Three quarters are better than a dollar because they make noise!
-- Lilly, Lilly's Purple Plastic Purse

Last time I talked about how to calculate a sine sweep mathematically. There's a closed-form solution which is quite elegant but, alas, useless in a practical computer implementation due to the very big numbers that are being fed to the sin(...) function.

A computer implementation will care only about the discrete samples that need to be generated. The integral in the previous post turns out to be counterproductive - we're much more interested in the infinite sequence of φ_i, and more particularly in their residue mod 2π.

Here are Matlab scripts that implement a sine sweep both ways:

First, the naïve mathematical solution that just calculates the exponential:

function signal = sinesweep_nostate( ...
    start, ...
    finish, ...
    seconds, ...
    sample_rate, ...
    amplitude, ...
    initial_phase, ...
    dc ...
)
% sinesweep_nostate returns a single-channel sine logarithmic sweep
%     DO NOT USE THIS FUNCTION IN PRODUCTION
%     THIS IS A PEDAGOGICAL EXERCISE ONLY
%     THE SIGNAL THIS PRODUCES GRADUALLY DISTORTS
%     INSTEAD USE sinesweep
%
%     start: starting frequency in Hz
%     finish: ending frequency in Hz
%     seconds: duration of sweep in seconds
%     samplerate: samples per second
%     amplitude: amplitude
%     initial_phase: starting phase
%     dc: dc

% echo these interesting intermediate values to the console
R = (finish / start) ^ (1 / seconds)
B = 2 * pi * start / log(R)
A = initial_phase - B

time = 0 : 1 / sample_rate : seconds;
phase = A + B * R .^ time;
signal = amplitude * sin(phase) + dc;

end % sinesweep_nostate

Now, the iterative version that adds up the little Δφs to calculate φ_i iteratively:

function signal = sinesweep( ...
    start, ...
    finish, ...
    seconds, ...
    sample_rate, ...
    amplitude, ...
    initial_phase, ...
    dc ...
)
% sinesweep returns a single-channel sine logarithmic sweep
%     start: starting frequency in Hz
%     finish: ending frequency in Hz
%     seconds: duration of sweep in seconds
%     samplerate: samples per second
%     amplitude: amplitude
%     initial_phase: starting phase
%     dc: dc

time = 0 : 1 / sample_rate : seconds;
frequency = exp( ...
    log(start) * (1 - time / seconds) + ...
    log(finish) * (time / seconds) ...
);

phase = 0 * time;
phase(1) = initial_phase;
for i = 2:length(phase)
    phase(i) = ...
        mod(phase(i - 1) + 2 * pi * frequency(i) / sample_rate, 2 * pi);
end

signal = amplitude * sin(phase) + dc;

end % sinesweep

If anything, one would expect the first to be more accurate, since it is mathematically precise, and the second is only an approximation. But let's see how the signal produced by each of them holds up.

I calculate, and plot, the same sweep both ways, with a slight dc offset to facilitate seeing the different sweeps on the same plot. In particular this is a logarithmic sweep from 20 kHz to 21 kHz, over 30 seconds, using 44100 samples per second, an amplitude of 0.2, an initial phase of π, and a dc of 0.25 for one and 0.26 for the other:

plot(...
x, sinesweep(20000, 21000, 30, 44100, 0.2, pi, 0.25), 'd', ...
x, sinesweep_nostate(20000, 21000, 30, 44100, 0.2, pi, 0.26), 's' ...
)

(x is just 1:30*44100 - necessary to allow a single plot statement.)

Note that the approximate method is plotted in diamonds, and will be 0.01 lower on the resulting graph than the "exact" method, plotted in squares.

(This takes a while to plot because there are a heckuva lot of points...)

Ah, a nice solid mass of green and blue. I won't show it here.

OK, let's zoom in to a very early chunk of the signal - I expect these to match up closely, with only the dc offset separating the points:

Yup. Looks pretty good - give or take a pixel (quantization error in the display.)

Now let's see what happens to the signal towards the end of the 30 seconds.

Ick. Something's rotten in the state of Denmark. This distortion is so bad that it's visible - you don't even have to take an FFT to see it.

Exercise: take an FFT and look at the distortion.

Advanced Exercise: demonstrate that the distortion is, in fact, in the "exact" method and not in the iterative method... that is to say, show which clock is right.

EDIT: On second glance it looks like the second picture is just showing a horizontal shift between the two signals, which is expected. I'll need to dig deeper if I'm to prove my assertion that the iterative method produces less distortion than the "exact" method.

How to calculate a sine sweep - the wrong way

Maurits — Tue, 04 Aug 2009 00:07:00 GMT

Suppose you want to generate a continuous sine-sweep from time t_start to time t_end. You want the starting frequency to be ω_start, and the ending frequency to be ω_end; you want the sweep to be logarithmic, so that octaves are swept out in equal times. (The alternative would be to sweep linearly, but usually logarithmic sweeping is what you want.) For today we're going to have continuous time and sample values, so sample rate and bit depth will not be part of this discussion; in particular, the units of t will be seconds, and our sample values will go from -1 to 1.

Here's a picture of want we want to end up with:

Without loss of generality, set t_start = 0. This simplifies some of the math.

Let ω(t) be the "instantaneous frequency" at time t. Advanced Exercise: Define "instantaneous frequency" mathematically.

Sweeping ω(t) logarithmically means that log ω(t) is swept linearly from log ω_start to log ω_end. So

Quick check: ω(0) = ω_start, ω(t_end) = ω_end. Yup.

Let's define R (the rate of change of the frequency) as (ω_end / ω_start)^{1 / t_end}. This formula reduces to

ω(t) = ω_start R^t

Next step is to look at phase. For a sine wave of constant frequency ω, phase progresses linearly with t on the circular interval [0, 2π):
φ = k ω t
for some constant k. If the frequency of a sine wave was 1 cycle per second, the phase would go from 0 to 2π in a single second - this reveals that the correct value of k is 2π:
φ = 2π ω t

What happens with a variable frequency? A little calculus provides the answer. Consider a small change Δt, small enough so that ω(t) is almost constant over the interval:
Δφ ≈ 2π ω(t) Δt
because over that interval the sine sweep function is well approximated by a sine wave of constant frequency ω(t).

Starting from an initial phase φ_start, let Δt → 0, and:

Substitute:
u = τ log R
τ = u / log R
dτ = du / log R

Define:
B = 2π ω_start / log R
A = φ_start - B
and we have:

φ(t) = A + BR^t

Just for fun, here's the explicit solution without intermediate values:

Now, the payoff: the signal is just the sine of the phase, so our sine sweep is:

or, more explicitly:

Ah, beautiful mathematically.

But useless practically.

Why useless?

Well, note that our equation for phase is an exponential. That expression inside the sin(...) gets very big, very quickly. Any practical implementation of sin(...) is going to be utterly useless once its argument gets beyond a certain threshold - you'll get ugly chunky steps before you're halfway into the sweep.

Nonetheless, there is a practical way to generate (pretty good) sine sweeps. More on that next time.

EDIT: all logs are base e.

Why square waves have ears: Gibbs' phenomenon (Wilbraham's phenomenon)

Maurits — Thu, 07 May 2009 22:30:00 GMT

In a recent post I sung the praises of square waves as a way to get a heckuva lot of power (3 dB more power than a sine wave) into a sample-range-limited signal. It's time to take them down a notch now.

A problem with square waves is they're impossible to generate in the analog domain. In fact, you can't even get close.

Signals generated in the analog domain are subject to physical laws regarding continuity (no teleportation) and whatnot. A common way to model these is to express (periodic) analog signals using a basis of sine waves with integral periods. Suppose I want to generate the square wave:

f(x) = 1, -π < x < 0

-1, 0 < x < π

Graphed below are some approximations of this function using sine waves as a basis. Note that only odd values of n are used in the sums of sin(nx).

The sums converge to +/-1 quite well, but there are definite "ears" at x near 0 where there's overshoot. This doesn't appear to die down. A closeup of one of the "ears":

If anything, rather than dying down, the "ears" converge to max(f_n) → about 1.18, or about 9% of the "jump" from -1 to 1. (Dym and McKean, in their 1972 book Fourier Series and Integrals, get the 9% right but incorrectly assert that the convergence is to 1.09.)

This mathematical phenomenon - Gibbs' phenomenon - is a good illustration of the difference between convergence of a series of functions and uniform convergence.

In this case, the series of partial sums pointwise converge to the square wave... for any given point x > 0 and ε > 0, the ear will eventually move to the left, and I can choose an N such that f_n(x) is within of ε of 1 for all n > N...

... but the series does not uniformly converge to the square wave. The following assertion is false: "for any given ε > 0, I can pick an N such that f_n(x) is within of ε of 1 for all n > N and all x > 0." This can be demonstrated by picking ε = 0.17, say. For any n, even, say, n = 10¹⁰⁰, there is an x close to 0 where f_1e100(x) > 1.17.

Second cousins, cousins once removed; relationships by generations to common ancestor

Maurits — Mon, 27 Apr 2009 21:04:00 GMT

Raymond Chen explains some common terms for blood relatives of varying distance across cultures in his blog post "What kind of uncle am I?"

He links to a diagram on genealogy.com that I felt was lacking something... so here's my version, with consanguinary colors.

Red means "marriage is almost certainly legally prohibited."

Yellow means "marriage may be legally prohibited - check your region's laws."

Green means "marriage is amost certainly legal."

Relationship by generations to common ancestor
#	0	1	2	3	4	...	m
0	self	father/mother	grand (father/mother)	great‑ grand (father/mother)	(great‑)² grand (father/mother)		(great-)^m ‑ 2 grand (father/mother)
1	son/daughter	brother/sister	aunt/uncle	grand (aunt/uncle)	great‑ grand (aunt/uncle)		(great‑)^m ‑ 3 grand (aunt/uncle)
2	grand (son/daughter)	niece/nephew	(first) cousin	first cousin, once removed	first cousin, twice removed		first cousin, (m ‑ 2) times removed
3	great‑ grand (son/daughter)	grand (niece/nephew)	first cousin, once removed	second cousin	second cousin, once removed		second cousin, (m ‑ 3) times removed
4	(great‑)² grand (son/daughter)	great- grand (niece/nephew)	first cousin, twice removed	second cousin, once removed	third cousin		third cousin, (m ‑ 4) times removed
...
n	(great‑)^n ‑ 2 grand (son/daughter)	(great‑)^n ‑ 3 grand (niece/nephew)	first cousin, (n ‑ 2) times removed	second cousin, (n ‑ 3) times removed	third cousin, (n ‑ 4) times removed		(n == m) ? ((n ‑ 1)th cousin) : ((min(n, m) ‑ 1)th cousin, \|n ‑ m\| times removed)

Why a full-scale sine wave has an intensity of -3 dB FS

Maurits — Wed, 08 Apr 2009 01:20:00 GMT

I was asked one day why this full-scale sine wave was being measured by our signal analysis tools as -3 dB FS, even though it hits the maximum and the minimum sample values:

The answer is "because it's a sine wave, not a square wave." The intensity of a signal can be calculated from the following formula:

The inner integral does not depend on t - it's just the average sample value - so it's usually precalculated:

The importance of taking dc into account during analysis can be appreciated if you try to calculate the intensity of a signal with a high dc.

Exercise: calculate the intensity of x(t) ≡ -0.5 using the formulas above; calculate the "naïve intensity" by using the last formula above and omitting dc. Note the difference.

Now that we have the necessary formulas, let's analyze our full-scale sine wave signal. Plugging in a full-scale sine wave and analyzing over a full period we get:

As expected, the average value of the signal over a single period is 0.

Evaluating the intensity requires finding the antiderivative of (sin(t))². This can be ascertained most easily by plotting a few values and realizing that (sin(t))² = (1 - cos(2t))/2:

This is a dimensionless number that ranges from 0 (signal is a flat line) to 1 (... we'll get to that later.)

We can convert this into a dB FS measurement using the formula I_{dB FS} = 20 log₁₀ I_RMS:

Et voilà - that's where the -3 dB comes from.

In contrast to a sine wave, a full-scale square wave centered at 0 has an intensity of 0 dB FS:

To finish up, a couple of advanced exercises:

Advanced Exercise: prove that, provided t₁ and t₂ are sufficiently far apart, the intensity of a general sine wave x(t) = a sin(ωt + φ) + c depends only on a and not on ω, φ, or c.

Advanced Exercise: completely characterize the set of digital signals that achieve 0 dB FS intensity. If you have, say, 1000 samples of mono 16-bit integer audio to play with, how many distinct signals achieve 0 dB FS intensity?

Rotating a matrix redux

Maurits — Fri, 12 Sep 2008 19:39:00 GMT

Vincent Tan picked up on Raymond Chen's "rotate a matrix" interview post.

As Vincent Tan points out, there is no way to create an n x n matrix R such that RA is a rotated version of A - for example, in the 2 x 2 case:

There is no 2 x 2 matrix R such that

R [ a b ] = [ b a ]
  [ c d ]   [ c d ]

Vincent Tan points out that such an R would entail hidden assumptions but asks for a simpler proof.

Here it is. I'll go back to the n by n case, assuming n >= 2. (The 0 x 0 case and the 1 x 1 case are actually trivially solvable using the identity matrix.)

Assume there is such a matrix R = (r_ij)_{i,j∈{1...n}} which has the property that RA = B = (b_ij)_{i,j∈{1...n}}is the rotated version of A for any n x n matrix A = (a_ij)_{i,j∈{1...n}}.

To see that this is impossible, consider the matrix with a 1 in the upper-left-hand corner and zeros everywhere else; that is, a_1,1 = 1, and a_ij = 0 for all other combinations of i and j.

To be the rotated version of this matrix, B should have b_n₁ = 1 and b_ij = 0 for all other combinations of i and j. (My coordinates are such that b_n₁is the number in the top right corner of the matrix.)

But how did that 1 get in the top right hand corner? The rules of matrix multiplication imply that b_n₁ = r_1,1a_n₁ + r_2,1a_n₂ + ... + r_n1a_nn. At first blush, this looks fine... until we realize that b_n₁is 1, and all of the a_njare 0... so we have the contradiction

1 = r_1,10 + r_2,10 + ... + r_n10 = 0

QED.

But this is not how rotation matrices are applied. Rotation matrices R are not applied as RA = B; instead, they're applied as RAR^-1 = B. Not that this helps our hapless interviewee; the operation being asked of him ("rotate a matrix") can't be done by a rotation matrix anyway. That is, there is no magic matrix R that works under this operation either.

EDIT: A simple way to prove that RAR^-1 = B doesn't work either (for n >= 2) is to think about what happens when you choose A to be the identity matrix I (the matrix with 1's on the main diagonal [i = j] and 0's everywhere else.)

RIR^-1 = RR^-1 = I; and for n >= 2, I is not its own "rotation."

We therefore arrive at the paradoxical result that you can't rotate a matrix via matrix rotation.

The largest prime ever - you saw it here first

Maurits — Sat, 30 Aug 2008 01:34:00 GMT

The GIMPS project says they've found the largest prime number ever, but they're keeping quiet about what it is until they've verified it (they expect to be done in a couple of weeks.)

Pshaw. I can tell you right now what their prime number is.

Since I'm a computer scientist I'll write it down in binary.

GIMPS' LARGEST PRIME NUMBER IS (scroll down / highlight to view:)

0b
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
...
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111

EDIT: On Saturday 9/6 another prime was found. They're also keeping mum about what this one is. But I know this one too...

EDIT2: Every new Mersenne prime also means a new perfect number is discovered; counting these two new Mersenne primes, there are now 46 known perfect numbers, all of them even. (It is conjectured, but not proven, that all perfect numbers are even.) To go from a Mersenne prime (which is of the form 0b111...11, where there are a prime number of 1's) to its corresponding perfect number, tack on one fewer number of 0's onto the end of the number: e.g., 0b11 (3, the first Mersenne prime) becomes 0b110 (6, the first perfect number;) 0b111 (7, the second Mersenne prime) becomes 0b11100 (28, the second perfect number) etc. (The proof that such numbers are perfect is simple; there is a more complicated proof that all even perfect numbers are of this form.)

EDIT: I can now reveal that the number of 1s is 43,112,609.

Solution: x! + y! + z! = x * y * z

Maurits — Sat, 09 Aug 2008 02:08:00 GMT

Last time I discussed the fact that there is a single, unique, solution to the formula x ! + y ! + z ! = x * y * z, where x, y, and z are non-negative integers. I asked for a computer program to find the solution given that x, y, and z are all <= 9 but I wondered aloud whether the solution was unique without that constraint.

The part where a computer can't help is the uniqueness. Here is a mathematical proof that there are no solutions if any of x, y, or z are >= 6:

Assume without loss of generality that x >= y => z. The following two inequalities hold trivially, since we're dealing with non-negative numbers:

x ! + y ! + z ! > x !
x * y * z <= x ³

Here's where 6 comes in:

Lemma: for x >= 6, x ! > x ³ (proof momentarily.)

If this lemma were true, then we'd be done... for x >= 6,

x ! + y ! + z ! > x ! > x ³ >= x * y * z

So a search for solutions for x ! + y ! + z ! = x * y * z can be restricted to 5 >= x >= y >= z. This is computationally feasible.
By inspection, there is a unique solution (see later in this post.)

Proof of lemma: first, look at values of x ! and x ³ for x = 0 through 7:

0! = 1 > 0 = 0³
1! = 1 = 1 = 1³
2! = 2 < 8 = 2³
3! = 6 < 27 = 3³
4! = 24 < 64 = 4³
5! = 120 < 125 = 5³
6! = 720 > 216 = 6³
7! = 5040 > 343 = 7³

It's not immediately clear how to progress. The key idea, as often in geometric-ish progressions: look at successive ratios. The initial 0 messes things up a bit, so we'll start with x = 1.

On the left, numbers advance by a factor of:

(x + 1)! / x ! = x + 1

Note this ratio gets bigger and bigger.

On the right, numbers advance by a factor of

(x + 1)³/ x ³ = ((x + 1) / x)³ = (1 + (1 / x))³
Note this rate of increase actually gets smaller.

The crossover point - where x ! stops losing ground and begins to catch up - is x = 3;

1 + 1 = 2 < 8 = (1 + (1/1))³
2 + 1 = 3 < 3.375 = (1 + (1/2))³
3 + 1 = 4 > 2.370370... = (1 + (1/3))³

By x = 6, the lost ground has been made up, and x ! never looks back. QED.

By the proof above, it only remains to look at the finite number of cases where x, y, and z are all <= 5. Here they all are: note that in addition to the unique solution for the equality

x ! + y ! + z ! = x * y * z

there are only four solutions to the inequality

x ! + y ! + z ! < x * y * z

All of the other cases have

x ! + y ! + z ! > x * y * z.

0! + 0! + 0! = 3 > 0 = 0 * 0 * 0

1! + 0! + 0! = 3 > 0 = 1 * 0 * 0
1! + 1! + 0! = 3 > 0 = 1 * 1 * 0	1! + 1! + 1! = 3 > 1 = 1 * 1 * 1

2! + 0! + 0! = 4 > 0 = 2 * 0 * 0
2! + 1! + 0! = 4 > 0 = 2 * 1 * 0	2! + 1! + 1! = 4 > 2 = 2 * 1 * 1
2! + 2! + 0! = 5 > 0 = 2 * 2 * 0	2! + 2! + 1! = 5 > 4 = 2 * 2 * 1	2! + 2! + 2! = 6 < 8 = 2 * 2 * 2

3! + 0! + 0! = 8 > 0 = 3 * 0 * 0
3! + 1! + 0! = 8 > 0 = 3 * 1 * 0	3! + 1! + 1! = 8 > 3 = 3 * 1 * 1
3! + 2! + 0! = 9 > 0 = 3 * 2 * 0	3! + 2! + 1! = 9 > 6 = 3 * 2 * 1	3! + 2! + 2! = 10 < 12 = 3 * 2 * 2
3! + 3! + 0! = 13 > 0 = 3 * 3 * 0	3! + 3! + 1! = 13 > 9 = 3 * 3 * 1	3! + 3! + 2! = 14 < 18 = 3 * 3 * 2	3! + 3! + 3! = 18 < 27 = 3 * 3 * 3

4! + 0! + 0! = 26 > 0 = 4 * 0 * 0
4! + 1! + 0! = 26 > 0 = 4 * 1 * 0	4! + 1! + 1! = 26 > 4 = 4 * 1 * 1
4! + 2! + 0! = 27 > 0 = 4 * 2 * 0	4! + 2! + 1! = 27 > 8 = 4 * 2 * 1	4! + 2! + 2! = 28 > 16 = 4 * 2 * 2
4! + 3! + 0! = 31 > 0 = 4 * 3 * 0	4! + 3! + 1! = 31 > 12 = 4 * 3 * 1	4! + 3! + 2! = 32 > 24 = 4 * 3 * 2	4! + 3! + 3! = 36 = 36 = 4 * 3 * 3
4! + 4! + 0! = 49 > 0 = 4 * 4 * 0	4! + 4! + 1! = 49 > 16 = 4 * 4 * 1	4! + 4! + 2! = 50 > 32 = 4 * 4 * 2	4! + 4! + 3! = 54 > 48 = 4 * 4 * 3	4! + 4! + 4! = 72 > 64 = 4 * 4 * 4

5! + 0! + 0! = 122 > 0 = 5 * 0 * 0
5! + 1! + 0! = 122 > 0 = 5 * 1 * 0	5! + 1! + 1! = 122 > 5 = 5 * 1 * 1
5! + 2! + 0! = 123 > 0 = 5 * 2 * 0	5! + 2! + 1! = 123 > 10 = 5 * 2 * 1	5! + 2! + 2! = 124 > 20 = 5 * 2 * 2
5! + 3! + 0! = 127 > 0 = 5 * 3 * 0	5! + 3! + 1! = 127 > 15 = 5 * 3 * 1	5! + 3! + 2! = 128 > 30 = 5 * 3 * 2	5! + 3! + 3! = 132 > 45 = 5 * 3 * 3
5! + 4! + 0! = 145 > 0 = 5 * 4 * 0	5! + 4! + 1! = 145 > 20 = 5 * 4 * 1	5! + 4! + 2! = 146 > 40 = 5 * 4 * 2	5! + 4! + 3! = 150 > 60 = 5 * 4 * 3	5! + 4! + 4! = 168 > 80 = 5 * 4 * 4
5! + 5! + 0! = 241 > 0 = 5 * 5 * 0	5! + 5! + 1! = 241 > 25 = 5 * 5 * 1	5! + 5! + 2! = 242 > 50 = 5 * 5 * 2	5! + 5! + 3! = 246 > 75 = 5 * 5 * 3	5! + 5! + 4! = 264 > 100 = 5 * 5 * 4	5! + 5! + 5! = 360 > 125 = 5 * 5 * 5

Here's the program I used to check the cases for x, y, z <= 9. I used perl. Note the similarity to Zbyszek's solution.

use strict;

# initialize table of factorials with 0! = 1
my @fac_table = (1);

# loop executes 10 times
# interesting fact - solution remains unique even if you use higher bases
# (e.g., change 9 to 15 for hex)
for my $i (0 .. 9) {
    $fac_table[$i + 1] = ($i + 1) * $fac_table[$i];

    # loop executes 1 + 2 + ... + 9 + 10 = 55 times
    for my $j (0 .. $i) {

        # inner loop executes
        # 1 +
        # 1 + 2 +
        # ...
        # 1 + 2 + ... + 9 +
        # 1 + 2 + ... + 9 + 10 times
        # 
        # Here's how I counted that up:
        # if $i, $j, and $k are all different,
        # there are (10 choose 3) = 10 * 9 * 8 / 1 * 2 * 3 = 120 ways
        # if $i, $j, and $k are all the same,
        # there are 10 ways
        # if $i and $k are different, but $j is the same as one or the other,
        # there are (10 choose 2) ways to pick $i and $k = 10 * 9 / 1 * 2 = 45 ways
        # and two choices in each of these for $j so there are 90 ways
        # total = 120 + 10 + 90 = 220 iterations
        # (verified with a loop counter)
        for my $k (0 .. $j) {
            # note $i >= $j >= $k

            if ($fac_table[$i] + $fac_table[$j] + $fac_table[$k] == $i * $j * $k) {
                print qq($i! + $j! + $k! == $i * $j * $k\n);
            }
        }
    }
}

A cute little exercise.

Interview question: find solution to x! + y! + z! = x * y * z

Maurits — Fri, 08 Aug 2008 01:54:00 GMT

I stumbled on hmlee's algorithm chart quite by chance. A lot of good questions in there.

Question 53 caught my eye as a mathematician.

Q53: Say you have three integers between 0 - 9. You have the equation: A! + B! + C! = ABC (where ABS is a three digit numbers, not A * B * C). Find A, B, and C that satisfies this equation.

Interesting. But I'd like to modify the question a little.

Q53': Say you have three integers between 0 - 9. You have the equation: A! + B! + C! = A * B * C.
Find A, B, and C that satisfies this equation.

Astute readers will notice that A, B, and C are interchangeable. Nonetheless there is a unique solution (modulo swapping A, B, and C.)

I'm much less interested in the answer to this question (I know the answer) than I am in the quality of the program used to find the answer. (I tried finding the answer by hunt-and-peck, then gave up and wrote a program - I find the program to be more interesting than the answer.) Try to find the solution as efficiently as possible (without cheating.)

I'll post my program later.

If you see a fact, try to see it as intuitively as possible.

I suspect that the following even more general problem has the same unique solution, which would be very interesting indeed. This is the kind of thing where programs fail, and the mathematical mind becomes necessary again:

Q53'': Say you have three integers that are >= 0. You have the equation: A! + B! + C! = A * B * C.
Find A, B, and C that satisfies this equation.

Triangular primes: or, the dangers of non-rigorous proofs

Maurits — Sun, 15 Jun 2008 20:41:00 GMT

Beware of bugs in the above code; I have only proved it correct, not tried it.

-- Donald Knuth

If you've bowled, you know the arrangement of the bowling pins forms a triangle.

(Image courtesy of the International Pumpkin Federation.)

If you've played eight-ball, you know the arrangement of the fifteen billiard balls forms a triangle.

Ten, fifteen... what other numbers form a triangle? The common arrangement of nine-ball and ninepins doesn't count because it's a diamond, not a triangle.

You can start with ten and add five balls to make a triangle of fifteen... then add six more to make a triangle of 21... then seven more to make a triangle of 28... and so on, with this sequence:

..., 10, 15, 21, 28, 36, 45, 55, 66, 78, 91, 105, 120, 136, 153, 171, 190, 210, 231...

Start looking for patterns. What do you see? Nothing jumps out right away. Are there any primes? Ones that end in 0, 2, 4, 6, or 8 are obviously even and therefore not primes... ones that end in 5 are divisible by 5 and therefore not primes... the remaining ones fall due to specific cases (21 = 3 x 7; 91 = 7 x 13; 153 = 3 x 3 x 17; 171 = 3 x 3 x 19; 231 = 3 x 7 x 11...)

In fact, gosh darn it, it seems like none of these numbers are prime, no matter how far we extend that "..." on the right! Can this be a coincidence?

A few mental coruscations later I have an idea that it is not a coincidence... that triangular numbers, by there very nature, cannot be prime. In fact I'm even willing to call it a "proof." Here it is.

"Theorem": there are no triangular primes.

First we need to generate a formula for the triangular numbers. Note that if you take an n x (n + 1) rectangle and draw a zig-zag line like so, you get two triangles.

Each of these triangles is composed of n diagonals, the shortest of which is 1, and the longest of which is n. That is to say, each of the triangles is composed of t_n squares. So we know that the total number of squares in the rectangle is 2t_n.

But we also know that the total number of squares is the base times the height, or n(n + 1). This gives us 2t_n = n(n + 1), or t_n = n(n + 1)/2.

The next part of the "proof" breaks down into case analysis. n can be odd (as in the diagram, where n is 5) or even.

Case where n is even:

n is an even positive number. Therefore n/2 is a positive number (maybe odd, maybe even; doesn't matter.) t_n can be written as (n/2)(n + 1), and is therefore not prime, since it has at least four factors: 1, n/2, n + 1, and t_n.

Case where n is odd:

n is an odd positive number. Therefore n + 1 is an even positive number. Therefore (n + 1)/2 is a positive number (maybe odd, maybe even; doesn't matter.) t_n can be written as (n)([n + 1]/2), and is therefore not prime, since it has at least four factors: 1, n, (n + 1)/2, and t_n.

Note that the "proof" that t_n is not prime inevitably concludes in a stronger result - that t_n has at least four factors... not only is t_n not prime, it can't even have as few as three factors. (Some numbers with three factors: 4, 9, 25, 49...)

Exercise: what kind of numbers have exactly three factors?

A beautiful proof. Perhaps the two cases can be elegantly folded together to normalize it a bit better. That is not a serious problem.

There is a serious problem.

The proof of our result is doomed.

Why?

Because the result does not hold! There is a triangular prime.

Exercise: find a triangular prime.

After having recovered from the shocking revelation that, our beautiful proof to the contrary, a triangular prime is so rude as to exist, a little self-examination is in order. What is wrong with the proof? This... and not the existence of triangular primes... is the lesson to be learned: that beauty is not always truth.

The great tragedy of Science -- the slaying of a beautiful hypothesis by an ugly fact.

-- Thomas Huxley

Unsolving the Rubik's Cube

Maurits — Sat, 17 May 2008 01:49:00 GMT

Recently I was musing on Order vs. Chaos and toying with my Rubik's Cube. I wondered, as a simple exercise, whether it would be possible to strongly unsolve the cube. Obviously there is a single way to put the cube into a state of greatest possible order... and a multitude of ways to put it into a state of moderate to severe chaos... but is there a "most chaotic" state?

Well, I mused, the "greatest possible order" state is achieved by bringing all the orange squares together... and all the blue squares together... and, in general, all the squares of any given color together. How homogenous... or xenophobic. Ew.

Might it not be interesting to intermingle the colors to as great an extent as possible? Can I put the cube in a state where no two orange squares are adjacent... and no two blue squares are adjacent... and, in general, no two adjacent squares are the same color?

Of course, I responded. In fact, I already know how to do that... I learned that trick before I even learned the Restore Order solution.

Twelve turns later, I had a solution to the Adjacent Squares Are Different problem.

Exercise: what are the twelve turns?

Well, that was quick.

But I wanted more.

Yeah, OK, no two adjacent squares are the same color, by the usual definition of adjacency (the squares share a common border.) But this is still a fairly homogenous solution... each face (of nine squares) still consists of only two colors, and there's a very high incidence of diagonally-touching squares of the same color. Can't we diversify this even more?

That took me a couple of days. But here's the solution I came up with:

Note that, as desired, no two adjacent squares are the same color... even if you consider squares that touch only at a corner to be adjacent... even if that corner lies on an edge, and the two squares in question lie on different faces of the cube.

The method to achieving the solution was simple in the sense that it only requires two moves (starting from a solved cube) but is probably far from optimal in the "total number of turns" sense.

There are two independent steps which can be done in either order:

Flip the orientation of all twelve of the "edge pieces" (the cubelets with two visible faces)
Migrate all eight "corner pieces" (the cubelets with three visible faces) to the diametrically opposite position on the cube

Each requires knowledge of a single move and a fair amount of courage.

First, some syntax.

Hold the cube facing you. I will name the six faces of the cube:

Fore (the face closest to you - in the picture above, the face with the green center)
Hind (in the picture above, the face with the blue center)
Top (in the picture above, the face with the white center)
Bottom (in the picture above, the face with the yellow center)
Left (in the picture above, the face with the orange center)
Right (in the picture above, the face with the red center)

Each face has a local definition of "clockwise"... this is the direction a clock painted on the face would turn.

Cubelet syntax

A combination of two letters (FR) means the edge cubelet common to both faces - in this case the Fore and Right faces. In the picture above, this is the green and white cubelet.
A combination of three letters (BHL) means the corner cubelet common to all three faces - in this case the Bottom, Hind, and Left faces. In the picture above, this is the red-green-and-white cubelet.

Move syntax: a letter means turn that face clockwise by 90 degrees. A letter with a subscripted -1 means turn it counterclockwise by 90 degrees. So a move "turn the Fore face clockwise, then turn the Left face counterclockwise, then turn the Top face counterclockwise" would be written:

F L^-1 T^-1

Start from a solved cube.

Flip the orientation of all twelve of the "edge pieces"

Pick your favorite color - say, red - and have that be the top face.

The following move flips the orientation of the LT and TH edge pieces, and also disturbs the orientation of some corner pieces:

L^-1 T^-1 L^-1 L^-1
F^-1 L^-1 F^-1 F^-1
T^-1 F^-1 T^-1 T^-1

Run the move once with red as the top face.
Position the cube so that red is still as the top face but the two remaining unflipped edge pieces with red on them are now in the LT and TH position. That is, turn the whole cube 180 degrees with an axis of rotation that goes through the center of the top and bottom faces.
Run the move again. All four edge cubelets with red on them should now be flipped.
Position the cube so that red is now the front face.
Run the move again four more times, keeping red as the front face but rotating the cube 90 degrees each time, so each execution of the move acts on two unflipped edge pieces.

All twelve of the edge pieces are now flipped. The corner pieces are still in their original positions, though they may be oriented incorrectly. That's OK.

Reposition all eight corner pieces to the opposite corner

The following move repositions FLT to TLH, TLH to TRH, and TRH to FLT:

L^-1 T R T^-1
L T R^-1 T^-1

As a convenience, the following mirror-image move repositions FRT to TRH, TRH to TLH, and TLH to FRT:

R T^-1 L^-1 T
R^-1 T^-1 L T

Strictly speaking, you can get away with only memorizing one of these moves - each move is equivalent to holding the cube in a different position and executing the other move twice.

Pick three faces that share a common corner - say, the faces whose center cubes are red, white, and blue. Position the cube so it is balancing on that corner. Note that the corner cubelets now occupy four distinct strata:

The "top" corner.
The three corners that share a common edge with the "top" corner.
The three corners that share a common edge with the "bottom" corner.
The "bottom" corner.

This part of unsolving the cube is completed in four distinct phases:

Unsolve the "top" corner - that is, find the red/white/blue cubelet (it's on the bottom corner) and move it to the top. This will require two moves, which will to a certain degree randomize the positions of all of the rest of the corners.
Unsolve the three corners that share a common edge with the "top" corner, without disturbing the cubelet in the "top" corner, or any already-unsolved cubelets in this stratum.
Unsolve one of the three corners that share a common edge with the "bottom" corner, without disturbing any of the cubelets in the two strata above.
Finally, there are three remaining un-unsolved cubelets. Unsolve all three of these simultaneously - this will take precisely one execution of one of the two moves above.

Generating a sine wave with phase - answers

Maurits — Mon, 31 Mar 2008 23:56:00 GMT

In a previous post I posed several mathematical problems... I'd like to go back and give some answers to them.

To reiterate, we take a sine wave period and wrap it around a cylinder, giving us this:

The problems are to:

Prove that the curve is planar.
Prove that the curve is an ellipse.
Make a Keplerian observation. Johannes Kepler was a mathematician/astronomer who made several observations relating to planetary orbits.

Let's define the curve. Since we're going to be making analogies to planetary orbit, let's define the curve parametrically. The parametric point is the analog of a planet.

Peter piper picked a peck of pickled peppers. -- Mother Goose

Penny Pingleton, you know you are punished. From now on you're wearing a giant P on your blouse EVERY DAY to school so that the whole world knows that Penny Pingleton is permanently, positively, punished.
-- Prudence Pingleton, Hairspray

OK, now that we have that out of the way... I want the parametric point to sweep its way around the unit cylinder with constant angular velocity, as viewed from above. So if we project the path of the point into the unit cylinder with z = 0, then r(t) = 1 for all t and θ(t) is linear in t. In fact let's have θ(t) be t, so at time t = 2π our parametric point has made a complete cycle.

Now we'll add the z component in. The curve is a wrapping of sin(t), so z = sin(t); we aren't affecting the vertical component of the paper by wrapping it horizontally around a cylinder.

We're actually, in a sense, done. We have the formalized equations:

r(t) = 1
θ(t) = t
z(t) = sin(t)

But let's convert to Cartesian coordinates, since we'll be dealing with planes. The relevant formulae are:

x² + y² = r²
tan(θ) = y/x

A little intuition, checked by back-substitution, gives us these for x and y:

x(t) = cos(t)
y(t) = sin(t)

Putting these together with our formula for z, we have:

x(t) = cos(t)
y(t) = sin(t)
z(t) = sin(t)

Note that, no matter what t is, y(t) = z(t)... that is, the parametric point travels entirely in the plane given by the equation y = z. This proves that the parametric path is planar. QED #1.

To tackle #2 we have to prove that this planar curve is, in fact, an ellipse. One way to do that would be to come up with x' and y' coordinates in the plane of the curve, transform the parametric equations into the new coordinate system, and verify that a(x')² + b(y')² = c² for some a, b, and c... but when I came up with the problem I had a much simpler proof in mind. There's also a third way of doing this, where you note that the curve is the result of an affine transformation of the unit circle... and an affine transformation of a circle is demonstratably an ellipse... but I hadn't thought of that.

Another astronomer/mathematician, Appollonius of Perga, made a study of "conic sections"... that is, the intersection of a plane with a double-headed cone. He came up with an exhaustive list of the kinds of curves that resulted.

Basic conic sections:

An ellipse, if the angle that the plane makes is shallower than the edge of the cone;
A hyperbola, if the angle that the plane makes is steeper than the edge of the cone;
And a parabola, if the plane is parallel to the edge of the cone.

For complicated reasons (to wit, that gravity diminishes as the square of the distance between two objects,) all heavenly bodies trace either an ellipse or a hyperbola as they go around (or past) another heavenly body.
Parabolae are theoretically possible but would smack heavily of "design"; as yet none have been observed.

For completeness, there are other "designed" ways to intersect a double-headed cone with a plane in a coincidental fashion:

Degenerate conic sections:

A circle - early astronomers were convinced that the heavenly bodies moved only in circles. It took a long time for us to believe our measurements (which showed uncircular orbits) and acknowledge that the orbits are in fact elliptical. Instead, great efforts were made to show that the deviation could be made up of other, smaller, circular sub-orbits. Eventually we admitted that the orbits were elliptical (ellipses are more complicated than circles, but much simpler than the proposed circles-within-circles) and not until Newton did we understand why planets move in ellipses.
A straight line - this is a degenerate hyperbola. This is one solution to the "one body" problem.
Two intersecting straight lines - a hyperbola, as seen from infinitely far off.
A single point - the other solution to the "one body" problem.

Since our curve is the intersection of a plane and a cylinder, we're done! ~~QED #2~~. Well, not quite.

Appolonius' results hold for cones. We have a cylinder. Those aren't quite the same thing. Right?

They aren't, quite... but a cylinder can be viewed as a degenerate form of cone. To wit, a cylinder is a cone whose apex is infinitely far off. I'll get back to a "proof" of this in a minute, but if you allow this, then we really are done.

Instead of the seven intersections of a double-headed cone and a plane, there are only four ways a cylinder and a plane can intersect. Two of these are new.

Cylindrical conics:

An ellipse - though it remains to be proven that this really is an ellipse. A circle is a special form of this... I won't show it again.
A straight line - the single body problem again.
Two straight lines - parallel this time. This is something new.
No intersection at all. The kōan of conics. This is new, but whether it is something is a question I will not attempt to address.

Now for the proof that cylindrical intersection #1 really is an ellipse. Place two double-headed cones coaxially with the cylinder. Arrange them so that:

The apexes of both cones are in the "up" direction, from anywhere on the curve in question.
The "top" cone intersects the highest point on the curve in question.
The "bottom" cone intersects the lowest point on the curve in question.

Diagram:

Notice that the entire curve lies in between the two cones. Consider the intersection of the plane that determines the curve with each of the cones. We know both of these are ellipses; we know that the intersection of the plane with the "upper" cone lies wholly outside our unknown curve; and we know that the intersection of the plane with the "inner" cone lies wholly inside our unknown curve.

Diagram:

The final stage of the proof lies in pushing the apexes of both cones to infinity, which "squeezes" our unknown curve in between two known ellipses. Since the horizontal distance between the cones goes to zero as 2^3/2 / tan(θ), our unknown curve cannot help but be elliptical-ish... to any degree of precision... and it is, thus, an ellipse. QED #2.

For the final problem, we must make a "Keplerian observation." The observation in question is that our parametric point, like the planets, sweeps out equal areas in equal times. What makes this interesting is that the parametric point does not move in the same way that a planet does... so it's a little odd that such a similar result should hold... but it does.

Let's talk a little about Kepler's second law. A planet moves around the sun in an elliptical orbit. Fine. The sun lies at one of the foci of the ellipse. An imaginary line between the planet and the sun will sweep out area at a constant rate. That is to say, when the planet is far from the sun, that line will be long... and it will move correspondingly slowly. When the planet is near to the sun, that line will be short... and it will move correspondingly quickly.

Conversely, our parametric point sweeps around the origin at constant angular velocity. So this is trivially "equal areas in equal times". Right?

Not quite. It's true that our parametric point appears to have constant angular velocity, if you project its path into the x-y plane... that is, if you view it from directly above, from a point on the z-axis.

But that's a silly way to look at things. To get an idea of the point's actual motion, it's far more natural to view it from an axis orthogonal to the plane of motion. So let's put an observer (Aranea) directly above the point, and another observer (Nellie) in the more natural location.

From Aranea's point of view, the motion is a simple constant-speed trip around a circle. But Nellie sees the parametric point's true velocity. The parametric point's velocity has two components... a constant "clockwise" component in the x-y plane, and a variable orthogonal component going "up" or "down". This is maximized when the curve crosses the x-y plane, and minimized when the curve is topping or bottoming out. So Nellie sees this:

It seems hard to believe, given that the parametric point is speeding up and slowing down according to different rules... and the notion of "center" is different... but the fact is, the parametric point also sweeps out equal areas in equal times!

To see this most easily, look at Aranea's point of view again. Have Aranea draw a grid on her picture of the system. She can count the area swept out in any given time by counting the number of squares.

Now consider what those squares look like to Nellie. They're rectangles. But they're all of equal area. Aranea and Nellie can label the squares according to some naming scheme, and will agree that the same set of squares/rectangles were swept out... but this means, since the rectangles are of equal area, that even in Nellie's point of view, equal areas are swept out in equal times! QED #3.

How it works: xkcd sucks at math

Maurits — Thu, 28 Feb 2008 20:55:00 GMT

I'm a casual reader of Randall Munroe's xkcd web comic. I'm partial especially to the artistic episodes.

I was reading the "How it Works" episode, reproduced here:

Fine, a noble sentiment (women in the hard sciences are unfairly targeted) and well executed.

As is my wont, I then went for the extra bit of juiciness to the episode by hovering over the image, and what do I find?

It's pi plus C, of course.

... OK, fine. A good reference to an in-joke in the mathematical community. Well done.

... except I can't stomach the idea of "π plus a constant." It just doesn't sit right. And there's something wrong about the equation on the board. It's missing something... else.

The equation as it appears on the board:

... and the suggested improvement:

Yeah. I still don't buy it.

Under the premise that the best way to spoil a good joke is to analyze it, let's see if we can figure out what our characters are trying to do with this integral, shall we?

Well, there are integrals and integrals. There are at least three common uses of integrals:

Find the antiderivative of a given function for later use.
Evaluate the antiderivative at upper and lower limits and subtract to find the area under the curve.
Do a contour integration to evaluate a function over a known region.

The "plus a constant" comment applies exclusively to the first use. The function y = x² is analytic everywhere and so is not likely to be interesting for a contour integral. But the second use seems to be very appropriate to this "integral equals a constant" equation:

The first thing to do is find the antiderivative. This can occasionally be very difficult, but in this case we have a textbook function which is the first recipe anyone memorizes:

The above formula holds for all p except for p = -1. That one's a little tricky because the denominator above would be 0. For completeness, here's the case with p = -1:

A little faith is required if you haven't seen the derivation, but it works out. (This is as good a definition as any of ln x, FWIW.)

Indeed, the antiderivative is a whole family of functions which differ only by a constant. But if we're going to evaluate it at certain limits, we need to (eventually) know what the limits are. Let's call them a and b for now:

(Note in particular that the evaluation doesn't depend on which of the family of functions we chose... C cancels out. This is my problem with the comment.)

Setting p = 2 we still have a single equation in two unknowns (a and b). Still need more information.

Well, let's think about it for a minute. Many functions have "natural" points of evaluation. For x² this is 0. For 1/x it's 1. What if we set a = 0? The natural-ness of 0 as a base point of evaluation is made clear from a graph of y = x²:

If we set p = 2 and a = 0, then the equation above reduces to the solvable problem:

The solution is now trivial:

So we can complete the original blackboard equation as follows:

or in fuller generality as

for any a.

(I'm sticking with the a = 0 solution, myself.)

Generating a sine wave with phase

Maurits — Fri, 18 Jan 2008 22:18:00 GMT

I alluded to a bug in my last post but didn't explicitly say what it was. Hint: it's all about phase.

So let's talk about phase for a minute. Sine waves are periodic... although they are frequently plotted over very large intervals, their natural domain is a single period.

(original)

Exercise - The original version, when printed, makes a nice armband.

Advanced Exercise - generate a one-and-a-half period sine wave, print it on both sides of a piece of paper, and make a Möbius strip.

Well, that's a step, but it's not really getting at the nature of the sine wave. Yes, we notice that the beginning value (0) is the same as the ending value... and the beginning slope (+1) is the same as the ending slope... and there is, perhaps, a certain smoothness beyond even slope (in fact, all derivatives agree at the crossover point...)

If you see a fact, try to see it as intuitively as possible.

Do the first exercise above - print out the original image, cut it out along the lines, and make a cylinder by connecting the short ends together. Rotate the cylinder through various orientations, paying particular attention to the location of the sine wave at all times.

What you get is hard to render in a two-dimensional blog post, but here's a stab at it (Matlab script below:)

(original)

Notice that this representation of the sine wave is an ellipse.

Exercise - Prove that the red line in the above graph is planar (Hint: you can type the equation of the plane in three keystrokes.)

Advanced Exercise - Prove that it's an ellipse.

Advanced Exercise - Make a Keplerian observation. (Hint: note the angles at which the red line crosses the dotted black lines.)

So what does this have to do with phase?

Everything.

There's another hint in the documentation of double sin(double), which I also linked in my last post:

sin returns the sine of x [phase]. If x [phase] is greater than or equal to 263, or less than or equal to –263, a loss of significance in the result occurs. (my emphasis)

A final hint: again from my last post, "as a side effect, we get a kinda-sorta implementation of ϕ [phase]."

When you find yourself with a kinda-sorta implementation of something, that is occasionally a hint from above that your life will be easier if you do some self-examination... perhaps a full-blown implementation of that thing will be (a) easier and (b) more what you actually want.

No more hints. If you want to figure it out for yourself, stop reading now.

OK, here's the scoop. The thing you feed to sin(...) is a radian measurement. This is naturally between 0 and 2π (or, perhaps, -π to π if you prefer.) You can feed it things that are out of this range... say, sin(100.0)... but this is a little out of the natural and there are consequences.

double-type numbers, and floating point numbers in general, can represent very small numbers to a very high degree of precision... and they can represent very large numbers with the same relative degree of precision. See IEEE754 for gory details.

An illustration is in order. Richard Feynman, celebrity physicist, tells a story of his youth. He claimed to be able to solve, in one minute, to within 10% accuracy, any problem that can be stated in ten seconds.

He did pretty well until someone came up with "tan(10¹⁰⁰)".

If you feed bigger and bigger numbers to sin(...), eventually it starts giving you sloppy answers. It has to. It's not getting enough information to give you a good answer.

I was able to test the tone generation function and measure the signal-to-noise ratio of the tones it was producing after varying lengths of sample time. It started off very well, but after very long times (days, weeks, years) the SNR would get slowly compromised until, after millions of years, the signal disappeared.

That is not the bug.

But it is a serious clue to the bug.

If the worst-case scenario for an implementation is that the signal will depreciate over a million years, ship it.

Take your cylinder that you made above. Place it in front of you so that the taped-together part is directly in front of your nose, and the part to the right has the red line going up. This is a sine wave.

Rotate it clockwise 90 degrees, so the part in front of your nose has the red line brushing the top. Now it is a cosine wave.

Rotate it counter-clockwise 60 degrees, so the part in front of your nose has the red line crossing the dotted line. Now it is a sine wave with a known phase (30 degrees.)

In fact, rotate it any angle (say, ϕ) and it's a sine wave with known phase ϕ.

We can't do that with our tone generator.

That is the bug. We're implementing a tweaked version of phase which has a forgivable side effect, but which is not a full implementation of phase.

Why do we care about implementing phase?

Well, for example, one problem I sometimes have when testing audio fidelity is I connect the stereo cables to the Audio Precision equipment the wrong way (left-to-right and right-to-left.) If I could generate the test tones out of phase by 90 degrees, with the left channel in front of the right channel, I could take a phase measurement and log a "you have the cables backwards" error. I send different frequencies over the cables, so the ifFrameOffset parameter is of little use here.

So what's the improved implementation?

Instead of

// given a buffer, fills it with sine wave data
HRESULT FillBufferWithSine(
    LPCWAVEFORMATEX pWfx, // includes sample rate
    double lfAmplitude,
    double lfFrequency,
    UINT64 ifFrameOffset,
    PBYTE pBuffer,
    UINT32 cbBytes
);

// given a buffer, fills it with sine wave data
HRESULT 
FillBufferWithSine(
    LPCWAVEFORMATEX pWfx, // includes sample rate
    double lfAmplitude,
    double lfFrequency,

    // in/out
    //     On input, initial phase (0 to 2pi).
    //     On output, phase of next sample.

    double *plfPhase,

    PBYTE pBuffer, // out - byte count is cbBytes
    UINT32 cbBytes
);

Now, if you want to generate a lot of contiguous sine tone buffers, you do something like this:

double lfPhase = 0.0; // start at 0... or somewhere else
while (...) {
    // ... 
    // FillBufferWithSine takes care of updating lfPhase as necessary 
    hr = FillBufferWithSine(pWfx, lfAmp, lfFreq, &lfPhase, pBuffer, cbBytes);
    // ... 
}

As a side effect of this new phase feature, the quality degradation non-issue goes away. So the generated tones will sound good forever... which is kind of neat... but not the motivation for this fix.

Why did this happen?

Because there are many ways to measure time. You can count samples... you can count milliseconds... you can count hundred-nanosecond intervals... you can count CPU flops... you can do so many different things. Some are more natural than others in different contexts.

The reason this happened is because a time measure that was very natural in one context (counting frames: playing an audio stream) was somewhat artificially shoved into another context (generating a sine wave) where there was another, more natural context (changing phase.) Alas, context switching is a frequent source of bugs.

Matlab script to generate the three-dimensional rendering of a sine wave:

t = 0:pi/50:2*pi;
h = -1:0.5:1;
z = ones(size(t))' * h;

sinx = cos(t);
siny = sin(t);
sinz = sin(t);

plot3( ...
    sinx, siny, z, 'k:', ...
    sinx, siny, sinz, 'r' ...
);