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

Add module with default implementation for type classes #19

Open
Shimuuar opened this issue Mar 3, 2020 · 4 comments
Open

Add module with default implementation for type classes #19

Shimuuar opened this issue Mar 3, 2020 · 4 comments

Comments

@Shimuuar
Copy link

Shimuuar commented Mar 3, 2020

I think that we should add module System.Random.Defaults (name subject to debate)

  1. Provide default implementations for genWord32R and genWord64R in terms of genWord32 & genWord64 respectively. Efficient implementation is far from trivial so it makes sense to provide defaults to PRNG implementors

  2. Provide default implementations for methods of Uniform & UniformRange type classes and possible others should they be created. For example

uniformBounded :: (UniformRange a, Bounded a) => m a
uniformBounded = uniformRange (minBound, maxBound)

have been proposed multiple times. There's obvious implementation of UniformRange in terms of Enum. We also could provide newtype wrappers for use with DerivingVia

If there's general agreement I'll make pull request

@lehins
Copy link
Collaborator

lehins commented Mar 3, 2020

Absolutely, I was hoping someone would step up and implement those.

I think we agreed on that bitmaskWithRejection is a good starting point for unsigned in ranges [0, a] and [0, a). But there is still quite a bit we are missing. Also with respect to clusivity of ranges in uniformR, should we provide helpers for adjusting it? For example we decide that unifromR (0, 1) :: m Float returns a floating point inclusive both 0 and 1 (i.e. [0, 1]), should we provide a helper function(s) that can turn the result into other variations [0, 1), (0, 1] and (0, 1)? I don't think there is a general way to do it for all numbers, but at least for floating points it's not that trivial. Quote form mwc-random:

To generate a Float variate with a range of [0,1), subtract 2**(-33). To do the same with Double variates, subtract 2**(-53).

With regard to the name of the module I can't come up with a better one. Things come to mind Helpers, Utilities. I've heard somewhere that it is customary to name modules in singular form, so System.Random.Default? Whichever you decide on, I am just throwing ideas that come to mind.

@Shimuuar
Copy link
Author

Shimuuar commented Mar 3, 2020

I think it's better to leave floating point number out of scope for first PR. It's big topic and even have separate issue for them #6

System.Random.Default looks fine to me. I don't have strong opinion on this but since it's going to be full of default implementations for probably everything Default seems like right choice.

@Shimuuar
Copy link
Author

Shimuuar commented Mar 3, 2020

RE clusivity. I think that for uniformR we should use inclusive range because this is only way to generate all possible ranges fir fixed-width types like Word32, enums, etc. With semi open interval it's not possible to define range with maxBound in it

For floating point maintaining closed/open distinction could be difficult because of rounding errors. Naive translation of either [0,1] or (0,1] to (a,b) with a≠0 will result in [a.b] because of rounding

@idontgetoutmuch
Copy link
Owner

I think it's better to leave floating point number out of scope for first PR. It's big topic and even have separate issue for them #6

It should definitely be out of scope for the first PR. We will in a much better place with performance and quality and floating point numbers will be no worse than they are now.

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

3 participants