-
Notifications
You must be signed in to change notification settings - Fork 21
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
Migration to 0.3 could use more documentation #83
Comments
Hi @ncfavier - I am sorry about that - perhaps you would consider creating some documentation?
They use different PRNG algorithms (multiply with carry and splitmix). Both are "serious" pseudo random number generators in the sense that they will pass a lot of tests for randomness (of course they cannot by definition pass all tests for randomness). They are not suitable for cryptographic applications if that is what you mean by "serious". |
Seconded, the new version killed a lot of code for me, and it's been rather painful to ascertain how to properly migrate. |
@freckletonj I am very sorry about that. I had no idea that cc: @ncfavier here is a small example of how I use 0.3 with
|
For information, there are 43 packages on Hackage that depend on random-fu. Maybe we could add a function |
Ah, and running an rvar is now: (runReaderT (sampleReaderRVarT someRVar) mwc) :: IO Double The docs are a little tough for me since:
But these 2 examples you gave, plus the above of how to run an RVar are helpful. One question though is, it seems perhaps a misfeature to require functions to specify whether they're a Reader or State, when it'd be nice for the caller to choose. But I guess then the intent is to keep library-type functions all in RVar or Distrubution for as long as possible? Anyways, I do love this library and it stands out to me as being one of the first libraries to look at if you need to deal with randomness. Thank you! |
I wasn't totally cavalier when I updated |
@idontgetoutmuch sorry to cause a fuss! I really appreciate this library and your work on it! I'd like to say that my pains were less from the update, and more from the documentation being misleading or absent, and not much clarity around what changed between versions. So, I hope you freely iterate this however you see fit, and, reverse-dependencies be damned! |
I think this is a case where the 80-20 rule can be judiciously applied - pulling numbers out of my ass here, but I'd assume 80% of the time people want to use randomness, they don't care about determinism, and they're operating in either I understand that maintaining this library happens on a volunteer basis, and I don't want to be too ungrateful. I also appreciate the work that you've put into this. |
Hi @sullyj3 - thanks for the feedback and I fully agree with what you say about making the library easy to use. I have however what I think is a better plan to improve things. I have however discovered that the maintainer / author of
and then "run" them via My plan is to migrate any distributions that Even better is that Also there is actually a team of use actively working on / using HTH |
Ok, that's encouraging. Thanks for laying that out for me. I look forward to seeing your plan come to fruition! |
Is it possible anymore to use random-fu as a standalone library? It seems like you have to bring in MTL and System.Random before:
after:
Is this the most minimal example with random-fu 0.3? I am also not sure if the examples are equivalent. |
They look equivalent to me. It might be possible to create and export helper functions from I am going to use your example in the documentation. I hope you don't mind. |
You can use the example in the documentation. I'm not sure that I will have time to submit a PR in the near future, if anyone else wants to that would be great. |
I'm trying to port some code (lambdabot/lambdabot#204) that previously used
sample v
in anIO
context to random-fu 0.3 in order to compile on GHC 9. This doesn't work anymore because theMonadRandom IO
instance is gone, so after digging around in the source code I eventually figured out I needed something likedo g <- MWC.createSystemRandom; sampleFrom g v
.I think this could be made clearer in the documentation as it seems like a common usecase?
Also, I'm not sure what the difference would be between using
MWC.createSystemRandom
andnewIOGenM =<< newStdGen
(assuming this is a silly "get a random quote" application and not anything needing Serious Random Numbers™).The text was updated successfully, but these errors were encountered: