[m-users.] The new random module(s)

[Richard O'Keefe]

Should permutation of lists be in the list module or the random module?

Hello "expression problem", how nice to see you again!

There are many different kinds of sequences, such as unrolled lists and
AVL DAGs and paged/segmented arrays, and the concept of permutation
applies to all of them.  It is too much to expect the random module to
know about all of them.  Equally, you really don't want to couple
everything in sight to the random module.

Also, there are many *ways* to scramble a sequence.
Crack open a good combinatorics book and read about "The Twelvefold Way".
There can also be weighted permutations, where each element has a given
probability of being the first (or next), it's not just uniform.

So we actually have a three-dimensional combination:
  - what kind of data is to be scrambled?
  - what method of scrambling is wanted?
  - what is the source of random numbers?
If I'm not mistaken, this is what multiparameter type classes are for.

The solution would appear to be to provide a random module with a
type

On Thu, 5 Sep 2019 at 23:09, Julien Fischer <jfischer at opturion.com> wrote:

>
> Hi Mark,
>
> On Thu, 5 Sep 2019, Mark Brown wrote:
>
> > On Thu, Sep 5, 2019 at 4:09 PM Julian Fondren <jfondren at minimaltype.com>
> wrote:
> >>
> >> In the permute_array/permute_list future,
> >> will permute_X be added for other data structures?
> >
> > I wasn't planning to. Permutation is (mathematically) usually only
> > defined for sets and sequences so I'm not sure what you'd be expecting
> > for other library types. I suppose there could be a set permutation
> > predicate that returns a randomly ordered list of the elements.
> >
> > In my view, the reason to put them in the random module is that they
> > are more related to each other, and to the other predicates that do
> > random stuff, than they are to predicates that merely work on lists or
> > arrays. But no matter, I can add list.random_permutation now unless
> > anyone else wants to add their opinion?
>
> I disagree: I expect to find generic operations on lists in the list
> module and generic operations on arrays in the array module.
>
> > (array.random_permutation ought to wait until the old RNG has been
> > sufficiently obsoleted. Note that I have only obsoleted the
> > random.init predicate as that is sufficient to produce a warning, and
> > declaring all predicates of the old implementation to be obsolete
> > would only result in getting multiple warnings for essentially the
> > same issue. I'll make that clearer in the docs for random.init.)
>
> ...
>
> > So what's the choice?
> >
> > 1. Add random.permute_* (or whatever) now.
> > 2. Add list.random_permutation and make a backwards incompatible
> > change to array.random_permutation now.
> > 3. Add list.random_permutation now, but wait before changing
> > array.random_permutation.
>
> I think we could avoid the namespace issues by naming the new versions
> either:
>
>
>      random.shuffle_list
>      random.shuffle_array
>
> or:
>
>      list.random_shuffle
>      array.randome_suffle
>
> depending on where they end up (i.e. don't use the word permutation
> or permute.)
>
> We can always reclaim the name permutation after the old interface has
> been removed.
>
> Julien.
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20190906/e223ec19/attachment.html>