You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using Rust for numerical computations and was wondering about the best place to take special functions from.
I came across the module statrs::function and saw that you use the puruspe (by the way, in the README.md there is an extra "r", it says "pururspe").
So, my question is: Would it not be better to join efforts and have and have the "best" source for special functions in one place?
Of course, there is always a trade-off between accuracy and velocity, but joining efforts hopefully leads to the best solution or documented solutions.
The text was updated successfully, but these errors were encountered:
@rasa200 Thank you for suggestion.
But I'm not interested in building the best special function crate. That's not my main purpose. Of course, I also want to integrate the well-made special function crate in peroxide.
But there are some problems or disadvantages.
First, it should be written by pure rust. If not, it can't be applied at WASM. (So, we can't use special crate.)
Second, we want to integrate only special function crate. statrs is great crate, but there are many overlapped functions. (We use rand-distr for probability distributions instead.) So, I don't use statrs now.
Thus, for these reasons, I used custom simple crate - puruspe.
Surely, if there will be good crate which satisfies above conditions, then I'll integrate it.
Hi there!!
Thank you very much for your great work!!
I am using Rust for numerical computations and was wondering about the best place to take special functions from.
I came across the module statrs::function and saw that you use the puruspe (by the way, in the README.md there is an extra "r", it says "pururspe").
So, my question is: Would it not be better to join efforts and have and have the "best" source for special functions in one place?
Of course, there is always a trade-off between accuracy and velocity, but joining efforts hopefully leads to the best solution or documented solutions.
The text was updated successfully, but these errors were encountered: