crate revival and discussion

[Orion Yeung]

@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!

[Orion Yeung]

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

• the 0.17 release on #205
• general input on here (#206)
  • what do you use this for?
  • what would you want to use it for?
  • what other statistical tooling do you use in lieu or alongside with this?

[alimf17]

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.

[Orion Yeung]

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?
Forgot I can do that too, started in #244