Math and Game Thoughts

Magic Square of Squares Part 1

Sat, 16 May 2026 00:00:00 +0000

The Magic Square of Squares asks for a \(3 \times 3\) Magic Square where all the entries are square numbers.

To be a \(3 \times 3\) Magic Square \(9\) numbers are arranged in a \(3 \times 3\) square and each column, row, and diagonal add up to the same value. For instance,

\[\begin{matrix} 2 & 7 & 6 \\ 9 & 5 & 1 \\ 4 & 3 & 8 \\ \end{matrix}\]

Is a magic square since each row, column, and diagonal sum to \(15\). However, in this case, not every element is a square number so it is not a “Magic Square of Squares”. No \(3 \times 3\) “Magic Square of Squares” is known. I had made a problem related to finding one on conjecscore.org but had not put really much thought into the problem.

I decided to spend a little time thinking about it, and decided my first goal would be to find potential values for the center entry.

I am going to sieve out various impossible chocies for the center entry. That is, a center entry is impossible if it could not possibly be used as a center entry in a “Magic Square of Squares”. To do so, I will leverage two well known properties that any magic square must have:

Let the sum of any row, column, or digonal be called the magic sum and denote it as \(S\). Then the center value of a magic square is precisely \(S/3\).
Furthermore, up to symmetry, all magic squares must have the form:

\[\begin{matrix} \frac S3 + a & \frac S3 - a - b & \frac S3 + b \\ \frac S3 - a + b & \frac S3 & \frac S3 + a - b \\ \frac S3 - b & \frac S3 + a + b & \frac S3 - a \\ \end{matrix}\]

Now, we may derive some equalities from the fact that all entries must be square. Since we are interested in the center square, denote it as \(n^2\). Furthermore, both \(n^2 + a\) and \(n^2 - a\) must be squares. Thus,

\[n^2 + a + n^2 - a = t^2 + f^2\]

on the other hand,

\[n^2 + a + n^2 - a = 2n^2\]

Combining the two equations shows that \(n^2\) is the average of two squares, that is:

\[n^2 = \frac{t^2 + f^2}{2}\]

Furthermore \(n = \sqrt{\frac{t^2 + f^2}{2}} = \frac{\sqrt{t^2 + f^2}}{\sqrt{2}}\). This might seem like a silly observation, but we may use the fact that \(n\) is an integer to observe that the prime factorization of \(t^2 + f^2\) must have an odd power of \(2\) in it.

There is a quick way to compute the largest power of \(2\) that divides a number:

def largest_two_pow(n):
    return n & (~(n - 1))

This gives a nice sieve for possible center entry values:

Range over \(t\) and \(f\).
Compute \(t^2 + f^2\) and check if the largest dividing power of \(2\) is odd.
If so, factor out one \(2\) and see if it is a perfect square.

When it comes to ranging over \(t\) and \(f\), this is just an arbitrary size range of numbers we want to check, however, since \(t = n^2 + a > n^2 - a > f\) we may impose the restriction \(t > f\) in the search. Thus, in code, we have something like:

from math import isqrt


def largest_two_pow(n):
    return n & (~(n - 1))

def sqrt_int(x):
    isqr_x = isqrt(x)
    return isqr_x ** 2 == x

def main():
    RANGE = 20000
    candidate_n = set()
    for t in range(1, RANGE):
        for f in range(1, t):
            tf2 = t * t + f * f
            if largest_two_pow(tf2) % 2 == 1:
                tf2 //= 2
                if sqrt_int(tf2):
                    candidate_n.add(isqrt(tf2))
    print(len(candidate_n))

A Small Adaptation for a Better Sieve

The output indicates there are \(2000\) candidate values for \(n\) that work. In fact, we can adapt this program slightly to get an even smaller selection of \(n\).

We observed above that \(n^2 + a\) and \(n^2 - a\) were squares to conclude \(n^2\) was an average of a pair of different squares. It is also true that \(n^2 + b\) and \(n^2 - b\) are squares. Similarly, \(n^2 + a + b\) and \(n^2 - a - b\) are also squares. Thus, we can repeat this argument to see that \(n^2\) is the average of at least \(3\) different pairs of squares. So, we should only add to candidate_n if \(n\) appears \(3\) times or more. This can be easily done with a Counter object:

from math import isqrt
from collections import Counter


def largest_two_pow(n):
    """Return the largest power of 2 that divides n."""
    return n & (~(n - 1))

def sqrt_int(x):
    """Checks if sqrt(x) is integral."""
    isqr_x = isqrt(x)
    return isqr_x ** 2 == x

def main():
    # 1st round
    RANGE = 20000
    candidate_n = Counter()
    for t in range(1, RANGE):
        for f in range(1, t):
            tf2 = t * t + f * f
            if largest_two_pow(tf2) % 2 == 1:
                tf2 //= 2
                if sqrt_int(tf2):
                    # tf2 now equals n^2 add n to candidates
                    candidate_n[isqrt(tf2)] += 1

    result = set({key for key, value in candidate_n.items() if value >= 3})
    print(len(result))


if __name__ == "__main__":
    main()

Now there are only \(147\) choices of \(n\) available.

Conclusion

