System.Random instances for tuples

[Dan Burton]

Ever find yourself wanting to generate a tuple of random things? Instances are trivial to write in Haskell 98:

instance (Random a, Random b) => Random (a, b) where
  randomR ((loL, loR), (hiL, hiR)) g = ((l, r), g'')

    where (l, g')  = randomR (loL, hiL) g
          (r, g'') = randomR (loR, hiR) g'
  random g = ((l, r), g'')
    where (l, g')  = random g
          (r, g'') = random g'

Can we add instances like this to System.Random in the random package?

-- Dan Burton

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Antoine Latter-2]

On Mon, Apr 16, 2012 at 9:04 PM, Dan Burton <[hidden email]> wrote:
> Ever find yourself wanting to generate a tuple of random things? Instances
> are trivial to write in Haskell 98:

CC'ing the maintainer of the package as well.

It looks like it makes sense to me.

>
> instance (Random a, Random b) => Random (a, b) where
>   randomR ((loL, loR), (hiL, hiR)) g = ((l, r), g'')
>     where (l, g')  = randomR (loL, hiL) g
>           (r, g'') = randomR (loR, hiR) g'
>   random g = ((l, r), g'')
>     where (l, g')  = random g
>           (r, g'') = random g'
>
> Can we add instances like this to System.Random in the random package?
>
> -- Dan Burton
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Yitzchak Gale]

Dan Burton wrote:
> Ever find yourself wanting to generate a tuple of random things? Instances
> are trivial to write in Haskell 98...
> Can we add instances like this to System.Random in the random package?

I'm guessing that this was left out because of its
surprising side-effect of adding strictness to the
first component: If you try to get the value of the
second component, the first one is forced.

For example, imagine that in randomR the
computation for the lower bound on the first
component is expensive or bottom, and you
only ask for the second component in the
calling code.

You would really want to use split for this. But
not much is known about how to write good
random generators with provably good splitting
properties.

-Yitz

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Henning Thielemann]

I find the tuple instances for Random useful.


On Tue, 17 Apr 2012, Yitzchak Gale wrote:

> I'm guessing that this was left out because of its
> surprising side-effect of adding strictness to the
> first component: If you try to get the value of the
> second component, the first one is forced.

I'm not surprised. Without this instance I would wrap 'randomR' in a State
monad and then do a
    liftA2 (,) (State random) (State random)
  which yields the same behavior.

I am thinking about whether your argument reveals a problem for lists. If
you do
    unzip (randoms g)
  then evaluating one of the result lists will also evaluate parts of the
other list. However, this is true for many applications of unzip.

  For me @randoms :: g -> [(a,a)]@ looks nicer than
  @case split g of (g0,g1) -> zip (randoms g0) (randoms g1)@.

> For example, imagine that in randomR the
> computation for the lower bound on the first
> component is expensive or bottom, and you
> only ask for the second component in the
> calling code.

Isn't this the same problem as in Ix tuple instances?

Are you sure that the bounds for the first component are computed if the
second component is evaluated? I think only the 'g' is forced.


What about QuickCheck.Arbitrary instance? As far as I remember the current
version of QuickCheck has tuple instances.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ryan Newton]

Alright, as a library proposal we need a discussion period and a deadline for decision.

As the maintainer, I personally have no objection but am completely agnostic on the choice between the design alternatives:

• Use split, don't add strictness to other tuple components
• Don't use split, inject additional strictness.

Honestly, since random instances will never include any "interesting" computation I'm not sure why one would ever mind the extra strictness.

Perhaps the documentation for the instances should say that bringing the tuple itself to WHNF may evaluate any subset of the tuple components...

  -Ryan

On Thu, Apr 19, 2012 at 10:18 AM, Henning Thielemann <[hidden email]> wrote:

I find the tuple instances for Random useful.

On Tue, 17 Apr 2012, Yitzchak Gale wrote:

I'm guessing that this was left out because of its
surprising side-effect of adding strictness to the
first component: If you try to get the value of the
second component, the first one is forced.

I'm not surprised. Without this instance I would wrap 'randomR' in a State monad and then do a
  liftA2 (,) (State random) (State random)
 which yields the same behavior.

I am thinking about whether your argument reveals a problem for lists. If you do
  unzip (randoms g)
 then evaluating one of the result lists will also evaluate parts of the other list. However, this is true for many applications of unzip.

 For me @randoms :: g -> [(a,a)]@ looks nicer than
 @case split g of (g0,g1) -> zip (randoms g0) (randoms g1)@.

For example, imagine that in randomR the
computation for the lower bound on the first
component is expensive or bottom, and you
only ask for the second component in the
calling code.

Isn't this the same problem as in Ix tuple instances?

Are you sure that the bounds for the first component are computed if the second component is evaluated? I think only the 'g' is forced.


What about QuickCheck.Arbitrary instance? As far as I remember the current version of QuickCheck has tuple instances.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ryan Newton]

But it's worth mentioning that we have an accepted but not yet released library proposal to factor "split" out into its own type class.

On Thu, Apr 19, 2012 at 10:31 AM, Ryan Newton <[hidden email]> wrote:

Alright, as a library proposal we need a discussion period and a deadline for decision.

As the maintainer, I personally have no objection but am completely agnostic on the choice between the design alternatives:

• Use split, don't add strictness to other tuple components
• Don't use split, inject additional strictness.

Honestly, since random instances will never include any "interesting" computation I'm not sure why one would ever mind the extra strictness.

Perhaps the documentation for the instances should say that bringing the tuple itself to WHNF may evaluate any subset of the tuple components...

  -Ryan

On Thu, Apr 19, 2012 at 10:18 AM, Henning Thielemann <[hidden email]> wrote:

I find the tuple instances for Random useful.

On Tue, 17 Apr 2012, Yitzchak Gale wrote:

I'm guessing that this was left out because of its
surprising side-effect of adding strictness to the
first component: If you try to get the value of the
second component, the first one is forced.

I'm not surprised. Without this instance I would wrap 'randomR' in a State monad and then do a
  liftA2 (,) (State random) (State random)
 which yields the same behavior.

I am thinking about whether your argument reveals a problem for lists. If you do
  unzip (randoms g)
 then evaluating one of the result lists will also evaluate parts of the other list. However, this is true for many applications of unzip.

 For me @randoms :: g -> [(a,a)]@ looks nicer than
 @case split g of (g0,g1) -> zip (randoms g0) (randoms g1)@.

For example, imagine that in randomR the
computation for the lower bound on the first
component is expensive or bottom, and you
only ask for the second component in the
calling code.

Isn't this the same problem as in Ix tuple instances?

Are you sure that the bounds for the first component are computed if the second component is evaluated? I think only the 'g' is forced.


What about QuickCheck.Arbitrary instance? As far as I remember the current version of QuickCheck has tuple instances.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries