11–20 of 31 posts
Seems like a worthy successor to Sympy, although the license system might prevent it from reaching the same level of adoption.
Benchmarks against Symbolica and numerica here: https://github.com/timschmidt/hyperlattice/blob/main/benchma...
Seems like a worthy successor to Sympy, although the license system might prevent it from reaching the same level of adoption.
I've been doing some symbolica-like things recently in the https://github.com/timschmidt/hyperreal ecosystem. Not a full CAS, just enough symbolic math to maintain precision through the calculations. Benchmarks against Symbolica and numerica here: https://github.com/timschmidt/hyperlattice/blob/main/benchma...
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?
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!
If you want to use Symbolica for some of these features, feel free to reach out!
Seems like a worthy successor to Sympy, although the license system might prevent it from reaching the same level of adoption.
As someone who has not used Sympy: Why does it need a successor?
I've been doing some symbolica-like things recently in the https://github.com/timschmidt/hyperreal ecosystem. Not a full CAS, just enough symbolic math to maintain precision through the calculations. Benchmarks against Symbolica and numerica here: https://github.com/timschmidt/hyperlattice/blob/main/benchma...
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 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.
But then I saw the absolutely awful license. A license like that at a time like this is no small miscalculation.