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.

Sign up for GitHub

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

Jump to bottom

Implement (Non-central) Distributions in Rust #24

Open
storopoli opened this issue Jan 22, 2024 · 5 comments
Open

Implement (Non-central) Distributions in Rust #24

storopoli opened this issue Jan 22, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@storopoli
Copy link
Member

If we implement the (non-central) distributions in Rust, we can drop the nmath C library and emscripten as dependencies.

What we need:

  • Distributions with cdf (and hence the pdf is included) and quantile functions:
    • Non-central $\chi^2$
    • Non-central $F$
    • Non-central $t$
    • $z$ (Standard Normal)
    • Binomial (for some exact tests)

Alternatives:

  • Make a PR to statsrs it is dead.
  • Implement our own in a lib sub-crate.
@storopoli storopoli added the enhancement New feature or request label Jan 22, 2024
@storopoli storopoli self-assigned this Jan 22, 2024
@rikhuijzer
Copy link
Member

I'm working on this. Dropping emscripten would be great because then we could move frontend.js into the back end 🥳 via web-sys. The problem currently is that web-sys doesn't support emscripten.

@storopoli
Copy link
Member Author

storopoli commented Jan 22, 2024 •
edited
Loading

Dropping emscripten would be great because then we could move frontend.js into the back end 🥳 via web-sys

Does this means that we can strongly type the API inputs and outputs and get rid of parse_[i|f]64?

@rikhuijzer rikhuijzer mentioned this issue Jan 22, 2024
Merged
@rikhuijzer
Copy link
Member

Does this means that we can strongly type the API inputs and outputs and get rid of parse_[i|f]64?

No, what would change is that instead of interacting with the DOM using Javascript (for example, via getElementById(id)), we could interact directly with the DOM from within Rust. This would mean that we could drop the JSON communication between back end and front end because the back end can directly modify the DOM elements.

@storopoli
Copy link
Member Author

Ok so we have 's/JavaScript/Rust' in all frontend?
But if we drop the JSON communication aren't we also dropping the parsing floats and ints into straight getting Rust's floats and ints?

@rikhuijzer
Copy link
Member

Ok so we have 's/JavaScript/Rust' in all frontend? But if we drop the JSON communication aren't we also dropping the parsing floats and ints into straight getting Rust's floats and ints?

Could be. I don't know whether HTML number elements are automatically interpreted as number types by web-sys.

rikhuijzer added a commit that referenced this issue Jan 22, 2024
@rikhuijzer
Implement pnt in Rust (#25)
6cfc0e7 
Works towards fixing #24.

This is a way in which we could get rid of C and, hence, emscripten. We
just incrementally port the C code to Rust. It's a lot of work, but not
super difficult. Once this is done, it should make other things such as
plotting and handling the browser DOM easier, so then it's a net win?

The code tries to stay as close as possible to the original
implementation. This should make it easier to find bugs in our port.

I've also tried [`c2rust`](https://github.com/immunant/c2rust). Apart
from some warnings, it seemed to work after generating
`compile_commands.json` with `intercept-build`. The generated code was
not very pretty, however, and relied heavily on libc, so I think a
manual rewrite is more future proof.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rikhuijzer @storopoli