We have a weekly D&D game with a few of my colleagues. We play at lunchtime. A few weeks ago, something terrible happened: our DM forgot his dice.

⊕Translation from the French: “I didn’t realize, but I didn’t bring any of my D&D stuff at all. I have 0 dice, 0 screen”

There are already thousands of websites and mobile apps for rolling dice in role-playing games, but that would be boring. What if I made one myself? ⊕Another tragic event happened in game: my character died during combat. And this particular warlock believes in a higher power, and the coming of the Great Old One in an apocalypse that will consume the world. The warlock’s interpretation of his death is that fate is rigged, and the dice are probably wrong.

The initial idea was very simple. Character sheets and player handbooks use “dice expressions” like 6d4 + 4. This means “roll six four-sided dice, add the values, and add 4”. This gives you the damage you deal to a monster while hitting it with your amazing sword or badass magical spell. So we could simply type a dice expression, and the tool would simulate the dice rolls, compute the sum, and give you the result. Quick and easy.

Dear reader: it ended up doing way more than that. Way too much.

The first version

Famously, all problems can be solved with regular expressions. So my first version was basically this regex: (?<sign>[+-]?)(?:(?<count>\d*)[dD](?<sides>\d+)|(?<num>\d+)), along with some code that went through each capture group and called random_range(1..6) if it encountered d6.

Then it’s just a matter of reading the command-line arguments, parsing them with the regex, and printing the result. I did it in Rust because I was already familiar with it, and I could quickly whip up a small command-line utility like this. And it gave me a single binary that I could share with the team.

Great.

But not enough.

The rabbit hole

Even a cursory glance at the player’s handbook will let you know that dice expressions can become much more complex than that. And my tool would not be a serious tool if it didn’t support everything, right? So I rewrote the parser to use a proper parser combinator library (nom) instead of a regex, and I happily started to implement necessary and not-so-necessary features:

• adding and subtracting dice expressions: 4d10 - 2d3 + 4,
• parenthesized groups and multipliers: d20 + (2d6+3)*2 + 5,
• keep/drop highest/lowest rolls: 2d20kh1 rolls a d20 with advantage, 4d6dl2 drops the two lowest values,
• re-rolls: 6d10r re-rolls 1s until the die stops showing 1,
• exploding dice, minimum and maximum results, count matching, and so on. All of these modifiers can obviously be combined!

But what about the user experience? Surely our dear users⊕At this stage, “users” means “myself”.

will grow tired of the simple CLI interface? So I added a REPL, and JSON output for programmatic use, and a web server because why not? Someone might want to use it through an HTTP API!

At that point it also stopped being just a dice rolling utility. I’m quite happy with the stats command, which rolls the dice expression many times and computes statistics, which is useful to see what you can expect from a given combination. What is the standard deviation of the damage dealt by your weapon? What chance do you have of hitting that goblin with your spell?

The website

At this point I was actively looking for opportunities to overengineer this even more. What useless feature could I possibly add?

Well, I had a nice command-line tool in Rust. Being a serious person working on a serious project, I had a clean architecture, with a library and binary that called it. So where could I use that library? Rust can compile to WebAssembly, why not try that? I could call the library from a small website and roll blazing fast dice in WASM directly in the browser!

I found a cheap domain name, and shortly after, the result was accessible on diceroll.run.

With the website, I could experiment with a lot of stuff that I wanted to explore:

• the WASM module itself of course, how to build it and use it from JS in the browser,
• generating a random seed at the start of the session for reproducibility,
• saving all the state (random seed and input history) in the URL query parameters, for easily sharing a session with other people!

Coding agents and learning opportunities

Among these vast amounts of overengineering and unnecessary features, there was at least a nice outcome: I learned a lot.

As mentioned earlier, the initial version was basically a single script generated with an AI agent. After that, as I became more invested in the features, I continued iterating with AI. But this was mostly for fun and a learning opportunity: I was under no pressure to actually deliver any of those features! So I didn’t “vibe code”, I used the agent to iterate on the code, reviewing it line-by-line as I would have done if I had written it myself.

This allowed me to iterate rapidly on the features and on the code structure. Rust was really helpful as well. I decided on the data structures and the libraries, and from there the LLM could generate very good code within the constraints of the data models and the compiler’s checks.

The parser in particular is code that can quickly become a little bit boring, even with a parser combinator library. Here the LLM could generate a battery of unit tests, and I could very easily check that it covered the most important cases, both expected successes and expected failures. Without AI assistance I don’t think I ever would have had the patience to write these tests for a side project! It’s in this sense that I believe AI agents can lead us to write much better code, especially for one-off, unimportant side projects like this.

The only part that was fully AI-generated with (almost) no supervision is the website. The HTML, CSS, and the bit of JS wrapping the WASM module was fully “vibe coded” in the sense that I didn’t read the code in detail, I just looked at the output, tried it, and iterated from there. Given that most of the logic is in the Rust library, I didn’t want to spend too much time changing CSS by hand…

With or without AI, small projects like these are a great learning opportunity. I could experiment with new (to me) libraries for parser combinators, minimal HTTP servers, CLI argument parsing, etc. The AI agent is also a great source of learning, studying the code of simple examples!

Use it (if you want)

The code is on GitHub (you can download a pre-built binary in the releases), and the website is on diceroll.run! As you can imagine, I would be very happy to hear about your ideas for new features and improvements 😛

In the past few months, I have been working on a new project: Leibniz. I designed it to improve the way we plan projects. Like most side projects, it started because of my own dissatisfaction with the existing tools and processes during my work. Here, I want to explain the story, the frustrations I encountered, and the vision I have.⊕This is the origin story and the product vision. I hope to have more to say about the technical details and the juicy algorithms later!

Project management, the old-school way

In my previous job, I was in charge of project management. The company was very old-school in its approach, and although quite small, copied most of its processes from large industrial companies like Thales and Safran.

This meant that most projects were managed in the following manner:

• a project manager designed the entire project from scratch, dividing the project into many tasks,
• she mapped the dependencies between each task,
• she assigned a resource (usually a job title, like “backend developer” or “research engineer”) to each task,
• she set a duration for each taskThis only covers the initial part of project planning. But the main difficulty actually arises during project execution: adapting activities, dependencies, and schedule to external, unforeseen events.
  
  .

After that, the project manager set up a meeting with the company’s top management to present the plan. It got challenged, often in very minute details, including time estimates. The goal of the project manager at this point was to obtain top management’s approval for running the project, and above all to negotiate the deadline (she wanted to set it as late as possible, because she would be held accountable if she missed it), and the resources made available to her (i.e. people).

And then the dance started: there was a big meeting with all the other project managers (each with their own projects and requirements), and they would all haggle over the “resources” (once again, actual people, fellow colleagues working right next to them). This often degenerated into apothecary-style counting: a typical sentence in these meetings was “ok, you can have Bob on week 3 of April, but then I will need 0.5 Alice on week 4 to compensate”. Not only were these arrangements nearly meaningless (how can a developer work for 2.5 days on a given project then switch to another?), but the vocabulary encouraged project managers to think of people as “resources”, machines that could be subdivided, reallocated, and moved as easily as equipment can be repurposed.

But that was not the worst part. The worst part was the tooling we had to use.

