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

Efficient access to private data #244

Open
YeungOnion opened this issue Jun 9, 2024 · 1 comment
Open

Efficient access to private data #244

YeungOnion opened this issue Jun 9, 2024 · 1 comment

Comments

@YeungOnion
Copy link
Contributor

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.

Originally posted by @alimf17 in #206 (comment)


Feel free to change the title on this issue

@YeungOnion
Copy link
Contributor Author

@alimf17 would the solution proposed in #295 work well for you? Or did you want to construct distributions unchecked and have all their evaluations be unchecked as well? At the moment, we've relied on using NAN to signal unconditionally bad input

  • inverse_cdf(x) = NAN implies x is not a probability, i.e. outside [0,1] or NAN
  • pdf(x) = NAN implies x is not in the sample space or is NAN

and I'd prefer keeping the checks around. #303 happens to be an interesting case of something like this, where returning NAN wouldn't clearly indicate where input was first identified as bad, but the error occurs because of underflow - a use case for [signaling] NAN.

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

1 participant