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

crate revival and discussion #206

Open
YeungOnion opened this issue Mar 8, 2024 · 3 comments
Open

crate revival and discussion #206

YeungOnion opened this issue Mar 8, 2024 · 3 comments

Comments

@YeungOnion
Copy link
Contributor

YeungOnion commented Mar 8, 2024

@henryjac and I (he/him pronouns) will serve as new maintainers for the crate, in @boxtown's words (on #201)

Thanks a bunch for stepping up! I genuinely wished I had the time/drive to give this crate the attention it deserves but I'm happy to see it transition to people who are interested in the maintaining health of the project. Best of luck!

We are each pretty new to this, but each have support from mentors as we transition into the role. We'd appreciate patience as we figure out how we'll each be filling this role - much of that will start as discussion here so it's public. I'd be open to directed feedback on how I do here; I can't speak for @henryjac; expecting similar.

Expect some updates in the docs to reflect what we'll be aiming for to support contributors and users as we figure out how to carry this crate forward. At the moment, I think our short term goals are to collect a few PRs for a new release which I've added a milestone for as well as tracker issue, #205. I'm planning to see which of these is more helpful, but milestones seem sparse in the repo, so maybe just the issue will suffice.

--
EDIT
In my haste, I didn't write how thankful I am for @boxtown, @troublescooter, and many others for getting us here!

@YeungOnion YeungOnion changed the title crate revival crate revival and discussion May 4, 2024
@YeungOnion YeungOnion pinned this issue May 4, 2024
@YeungOnion
Copy link
Contributor Author

Since posting this, I've started to accept a few PRs to show activity on the gh repo, but I realize I've not stated that intent, so that's what I'm up to now. For now, I'm happy to continue prioritizing

  • existing gaps:

    • helpful usage and contributing docs,
    • CI to support consistency,
    • changes to abide by simple API guidelines,
    • removing panic! where available or where inconsistent,
  • and fixes:

    • egregious numerical inaccuracies,
    • inaccurate docs,
    • broken tests

But I'm hoping for some input/feedback for

@alimf17
Copy link

alimf17 commented Jun 9, 2024

I don't quite know if this is the proper place for this, but is there a way to make certain guarantees that unsafe code external to the crate can depend upon? I use this code a lot for code that is supposed to be relatively high performance, but it's relatively difficult to extract information from the struct safely and efficiently so that I can manipulate it with unsafe code.

As a simple example, is there a way to add some kind of InfallibleDistribution trait which is basically the Distribution trait but for distributions that have the relevant statistics always defined regardless of their parameters? Currently, I'm using unwrap_unchecked() on the std_dev() output of the Normal distribution, but that's not technically guaranteed by the API to always be sound, even though the standard deviation of any Normal distribution is obviously always defined.

@YeungOnion
Copy link
Contributor Author

Hey! Thanks for asking. It may not be the best place for this issue, hoping this one could be more focused on what areas/contexts you use statrs.

Could you open an issue to discuss this?

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