symengine VS reduce-algebra

SymEngine will do this: https://github.com/symengine/symengine

If you need programmability or interoperability, Sympy is way nicer. If you just want an interactive symbolic calculator, Maxima is fine but sometimes quirky (has odd conventions due mainly to its age). As heisig points out, Maxima can be quite a bit faster (but I run into slow things with it too). Using Maxima via Sage is in some ways the best of both worlds.

You may also be interested in SymEngine: https://github.com/symengine/symengine

Context: I'm making a application for robotics calculations, making symbolic calculations using (symengine), and at some point I would like to be able to see the steps of these calculations, symengine has a function that returns the latex code do the elements you want. So I was trying to find a library or something of sorts to render that text into an image, I'm using Dear IMGUI in the docking branch to make a simple UI where I would like to display these equations. I know it might not even exists but I would like to give it a try. I found KLateXFormula, which depends on Qt as far as I understood, so I would like to avoid that if possible, I also studied a bit about the TeXStudio repo and found they use Qt to render previews. I also tried to understand the miktex repo searching for a function that I could use, but I barely understood the structure of the repo. I'm getting frustraded. I also found approaches where people would call latex executables to parse latex to DVI(Or something like this) but I would also like to avoid this approaches if possible.

- Might there be any way to leverage the work of https://github.com/symengine/symengine ? I assume a straight-up language binding to symengine might be a completely separate project, but possibly for some specific features symengine, maybe... (It is a pity they chose c++ and not rust to implement symengine in. In the end, the main target seems python/sympy here and not c++.)

Usually the arguments are a) it provides runtime access to the source (which for example is useful in R), b) runtime introspection is easier to understand (for the proponents) and c) macros are too static (they want more flexibility at runtime). For example authors of the REDUCE computer algebra system disliked Common Lisp for the lack of FEXPRs and that's why they stayed away from it: https://reduce-algebra.sourceforge.io/ .

> The languages you mention probably

No, see above.

Reduce is another lisp based computer algebra system from the prehistoric times, now open sourced.

https://en.wikipedia.org/wiki/Reduce_(computer_algebra_syste...

https://reduce-algebra.sourceforge.io/

I paid money for a Reduce release for RISCOS back in the last ice age. I recollect having to register my licence with the Rand Corporation for some reason.

I idly wonder how these compare to the arbitrary-precision implementations in REDUCE (https://github.com/reduce-algebra/reduce-algebra/blob/master...) - written mostly by me, 30 years ago in the unusual, Lisp-based but largely procedural, language of REDUCE. Can't remember much about the subject now.

The citations in the Julia source file are certainly newer - Abramowitz and Stegun was basically all I had.

I think the REDUCE functions were considered quite fast (for higher precision) at the time, but it was certainly true that they weren't tested as thoroughly as would be the norm now.