Repository navigation
Add Random instances for tuples #26
Description
Activity
That sounds super reasonable. I'll talk about it with Dominic when we next
catchup.I assume we probably don't need more Than size 6 or 10 tuples? :)
On Thursday, April 23, 2015, Neil Mitchell [email protected] wrote:
Looking at the interface, I see no reason tuples can't be instances of the
Random class, which would make it more useful.—
Reply to this email directly or view it on GitHub
#26.My particular use case was for 4 tuples - specifically, I wanted to call
seedTFGenwith a randomly chosen seed. Agreed, 6 seems sufficient.@ndmitchell this is a good feature, i'll make it happen, see what i can do...
how would you specify/what to talk about generating samples / intervals?
(i'm amidst revisiting / generalizing the sampler api, though that wont happen for the next release, i presume you want every tuple value, not an "interval/range"?
@cartazio I didn't really have any idea about what intervals should mean - but I guess between
(a,b)and(c,d)should probably be equivalent to the first member in the rangea-cand the second inb-d.What is the status on this issue? Is there a chance that the pull-request will be merged and an update is published?
- Support for tuple sampling will be happening. Stay tuned…On Tue, Apr 17, 2018 at 5:16 AM power-fungus ***@***.***> wrote: What is the status on this issue? Is there a chance that the pull-request will be merged and an update is published? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwhM9iIYigK0tXQPKQ1CnLuYiCDPFks5tpbL4gaJpZM4EG2Sw> .Reacted by Liang-Ting Chen
Will this be happening soon? I am really looking forward to this feature. :-)
9 remaining items
@ndmitchell proposed above that "between (a,b) and (c,d) should probably be equivalent to the first member in the range a-c and the second in b-d". Under this interpretation we can define
UniformRange, but I'm not quite convinced that this is a right and unambiguous thing to do. (That's basically what I meant to ask in the comment above)I think we can define such instance if we treat
aandbcompletely independent of each other. For example this could work:instance (UniformRange a, UniformRange b) => UniformRange (a, b) where uniformRM ((al, bl), (ah, bh)) g = do a <- uniformRM (al, ah) g b <- uniformRM (bl, bh) g pure (a, b)
If we think of the tuples as some related value such complex numbers or something then it definitely doesn't make sense, but above instance (and similar one for
Random) I believe could be pretty useful. @Shimuuar What's your take on this?That would be easy to implement. And in some sense it is uniform. But it's wrong is we use interpretation: "sample uniformly every value between
aandb". I think it's better to avoid defining weird instances from get-goReacted by Leonhard MarkertIn that case, I think it would be ok to add such instance for
Random, but not forUniformRange, since former already does not promise uniformity as with types likeFloatandInteger.Reacted by Aleksey KhudyakovDefining more instances of
Randomthan ofUniformRangewill motivate users to use the former and block its eventual deprecation. If we think that this is a handy instance, let's add it toUniformRangeas well with a proper comment/clarification.I certainly disagree with
Randombeing deprecated, even over time! After over two decades of people using it, this would be a wrong move. Moreover, many programming languages have a concept like "Random", that produces some standard distribution that does not have a mathematical backing but is useful for programmers. Tuples here is a perfect example.Users can choose themselves which instance they want to use. One says
Uniformand it promises the uniform distribution, another one isRandom, which makes it open to interpretation. Many of the types do coincide and that is fine, IMHO.The problem is that currently
RandomandrandomRare not open to intepretation: they do claim uniformity.Lines 189 to 190 in 11464aa
Lines 197 to 199 in 11464aa
I do not particularly mind lifting this guarantee for
Random, but I think that in future with a wider adoption ofUniformRangepeople would ask forUniformRangefor tuples as well. I would rather define either both, or none.FWIW, I have no particular desire for a uniform range in 99%+ of cases. I've wanted random tuples a handful of times. I'm perfectly happy with Random.
@Bodigrim the whole point of the
UniformandUniformRangeclasses coming into existence was for them to be different fromRandomtype class. So when "people do ask", I'll be happy to tell them such instance cannot exist, but for now let's not worry about what "people might ask".I am on the same page with @ndmitchell and @Shimuuar seems to support this idea as well.
So, let's remove the "uniform" promise from
Randomclass, because it is already a lie and add some tuple instances forRandom, but notUniformRange.If we communicate the difference between
RandomandUniformclearly and unambiguously, then I'm on board as well.Reacted by Alexey Kuleshevich@lehins wrote:
add some tuple instances for
Random, but notUniformRange.I'm on board with this conclusion.
So, let's remove the "uniform" promise from
Randomclass, because it is already a lieI don't understand this premise. Which
Randominstances do not produce uniform distributions?Which Random instances do not produce uniform distributions?
Integer,FloatandDouble. Callingrandomfunction for these types will produce values distributed uniformly in a subrange, instead of full range, because as you know full range is infiniteFinally this is implemented and is merged into master. These instances will be soon released with
random-1.2.1
Looking at the interface, I see no reason tuples can't be instances of the Random class, which would make it more useful.