Posts on Rado's Radical Reflections

Three Cultures of Math

rkirov@gmail.com — Fri, 08 May 2026 20:45:53 -0700

Recent advances in general models — ChatGPT and Claude — have started to autonomously solve open mathematical problems. For example, Erdős 1196, Tim Gowers’s PhD student problems, OpenAI’s Ramsey numbers result. There are a lot of caveats — were the problems widely enough studied, could the solutions be coming from some past human result, etc. But if one zooms out and considers the progression of AI capabilities, it is hard not to conclude that more and more open problems will be solvable by autonomous AI.

From Painfully Explicit to Implicit in Lean

rkirov@gmail.com — Sun, 12 Apr 2026 09:25:28 -0700

Note: AI was used to edit this post. As a proof-of-human thought and input, I am also publishing the original draft which was written fully before asking AI to edit the post with me.

This post is aimed at Lean language beginners that are interested in writing proofs in Lean, but still feel lost when reading Lean code.

A very simplified mental model of Lean is that at the core there are two systems:

Code Proven to Work - The Math Way

rkirov@gmail.com — Sun, 22 Mar 2026 17:25:24 -0700

This post is aimed at a general programmer and no prior knowledge of math or CS is assumed.

I got nerd-sniped to write this after reading Simon’s excellent post Code proven to work. As someone who works in the software industry that is adapting to using AI tools, the post was very timely and very well put. I agree with everything said, but I just can’t resist being that guy - bringing up the “you keep using that word” meme.

Human Intuition, AI Formalization: A Real Analysis Case Study

rkirov@gmail.com — Sun, 08 Mar 2026 23:35:37 -0700

Disclaimer - I wrote the core ideas; Claude helped flesh out and polish the article. See appendix for more on this.

This is a follow up to my previous post on leaning on Claude for Lean. I’ve now worked up to chapter 8.3 in Tao’s companion. The speed is great and Claude’s capabilities continue to impress (autoformalization is possible, but not my goal). I haven’t been stuck on anything so far. I’ve also upstreamed many typos to the companion repo.

From Sets in Math to Types in Lean: Subtype, Fin, Set, Finset, and Fintype

rkirov@gmail.com — Sat, 14 Feb 2026 20:54:04 -0800

Preface: Why All Mathematicians Should Learn Lean

LLMs can generate plausible-sounding proofs at unprecedented speed and scale. Some are correct, many are not, and LLMs themselves cannot reliably tell the difference. Humans can — but they don’t scale. Formal proof assistants like Lean do: they verify correctness mechanically and can serve as a backstop to the torrent of AI-generated mathematics.

This puts mathematicians at a fork. Either accept formal proofs as the verification layer, or reject all LLM-generated mathematics outright. The first path seems far more productive — but it requires mathematicians to read and write formalized math, at least well enough to verify that formal statements faithfully capture informal ones.

Leaning on AI

rkirov@gmail.com — Sun, 08 Feb 2026 21:16:11 -0800

It’s been five months since my last dedicated Lean post and as usual I have started to lose steam on Lean projects. After the thrill of discovering the world of formalized mathematics started to wear off, I did not find motivation to push as hard as before. The SF Math with Lean work group kept me vaguely connected (at least in the one hour a week we meet (see retro)) but other than that I wasn’t putting in more than a few hours a week on math and Lean.

Local Lean Workgroup Retro

rkirov@gmail.com — Sun, 01 Feb 2026 14:04:19 -0800

I started learning formalized mathematics with Lean last year 1, 2, 3, 4. As I progressed beyond basics, it dawned on me that I need to start interacting with the broader community as Lean is rapidly evolving and beyond basic getting started guides there aren’t as many high-quality resources to learn solo. It could also be a great way to meet folks with similar interests and build more social connections. To that end I tried to start a local workgroup around Oct'25 details. I have never done anything like this before, so this is a small retro of how it went so far (in Jan'26) and what’s next.

Is this JS function pure?

rkirov@gmail.com — Tue, 11 Nov 2025 20:18:26 -0800

In 2019, as functional programming was making the last inroads dethroning OOP, I kept hearing the mantra of “just use pure functions” in JS. Something didn’t sit right with me when talking very deterministically about pure functions in a large unpure language like JS. Especially, after seeing JS tooling perform optimizations based on a pure annotation (like webpack).

While everyone agrees x => x + 2 is pure, I felt there are a lot of subtle situations where disagreements might arise. What is worse than terms with imprecise meaning is terms with imprecise meaning where people using them are not aware there is imprecision.

Why formalize mathematics - more than catching errors

rkirov@gmail.com — Thu, 16 Oct 2025 22:32:49 -0700

I read a good post by one of the authors of the Isabelle theorem prover, that got me thinking. The author, Lawrence Paulson, observed that most math proofs are trivial, but writing them (preferably with a proof assistant) is a worthwhile activity, for reasons similar to safety checklists - “Not every obvious statement is true.”

As I have been a bit obsessed with doing formalized mathematics, this got me thinking about why I am excited to spend many hours recently writing formalized proofs in Lean for exercises from Tao’s Real Analysis (along with this recent attempt to write a companion to Riehl’s Category Theory In Context). On a very personal level, I just like math, computers and puzzles, and writing Lean proofs feels like doing all three at once. But I do believe formalization is important beyond nerd-snipping folks like me.

Learning Lean: Part 4

rkirov@gmail.com — Sat, 20 Sep 2025 07:54:08 -0700

It’s been 3 months since my previous post about learning Lean part 3, so it’s time to write another one. I have mostly continued to work through Tao’s Analysis book through his excellent companion - which means all proofs from the paper textbook are fully formalized in Lean, while examples and exercises are stated in Lean but left with a sorry for me to fill in. Altogether the companions has close to 2000 sorries to fill-in.

Learning Lean: Part 3

rkirov@gmail.com — Fri, 27 Jun 2025 22:30:30 -0700

I am continuing to learn Lean (see part 1 and part 2). I lost some steam around March-April, but in the last two months I picked it up again. In a way it was a nice spaced repetition for relearning some of the basics. This summary was supposed to be my notes from finishing the rest of Mathematics in Lean and finishing chapters 2 and 3 of exercises from Terence Tao’s Analysis textbook, but also I couldn’t help also comment on the challenges and opportunties I see in doing formal mathematics with Lean.

Thoughts on Signals in the JavaScript Ecosystem

rkirov@gmail.com — Sun, 30 Mar 2025 08:05:09 -0700

Around 5-8 years ago when working on Angular and TypeScript rules in Bazel, I got very interested in exploring the core ideas of incremental computation, which seemed like the right way to abstractly (but still precisely) describe the similarities between build systems and UI reactivity. As an aside, incremental dataflow is a third view into the same concept, but I am least familiar with it.

I wrote the following series of posts to try to pull all the different threads together. It was useful for me to put something to paper, but at the end I failed in painting a picture as clear as I wanted.

Learning Lean: Part 2

rkirov@gmail.com — Sun, 02 Mar 2025 07:14:48 -0800

I am continuing to learn Lean (see part 1) by going through Mathematics in Lean. These are my notes as I just finished chapters one through five.

Mathematics in Lean

The online book is well-paced and well-written to connect with what an average student of mathematics already knows. The focus is on learning how to do basic mathematical proofs in Lean, and the underlying language is taught as needed for those goals, in comparison to Theorem Proving in Lean which is more of a language guide. For example, the fact that naturals are constructed as an inductive type with zero and succ constructors is shown much after one is shown how to work with them. This is aligned with how a lot of mathematics is done before one discusses foundations in a typical mathematics curriculum, which might differ from a CS one.

Learning Lean: Part 1

rkirov@gmail.com — Tue, 11 Feb 2025 22:26:55 -0800

Motivation

I’ve been captivated by the recent movement to popularize mathematics formalization through the Lean theorem prover, and this year I’m diving deeper into learning it.

For those unfamiliar with this revolution, I highly recommend watching Kevin Buzzard’s talks on YouTube for an overview of why formal mathematics is generating such excitement in the mathematical community.

The immediate benefits of formalization are well-documented: it helps catch errors in proofs and reduces the need for trust between collaborators since every step is mechanically verified. However, I believe there’s another compelling advantage that’s less frequently discussed: formalization enables a better separation of concerns in mathematical writing.