I managed small projects, mainly software. Think a few months, at most a year, and a small team of between 5 and 10 people. Something that most startups handle very easily. We could have done it with an agile team iterating rapidly, but to fit the process, I had to build a full project plan, including the list of tasks with all the metadata, a Gantt chart, and so on. It could have been done very easily. But the company used Microsoft Project.

Microsoft Project has… a few issues. The software was basically built in the 90s and never touched since. The developers had clearly never spoken to an actual user in their entire lives. If it was made for anyone, it was for project managers on extremely large projects (perhaps for designing and building an entire airplane).⊕I should note that this is a personal impression based on very superficial use. We are talking about a very large piece of software in which Microsoft has probably invested decades of work. I am sure many people have mastered it and find it invaluable. But it was not what I wanted for my simple use cases. And it certainly didn’t spark joy.

There were thousands of features I would never need, and the basic ones were very hard to use.

• The entire interface is built like an Excel spreadsheet. Each activity on its own line, with ID, name, duration, resources, and dependencies. A project is inherently a graph, and project planning (at least for me) is an inherently visual activity. Yet the only place where you can actually edit the project is a very dense table.
• Dependencies are represented in the most obscure way possible: each activity has a “dependencies” column where you fill the IDs of the activities on which it depends. Good luck figuring out what it means when you see that your activities depend on 127, 134, and 34. It basically feels like you are looking at the underlying database schema, not at something built for actual users.
• It is very hard to collaborate on projects. Even though the essence of a project is to organize an entire team, you cannot share it easily other people. If one person has it opened, you have to wait until they close it before being able to open it yourself. And the interface is so dense and unclear that only people who are used to work with it know what to look for, so it’s useless to show to individual developers for instance.
• The scheduling algorithm feels limited: you have hundreds of options to configure different dependency types, but it many cases the program just gives up and settles for highlighting conflicts between activities (generally resource conflicts). Then you have to fix them manually, moving tasks and hardcoding their start date, defeating the entire purpose of a scheduling software.

Project scheduling is a good abstraction

None of this was great, both in terms of process and tooling. It’s easy to conclude that we should throw out the whole thing and do something else entirely (agile, scrum, whatever you want to call it). But underneath the unpleasantness, I still thought that the underlying model was interesting. The problem is not the Gantt chart; the problem is sticking rigidly to it. The problem is not decomposing the project into small tasks and assigning them to people; it’s treating people as consumable, impersonal resources. The model was still useful for helping me structure my thoughts on large and ambitious projects, and to communicate the tradeoffs and decisions to other people (both the members of my team and my managers).

And to be honest, the maths nerd in me was also quickly fascinated by the underlying algorithms for project schedulingThe mathematical model of a project, as used in most algorithms, is very clean and elegant, with very few concepts. This convinced me that there exists a good UX that will help people manipulate it easily.

.

So I went looking for a way to leverage that model while challenging both the tooling and the process. As a small-scale manager, there wasn’t much I could do about the process directly, but I could propose better tooling and use that as a means to challenge the process itself.

Looking for alternative tooling

Given the 1990s look and feel of Microsoft Project, I naturally assumed there would be something better that I could propose to my boss. I had already managed to convince him to let me migrate my team to Linear, while the rest of the company was still on Jira. Where was the Linear to Microsoft Project’s Jira?

It turns out it didn’t really exist. Most competitors were either as bad as Microsoft Project (with fewer features), or were focused on some other area I didn’t need (mostly CRMs, ERPs, and things like that), with project scheduling bolted on the sideOf course I can’t pretend I looked at each and every one of them…

.

Looking into it, the reason everyone gave was that project scheduling was a “hard problem” requiring dedicated research teams and state-of-the-art algorithms. This piqued my curiosity, and without much ambition, just out of curiosity, I looked into the literature on project scheduling. I quickly learned that simple algorithms (like the critical path method) cover the most basic use cases very simply. But the theory was much richer than I expected: there are hundreds of variants of the scheduling problem, and there’s a very active research community with close ties to the industry. (I wrote about it a bit in a previous post.) I eventually bought a book on project scheduling with time windows and resource constraints, had a very basic implementation running within a few days in my spare time.

The algorithm is not the product

As is often the case, the algorithm is not the difficult part. The difficult part is the product. What did I want from this software? As my own first user, my needs were clear:

• An intuitive user experience. This is table stakes: nobody wants to spend months mastering a project scheduling tool.
• Easy visualization and manipulation of dependencies. Dependencies are the key part of the model. Everything, from the resource allocations to the final schedule, hinges on them.
• A collaborative experience from the start. If you can’t share it with anyone, the project plan loses 90% of its use.
• A state-of-the-art scheduling algorithm, that never forces you to adjust manually.
• A fast, responsive experience. When I change something, I want the changes to be reflected immediately in the schedule.

Above all, I wanted it to be useful to everyone: not only to people working with traditional project management processes, but also to people who work in more agile, flexible environments. And from small projects of a few tasks to enormous undertakings involving thousands.

Going forward

Over the past months, I have built a tool that answers most of my needs. I am my own first user (and apart from a few colleagues, the only one). Despite no longer working at the same company, and following vastly different processes, I still use it every day.

Project scheduling algorithms are so general that they can be applied to many different contexts. In the next few posts I will probably talk more about some design choices and some technical decisions I made. For spoilers, the key features are on the website! And maybe I will also explain the name…

A few days ago I stumbled into the OEIS again via their pictures page. Looking at some of the pages there gave me an idea for a new, small project, so I gave it a shot.

What is the OEIS?

The Online Encyclopedia of Integer Sequences, or “OEIS” for short, is a collaborative project whose objective is to collect all sequences of integers into a comprehensive repository. It is useful to all mathematicians (professional or amateur!) who stumble into a sequence and wish to identify it: they can type a few terms into the search bar, and the OEIS will return all sequences that match.

The OEIS was started by Neil J. A. Sloane, after publishing a few books collecting many important sequences. Many people had interesting sequences they wanted to contribute, and sent letters to Sloane with suggestions. The collection began to be so large that Sloane started an online version, which became the OEISThe full history can be found here.

.

Each sequence in the database has a unique identifier like A000108. An entry includes a description, the known terms of the sequence, and a lot of additional data: explicit formulas when they exist, comments and bibliographical references, programs to compute the sequence, and other related sequences in the database. The demo is a good place to start for how to use the database.

Like most people, I have no real need of the OEIS on a day-to-day basis. However I still find it fascinating. Many sequences are well-known: the prime numbers (A000040), the Fibonacci numbers (A000045), etc. Others I have encountered elsewhere in popular mathematics, like the Busy Beaver problem (A060843), whose 5th term has been computed recently. And others I have discovered directly on the OEIS, like the “peaceable coexisting armies of queens” (A250000, look at the ASCII chess boards in the examples!).

What I like about these sequences is that they are often at the intersection of many domains in mathematics. Some of these sequences have very deep connections to many areas, and let you discover new interesting concepts and ideas. Moreover the relationships between sequences is often interesting as well, and let you continue the exploration.

The idea

The only problem is that the OEIS is more a search engine, and therefore most sequences are not very discoverable. Contributors and editors add keywords to the sequences, some are nice, some have a nice graph (click on “graph” under the sequence itself!), and the wiki lists some important sequences. But other than this it is not easy to discover interesting sequences randomly.

