What is so awful about the license? Non-professionals can use it for free without core restrictions. Are you a professional?

Are you a hobbyist? If so, you can use all your cores for free. If you are a professional, there are also no core restrictions, but you have to get a paid license.

Currently hobbyist is the one that describes me the best. As I am no longer in academia. I did not know that there was a special hobbyist tier. The Academia Tier is realy a bit annoying because if you are a Student you do not have the pull to get a license for this even though you are affiliated.

Additionaly what was one of the reasons why I looked at Symbolica because I would have liked to implement it in for the backend in a FOSS (non Profit) project that I wanted to start back when I was still in Academia. My plans shifted though so Its unlikely I am gonna do it in the short term. But what I originaly wanted is a FOSS alternative to Mathcad. I needed a Symbolic Calculation tool that does the heavy lifting.

I saw this project before, nice work! What is your plan when it comes to the hard core algebra parts like multivariate polynomial factorization and cylindrical algebraic decomposition? These features require quite some complex mathematical code and it is tricky to get it correct, and to get it working fast. Do you want to use other libraries for this or do you want to implement this all yourself?

If you want to use Symbolica for some of these features, feel free to reach out!

Thanks! I'm hoping to use libraries for this, but unfortunately there aren't many available in Rust yet for those kinds of problems.

Integrating Symbolica would be awesome, but our licenses are incompatible at the moment. If you're willing to relicense parts for Woxi, I'd be happy to work on this together!

Nice, I will check this out in more detail later. I had a quick look at the benchmarks and it looks like you compare f64 hyperreal with numericas 128 bit implementation, which will fall back to using arb-prec GMP. There is also F64(simply wrapping around f64), and now DoubleFloat with 106 bits precision, which should be much faster. There is also the ErrorPropagatingFloat wrapper that may be of interest.

For simple numerical operations, using an entire Symbolica Atom will introduce a large amount of overhead. It should only be used if the expression contains symbols as well. But perhaps I misunderstood the point of the benchmark?

Hyperreal doesn't have any f64 mode. All math done with hyperreals is at infinite precision using a Rational of two BigUInts and a recursive real Computable. Real provides a cohesive interface over both allowing for easy scalar math. Computables are handled symbolically through a set of deterministic reduction rules until approximation is required, to preserve precision and reduce complexity. Approximation only happens at explicit public API boundaries like .to_f64_lossy() not used except for IO.

Hyperreal gets performance back through caching observed facts about the numbers it's representing at creation, and through operations, and specializing dispatch for predicates and geometric operations. Using this approach throughout the stack allows us to avoid computing on the full representation or collapsing it into an approximation. Instead asking questions like "do we know if it's definitely zero, definitely not, or unknown?" or "is it rational?" or "does it have a known sign, or unknown?" and so on. Each question specializes dispatch further, and some eliminate the need for it entirely.

Asking questions using the cached facts is approximately as fast as computing with f64s. So we do that whenever possible throughout the stack. But then when you actually need to do the exact computation, hyperreal does that too, and can approximate it out to whatever precision you'd like. f32 and f64 being common, but others being supported as well. The downside is that calculating quickly with them requires this sort specialization, but the work's been done for the geometry functions.

I'll look into DoubleFloat and ErrorPropagatingFloat for benches. I should mention that numerica@128bit beat the other pure rust bignum crates I tested. The benchmarks are mostly just to give me an understanding of the performance shapes of the implementation choices of high precision numeric libraries alongside hyperreal.

Thanks for the clarification! Hyperreal sounds very useful for zero testing (at the moment I use ErrorPropagatingFloat for this, but it is fickle), I will play around with this in the near future.

Yes, it should be useful for that. Hyperreal's trig and approximate functions performance is also stellar. Perhaps the biggest compromise in terms of the math supported by hyperreals at the moment is that although Rational equality can be exactly tested, Computable equality is currently structural. So it's possible to end up with two mathematically equivalent Computables which aren't structurally equal. Because it's not a full CAS.

It's still possible to approximate them both, and test them against each other, but since the whole architecture is built to reduce, avoid, and cache approximations because they're expensive, it's not the default.

In the end the zero test problem is undecidable for reasonably complicated expressions, so sadly there is no guarantee that you can rewrite one Computable into another even if they evaluate to the same. For polynomials you can do finite field evaluation tests to prove equality with a likelihood bound of your choosing. That may be interesting for hyperreal too.

Yes. One of those problems with no neat solution, and worse no performant one. :)

You might find this bit of performance engineering interesting: https://github.com/timschmidt/hyperreal/blob/8a016808f4b0ba3...

The matrix math layer wanted that kind of optimization to avoid worst case operations.

Author of Symbolica here! If these packages work well for you, then just use them :) I don't have a lot of experience with using these tools, but the last time I tried the user experience isn't so great, because of lack of LSP support (no typing, autocomplete etc). It could have improved in the mean time. I believe the tools are also more oriented to polynomial algebra and no so much for manipulating general expressions.

Pure looks interesting!

You can also use Symbolica in Rust, which also has operator overloading so it will look quite similar. At some point I will also add Julia bindings.

Author of the blog post here. I am happy to answer any questions about the article, pattern matching in general or about Symbolica!

I believe there is a family of programming languages named OBJ that are known as "term re-writing" languages that operate at this symbolic/syntatic level.

Are you familiar with them? How does Symbolica compare/contrast with them?

https://en.m.wikipedia.org/wiki/OBJ_(programming_language)

(While OBJ is old, there are some newer /recent decendents from its family)

Not the author of Symbolica but I will take a stab at responding. Symbolica is fundamentally a CAS (computer algebra system) so it should be compared with other CAS. And compared with other CAS, Symbolica aims to provide much better performance. In addition it is much more hackable, being written from scratch in Rust.

What software did you use to generate the graphs?

I used mermaid, which gets live-compiled on the website, that is built using quarto. Here is an example:

```{mermaid} flowchart LR A -- 1 --- B B -- 2 --- C B -- 8 --- E C -- 3 --- D C -- 9 --- F D -- 10 --- E D -- 4 --- G G -- 5 --- H G -- 6 --- F E -- 9 --- F ```

most probably https://mermaid.js.org/syntax/flowchart.html

I am using GMP indeed, through the Rust crate `rug`.

Thanks for the reply! If you don't mind asking more: what do you use for polynomial GCD? Apparently it is quite fast, do you use some standard algorithm implemented well or is there some kind of algorithmic improvement? Is it described somewhere, say a paper or a book? Have you tried to benchmark it against NTL, for example? Thanks again!

You can also just use

    Expression.parse('x+f(x)+5')

Of course, to refer to a specific variable of the CAS in Python, you need to bind it to a Python variable. There is no way around this.

In the end most of the time of the user is not spent on syntax, but on designing algorithms. With Mathematica, you are locked into the Mathematica ecosystem. With Symbolica / sympy and other CASs that are libraries, you can use all the familiar data structures of the language you are coding in.

Thanks for the feedback! I will see if I can slow down the slideshow. You can see more demos in the docs and the live notebook.

An expression is very general. Each variable and function is commutative and should hold for the complex numbers. For functions you can set if they are symmetric, linear or antisymmetric. Non-commutativity can be emulated by adding an extra argument that determines the ordering or by giving them different names.

If you use the Polynomial class instead of Expression, you can choose the field yourself. This is especially the clear in Rust where most structures are generic over the field. For example:

MultivariatePolynomial<AlgebraicNumberRing<RationalField>>

or

    UnivariatePolynomial<FiniteField<u64>>

Thanks for the quick answer! I had only looked at the python API docs, so I missed that. I’ve just been wrapping up learning a bunch of Lie theory and will keep symbolica in mind next time I want to play with some big nasty expressions!

> Non-commutativity can be emulated by adding an extra argument that determines the ordering or by giving them different names.

Would you mind giving an example? (or just tell me it’s in the docs and i’ll look deeper)

It's not a language specific feature, but you can do the bookkeeping yourself. In the simplest form you can write:

    f(1,...)*f(2,...)

Then when you do pattern matching with wildcards x_ and y_ you can do

   f(x_,...)*f(y_,..)

with the requirement that x_ < y_. This way you will know you match them in the expected order and not the other way around.