Live data from Hacker News

Symbolica 2.0: Programmable Symbols for Python and Rust

symbolica.io

21–30 of 31 posts

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#21

Generally seems realy nice but I realy do not like the license, I hate this kind of licenses that restrict you from using the full power of your device. What is this one core is free. I have 8 cores just on my private system. My Laptop has even more.

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.

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#22
post #19

I was excited to see this, since I'm looking for a symbolic algebra library. But then I saw the absolutely awful license. A license like that at a time like this is no small miscalculation.

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

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#23
post #5

As an alternative, I’m working on reimplementing Wolfram Language/ Mathematica in Rust: https://woxi.ad-si.com/ A lot of Wolfram Language code just works already!

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

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!

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#24

Earlier quoted context omitted.

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

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

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.

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#25
post #5

As an alternative, I’m working on reimplementing Wolfram Language/ Mathematica in Rust: https://woxi.ad-si.com/ A lot of Wolfram Language code just works already!

So you haven't heard from there lawyers yet ? Hope it stays that way.

Does Woxi also show intermediate steps ? That to me is a killer feature of Mathematica.

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#26
post #25
post #5

As an alternative, I’m working on reimplementing Wolfram Language/ Mathematica in Rust: https://woxi.ad-si.com/ A lot of Wolfram Language code just works already!

So you haven't heard from there lawyers yet ? Hope it stays that way. Does Woxi also show intermediate steps ? That to me is a killer feature of Mathematica.

Mathics (https://mathics.org/) has been working on a Mathematica clone for years and hasn't had any problems so far. There have been many legal cases establishing that APIs are't copyrightable, and since Woxi shares zero code with Mathematica, it should be fine.

No support for intermediate steps yet, but if there is interest in it, I'd be happy to prioritize it.

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#27
post #26
post #25

Earlier quoted context omitted.

So you haven't heard from there lawyers yet ? Hope it stays that way. Does Woxi also show intermediate steps ? That to me is a killer feature of Mathematica.

Mathics ( https://mathics.org/ ) has been working on a Mathematica clone for years and hasn't had any problems so far. There have been many legal cases establishing that APIs are't copyrightable, and since Woxi shares zero code with Mathematica, it should be fine. No support for intermediate steps yet, but if there is interest in it, I'd be happy to prioritize it.

All the best for your endeavour. It's a big one you are tackling.

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#28

Earlier quoted context omitted.

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

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.

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#29

Earlier quoted context omitted.

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…

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.

Re: Symbolica 2.0: Programmable Symbols for Python and Rust

#30

Earlier quoted context omitted.

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…

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.

Post reply on HN