Show HN: SymDerive – A functional, stateless symbolic math library
15 comments
Here's a blog post where symderive was used with Claude Code's team agent framework to recast Fischer's early work in a modern language:
https://dinunno.substack.com/p/transforming-fisher-an-agenti...
https://dinunno.substack.com/p/transforming-fisher-an-agenti...
This looks wonderful, I've dreamt of something like this back when I was in academia!
You mention some advanced stuff like abstract index notation which is usually the hardest part to get right with things like simpy and even mathematica, how does your package handle simplifications of complex tensor expressions (GR, hydrodynamics, etc.)?
You mention some advanced stuff like abstract index notation which is usually the hardest part to get right with things like simpy and even mathematica, how does your package handle simplifications of complex tensor expressions (GR, hydrodynamics, etc.)?
You can specify symmetry/antisymmetry patterns for tensor index slots and it takes advantage of that to speed up the calculations. This part was pretty important for me so i spent some time thinking about it. I wanted to try to put xACT’s patterns in but it would have been quite the undertaking.
It could definitely be better though
Please never use `from something import *`, not even for a demo. It is not explicit, not maintainable, and goes against all Python guidelines. Certainly never expect any user to use it either.
FWIW the afaik most common symbolic math Python library sympy does that on the first page of their tutorial. I think in this space it's pretty common.
https://docs.sympy.org/latest/tutorials/intro-tutorial/intro...
I have to admit that I still like to use the ancient
https://docs.sympy.org/latest/tutorials/intro-tutorial/intro...
I have to admit that I still like to use the ancient
from pylab import *
Two wrongs don't make a right. It risks significant ambiguity in longer snippets or files, and is therefore bad practice.
Yeah, you’re not wrong. Makes the syntax a bit annoying here (goal was to lower barrier of entry for physicists). I agree this is bad practice.
In the limiting sense, especially when a user mixes your snippet with snippets from other packages, the barrier of entry becomes greater due to the resolution ambiguity, not less.
fixed in the readme. thanks -
while we are talking imports ... how did `import pyspark.sql.functions as F` ever get past the pep police
while we are talking imports ... how did `import pyspark.sql.functions as F` ever get past the pep police
You would be suprised on how many large scale project I saw this beauty lamao, not saying that this is okay, people just dgaf
> The "Pipe" approach (Cleaner for agents
How did you verify the benefit?
How did you verify the benefit?
I’m a physicist turned quant. Some friends and I 'built' SymDerive because we wanted a symbolic math library that was "Agent-Native" by design, but still a practical tool for humans.
It boils down to two main goals:
1. Agent Reliability: I’ve found that AI agents write much more reliable code when they stick to stateless, functional pipelines (Lisp-style). It keeps them from hallucinating state changes or getting lost in long procedural scripts. I wanted a library that enforces that "Input -> Transform -> Output" flow by default.
2. Easing the transition to Python: For many physicists, Mathematica is the native tongue. I wanted a way to ease that transition—providing a bridge that keeps the familiar syntax (CamelCase, Sin, Integrate) while strictly using the Python scientific stack under the hood.
What I built: It’s a functional wrapper around the standard stack (SymPy, PySR, CVXPY) that works as a standalone engine for anyone—human or agent—who prefers a pipe-based workflow.
The "Vibes" features:
Wolfram Syntax: Integrate, Det, Solve. If you know the math, you know the API.
Modular: The heavy stuff (Symbolic Regression, Convex Optimization) are optional installs ([regression], [optimize]). It won’t bloat your venv unless you ask it to.
Physics stuff: I added tools I actually use—abstract index notation for GR, Kramers-Kronig for causal models, etc.
It’s definitely opinionated, but if you’re building agents to do rigorous math, or just want a familiar functional interface for your own research, this might help.
I have found that orchestrators (Claude Code, etc) are fairly good at learning the tools and sending tasks to the right persona, we have been surprised by how well it has worked.
Repo here: https://github.com/closedform/deriver
I will cry if roasted too hard