Ticket to Ride: First Journey simulation authored with AI

rkirov@gmail.com — Sat, 18 Jan 2025 11:52:17 -0800

Ticket to Ride: First Journey simulation authored with AI

After playing Ticket to Ride: First Journey with my family recently, I got the urge to analyze some statistical properties of the game. This seemed like an excellent opportunity to experiment with Cursor AI and explore more automated approaches to coding. Here’s what I discovered.

Results

After a couple of hours the AI and I produced the following analyses:

The 32 tickets in the game can be categorized by their optimal paths:

Puzzle games of 2024

rkirov@gmail.com — Tue, 31 Dec 2024 11:42:13 -0800

As the year draws to a close, I want to share my favorite puzzle games from 2024. This isn’t meant to be an exhaustive review or ranking of all puzzle games released this year, but rather a personal reflection on the games that captured my attention. If you’re new to the puzzle genre, I recommend starting with the essential thinky games list - all of those titles are excellent.

Patrick’s Parabox

This game had been on my radar since its 2022 release, but I only got around to playing it this year. While the core mechanics of zooming in, zooming out, and recursion were fun and somewhat expected from the trailers, I was pleasantly surprised by the infinity paradoxes and creativity in the later levels. The developers really went the extra mile while staying true to the core concept, making the experience of completing the game thoroughly enjoyable.

Advent of Code 2024 Retro

rkirov@gmail.com — Wed, 25 Dec 2024 21:40:07 -0800

Advent of Code AoC is an annual programming competition that releases daily coding puzzles throughout December. For the past four years, I’ve tackled these challenges from the West Coast, where the 9 PM PST release time perfectly suits my schedule. While I compete for points on the global leaderboard (with modest success), the real joy comes from the community around it. Through Stripe’s solution-sharing Slack group, and the active r/adventofcode community, discussing creative approaches to challenging problems adds an new dimension to my favorite pastime - solving puzzles.

Incremental Computation (part 3)

rkirov@gmail.com — Tue, 19 May 2020 00:00:00 +0000

Why TypeScript?

Maybe you wondering why did I use TypeScript for this post. As it happens I have been working in the frond-end community in the last 8 years. My interest in incremental computation started by observing the similarities between some of the work I have done inside Angular’s “change detection” algorithms, and work I have done around integrating TypeScript’s compiler in Google’s build system.

UI programming

Why is incremental computation naturally appearing in UIs? As the user is interacting with an UI they are providing new inputs. Usually, these inputs are small compared with the initial input to the UI. On the other side the producing the DOM is the quintessential “expensive” computation. If it redone on each user input the UI will be unusable. So all UI frameworks attempt to solve the incremental computation problem, struggling with the fact that JS has no support for incremental computation. To make matters worse as we have seen incrementality is easier in a functional language, but JS is not well suited to that paradigm (which doesn’t stop people from trying).

Incremental Computation (part 2)

rkirov@gmail.com — Sun, 10 May 2020 00:00:00 +0000

We have been talking about general computation, but so far our language was very limited. We only used function calls, numbers, and simple variable binding.

We will slowly add more language primitives and see how to still have full incrementality of the computation.

Conditional statements

Let’s add a single conditional statement first.

function cond(b: boolean, x: number, y: number) {
  return b ? x * x : y * y; 
}

What does it mean to make cond incremental? Say we compute the result first for some values of b, x, y.

Incremental Computation (part 1)

rkirov@gmail.com — Sun, 03 May 2020 00:00:00 +0000

Incremental computation is a way of performing computations, with the expectation of future changes in the inputs to the computiation. When those changes occur the output can be updated efficiently, at minimum faster than redoing the whole computation from scratch.

This problem occurs in many programming domains - UI programming, data flow, build systems, compilers, code editors. Likely you have seen it before, but didn’t call it incremental computation. Despite its prevalence, it is rarely viewed as a common computational paradigm. It is more often referred to as an ad-hoc application of caching or memoization. In comparison, other computational paradigms like concurrent, lazy, distributed computation have better known nomenclature and techniques.