Acadia National Park is now one of my favorite national parks! Even though it's not a massive park by land area, there are lots of places to explore. In my first trip there last week, we had to fit a lot into 2 days (with 2 days of driving! which was probably a mistake).

7 people

60° weather

$500/person

4 days

3 nights

2 cars

1 trip

This trip was also during the beginning of the current government shutdown, but most trails were open and we were careful and respectful of the park rules. (Don't do this or that!) The only "trail" that was closed for our itinerary was the Cadillac Summit drive.

Acadia Mountain was the closest hike to our AirBnb, and was hopefully a moderate level hike to see if everyone in the group would be up for some of the more difficult ones.

Just the other day, a friend mentioned a simple but interesting problem. (I initially wasn't given the Reddit post^[1], as that would be cheating. I wanted to see where this would lead me, and not replicate the analyses of others.)

At the beginning of the game, you're given 20 empty slots. One by one, a random number $x\in [1,1000]$ is uniformly generated (assuming without replacement, since that makes more sense for a game), and you must place the given number in one of your 20 slots. The catch is that the numbers in your slots must be in increasing order!

Here's a version of the game to play around with:

The beginning of the game is generally easy, but it gets hard to complete the game as it gets more likely that a number that falls between two adjacent slotted numbers is generated.

So the first basic question:

How often, on average, can you win the game (fill all 20 slots)?

(For the Bayesian, how likely are you to win the game?)

I'm going to try and keep my notation consistent.

• You are given $m$ slots to fill from a pool of $n$ numbers where $r$ numbers are generated. In the version of the game described above, $m=r=20$ (you generate as many numbers as you have slots) and $n=1000$.
• $Pr(\cdot )$ refers to the probability of some event, but $P(\cdot )$ will refer to specifically the probability of winning the game.

There are a few interesting questions that we could ask, beyond the prime question above:

1. What are the odds that you win the game, assuming you can play the perfect strategy?
2. What is the perfect strategy? Could a human reasonably use it without the use of a computer?
3. Does the strategy that leads to the most wins also tend to get the farthest in the game?

When many of us were kids, there were perhaps many things we wanted. From as material as a new toy to basic needs like food or affection. We grasp the things we have tightly (sharing is universally such an important lesson for children) and reach out for more around us (like a monkey grasping onto nuts in a pot). It's a stage characterized by exploration, but maybe also by entitlement and selfishness.

At some point, we begin to work to gain things. We take things we have (work ethic, money, education, skills, time, physical ability, resources, connections, health, etc.) and exchange them for things we need or want. Depending on what is being gained and the person, this happens earlier or later for different people. A necessary step in understanding the value of things. With the awareness of value and cost, we tend to hold on more tightly to our things, to our beliefs.

In the third "post-sacrifice" stage, sacrifice is an already accepted habit. When the time comes to sacrifice, it's not a personal loss if we start from the premise that it's not ours to begin with. Anything sacrificed is simply something not gained, and anything not sacrificed is a welcome prize. We acknowledge the effort that we and others put into things. Letting go enables us to pursue greater and more meaningful things. Yet we must not forget the lessons of fulfilling our needs and valuing what we have.

Getting from pre-sacrifice to sacrifice stage takes work. It's a grueling and not altogether pleasant experience.

Getting from sacrifice to post-sacrifice is not usually something that can be forced. It takes life experience in various domains. There may be things we can do or practice to make the transition more likely, but mindset changes can't just happen overnight nor by force of will.

Moving from one stage to the next may not occur together. We might be willing to sacrifice in one area, but entirely stubborn in our ways in another.

Forward movement may not be permanent. The earlier stages are much more deeply ingrained habits, which we often slip back into in moments of stress, distress, or excitement.

During my transition to O'ahu, my work will be paying for my meals and lodging up to a certain amount, so I decided to try and splurge a few nights (after this experience, I've found I don't have the stomach for food this rich every day), particularly on meals. There's a really fancy steak and seafood restaurant on the top floor of my hotel, so I popped up to try it out.

I recently got the opportunity to move to Hawaii, to the island of O'ahu for work, just for a year. It's been a long time since I've "blogged," either here or on other websites that shall not be named. Quite a few people asked if I would give updates on my life in the islands, so instead of shoving pictures down their throat every day/week (which is what I'm doing with my family), I thought I'd restart this blog with Hawaii updates!

So, here's my first 100 hours on the island.

(I have basically no pictures from then. Either it was just endless ocean, or I was taking a video for one of my seatmates.)

A while ago, John Cook made a post about Gaussian integer walks. See his post for the details, but at the end, he provides some Python code which he uses to generate the walks/plots. However, just for the simulation starting at $127+130i$, it took several minutes for the whole process, including plotting, which just seemed completely unreasonable to me as a Julia user. So of course, I wanted to see if I could reimplement that code in Julia to be much faster and yet not sacrifice ease of readability.

The basic premise is this: start at some point in the complex plane (with integer coefficients), facing east. Move unit-by-unit until the number is a Gaussian prime; if Gaussian prime, turn left.

The first thing we need is a function to determine if a complex number is a Gaussian prime (Julia uses im for the imaginary unit):

function isgaussprime(z::Complex{<:Integer})
    a, b = real(z), imag(z)
    if a * b != 0
        return isprime(a^2 + b^2)
    else
        c = abs(a+b)
        return isprime(c) && c % 4 == 3
    end
end

To do the Gaussian walk, we are going to write the function walk that starts at some point and keeps walking up to some limit (these walks all end up spirally, so we need some limit):

function walk(start, limit = 10)
    points = [start]
    z = start
    delta = 1
    
    while limit > 0
        z = z + delta
        push!(points, z)
        
        isgaussprime(z) && (delta *= im)
        z == start && break
        limit -= 1
    end
    
    points
end

To support the interactivity, I also have some other related functions, see the attached notebook.

(To be fair, the code above doesn't quite do the same thing as the original code in a couple of ways, but it should still be straightforward to understand. There is also a huge speed improvement, to the point that this can be done interactively.)

The cool part is what happens when we plot the walk for various complex numbers. To verify the implementation against the original code, we'll use the same examples. First, for $3+5i$,

function walklimit(start)
    limit = 1
    z = start
    delta = 1
    
    while true
        z = z + delta
        
        isgaussprime(z) && (delta *= im)
        z == start && break
        limit += 1
    end
    
    limit + 1
end

function walkbounds(start)
    min_real, max_real, min_imag, max_imag = real(start), real(start), imag(start), imag(start)
    z = start
    delta = 1
    
    while true
        z = z + delta
        
        min_real = min(min_real, real(z))
        max_real = max(max_real, real(z))
        min_imag = min(min_imag, imag(z))
        max_imag = max(max_imag, imag(z))
        
        isgaussprime(z) && (delta *= im)
        z == start && break
    end
    
    (min_real, max_real), (min_imag, max_imag)
end

A student in a class I TA for at UMD decided to make a variant of a BOGO sort that has selection sort-like properties. On Piazza, they asked what the runtime would be, guessing a median runtime of $O(n^{2}n!)$.

Here’s the code in Java (pretty much verbatim):

public static ArrayList<Integer> bogoSelectionSort(ArrayList<Integer> list) {
    ArrayList<Integer> ans = new ArrayList<>();
    int size = list.size();

    for (int i = 0; i < size(); i++) {
        int min = list.get(0);

        for (int j = 0; j < list.size(); j++)
            for (list.get(j) < min)
                min = list.get(j);

        if (min == list.get(0)) {
            ans.add(min);
            list.remove(0);
        } else {
            Collections.shuffle(list);
            i--;
        }
    }
    return ans;
}

Well, obviously, the best case happens when we very, very luckily always get the minimum to be the first element (or the input is already sorted). Approximately,

• the outer for loop runs proportional to $n=\mathtt{list}\mathtt{.}\mathtt{size}\mathtt{(}\mathtt{)}$,
• the inner loop will run in time proportional to $n$,
• list.remove(0) will run in time proportional to $n$, and
• Collections.shuffle(list) will run in time proportional to $n$. Overall, best case is $O(n^2)$.

It could run forever. $O(\mathrm{\infty })$. (This is just as useful as the best-case analysis above.)

To model the outer for-loop, we can describe it as a linear number of operations of the body. Even though we might repeat a step, we can model that as part of what's happening inside the loop. So we can model the complexity as

For the average-case, we care the expectation of the exact formula.

First, we'll find a closed form for the inner function, given a particular iteration index i, and then find its expectation.

Note that so long as we continue to fail to get the minimum of the list in the right position, we do the same amount of work since the size of the list doesn't change. Once we succeed, the size of the list changes (and thus the amount of work done). At a high level,

So how much work is done for each failure (for a fixed i)? Regardless of success or failure, we look for the minimum of the remaining elements of the list, which takes time about $n-i$. On fail, the list is shuffled in time $n-i$. On success, the minimum is added to the result ArrayList and removed from the front of the list taking time $n-1$. In both cases, we do $\approx 2(n-i)$ work.

Now, finding the expectation of our function,

For a given iteration (at index i), how many failures do we expect before the first success? This is a classic application of a geometric distribution. We'll use the following definition:

where $p$ is the probability of success.

At iteration i, there are $n-i$ elements in the list, so we have a ${\displaystyle \frac{1}{n-i}}$ probability of getting the minimum in the first position (given a proper, uniformly random shuffle and the list contains distinct elements). Now, we can calculate the expectation of $k$.

giving us an average of $n-i-1$ failures. Substituting into the full expectation,

Suppose we want to know the median instead of the average amount of work done? It would be really nice if we could just reuse the analysis from above but substitute the median of the geometric distribution: $\lceil {\displaystyle \frac{-1}{\lg (1-p)}}\rceil -1$. However, there are some issues we should resolve first (which might make the analysis more complicated):

1. In general, there's no linearity of medians.
2. There's inconsistent notation for medians, so I'll use ${\mu }_{1/2}[\cdot ]$ as a median operator.
3. Medians are discrete, not continuous like expectations. We'll have to bound the expression to make it useful. (See how the median of the geometric distribution contains a ceiling operation.)

Although there's no linearity of medians in general, it does hold for the geometric distribution. Specifically, monotonically decreasing distributions are closed under (positive) scalar multiplication and addition. For monotonically decreasing distributions $X$ and $Y$,

1. Multiplication by a positive scalar. ${\mu }_{1/2}[aX]=a{\mu }_{1/2}[X]$ where $a$ is a positive real. Scaling all values by the same amount doesn't change the relative order. If $a$ were allowed to be non-positive, then either $X$ would have no order (if $a=0$) or the order would be reversed (if $a<0$).
2. Addition of a scalar. By similar logic, ${\mu }_{1/2}[X+c]={\mu }_{1/2}[X]+c$, where $c$ is any real. Relative order is preserved.
3. Addition. Adding $X$ to $Y$ doesn't change the order of $Y$ (or vice versa). For $i<j$, it must be the case that $X_i+Y_i>X_j+Y_j$, since both $X_i>X_j$ and $Y_i>Y_j$. So in this case, we can apply linearity.

Because we now have linearity, we can start from the inner function from before.

Note that the function is ill-defined for $i=n-1$ since we would need to evaluate $\lg (0)$. So we can evaluate what happens in the case separately. When $i=n-1$, there is $n-(n-1)=1$ element in the list. With only one element in the list, it must be in the first position, so we do $2(n-(n-1))=2$ steps of work. To be precise, the median of the function $\text{Inner}(i;n)$ is bounded (and can be approximated) by

Coming back to the original problem, we want to find the median of our original definition of $T(n)$:

Now, it's not easy to get ${\displaystyle \frac{-i}{\lg (1-\frac{1}{i})}}$ into an explicit form, so we'll try bounding it with a polynomial. Let's guess $i^2$ as our upper bound.

Since 1 is finite and nonzero, our "bad" function from above, ${\displaystyle \frac{-i}{\lg (1-\frac{1}{i})}}$, can be bounded by a constant multiple of $i^2$, so long as we choose a big enough multiple. It turns out that $i^2$ is already big enough. For positive $i$, if we try to find the intersection points between the two functions:

For negative $x$, there are no values that satisfy that equation, so there are also no intersection points between the two functions. Since

we have an upper bound. Going back to our median,

So both the average and median cases result in the same estimate of a cubic algorithm.

So even though this sorting algorithm is naive and inefficient, it's not really all that inefficient. In fact, it's really only one simple step away from a typical quadratic sorting algorithm. How could we get something that is really inefficient? That's the question addressed in How inefficient can a sort algorithm be?^[1]. The paper describes a method to make an abitrarily inefficient sorting algorithm.