So I got the idea of implementing a bot that would share a random sequence regularly, so I could read the full OEIS page if the description seemed interesting. Since I am mostly on Mastodon, I wanted to implement this as a Mastodon bot so that others could follow it if they want.

The implementation

The general idea is as follows:

1. Pick a random sequence ID out of the nearly 400,000 sequences currently in the database.
2. Retrieve the metadata for this sequence (its name, the first few terms, keywords and comments).
3. Format this as a Mastodon post and post it.

It is a very simple process (basically a GET request to the OEIS followed by a POST request to a Mastodon instance). Mastodon servers have a public API that is very easy to use and very well documented: I only needed the statuses endpoint. It requires a token that can be generated easily from the account settings, by creating an application with the write:statuses scope.

The OEIS API has a JSON output format. I wanted to parse this correctly. Looking at the documentation of the format, I realized that many sequences should be excluded because they are duplicates, unimportant, or too obscureSpecifically, I excluded sequences tagged with dead, dumb, dupe, less, obsc, probation, or uned.

. So I added a step in the process above to make sure that the sequence picked at random was sufficiently interesting. Given the number of available sequences, there should be more than enough interesting ones!

I implemented it in RustMostly because I am comfortable with it, it has a very good ecosystem, and it can be deployed as a single binary.

. Claude Code was fairly helpful to build all this, especially for the serde types to deserialize the OEIS internal format. All in all, I had a fully functional program in under an hour, for something that would have taken me at least a few hours if I had done everything “manually” (and which would not have been particularly interesting or fun to do). I am reasonably happy with the overall quality of the code, that you can find on GitHub.

The final program is deployed on my VPS, I just copied the executable and set up a systemd timer to call it every 4 hours. The token for Mastodon is given as an environment variable in the service file.

The result

I created an account on Mathstodon, the instance I use for my personal account. As this is my first bot, I wasn’t sure about the process, but the administrators of the instance were happy to allow the bot as long as it is clearly identified as such and does not spam too much. I also made it clear that the bot is not operated officially by the OEIS. Should they decide to join Mastodon, I would be happy to cede them the account if they wish.

If you want to follow it, the account is @OEISbot!

OEIS sequence A177263
Triangle read by rows: T(n,k) is the number of permutations of {1,2,...,n} having k as the last entry in the first block (1<=k<=n).

1, 0, 2, 1, 1, 4, 4, 5, 5, 10, 18, 22, 23, 23, 34, 96, 114, 118, 119, 119, 154, 600, 696, 714, 718, 719, 719, 874, 4320, 4920, 5016, 5034, 5038, 5039, 5039, 5914, 35280, 39600, 40200, 40296, 40314, 40318, 40319, 40319, 46234, 322560, 357840, 362160, 362760, 362856, 362874, 362878, 362879, 362879, 409114

https://oeis.org/A177263

OEIS sequence A071904
Odd composite numbers.

9, 15, 21, 25, 27, 33, 35, 39, 45, 49, 51, 55, 57, 63, 65, 69, 75, 77, 81, 85, 87, 91, 93, 95, 99, 105, 111, 115, 117, 119, 121, 123, 125, 129, 133, 135, 141, 143, 145, 147, 153, 155, 159, 161, 165, 169, 171, 175, 177, 183, 185, 187, 189, 195, 201, 203, 205

https://oeis.org/A71904

For now only a few sequences have been posted, but I’m excited to see what interesting sequences come up!

Imagine you are the director of a unit in a large company. You have 5 teams, with various numbers of people in each team. An important new project has come up, and you would like to set up a new team to tackle it. The problem is: you don’t have any budget to hire new people!

What can you do? Well, you could take one person from each existing team, and build a new team with these 5 people.

It works well for a while, but of course soon enough, a new project comes up, and you still don’t have any additional budget! It worked the first time, so you reshuffle the teams once more in the same way. One of the existing team had only one person left, so they go to the newly created team and their existing team just disappears.

Now the CEO is getting concerned with your unconventional management practices. She summons you to her office and asks you: What would happen if you do this repeatedly for every new project? How many teams will you end up with, with how many people in each one of them?

The Bulgarian Solitaire

Instead of this (admittedly far-fetched) management scenario, you can do the same process with playing cards. You have \(n\) cards divided arbitrarily into several piles. At each step, you remove one card from each pile and collect them in a new pile next to the existing ones. If you repeat this operation, how many piles of cards will you get? With how many cards in each of them? This problem is called the Bulgarian Solitaire. It is described in this paperWhich also describes the history of the problem, including why it is called “Bulgarian”.

.

With \(n\) cards, the Bulgarian Solitaire is an example of a discrete dynamical system on partitions of \(n\). A partition is an unordered sequence of numbers that sum to \(n\). For instance, \((4,3,2,1)\) and \((8,3,2,2)\) are partitions of 15. At each step, the Bulgarian Solitaire will transform a partition like \((8,3,2,2)\) into a new one, in this case \((7,2,1,1,4)\) (the new pile is at the end, but we don’t care about the order so we can also write it as \((7,4,2,1,1)\)).

What we are trying to understand is in fact a standard question in dynamical systems: where is the system going? Are there stable states, cycles? What are they?

Visualizing the Bulgarian Solitaire process

As a first example, let’s take \(n=10\) cards, in piles of 4, 3, and 3 cards. We take one card from the top of each pile (in orange), and we make a new pile of size 3:

Visualizing cards like this is not very practical, but as it turns out, mathematicians have already devised a nice way to visualize partitions: Young diagrams. They represent a partition as rows of boxes. For example, the partition \((6,5,3,1)\) of the number 15 can be visualized as:

In our cases, we can rotate the Young diagram by 90° so that it looks more like piles of cards:

A step in the Bulgarian Solitaire will look like this:

We take one card from each pile (highlighted in orange in the diagram above), and create a new pile from them. Then we reorder the piles so that they are sorted by decreasing size.

Convergence of the Bulgarian Solitaire

Now, if you try the Bulgarian Solitaire with 15 cards, for every possible starting position, you will end up with 4 piles of size 1, 2, 3, and 4. It turns out that this pattern can be observed consistently:

How can we prove this?

There is a nice trick: we rotate (again!) our Young diagram by 45°:

When we do a step in the Bulgarian Solitaire, we move around the boxes:

Sometimes we can see that a box (in grey here) is above an empty space, and therefore it falls down. This corresponds to cases when there is a need to reorder the piles so that they remain in order of decreasing size.

We can see that at each step, the total potential energy of the boxes either stays the same (when all boxes are still resting on other boxes or on the edges) or decreases (when a box is above an empty space and falls down). And the lowest possible potential energy is reached when the configuration is fully triangular, when boxes are spread evenly across all piles!

So now we just need to prove that all configurations will end up at this minimum of potential energy, i.e. that there is no local minimum that prevents the system from reaching this global minimum.

Imagine we are not at this triangular position. Since the total number of boxes is triangular, there is necessarily one layer with an empty space for a box, and one layer above with an additional box. At each step, the boxes will “rotate”, and the empty space and the additional box will move one space to the right. If the layer with the empty space is of size \(k\), the layer above it will be of size \(k+1\), and these numbers are relatively prime. After a certain number of steps, the additional box will be directly above the empty space and will fall down.

So no configuration that is not fully triangular is stable: after a certain number of steps, the potential energy will decrease. The detailed proof can be found in section 2 of the paper.

Simulating the Bulgarian Solitaire

Let’s simulate the process (in Python) to visualize the convergence. The script will generate all partitions of a given integer \(n\), and generate the transition graph of the Bulgarian Solitaire. If a step of the Bulgarian Solitaire transforms partition \(p_1\) into partition \(p_2\), we will draw an edge between \(p_1\) and \(p_2\).

We’ll start by defining helpful type aliases: a partition is a tuple of ints, and the graph we will generate is a dictionary from partitions to partitions.

type Partition = tuple[int, ...]
type Graph = dict[Partition, Partition]

Next, we need a function that enumerates all possible partitions of a given integer \(n\). It is built recursively: for all possible prefixes \(0 < k \leq n\), the partitions we are looking for consist of \(k\) followed by all partitions of \(n-k\).

from collections.abc import Generator

def integer_partition(n: int) -> Generator[Partition]:
    if n <= 0:
        return

    def find_partitions_recursive(target: int, current_partition: list[int]):
        if target == 0:
            yield current_partition
            return

        max_val = current_partition[-1] if current_partition else target
        for i in range(min(target, max_val), 0, -1):
            current_partition.append(i)
            yield from find_partitions_recursive(target - i, current_partition)
            # Backtrack
            current_partition.pop()

    yield from map(tuple, find_partitions_recursive(n, []))

The step function is the Bulgarian Solitaire itself:

def step(partition: Partition) -> Partition:
    next = [len(partition)] + [k - 1 for k in partition if k > 1]
    return tuple(sorted(next, reverse=True))

We can now compute the transition graph:

def compute_graph(n: int) -> Graph:
    return {partition: step(partition) for partition in integer_partition(n)}

Now for display, we generate some Graphviz code. The colors are adapted for viewing directly in the terminal.

def print_graphviz(graph: Graph) -> None:
    print("""digraph {
    bgcolor="transparent";
    node [shape="rect", fontcolor="white", color="white"];
    edge [fontcolor="white", color="white"];
    """)
    for k, v in graph.items():
        print(f'    "{k}" -> "{v}";')
    print("}")

To finish, let’s add a command-line interface:

import argparse

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("n", type=int)
    args = parser.parse_args()

    graph = compute_graph(args.n)
    print_graphviz(graph)


if __name__ == "__main__":
    main()

The script can then be called directly:

# Save the graphviz file
python bulgarian_solitaire.py 10 > graph10.dot
# Generate a PNG graph
python bulgarian_solitaire.py 10 | dot -Tpng > graph_10.png
# Display the image directly in the terminal (if it supports image display)
python bulgarian_solitaire.py 12 | dot -Tpng | viu -

Here is the output for \(n=6\):

And for \(n=10\):

As we can see, all partitions indeed converge to the triangular configurations \((3,2,1)\) and \((4,3,2,1)\).

Now what happens when the number \(n\) is not triangular?

For \(n=7\):

The dynamical system converges to a cycle between \((4,2,1)\), \((3,3,1)\), \((3,2,2)\), and \((3,2,1,1)\). When we look at this cycle, we realize that it is the triangular configuration \((3,2,1)\), plus an additional box cycling above.

For \(n=8\):

Here we get two connected components in the graph. And here again, we get the triangular partition but with two additional boxes cycling above.

This property can be proved (Theorem 2 in the paper), and the number of connected components can be computed exactly for all \(n\).

Conclusion

The Bulgarian Solitaire is a nice example of a discrete dynamical system. The proof is particularly interesting because it relies on visualization and physical intuition about the “potential energy” of the system, which translates directly into the formal proof.

The paper also mentions generalizations. I am interested in particular in the stochastic Bulgarian Solitaire. Instead of taking one card from each pile at each step, we take one card from each pile independently with probability \(0<p<1\). The dynamical system becomes a Markov chain, and it would be interesting to study (even experimentally) its convergence properties.

Bonus: BQN implementation of the simulator

First, the Step function computes one step of the Bulgarian Solitaire. It removes 1 from each pile (¯1⊸+), removes the piles that became empty (0⊸≠), adds a pile of the original size (≠∾), and sorts the piles for consistency (∨).

Step←∨≠∾(0⊸≠⊸/¯1⊸+)

The Partitions function generates all partitions of a given integer. Conveniently, this was already available in BQNcrate!

Partitions←{∾⊢´∾⟜(<-⟜↕∘≠{𝕨∾¨∾(-𝕨⌊≠𝕩)↑𝕩}¨⊢)⍟𝕩⋈⋈⋈↕0}

We can now compute the graph, by first computing all partitions of the input, then building the edges by calling Step on each partition.

ComputeGraph←{>(⊢⋈Step)¨Partitions𝕩}

We now generate and print the graphviz code:

