NuMojo Moved into a GitHub Organization Updated to Include access to different backends
NuMojo now exists under the Mojo Numerics and Algorithms group (MoNA).
For those of you that haven't heard of NuMojo, we are essentially trying to fill the same niche as numpy does for python. So far we have Tensor input versions of many of the standard library math functions. In the future we will have our own Tensor type and cover most, if not all, of the functionality of numpy and much of the functionality of scipy.
As for our new backend functionality, we added a number of function-only structs that conform to a trait called
Backend. From my testing, Vectorized is the fastest and is therefore the default backend.
* Naive: Just loops
* Vectorized: SIMD vectorized
* VectorizedUnroll: SIMD vectorized with a user-defined unroll factor.
* Parallelized: parallel execution without vectorization
This allows users to easily select different backends for different parts of their code and will allow future development to target different backends both at the hardware level and the algorithm level across the entire package by building a backend struct that conforms to Backend.
We are now accepting Feature requests, pull requests, and people who want to join our open-source organization. You can find our Discord on the GitHub page. I look forward to working with the members of this community to build the future of high-powered computing for Mojo and meeting people who love making math fast as much as I do.GitHub
GitHub - Mojo-Numerics-and-Algorithms-group/NuMojo
Contribute to Mojo-Numerics-and-Algorithms-group/NuMojo development by creating an account on GitHub.
4 Replies
I'd be happy to chat about this. I'm working on some codes related to my research. So far, I have ported the xo(or)shiro prng's to native mojo, implemented a toy static matrix (awaiting someone to port Eigen or similar to mojo), and started on some RK integration methods. I also used
numojo but changed it to mojosci as I don't prefer numojo. Perhaps we can think of a better name. It may be too soon to create a working group. Seems to be an army-of-one at the moment. 🙂 I'm happy to think about this. Mojo is the language I have always wanted for scientific computing (way too much time in R and C++; I like Julia in broad-strokes, but I don't like the type-system). We should definitely plan a mojo science conference or side-session in the coming years.If you want to take charge of mojosci (or a Scipy-like library regardless of the name) but put it under the Mojo Numerics and Analysis group (there are 3 active developers including myself at the moment) we could add that repository to the group and feed back and forth between the libraries as one or the other makes improvements.
I was actually thinking about splitting into several libraries anyway now that we are planning to make and maintain our own array type, as I think SciPy has too large of a scope by itself let alone when combined with numpy.
Yes, I could do that. It would be good to get the package/module/naming structure right early on. In the R world, packages are fairly broad. Seems that way in Python as well. Rust on the other hand often has quite small and single purpose packages.
Is tkeitt also your github username?
Nevermind, I found it.