I worked with GiNaC https://www.ginac.de/ and noticed that the bottleneck was variable substitutions, e.g., replace a variable with a constant and simplify the expression. I'm still dreaming of an efficient CAS.
https://github.com/dsharlet/ComputerAlgebra (disclaimer: my project) might do what you want, it lets you manipulate expressions and then compile them to "native" .net functions that can be evaluated with high performance.
Thanks! I'll have a look at it for sure. During my phd I developed a tool for reachability analysis of polynomial dynamical systems https://github.com/dreossi/sapo I needed expression manipulation to compute Bernestein coefficients of polynomials
I wrote a simple algebra system in C# [1] that uses term rewriting expressed as algebraic identities to simplify terms. You can then compile them to .NET functions for efficient execution.
It uses a recursion limit, but I sketched out a design that eliminates the need for it by use of a specific data structure as used in the Simplify theorem prover to ensure termination in the presence of rewriting. Haven't gotten around to it unfortunately.
The author of this is my friend, I told him as most of his projects has no licenses. He's going to add them soon, my hunch says it will be MIT, meanwhile feel free to open issue in the repo to tell him.
Suppose I find a paper submitted to a conference. The conference lets me download the original latex source of the paper. If I want to take the function they wrote out and take the derivative of it I'd currently have to rewrite the expression. Unfortunately this is very risky with extremely large and complex functions. Ideally it would be cool to just copy a latex expression into your "SymbolicVariable.Parse" method and tell it that it's written in LaTeX.
Copy and paste has a much lower chance to incur errors than rewriting an expression.
well I think that would be another layer before sending this to parser
so we can convert the latex expression and send it to the library after that .. I guess it is doable if we are limiting ourself to the math expressions only.
My hard-earned lesson is that representation and manipulation should not be commingled. Traditional mathematical notation is too irregular and idiosyncratic to be safely handled by a symbolic mathematics system. That’s part of the reason why a trained eye can almost always spot the output of a CAS because though correct it almost always expresses stuff in vaguely ’mechanistic’ and/or longwinded ways.
Mentioned elsewhere: I built an (incomplete) implementation of the Risch algorithm for symbolic integration and slapped a MathML-parsing front end on it, and frequently ran into ambiguous cases where the ”abstract syntax” of the purported integral wasn’t what any sane human mathematician would think it could be, yet these errors were self-consistent (limits on double- and higher integrals being circumstances that constantly vexed me).
No, don’t suggest or try doing both of these things in the same place. Keep them separate. It’s just basic software architecture.
Trying to support cool MathML syntax (and failing) in my (partial) implantation for symbolic integration using the Risch algorithm got me banned on Twitter by Nassim Nicholas Taleb. True story.