Still nothing significant, but hopefully, after some more thought, I can get some better candidates and at least get a decent score on conjecscore. I will continue thinking about this problem when I have more time. Secondly, next time, I will do a review of the literature (I like to try the problem by myself for a bit first though!)

Modular Game Components

Mon, 11 May 2026 00:00:00 +0000

I tried Godot some years back and while it was an impressive piece of software, I found myself struggling with it. (Just to emphasize, I have nothing against Godot! Try it out! It really is a great piece of software that many people use to make great things!) Instead I found that I really liked the simplicity of Love2D. If you wanted to print “Hello, World!” to the screen, it really was as simple as:

function love.draw()
  love.graphics.print("Hello World!")
end

Saying that, Love2D might be too simple (well, for me). The simplicity of the love.draw loop exhbits challenges in organization. For instance, if there is only one love.draw function, how do you keep track of which scene (i.e. which level, menu screen, etc.) you are on? A naive approach to this might look like:

function love.load()
  scene = "menu"
end

function love.draw()
  if scene == "menu" then
    ...
  elseif scene == "level1" then
    ...
  ...
  end
end

but this becomes an unreeadable mess very quickly. Fortunately, awesome-love2d addresses this!

Modular Components

awesome-love2d keeps a list of libraries compatible with Love2D. In particular, I liked HUMP. For the issue of scene management, HUMP provides a submodule HUMP.gamestate which allows you to make (along with some other features) separate draw functions for each scene:

local menu = {}
local game = {}

function menu:draw()
    -- Do something for drawing menu.
end

function game:draw()
    -- Do something for drawing the game.
end

The organization I sought after was now found!

HUMP even has other features. HUMP.timer (as the name suggests) allows for creating timers. It also has functionality for tweening values. That is, you can take one value and gradually change it to another value over time. I really love these two sublibraries. But even I found the HUMP.tween library a little too lacking. This gave me a predicament: should I use another tweening library, contribute to HUMP, modify HUMP source to accomidate my project, or make my own.

Making My Own

There was another problem I have yet to mention: I wanted to write games in Python. I know this is a rather weird choice given that Python is notoriously slow. Admittedly, I wanted to write in Python just because I was most familiar with Python. Pygame seemed to be relatively similar to Love2D, but awesome-pygame had fewer libraries listed. Even worse, after searching, I was not able to find much either. The good news, I could use this opportunity to help contribute to the Pygame ecosystem!

Learning From HUMP

I wanted a lot of HUMP functionality, but wanted to better enforce the Unix philosophy. Thus, instead of making a HUMP equivalent for Pygame, I sought to make smaller libraries, of which, combining all of them results in something that resembles HUMP. As for scene management, it seems as though there is an equivalent to HUMP.gamestate called PyScenes but I could not find anything for tweening. So, I decided to start working on a tweening library.

transytion is a tweening library that originally started out similar to HUMP.timer, but it addressed some of the issues I had with HUMP.timer, namely:

The callback mechanism was a bit cumbersome to use.
Stopping tweens should have some sort of (optional) stop callback. Therefore, if something happens (for instance, an enemy dies) the tween can have a convenient to use fail mechanism and switch to doing something else.
I wanted an extensive system for composing tweens together instead of glueing callbacks together.

Even later I realized that I could utilize Python decorators to simplify tween creation. A function can be associated with a tween (say, move), and by using some decorator magic, calling that function will not actually call the function immediately. Instead the function call runs move then calls the function. Taken from the documentation, this allows us to write:

move = Tween(...)
@tween_then_call(move)
def say_something():
    print("Hello!")

say_something()

Thus, if one wants a character to move a bit, then say something, move a bit more, and say even more, we can keep things organized:

say_something()
say_something2()

This keeps the focus of the code on the underlying logic and not the animations.

Beyond HUMP

As I continued working with Pygame, there seemed to be other core components missing:

From my experience with conjecscore.org, I found it annoying to manage the layout of content on the screen compared to how it is done in web development. Layout ended up being much harder than I thought it would be. To (partially) fix this, I worked on lpyout as a layout engine for games.
The shortest path libraries I found were inconvenient to use (for games at least). For most of these libaries, the input required a graph representation (such as an adjacency matrix). I did not have an adjacency matrix of the world. Instead, I had a grid of the world. I made gtravyl that takes in a grid representation of the world and finds the shortest path. Although not as flexible, I believe this is much easier to use than the existing libraries out there while remaining flexible enough for most use cases.
I feel (although potentially a very controversial opinion) that event listeners are underrated as an organizational tool. This includes games, so I developed pypagate which can create formulas and (from formulas) create listeners. Formulas can describe many situations quite elegantly. Consider the following game scenario from the README of pypagate that creates event listeners for when a game should end:

>>> from pypagate import Term, fire_on
>>> class Player:
...     def __init__(self, health):
...         self.health = Term(health)
...
>>> player = Player(3)
>>> @fire_on(player.health == 0)
>>> def game_over():
...     print("Game over")
>>> player.health -= 1
>>> player.health -= 1
>>> player.health -= 1
Game over

Conclusion

My ultimate goal is not to create a game engine but to extend existing game frameworks, such as Pygame, so that we have the modularity of the Unix philosophy with the feature completeness of an engine. The result is a collectiion of libraries that anyone can use (Apache 2.0 License).