EdgeToGraphviz←{∾⟜(""";"∾@+10)5↓∾""" -> """⊸∾¨•Fmt¨𝕩}
graphvizheader←"bgcolor=""transparent"";
node [shape=""rect"",fontcolor=""white"",color=""white""];
edge [fontcolor=""white"",color=""white""];"
ToGraphviz←{"digraph {"∾graphvizheader∾(∾EdgeToGraphviz¨<˘𝕩)∾"}"}

n←•ParseFloat⊑•args
•Out ToGraphviz ComputeGraph n

Similarly to the Python version, we can run the script with:

bqn bulgarian_solitaire.bqn 6 | dot -Tpng > graph_6.png

This is the title of a recent preprint (Nikolaou et al. 2025)Quick link: ArXiv:2510.15511.

, that has some interesting insights on the mathematical properties of Transformers when viewed as functions.

The immediate reaction is “this is nonsense”, and the title may be viewed as either misleading or deliberately provocative in order to gather interest. Indeed, most functions inside neural networks⊕ The SwiGLU activation function. It is clearly not injective.

and particularly Transformers are not injective. One thinks immediately of activation functions, normalization layers, and so on, counter-examples abound. So how can an entire language model be injective?

At a higher level, injectivity seems like an even taller order. From the user’s point of view, plenty of input prompts will lead to the same answers (one can think of all prompts ending with “answer with yes or no”)Indeed, the public discourse around this paper was dismal, with thousands of users on X/Twitter posting ChatGPT screenshots “disproving” injectivity…

.

So, let’s actually go through the paper to understand the claim more precisely!

Language models as functions

There are many different ways of viewing language models as mathematical functions. In the first intuition above, we considered models as functions from vectors to vectors, or from text to text. This is what makes the result seem counter-intuitive at first.

I think one of the main contribution of the paper is to slightly change the context: they see language models as functions from a prompt (i.e. a finite sequence of discrete tokens) to activations on the output layers (vectors).⊕ The function we are studying: from prompt space (sequence of tokens) to latent space (vector of activations).

Formally, we have a finite vocabulary \(\mathcal{V}\), and context length \(K\). From a sequence of tokens \(s \in \mathcal{V}^{\leq K}\) and parameters \(\mathbf{\theta}\), the language model gives us last-token representations \(\mathbf{r}(s, \mathbf{\theta}) \in \mathbb{R}^d\).

The central claim of the paper is that this function is injective.

Why is injectivity important?

Since the various components of the language models are not themselves injective, people tend to assume that there is some “forgetting” and privacy is built into all language models. Since the input prompt is transformed into an intermediate representation that goes through many transformations, information is lost and the input prompt cannot be reconstructed exactly. This intuition is wrong.

This has practical consequences for systems that store intermediate activations (e.g. embeddings), in the assumption that this is somehow more secure, or more respectful of their users privacy, than storing the user inputs directly. In practice, all the information is in the activations, and the paper provides both a formal proof and a practical reconstruction method.

Structure of the paper

The paper has two main parts.

• The theoretical part defines a Transformer-based language model mathematically as a function from sequences of tokens to real-valued vectors. In this context, they prove that language models based on common blocks (feed-forward layers, embedding layers, self-attention blocks, common activations, etc) are almost surely injective after random initialization of the parameters, and that this property is preserved during training.
• The practical part builds on these insights and builds a fairly straightforward algorithm to reconstruct user inputs from the activations of any intermediate layer, including the output layer. They show 100% reconstruction accuracy on widely-used language models.

The theoretical argument

A primer on analytic functions

To prove the main results, the paper uses the notion of analyticitySee Appendix A of the paper for the full background on analytic functions.

. Analytic functions are highly regular, actually even “smoother” than infinitely differentiable functions. It is this “smoothness” that will have important consequences for proving injectivity.

Intuitively, analytic functions are “locally polynomial”:

Intuitively, not only the function is infinitely differentiable, and therefore can be locally approximated by its Taylor series, but actually the coefficients are zero after some point, so the function is locally a polynomial. This gives enormous regularity guarantees, and analytic functions are among the most well-behaved.

A vector-valued function is analytic if all its components are analytic, and we can similarly extend the definition to matrix-valued functions. This is very important for our discussions since the component blocks of Transformers are often matrix-valued, e.g. attention layers.

Importantly, the set of analytic functions is closed under common operations: addition, product, quotient, and composition. This means that we only have to prove the analyticity of common building blocks of Transformers, and through addition and composition the analyticity of the overall function will be immediately proven.

Moreover, analytic functions have a key property relating to their zero sets:

The gist is simply this: if \(f\) is not zero everywhere, then it is zero almost nowhere. If there is an entire continuous region where \(f\) is zero, it means that \(f\) is zero everywhere! This is a very strong property of analytic functions: fundamentally, they are so regular that if they are zero on any significant portion of their domain, their smoothness imposes that they become zero everywhere.

This proposition is key to the paper as it will be used to prove injectivity. We can now go on to the actual results of the paper.

Language models are analytic

A language model is a composition of many building blocks. Transformer blocks are themselves composed of self-attention layers and MLPs, which are themselves compositions of stacking operations, normalizations, softmax, exponentials, and polynomials. By going bottom-up, we can start from basic blocks (polynomial functions, the exponential function), show that they are analytic, and since analytic functions are closed under composition, show that the entire language model is analytic.

The proofs that these building blocks are analytics are detailed in Appendix A of the paper. The full language model is defined mathematically as a composition of these building blocks in Appendix B, with Proposition B.3 putting everything together and proving that Transformers are analytic.

Injectivity at initialization

Let us draw a set of parameters \(\mathbf{\theta}\) at random, from a distribution with a density. For any two prompts \(s, s' \in \mathcal{V}^{\leq K}\), the probability that the output activations \(\mathbf{r}(s, \mathbf{\theta})\) and \(\mathbf{r}(s', \mathbf{\theta})\) are equal is zero.

This is because the function \(\mathbf{\theta} \mapsto \mathbf{r}(s, \mathbf{\theta}) - \mathbf{r}(s', \mathbf{\theta})\) is a sum of analytic functions, and is therefore analytic. By the key proposition above, its zero set has measure zero. So by drawing random parameters \(\mathbf{\theta}\), you have almost surely \(\mathbf{r}(s, \mathbf{\theta}) \neq \mathbf{r}(s', \mathbf{\theta})\).

We have just proven that if \(s \neq s'\), then, with probability 1 over \(\mathbf{\theta}\), we have that \(\mathbf{r}(s, \mathbf{\theta}) \neq \mathbf{r}(s', \mathbf{\theta})\) i.e., \(\mathbf{r}\) is injective!

Injectivity is preserved during training

However, we only draw \(\mathbf{\theta}\) at random during initialization. What if during training, as \(\mathbf{\theta}\) changes, the language model loses its injectivity?

It turns out that gradient descent itself is also analytic (and so are its variants, stochastic gradient descent, minibatch GD, etc). It is therefore once again very smooth, and can only stretch and bend the parameter space, but not collapse regions of positive volume into single points. So as the parameters change during training, the points that are apart stay apart and do not collapse onto each otherThe argument is made formally in the paper using topological properties of the Jacobian of the gradient descent function. I won’t go into the details here, see Section 2 of the paper for an overview, and Appendix C for the full proof.

.

The injectivity property established at initialization is therefore preserved at each step of the training. This concludes the main result of the paper: a fully-trained language model based on Transformers is injective. Two different input prompts will always lead to two different output activations in the final layer (and in any intermediate layer for that matter).

Remarks

The paper bases all the proofs on a definition of a “standard” language model based on Transformers. However, there are architecture choices that can break the fundamental hypotheses. In particular, some activation functions like ReLU are not analytic (indeed, it is not even differentiable), and things like quantization also break the analytic property of the entire model. In these cases, the model will not be injective.

However, all modern language model architectures use smooth activationsSee this great article on SwiGLU and family for an overview of activation functions used in LLMs.

, and quantization is not the norm everywhere. As we will see in the next section, the theoretical result hold very well in practice for LLMs that are widely used today.

Practical application

Proving a theorem might not be enough, as there are plenty of things that are ignored in the mathematical formulation (e.g. floating-point precision). Moreover, real-world LLMs are very complex systems with thousands of building blocks. For instance, activation functions are part of a very active research domain and change frequently, so there is no guarantee that all activation functions found in the wild follow the requirements of the theorem.

The first practical test is to check for collisions: two input prompts that lead to the same activation vector. If we can exhibit two sequences of tokens like this, we will have broken the injectivity.

For large vocabularies, the input space is too big to be checked exhaustively, so they can’t check everything. Instead they start with a dataset of real-world prompts and find the ones that are the closest in the output. They append all the possible sequences of tokens to these prompts. Therefore the test is “exhaustive” starting from “prefix” prompts that were already very close.

What they find is that all input pairs are very far from a collision threshold of \(10^{-6}\) (probably chosen to account for floating-point error). As this check is not truly exhaustive and the thresholds have been fixed somewhat arbitrarily, it’s not very significant, but it acts as a nice “sanity check” for the theory.

⊕Distance between final layer and intermediate layer outputs for the “exhaustive” check on input prompts. All are significantly above the collision threshold as defined in the paper.

The second practical experiments is to exploit the injectivity result to build an algorithm to invert a language model. Starting from the last-layer activations, they build a simple gradient-guided search that reconstruct the input sequence of tokens. The results are impressive: they get 100% token-level accuracy on all prompts, and in a remarkably quick process. The following results are for the GPT-2 Small model:

Conclusion: rebuilding our intuition

Expressivity and regularization

Transformers (and neural networks in general) are very useful because they generalize very well. The class of learned functions needs to be very large to be as expressive as possible, but still constrained to avoid overfitting. The regularization built into our language models can be understood as properties of the functions they represent. Analytic functions are a class of very smooth, very regular functions, that have a lot of nice property, so it is no accident that they are very good targets of a machine learning algorithm.

Curse of dimensionality

The main result of the paper does not seem so unintuitive if its hypotheses are laid out clearly. What we have is a function with inputs on a discrete space (finite sequences on a finite vocabulary), and outputs in continuous, high-dimension vector space. Since the output space is so much larger, it would actually be very surprising that a non-pathological function makes several inputs “collapse” into a single high-dimension vector!

Moreover, there is an instance of the curse of dimensionality: if you draw two vectors with random directions in a high-dimension space, they will very probably be orthogonal (Vershynin 2018, sec. 3.3.3). High dimensions tend to “push everything to the edges” and so collisions become increasingly unlikely. So another way to see this result is that it is unintuitive only because probability on high-dimension vector spaces is in itself quite unintuitive!

References

This paper (Liu et al. 2024) proposes an alternative to multi-layer perceptrons (MLPs) in machine learning.

The basic idea is that MLPs have parameters on the nodes of the computation graph (the weights and biases on each cell), and that KANs have the parameters on the edges. Each edge has a learnable activation function parameterized as a spline.

The network is learned at two levels, which allows for “adjusting locally”:

• the overall shape of the computation graph and its connexions (external degrees of freedom, to learn the compositional structure),
• the parameters of each activation function (internal degrees of freedom).

It is based on the Kolmogorov-Arnold representation theorem, which says that any continuous multivariate function can be represented as a sum of continuous univariate functions. We recover the distinction between the compositional structure of the sum and the structure of each internal univariate function.

The theorem can be interpreted as two layers, and the paper then generalizes it to multiple layer of arbitrary width. In the theorem, the univariate functions are arbitrary and can be complex (even fractal), so the hope is that allowing for arbitrary depth and width will allow to only use splines. They derive an approximation theorem: when replacing the arbitrary continuous functions of the Kolmogorov-Arnold representation with splines, we can bound the error independently of the dimension. (However there is a constant which depends on the function and its representation, and therefore on the dimension…) Theoretical scaling laws in the number of parameters are much better than for MLPs, and moreover, experiments show that KANs are much closer to their theoretical bounds than MLPs.

KANs have interesting properties:

• The splines are interpolated on grid points which can be iteratively refined. The fact that there is a notion of “fine-grainedness” is very interesting, it allows to add parameters without having to retrain everything.
• Larger is not always better: the quality of the reconstruction depends on finding the optimal shape of the network, which should match the structure of the function we want to approximate. Finding this optimal shape is found via sparsification, pruning, and regularization (non-trivial).
• We can have a “human in the loop” during training, guiding pruning, and “symbolifying” some activations (i.e. by recognizing that an activation function is actually a cos function, replace it directly). This symbolic discovery can be guided by a symbolic system recognizing some functions. It’s therefore a mix of symbolic regression and numerical regression.

They test mostly with scientific applications in mind: reconstructing equations from physics and pure maths. Conceptually, it has a lot of overlap with Neural Differential Equations (Chen et al. 2018; Ruthotto 2024) and “scientific ML” in general.

There is an interesting discussion at the end about KANs as the model of choice for the “language of science”. The idea is that LLMs are important because they are useful for natural language, and KANs could fill the same role for the language of functions. The interpretability and adaptability (being able to be manipulated and guided during training by a domain expert) is thus a core feature that traditional deep learning models lack.

There are still challenges, mostly it’s unclear how it performs on other types of data and other modalities, but it is very encouraging. There is also a computational challenges, they are obviously much slower to train, but there has been almost no engineering work on them to optimize this, so it’s expected. The fact that the operations are not easily batchable (compared to matrix multiplication) is however worrying for scalability to large networks.

References

This article (PDF) by Nick Trefethen in the London Mathematical Society Newsletter demonstrates an interesting relationship between what we perceive as “randomness” and what we perceive as “certainty”.

There are many ways to generate pseudo-random numbers that look perfectly “random” but are actually the output of fully deterministic processes. Trefethen gives an example of a chaotic system based on a logistic equation.

But more interesting (to me) and more original may be the other way around: how to get certainty from randomness. There are ordinary differential equations that can take random noise as input, and whose solution is very stable, oscillating between two possible values. Given a function \(f\) approximating random white noise, the solution to the ODE \[ y' = y - y^3 + Cf(t) \] is “bistable” and remains always around -1 and 1. The parameter \(C\) allows to control the half-life of the transitions.

To explore this behaviour, I replicated Trefethen’s experiments in Python with the Diffrax library (a differential equations solver based on JAX). The full code is in this Gist.

It suffices to define a simple function for the vector field and to give it to a solver:

def f(t, y, args):
    return y - y**3 + 0.4 * args[t.astype(int)]

where args will be the input, as a simple array of normally-distributed random values. \(C\) is hardcoded as 0.4 as in the article, but could be passed through args as well (it can be a dictionary).

Dietterich (2018) is an interesting article about how to make robust AI. High risk situations require the combined AI and human system to operate as a high reliability organization (HRO). Only such an organization can have sufficiently strong safety and reliability properties to ensure that powerful AI systems will not amplify human mistakes.

Reliability and high-reliability organizations

The concept of high reliability organization (HRO) comes from Weick, Sutcliffe, and Obstfeld (1999). Examples of HROs include nuclear power plants, aircraft carriers, air traffic control systems, and space shuttles. They share several characteristics: an unforgiving environment, vast potential for error, and dramatic scales in the case of a failure.

The paper identifies five processes common to HROs, that they group into the concept of mindfulness (a kind of “enriched awareness”). Mindfulness is about allocating and conserving attention of the group. It includes both being consciously aware of the situation and acting on this understanding.

This mindfulness leads to the capacity to discover and manage unexpected events, which in turn leads to reliability.

Characteristics of a high reliability organization

An HRO is an organization with the following five attributes.

Preoccupation with failure

Failures in HROs are extremely rare. To make it easier to learn from them, the organization has to broaden the data set by expanding the definition of failure and studying all types of anomalies and near misses. Additionally, the analysis is much richer, and always considers the reliability of the entire system, even for localized failures.

HROS also study the absence of failure: why it didn’t fail, and the possibility that no flaws were identified because there wasn’t enough attention to potential flaws.

To further increase the number of data point to study, HROs encourage reporting all mistakes and anomalies by anyone. Contrary to most organizations, members are rewarded for reporting potential failures, even if their analysis is wrong or if they are responsible for them. This creates an atmosphere of “psychological safety” essential for transparency and honesty in anomaly reporting.

Reluctance to simplify interpretations

HROs avoid having a single interpretation for a given event. They encourage generating multiple, complex, contradicting interpretations for every phenomenon. These varied interpretations enlarge the number of concurrent precautions. Redundancy is implemented not only via duplication, but via skepticism of existing systems.

People are encouraged to have different views, different backgrounds, and are re-trained often. To resolve the contradictions and the oppositions of views, interpersonal and human skills are highly valued, possibly more than technical skills.

Sensitivity to operations

HROs rely a lot on “situational awareness”. They are ensuring that no emergent phenomena emerge in the system: all outputs should always be explained by the known inputs. Otherwise, there might be other forces at work that need to be identified and dealt with. A small group of people may be dedicated to this awareness at all times.

Commitments to resilience

HROs train people to be experts at combining all processes and events to improve their reactions and their improvisation skills. Everyone should be an expert at anticipating potential adverse events, and managing surprise. When events get outside normal operational boundaries, organizations members self-organize into small dedicated teams to improvise solutions to novel problems.

Underspecification of structures

There is no fixed reporting path, anyone can raise an alarm and halt operations. Everyone can take decisions related to their technical expertise. Information is spread directly through the organization, so that people with the right expertise are warned first. Power is delegated to operation personal, but management is completely available at all times.

HROs vs non-HROs

Non-HROs increasingly exhibit some properties of HROs. This may be due to the fact that highly competitive environments with short cycles create unforgiving conditions (high performance standards, low tolerance for errors). However, most everyday organizations do not put failure at the heart of their thinking.

Failures in non-HROs come from the same sources: cultural assumptions on the effectiveness or accuracy of previous precautions measures.

Preoccupation with failure also reveal the couplings and the complex interactions in the manipulated systems. This in turn leads to uncoupling and less emergent behaviour over time. People understand better long-term, complex interactions.

Reliability vs performance, and the importance of learning

An interesting discussion is around the (alleged) trade-off between reliability and performance. It is assumed that HROs put the focus on reliability at the cost of throughput. As a consequence, it may not make sense for ordinary organizations to put as much emphasis on safety and reliability, as the cost to the business may be prohibitive.

However, investments in safety can also be viewed as investments in learning. HROs view safety and reliability as a process of search and learning (constant search for anomalies, learning the interactions between the parts of a complex system, ensuring we can link outputs to known inputs). As such, investments in safety encourage collective knowledge production and dissemination.

Mindfulness also stimulates intrinsic motivation and perceptions of efficacy and control, which increase individual performance. (People who strongly believe they are in control of their own output are more motivated and more efficient.)

HROs may encourage mindfulness based on operational necessity in front of the catastrophic consequences of any failure, but non-HROs can adopt the same practice to boost efficiency and learning to gain competitive advantage.

Additional lessons that can be learned from HROs (implicit in the previous discussion):

1. The expectation of surprise is an organizational resource because it promotes real-time attentiveness and discovery.
2. Anomalous events should be treated as outcomes rather than accidents, to encourage search for sources and causes.
3. Errors should be made as conspicuous as possible to undermine self-deception and concealment.
4. Reliability requires diversity, duplication, overlap, and a varied response repertoire, whereas efficiency requires homogeneity, specialization, non-redundancy, and standardization.
5. Interpersonal skills are just as important in HROs as are technical skills.

References

This is a short overview of the following paper (Kloss, Martius, and Bohg 2021):

Kloss, Alina, Georg Martius, and Jeannette Bohg. 2021. “How to Train Your Differentiable Filter.” Autonomous Robots 45 (4): 561–78. https://doi.org/10.1007/s10514-021-09990-9.

Bayesian filtering for state estimation

Bayesian filters⊕(Thrun 2006) contains a great explanation of Bayesian filters (including Kalman and particle filters), in the context of robotics, which is relevant for this paper. For a more complete overview of Kalman filters, see (Anderson and Moore 2005).

are the standard method for probabilistic state estimation. Common examples are (extended, unscented) Kalman filters and particle filters. These filters require a process model predicting how the state evolves over time, and an observation model relating an sensor value to the underlying state.

The objective of a filter for state estimation is to estimate a latent state \(\mathbf{x}\) of a dynamical system at any time step \(t\) given an initial belief \(\mathrm{bel}(\mathbf{x}_0) = p(\mathbf{x}_0)\), a sequence of observations \(\mathbf{z}_{1\ldots t}\), and controls \(\mathbf{u}_{0\ldots t}\).

We make the Markov assumption (i.e. states and observations are conditionally independent from the history of past states).

\[ \begin{align*} \mathrm{bel}(\mathbf{x}_t) &= \eta p(\mathbf{z}_t | \mathbf{x}_t) \int p(\mathbf{x}_t | \mathbf{x}_{t-1}, \mathbf{u}_{t-1}) \mathrm{bel}(\mathbf{x}_{t-1}) d\mathbf{x}_{t-1}\\ &= \eta p(\mathbf{z}_t | \mathbf{x}_t) \overline{\mathrm{bel}}(\mathbf{x}_t), \end{align*} \]

where \(\eta\) is a normalization factor. Computing \(\overline{\mathrm{bel}}(\mathbf{x}_t)\) is the prediction step, and applying \(p(\mathbf{z}_t | \mathbf{x}_t)\) is the update step (or the observation step).

We model the dynamics of the system through a process model \(f\) and an observation model \(h\):

\[ \begin{align*} \mathbf{x}_t &= f(\mathbf{x}_{t-1}, \mathbf{u}_{t-1}, \mathbf{q}_{t-1})\\ \mathbf{z}_t &= h(\mathbf{x}_t, \mathbf{r}_t), \end{align*} \] where \(\mathbf{q}\) and \(\mathbf{r}\) are random variables representing process and observation noise, respectively.

Differentiable Bayesian filters

These models are often difficult to formulate and specify, especially when the application has complex dynamics, with complicated noises, nonlinearities, high-dimensional state or observations, etc.

To improve this situation, the key idea is to learn these complex dynamics and noise models from data. Instead of spending hours in front of a blackboard deriving the equations, we could give a simple model a lot of data and learn the equations from them!

In the case of Bayesian filters, we have to define the process, observation, and noise processes as parameterized functions (e.g. neural networks), and learn their parameters end-to-end, through the entire apparatus of the filter. To learn these parameters, we will use the simplest method: gradient descent. Our filter have to become differentiable.

The paper shows that such differentiable filters (trained end-to-end) outperform unstructured LSTMs, and outperform standard filters where the process and observation models are fixed in advance (i.e. analytically derived or even trained separately in isolation).

In most applications, the process and observation noises are often assumed to be uncorrelated Gaussians, with zero mean and constant covariance (which is a hyperparameter of the filter). With end-to-end training, we can learn these parameters (mean and covariance of the noise), but we can even go further, and use heteroscedastic noise models. In this model, the noise can depend on the state of the system and the applied control.

Learnable process and observation models

The observation model \(f\) can be implemented as a simple feed-forward neural network. Importantly, this NN is trained to output the difference between the next and the current state (\(\mathbf{x}_{t+1} - \mathbf{x}_t\)). This ensure stable gradients and an easier initialization near the identity.

For the observation model, we could do the same and model \(g\) as a generative neural network predicting the output of the sensors. However, the observation space is often high-dimensional, and the network is thus difficult to train. Consequently, the authors use a discriminative neural network to reduce the dimensionality of the raw sensory output.

Learnable noise models

In the Gaussian case, we use neural networks to predict the covariance matrix of the noise processes. To ensure positive-definiteness, the network predicts an upper-triangular matrix \(\mathbf{L}_t\) and the noise covariance matrix is set to \(\mathbf{Q}_t = \mathbf{L}_t \mathbf{L}_t^T\).

In the heteroscedastic case, the noise covariance is predicted from the state and the control input.

Loss function

We assume that we have access to the ground-truth trajectory \(\mathbf{x}_{1\ldots T}\).

We can then use the mean squared error (MSE) between the ground truth and the mean of the belief:

\[ L_\mathrm{MSE} = \frac{1}{T} \sum_{t=0}^T (\mathbf{x}_t - \mathbf{\mu}_t)^T (\mathbf{x}_t - \mathbf{\mu}_t). \]

Alternatively, we can compute the negative log-likelihood of the true state under the belief distribution (represented by a Gaussian of mean \(\mathbf{\mu}_t\) and covariance \(\mathbf{\Sigma}_t\)):

\[ L_\mathrm{NLL} = \frac{1}{2T} \sum_{t=0}^T \log(|\mathbf{\Sigma}_t|) + (\mathbf{x}_t - \mathbf{\mu}_t)^T \mathbf{\Sigma}^{-1} (\mathbf{x}_t - \mathbf{\mu}_t). \]

Implementation issues

We need to implement the filters (EKF, UKF, PF) in a differentiable programming framework. The authors use TensorFlow. Their code is available on GitHub.

Some are easy because they use only differentiable operations (mostly simple linear algebra). For the EKF, we also need to compute Jacobians. This can be done automatically via automatic differentiation, but the authors have encountered technical difficulties with this (memory consumption or slow computations), so they recommend computing Jacobians manually.It is not clear whether this is a limitation of automatic differentiation, or of their specific implementation with TensorFlow. Some other projects have successfully computed Jacobians for EKFs with autodiff libraries, like GaussianFilters.jl in Julia.

The particle filter has a resampling step that is not differentiable: the gradient cannot be propagated to particles that are not selected by the sampling step. There are apparently specific resampling algorithms that help mitigate this issue in practice when training.

Conclusions

Differentiable filters achieve better results with fewer parameters than unstructured models like LSTMs, especially on complex tasks. The paper runs extensive experiments on various toy models of various complexity, although unfortunately no real-world application is shown.

Noise models with full covariance improve the tracking accuracy. Heteroscedastic noise models improve it even more.

The main issue is to keep the training stable. They recommend the differentiable extended Kalman filter for getting started, as it is the most simple filter, and is less sensitive to hyperparameter choices. If the task is strongly non-linear, one should use a differentiable unscented Kalman filter or a differentiable particle filter.

References

Mumford, David. 2000. “The Dawning of the Age of Stochasticity.” Atti Della Accademia Nazionale Dei Lincei. Classe Di Scienze Fisiche, Matematiche E Naturali. Rendiconti Lincei. Matematica E Applicazioni 11: 107–25. http://eudml.org/doc/289648.

This article (Mumford 2000) is an interesting call for a new set of foundations of mathematics on probability and statistics. It argues that logic has had its time, and now we should make random variables a first-class concept, as they would make for better foundations.

The taxonomy of mathematics

⊕This is probably the best definition of mathematics I have seen. Before that, the most satisfying definition was “mathematics is what mathematicians do”. It also raises an interesting question: what would the study of non-reproducible mental objects be?

The study of mental objects with reproducible properties is called mathematics. (Davis, Hersh, and Marchisotto 2012)

What are the categories of reproducible mental objects? Mumford considers the principal sub-fields of mathematics (geometry, analysis, algebra, logic) and argues that they are indeed rooted in common mental phenomena.

Of these, logic, and the notion of proposition, with an absolute truth value attached to it, was made the foundation of all the others. Mumford’s argument is that instead, the random variable is (or should be) the “paradigmatic mental object”, on which all others can be based. People are constantly weighing likelihoods, evaluating plausibility, and sampling from posterior distributions to refine estimates.

As such, random variables are rooted in our inspection of our own mental processes, in the self-conscious analysis of our minds. Compare to areas of mathematics arising from our experience with the physical world, through our perception of space (geometry), of forces and accelerations (analysis), or through composition of actions (algebra).

The paper then proceeds to do a quick historical overview of the principal notions of probability, which mostly mirror the detailed historical perspective in (Hacking 2006). There is also a short summary of the work into the foundations of mathematics.

Mumford also claims that although there were many advances in the foundation of probability (e.g. Galton, Gibbs for statistical physics, Keynes in economics, Wiener for control theory, Shannon for information theory), most important statisticians (R. A. Fisher) insisted on keeping the scope of statistics fairly limited to empirical data: the so-called “frequentist” school. (This is a vision of the whole frequentist vs Bayesian debate that I hadn’t seen before. The Bayesian school can be seen as the one who claims that statistical inference can be applied more widely, even to real-life complex situations and thought processes. In this point of view, the emergence of the probabilistic method in various areas of science would be the strongest argument in favour of bayesianism.)

What is a “random variable”?

Random variables are difficult to define. They are the core concept of any course in probability of statistics, but their full, rigorous definition relies on advanced measure theory, often unapproachable to beginners. Nevertheless, practitioners tend to be productive with basic introductions to probability and statistics, even without being able to formulate the explicit definition.

Here, Mumford discusses the various definitions we can apply to the notion of random variable, from an intuitive and a formal point of view. The conclusion is essentially that a random variable is a complex entity that do not easily accept a satisfying definition, except from a purely formal and axiomatic point of view.

This situation is very similar to the one for the notion of “set”. Everybody can manipulate them on an intuitive level and grasp the basic properties, but the specific axioms are hard to grasp, and no definition is fully satisfying, as the debates on the foundations of mathematics can attest.

Putting random variables into the foundations

The usual way of defining random variables is:

1. predicate logic,
2. sets,
3. natural numbers,
4. real numbers,
5. measures,
6. random variables.

Instead, we could put random variables at the foundations, and define everything else in terms of that.

There is no complete formulation of such a foundation, nor is it clear that it is possible. However, to make his case, Mumford presents two developments. One is from E. T. Jaynes, who has a complete formalism of Bayesian probability from a notion of “plausibility”. With a few axioms, we can obtain an isomorphism between an intuitive notion of plausibility and a true probability function.

The other example is a proof that the continuum hypothesis is false, using a probabilistic argument, due to Christopher Freiling. This proof starts from a notion of random variable that is incompatible with the usual definition in terms of measure theory. However, this leads Mumford to question whether a foundation of mathematics based on such a notion could get us rid of “one of the meaningless conundrums of set theory”.

Stochastic methods have invaded classical mathematics

This is probably the most convincing argument to give a greater importance to probability and statistical methods in the foundations of mathematics: there tend to be everywhere, and extremely productive. A prime example is obviously graph theory, where the “probabilistic method” has had a deep impact, thanks notably to Erdős. (See (Alon and Spencer 2016) and Timothy Gowers’ lessons at the Collège de FranceIn French, but see also his YouTube channel.

on the probabilistic method for combinatorics and number theory.) Probabilistic methods also have a huge importance in the analysis of differential equations, chaos theory, and mathematical physics in general.

Thinking as Bayesian inference

I think this is not very controversial in cognitive science: we do not think by composing propositions into syllogisms, but rather by inferring probabilities of certain statements being true. Mumford illustrates this very well with an example from Judea Pearl, which uses graphical models to represent thought processes. There is also a link with formal definitions of induction, such as PAC learning, which is very present in machine learning.

I’ll conclude this post by quoting directly the last paragraph of the article:

My overall conclusion is that I believe stochastic methods will transform pure and applied mathematics in the beginning of the third millennium. Probability and statistics will come to be viewed as the natural tools to use in mathematical as well as scientific modeling. The intellectual world as a whole will come to view logic as a beautiful elegant idealization but to view statistics as the standard way in which we reason and think.

References