Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extracting Nox #8

Closed
nestordemeure opened this issue Mar 7, 2024 · 1 comment
Closed

Extracting Nox #8

nestordemeure opened this issue Mar 7, 2024 · 1 comment

Comments

@nestordemeure
Copy link
Contributor

nestordemeure commented Mar 7, 2024

Hi!

First, great work! I have done a lot of numerical computing (in non-space-related domains) and you have built some things I have been wishing for several times in the past few years! Thank you so much for sharing your work with the community.

On that topic, is there a plan to extract your XLA bindings and Nox into their own repository (to make targeted contributions / issues easier) and crates1 (so that others can start using them for non-Elodin related projects)?

Footnotes

  1. I guess the XLA bindings might have a shot at being merged back into Laurent Mazare's crate if he is open to contributions.

@sphw
Copy link
Contributor

sphw commented Mar 7, 2024

Super glad you like Nox. I agree that it fills a niche not covered by the other Rust linear algebra libraries.

We are likely not going to move the crates out of this mono-repo, we find it easier to work with the mono-repo approach for a bunch of reasons. What we will do though is publish our crates to crates.io. I don't envision huge changes to Nox going forward, but API stability is not guaranteed. We also have a good way to go in increasing our test coverage to make sure things like batching operations are 100% correct. We are happy for others to start contributing directly to this repo. We'd love for others to add things like automatic differentiation that we have less of a need for internally but are super useful for many use-cases.

I'm happy to talk to LaurentMazare about upstreaming our changes. IMO it's not so much a case of better or worse here, but different. The upstream xla-rs crate uses a shared library while we statically link. I believe that is a better choice, but a solid argument could be made either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants