SPACECADET3D

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.

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.

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.

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!

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?

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.

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 ```

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

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.

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

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>>

These polynomials appear when computing Feynman diagrams, which are used to make predictions for the Large Hadron Collider. The collider can measure collisions with such astonishing precision (<1% error) that predictions of the same order are also needed. The more precise you want to be, the more terms in a series approximation of the mathematical description of the collision you need to compute. For example, I computed the fifth-order approximation of the QCD beta function, which governs how intense the strong force affects matter. This takes 5 days of symbolic manipulations (pattern matching, substitutions, rational polynomial arithmetic, etc) on 32 cores.

The large polynomials appear in the middle of the computation, often referred to as intermediate expression swell. This also happens when you do a Gaussian elimination or compute greatest common divisors: the final result will be small, but intermediately, the expressions can get large.