A nice little diagram from my latest post on Smoothness (eriksfunhouse.com/writings/s…), showing how two different domains of learning learns differently at different phases of learning(say that quickly twice).

Wrote my previous post up as an article as well! First one ever - thought I would give it a go and see how it goes! x.com/arnovicher/status/2042…

Is the difficulty of solving differential equations a law of nature? It certainly seems so those unfortunate ones of us who have had to do it! And I have done a little bit of writing on the topic that I thought might be interesting to share. With the help of ☀️, Claude Code and a few holidays, I have gotten back into some of my old research topics around dynamical systems, category theory and simulations. As part of that of that I have been building a new typed compositional language for dynamical systems, based on research that goes 20 years back to my PhD under Prof Ursula Martin. I am calling it Gimle (gimlelabs.com). As I work on Gimle, I keep discovering new side-quests, some of which I then turn into working papers or notes: gimlelabs.com/papers/ One of these was to try to better understand the difficulty of finding solutions to dynamical systems and the link between this and reasoning about the termination of loops in programs. The gist of the link goes like this: When we describe dynamical systems in the terms of category theory, we compose them from a set of atomic operations, like integrators, adders, and multipliers, and we then compose using the structure of a traced monoidal category. Feedback then creates differential equations. In programming, we likewise compose programs from atomics, sequential and parallel composition and feedback. Both form traced monoidal categories. Trace = differential = programmatic loops. In both worlds, the "hard to solve" objects are the ones with trace. The "solved" objects are trace-free. A trace-free dynamical system is a closed-form solution, no iteration needed. A trace-free program is a straight-line program, no loops. In both cases, "Solving" the system or program means eliminating the trace. The bridge between these two already exists going back to Bainbridge (1972), and extended as part of my PhD project. Through this work we have a formal trace-preserving mapping from these two worlds into a common program logic, based on Hoare Logic. Since this mapping preserves trace, trace elimination on either side projects to the same problem in the middle. This reframes "closed-form solvability" as a definability question: does the implicit function defined by the fixed point lie in your vocabulary of elementary functions? f' = f is solvable if {exp} is in your vocabulary. ∫e^(-x²)dx is not if you only have elementary functions. Same question on the program side — does your loop have a formula? `for i in 1..n: s = i` → `s = n(n 1)/2` ✓ `for i in 1..n: s = f(i)` → ??? (generally no) Now it gets interesting. Trace elimination for programs is undecidable, it reduces to the halting problem. A loop has a closed-form replacement iff the computation terminates. The categorical bridge transfers this to the continuous side: determining whether an ODE has a closed-form solution is also undecidable. This formalises something most mathematician intuitively feels: "most differential equations can't be solved in closed form." It's not just that we haven't found the right tricks. The impossibility is structural, connected to the halting problem not by analogy, but by traced monoidal functors. The deeper view comes from Bainbridge's coalgebra/algebra duality. Traced morphisms are coalgebraic: they describe systems dynamically, via feedback. Trace-free morphisms are algebraic: they describe systems statically, via direct expressions. "Solving" is the action of mapping from coalgebra to algebra. Still a lot of hand-waving around this, but I thought it was such an interesting observation that I wrote it up. It is also the basis for another, more powerful, side-quest, that I call Simulation Learning. The idea being that perhaps to find these closed form solutions we need to be able to temporarily branch out and weaken the strict logic of our proofs to perform non-trivial trace-elimination that then inform the main proof. Anyway, more on that later :) If you are interested, here is the a short blog write-up and a link to the pdf note: "Trace Elimination as Closed-Form Discovery: A Duality Between Dynamical Systems and Programs" gimlelabs.com/papers/trace-e… gimlelabs.com/assets/papers/…

