computer science

The old Daily Coding Problem email list gave us this problem around 2020:

Daily Coding Problem: Problem #237 [Easy]

A tree is symmetric if its data and shape remain unchanged when it is reflected about the root node. The following tree is an example:

        4
      / | \
    3   5   3
  /           \
 9             9

Given a k-ary tree, determine whether it is symmetric.

This problem is less well described than I thought when I worked on it in 2020.

There’s an older programming job interview question:

Given a string of round, curly, and square open and closing brackets, return whether the brackets are balanced (well-formed).

For example, given the string “([])”, you should return true.

Given the string “([)]” or “((()”, you should return false.

I’ve benchmarked mergesort variants with randomly-chosen data values, initial data values already sorted, and initial data values sorted in descending order.

What happens to mergesort algorithms when initial data values are chosen for worst case time complexity?

There’s one more item I discovered during my mergesort investigation that bothers me. I wrote code that finishes with a low-to-high data value list. Starting with a “reverse sorted” (high-to-low data values) list with Wikipedia’s bottom up algorithm does not show the abrupt performance drops that a randomly-chosen data values initial list does, but has bumps in comparison count at lists of 2^N+1 lengths.

Why is this?

I watched the Numberphile video Cracking Enigma in 2021 and I decided I had to give that a try.

• Problem statement and some experimentation
• Explanation of the algorithm I came up with in 2021.
• Recursive merge sort algorithm to have something to compare
• Re-using linked lists while benchmarking
• Effect of address-ordered linked lists
• Traversing linked lists does not exhibit weird performance drops at specific list lengths
• Effect of size of linked list nodes tests whether virtual memory is somehow involved. It is not.
• Bottom-up implementation with linked lists from Wikipedia, has the same performance drops as my July 2021 algorithm
• Memory access effects: incrementing .Data values, or arbitrarily changing .Next pointers does not cause the performance drops. I looked for other anomalies, too.
• Effect of garbage collection before preparing a new, unsorted, linked list
• The memory access patterns of recursive and wikipedia bottom up algorithms are identical, for linked lists that are powers-of-2 long. For other length linked lists, the memory access patterns are not.
• I wrote an iterative, explicit stack frame variation of recursive mergesort to try to get the same abrupt performance drops as the wikipedia bottom up algorithm. No joy.
• Recursive mergesort variations that explore specific differences between iterative and recursive algorithms do not impart any revelations.
• Counts of comparison operations finally reveals the cause of the performance drops.
• More counts of comparison operations, this time featuring pre-sorted and reverse-sorted initial linked lists
• Try to understand if merge algorithm choices affects mergesort performance.
• Examine effects of worst case initial data affects mergesort comparison counts.

What happens if you compare the number of comparisons made by recursive and wikipedia bottom up algorithms if the initial list is pre-sorted (low data value to high data value) or reverse sorted (high data value to low).

My recursive mergesort algorithm, and the wikipedia bottom-up) algorithm read and write the same list nodes in the same order, for list lengths that are powers of two. Something other than mere data reading and pointer writing causes abrupt performance drops at linked list lengths of 2^N+1 nodes.

I decided to count the number of comparisons used in merging lists. I had to write a different program so as to use an unsorted list with data in the same randomly chosen order for each of the three algorithms.

I tried several minor variations of recursive mergesort to try to understand the abrupt performance drops that my iterative mergesort code exhibits at some linked list lengths.

I wrote variants of recursive mergesort that simulate function call recurision by iteration with an explicit stack of activation records. This is an effort to try to understand the abrupt performance drops that the wikipedia bottom up algorithm exhibits at some linked list lengths.

Incidentally, these two algorithms both satisfy the Daily Coding Problem problem statement. Their simulated call stack could potentially overflow for extremely long lists, but those stacks wouldn’t have to be much bigger to accomodate those long lists.