[HN Gopher] Show HN: SymDerive - A functional, stateless symboli...
       ___________________________________________________________________
        
       Show HN: SymDerive - A functional, stateless symbolic math library
        
       Hey HN,  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 "Pipe"
       approach (Cleaner for agents, readable for humans)       result = (
       Pipe((x + 1)**3)           .then(Expand)           .then(Simplify)
       .value       )       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
        
       Author : dinunnob
       Score  : 21 points
       Date   : 2026-02-01 01:20 UTC (3 days ago)
        
       | OutOfHere wrote:
       | 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.
        
         | cl3misch wrote:
         | 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
         | from pylab import *
         | 
         | in scripts that only I will ever see. It makes it so much
         | easier to use numpy in a "tool of thought" way. I would never
         | do this in a library, though.
        
           | OutOfHere wrote:
           | Two wrongs don't make a right. It risks significant ambiguity
           | in longer snippets or files, and is therefore bad practice.
        
         | marcelbundle wrote:
         | You would be suprised on how many large scale project I saw
         | this beauty lamao, not saying that this is okay, people just
         | dgaf
        
       | viraptor wrote:
       | > The "Pipe" approach (Cleaner for agents
       | 
       | How did you verify the benefit?
        
       ___________________________________________________________________
       (page generated 2026-02-04 23:01 UTC)