Really enjoyable episode of the The Pragmatic Engineer by @GergelyOrosz with Grady Booch on the history of software engineering - great history lesson but my favourite part was the reference to Plato' Sophist! A mind blowing moment for me personally - never thought about that before! Now spent my whole morning just thinking about that and getting back into Plato 😄 The reference is to the part where "The Stranger from Elea", discusses Not Being and Being. The most famous quote from this part goes like this (in Jowett's translation): My notion would be, that anything which possesses any sort of power to affect another, or to be affected by another, if only for a single moment, however trifling the cause and however slight the effect, has real existence; and I hold that the definition of being is simply power. gutenberg.org/files/1735/173… The point The Stranger is making is that a thing exists only if it has the power to act, ie if an object cannot act then it does not exist. Mapping that back to Grady's point: we can't just talk about objects, we have to talk about their actions. Or in my world of computational theory and dynamical systems, we are arguing that we should view data not just as inanimate objects but always through the lens of the computations that generate and act on it. Simply measuring the world without understanding the process that created the measured property is pointless. So the bigger question Plato's is getting at: is the world best viewed as a collection of things with attributes or as a set of processes interacting with each other. Which, I guess, is really one of central question of the theory of computing, dynamical systems and computational theory in general.

Another nice thing I did this weekend was to build an “agent skill” for Hugin, which then allows me to use Claude Code as my main agent for building Hugin agents. github.com/gimlelabs/gimle-h… Still needs a lot more work but so now CC is my agent builder, kicking off sub-agents, building new Hugin agents, publishing them to a Github repo, then using them to do stuff etc. Given how mature/good CC is, this is much more powerful than the BabyHugin app I posted about yesterday. So I think this is my new goto way of working on a lot of things. I am very much considering now moving all of the Gimle stack (pde solvers, simulators, proof solvers and physics models) to Claude Code - basically having that as my interface for all Gimle science, instead of building a new IDE for it. Just clis and good interfaces and then CC on top. I now think that is the future for scientific flows, not Matlab style interfaces with some AI added.

To illustrate the pattern I mentioned earlier, of agents building agents, I built a new demo app, BabyHugin(github.com/gimlelabs/gimle-h…) - inspired by @babyAGI_ @yoheinakajima . BabyHugin tries to solve tasks by creating new agents if there isn’t already an agent/capability to solve the task. Here is a quick video of that in action, on the left is the console and on the right is the Hugin monitor, where you can see what is actually happening behind the scene. I asked BabyHugin to create an agent that can retrieve the weather for a given city. Once done I then asked it to run that agent. In the monitor you can see how it kicks off an `agent_builder` using a generic `launch_agent` tool that it has. The `agent_builder` agent then builds a new agent that can solve the given task of ‘given a city find the weather forecast’. It then runs that agent to see if it works, refines it, if needed, and then returns to me to ask what’s next.

One thing I have been playing around with in the last couple of evenings is an agent builder - a Hugin agent specialised in building Hugin agents! Gave me a few of those wow moments, where you see something so cool you just have to get out of your chair and go for a walk 😄 My favourite thing is to ask it to either build agents to analyse different types of financial data, or the weather or to build specialised coding agents and then just watch it in action. I really, really like the idea of having agents build their own sub-agents for new skills, which then leads to tools becoming agents, in a sense. In Hugin you have builtin `launch_agent` and `list_agents` tools, which then become the main interface for an agent - like tool exploration but now it is agent exploration! And if an agent is missing a “tool” it can just create it using the “agent builder” agent! SO now you have agents, searching for other specialised agents to perform certain tasks and then, if they don’t exist, they build new agents for that task - which are then discovered and used by other agents later... and so on... Also, since a Hugin agent is just a folder with a few sub-folders of yaml/python files you can easily share these via Github or similar, by just pointing it to a repo of agent configs. And all of this done by just one simpleton dude with a few evenings to spare - the future is truly here! 😄 (I'll post a video later, when time permits, of this pattern in action)

Hugin v0.1(Hugin..) is now out!! Simple framework for powerful agents! Originally I built it for reasoning about physical systems(coming soon!) but I liked it so much that I reworked it to be a general purpose agent framework - since I think it beats most other frameworks in terms of ease, versatility and multi-agent capabilities(especially!). It is based on some previous stuff I did on state machines models for agents eriksfunhouse.com/writings/s… Hopefully it will be interesting/useful to some! Will post a few cool examples next to show off what it can do! One nice little demo app in the repo is the "The Hugins" - an example of asynchronous exploring, acting and communicating in a isometric 3D world. hugin.gimlelabs.com/ github.com/gimlelabs/gimle-h…