Il 27/12/2022 00:45, Albert ha scritto:
> Is this the best way to generate unique random numbers in a set of 6
> numbers?
>
>
> <******************************************************>
>
> void generateNumbers()
> {
> int val1, val2, val3, val4, val5, val6;
>
> val1 = rand() % 59 + 1;
> printf("%4d", val1);
>
> val2 = rand() % 59 + 1;
> while (val2 == val1)
> {
> val2 = rand() % 59 + 1;
> }
> printf("%4d", val2);
>
> val3 = rand() % 59 + 1;
> while (val3 == val1 || val3 == val2)
> {
> val3 = rand() % 59 + 1;
> }
> printf("%4d", val3);
>
> val4 = rand() % 59 + 1;
> while (val4 == val1 || val4 == val2 || val4 == val3)
> {
> val4 = rand() % 59 + 1;
> }
> printf("%4d", val4);
>
> val5 = rand() % 59 + 1;
> while (val5 == val1 || val5 == val2 || val5 == val3 || val5 == val4)
> {
> val5 = rand() % 59 + 1;
> }
> printf("%4d", val5);
>
> val6 = rand() % 59 + 1;
> while (val6 == val1 || val6 == val2 || val6 == val3 || val6 == val4
> || val6 == val5)
> {
> val6 = rand() % 59 + 1;
> }
> printf("%4d", val6);
> printf("\n");
> }
> <******************************************************>
>
> The main prog using this function:
> #include <stdio.h>
> #include <stdlib.h>
> #include<windows.h>
>
> int main(void)
> {
> for (int i = 0; i < 100; i++)
> {
> generateNumbers();
> Sleep(1000);
> }
> return 0;
> }

using a lookup table?

void generateNumbers()
{ char num_flag[61];
int val[6];

memset(num_flag, '\0', sizeof(num_flag));

for(int i = 0; i < 6; i++)
{
while(num_flag[val[i] = rand() % 59 + 1]);
num_flag[val[i]] = 1;
}

printf("\n");
for(int i = 0; i < 6; i++)
printf("%d ", val[i]);
printf("\n");
}

Richard Damon <Richard@Damon-Family.org> writes:

> On 12/27/22 9:57 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 12/27/22 3:08 PM, Ben Bacarisse wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> On 12/27/22 12:53 PM, Ben Bacarisse wrote:
>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>
>>>>>>> On 12/27/22 11:59 AM, Ben Bacarisse wrote:
>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>
>>>>>>>>> On 12/27/22 10:57 AM, Ben Bacarisse wrote:
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>
>>>>>>>>>>> On 12/26/22 6:45 PM, Albert wrote:
>>>>>>>>>>>> Is this the best way to generate unique random numbers in a set of 6
>>>>>>>>>>>> numbers?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> An alternate way to generate numbers without repeat, and avoid
>>>>>>>>>>> recalling the random number generator, is first generate the number
>>>>>>>>>>> between 0 and N-1,
>>>>>>>>>>>
>>>>>>>>>>> Then generate the second number between 0 and N-2, and if the result
>>>>>>>>>>> is greater than or equal the first number, increment it.
>>>>>>>>>>>
>>>>>>>>>>> Then generate the third number between 0 and N-3, and if the result is
>>>>>>>>>>> greater than or equal to the first number, increment it. THen if it is
>>>>>>>>>>> greater than or equal to the second number, increment it.
>>>>>>>>>>>
>>>>>>>>>>> Just keep repeating the pattern with smaller and smaller ranges, and
>>>>>>>>>>> compare to the previous numbers in order, and increment if the value
>>>>>>>>>>> at that point is greater than or equoal.
>>>>>>>>>> I don't see how this does the job at all. For example, when picking 3
>>>>>>>>>> from, say, [0,5] we might pick 2 and then 1. Now if the third choice is
>>>>>>>>>> 1 it is not equal to 2 (so no increment) but it is equal to 1 so
>>>>>>>>>> increment to 2.
>>>>>>>>>
>>>>>>>>> As I think about it, if you increment, you need to restart the scan
>>>>>>>>> with the beginning number, but not repeat a test. Another way is have
>>>>>>>>> a sorted list of picks and work smallest to largest.
>>>>>>>>>
>>>>>>>>> So:
>>>>>>>>>
>>>>>>>>> #1
>>>>>>>>> From [0, 5] get 2
>>>>>>>>>
>>>>>>>>> #2
>>>>>>>>> From [0, 4] get 1
>>>>>>>>> 1 not >= 2 so ok.
>>>>>>>>>
>>>>>>>>> #3
>>>>>>>>>
>>>>>>>>> From [0, 3] get 1
>>>>>>>>> 1 not >= 2 so next
>>>>>>>>> 1 IS >= 1 so make 2 and restart
>>>>>>>>> 1 >= 2 so make 3
>>>>>>>> Presumably "2 >= 2 so make 3"
>>>>>>>>
>>>>>>>>> don't repeat test 2.
>>>>>>>> Now you just get highly biased results (if I've got then hang of it).
>>>>>>>>
>>>>>>>
>>>>>>> No, it is unbiased, we skip the test of the second number, as that
>>>>>>> rule was already used for this number.
>>>>>>
>>>>>> What's the algorithm, then? My attempt to code it from your description
>>>>>> must have gone wrong.
>>>>>
>>>>> You choose a random number based on the number of UNCHOSEN numbers
>>>>> left.
>>>> Can you give the algorithm using some pseudo code?
>>>>
>>>>> since they weren't all the lowest numbers, you increase the value by
>>>>> one for every chosen value that is less than or equal to the number
>>>>> picked (including after any other increases).
>>>> Surely it's a few lines of pseudo code. I'm getting lost in the words.
>>>
>>> simplest version, which keeps a temp sorted array.
>>>
>>> function non_repeating_random_range(
>>> int npick, // number of picks to make
>>> int nchoice, // range of choices
>>> int* randoms): // array to return the answers in
>>>
>>> int ordered_list[npick]; // List of picks in acending order
>>> for i in 0 to npick-1
>>> random = random_number(nchoice-i); // Random unpicked slot
>>> for element in urdered_list:
>>> if random >= element: random++
>>> else break from loop
>>> *randoms++ = random;
>>> insert random into ordered_list
>> OK, I see what you were getting at.
>> That seems a little more fussy than Floyd's algorithm using a set:
>> set<int> S = {}
>> for j = nchoice - npick + 1 to nchoice
>> r = random_int(j) + 1
>> insert into S (if r in S then j else r)
>
> Because his method first only generates a "Set", which appears to not
> remember the order of insertion

I don't know what this "because" relates to.

> He is generating a random combination, not a random (partial)
> permutation. The original program seemed to make a distinction. The
> question comes is the answer 1, 2, 3, 4, 5 different than 5, 4, 3, 2,
> 1 ?
>
> If his set tries to remember order, then the first element CAN'T be
> from the whole set, as the random_int for that isn't from the whold
> nchoice option.

I'm lost again.

--
Ben.

On 12/28/22 9:06 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 12/27/22 9:57 PM, Ben Bacarisse wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 12/27/22 3:08 PM, Ben Bacarisse wrote:
>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>
>>>>>> On 12/27/22 12:53 PM, Ben Bacarisse wrote:
>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>
>>>>>>>> On 12/27/22 11:59 AM, Ben Bacarisse wrote:
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>
>>>>>>>>>> On 12/27/22 10:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 12/26/22 6:45 PM, Albert wrote:
>>>>>>>>>>>>> Is this the best way to generate unique random numbers in a set of 6
>>>>>>>>>>>>> numbers?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> An alternate way to generate numbers without repeat, and avoid
>>>>>>>>>>>> recalling the random number generator, is first generate the number
>>>>>>>>>>>> between 0 and N-1,
>>>>>>>>>>>>
>>>>>>>>>>>> Then generate the second number between 0 and N-2, and if the result
>>>>>>>>>>>> is greater than or equal the first number, increment it.
>>>>>>>>>>>>
>>>>>>>>>>>> Then generate the third number between 0 and N-3, and if the result is
>>>>>>>>>>>> greater than or equal to the first number, increment it. THen if it is
>>>>>>>>>>>> greater than or equal to the second number, increment it.
>>>>>>>>>>>>
>>>>>>>>>>>> Just keep repeating the pattern with smaller and smaller ranges, and
>>>>>>>>>>>> compare to the previous numbers in order, and increment if the value
>>>>>>>>>>>> at that point is greater than or equoal.
>>>>>>>>>>> I don't see how this does the job at all. For example, when picking 3
>>>>>>>>>>> from, say, [0,5] we might pick 2 and then 1. Now if the third choice is
>>>>>>>>>>> 1 it is not equal to 2 (so no increment) but it is equal to 1 so
>>>>>>>>>>> increment to 2.
>>>>>>>>>>
>>>>>>>>>> As I think about it, if you increment, you need to restart the scan
>>>>>>>>>> with the beginning number, but not repeat a test. Another way is have
>>>>>>>>>> a sorted list of picks and work smallest to largest.
>>>>>>>>>>
>>>>>>>>>> So:
>>>>>>>>>>
>>>>>>>>>> #1
>>>>>>>>>> From [0, 5] get 2
>>>>>>>>>>
>>>>>>>>>> #2
>>>>>>>>>> From [0, 4] get 1
>>>>>>>>>> 1 not >= 2 so ok.
>>>>>>>>>>
>>>>>>>>>> #3
>>>>>>>>>>
>>>>>>>>>> From [0, 3] get 1
>>>>>>>>>> 1 not >= 2 so next
>>>>>>>>>> 1 IS >= 1 so make 2 and restart
>>>>>>>>>> 1 >= 2 so make 3
>>>>>>>>> Presumably "2 >= 2 so make 3"
>>>>>>>>>
>>>>>>>>>> don't repeat test 2.
>>>>>>>>> Now you just get highly biased results (if I've got then hang of it).
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, it is unbiased, we skip the test of the second number, as that
>>>>>>>> rule was already used for this number.
>>>>>>>
>>>>>>> What's the algorithm, then? My attempt to code it from your description
>>>>>>> must have gone wrong.
>>>>>>
>>>>>> You choose a random number based on the number of UNCHOSEN numbers
>>>>>> left.
>>>>> Can you give the algorithm using some pseudo code?
>>>>>
>>>>>> since they weren't all the lowest numbers, you increase the value by
>>>>>> one for every chosen value that is less than or equal to the number
>>>>>> picked (including after any other increases).
>>>>> Surely it's a few lines of pseudo code. I'm getting lost in the words.
>>>>
>>>> simplest version, which keeps a temp sorted array.
>>>>
>>>> function non_repeating_random_range(
>>>> int npick, // number of picks to make
>>>> int nchoice, // range of choices
>>>> int* randoms): // array to return the answers in
>>>>
>>>> int ordered_list[npick]; // List of picks in acending order
>>>> for i in 0 to npick-1
>>>> random = random_number(nchoice-i); // Random unpicked slot
>>>> for element in urdered_list:
>>>> if random >= element: random++
>>>> else break from loop
>>>> *randoms++ = random;
>>>> insert random into ordered_list
>>> OK, I see what you were getting at.
>>> That seems a little more fussy than Floyd's algorithm using a set:
>>> set<int> S = {}
>>> for j = nchoice - npick + 1 to nchoice
>>> r = random_int(j) + 1
>>> insert into S (if r in S then j else r)
>>
>> Because his method first only generates a "Set", which appears to not
>> remember the order of insertion
>
> I don't know what this "because" relates to.

Do you understand the difference between a "List" and a "Set"

A List has the POTENTIAL of dupicate entries, and keeps track of order.

A Set (normally) can't hold duplicate entries, and doesn't keep track of
order.

The Set {1, 2, 3, 4} is the exact same Set as {4, 3, 2, 1}
but the list [1, 2, 3, 4] isn't the same as [4, 3, 2, 1]

Floyd's program give just a random Set of numbers (perhaps becuase the
OP used the term "Set" in an informal manner to express his problem. It
does NOT generate a uniform answer if the order was important.

>
>> He is generating a random combination, not a random (partial)
>> permutation. The original program seemed to make a distinction. The
>> question comes is the answer 1, 2, 3, 4, 5 different than 5, 4, 3, 2,
>> 1 ?
>>
>> If his set tries to remember order, then the first element CAN'T be
>> from the whole set, as the random_int for that isn't from the whold
>> nchoice option.
>
> I'm lost again.
>

Floyd's program is based on math that assumes it doesn't matter what
order the numbers are in, that the results are just considered a "Set"
that doesn't consider the order of the numbers to be important.

In Math, these sorts of assortments are often called combitorals. In
combitorial math, STAR and RATS are "The Same" as they use the same SET
of letters, so they are the same results of selecting 4 letters out of
the alphabet.

Permutations keep track of order, so STAR and RATS are different answers.

A simple point to note, Floyd's generator when taking 6 picks out of 59
symbols will NEVER chose the number 59 as its first pick, so it does NOT
generate permutations with uniform distribution. In fact, the ONLY pick
that can have the value of 59 will be the last one, but that one will
have a 6/59 chance of being 59.

When treated as a combination, so order doesn't matter, the sets do turn
out to be uniformly distrbuted.

Ultimately, the question comes did the OP think order mattered or not.

Richard Damon <Richard@Damon-Family.org> writes:

> On 12/28/22 9:06 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 12/27/22 9:57 PM, Ben Bacarisse wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> On 12/27/22 3:08 PM, Ben Bacarisse wrote:
>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>
>>>>>>> On 12/27/22 12:53 PM, Ben Bacarisse wrote:
>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>
>>>>>>>>> On 12/27/22 11:59 AM, Ben Bacarisse wrote:
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>
>>>>>>>>>>> On 12/27/22 10:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/26/22 6:45 PM, Albert wrote:
>>>>>>>>>>>>>> Is this the best way to generate unique random numbers in a set of 6
>>>>>>>>>>>>>> numbers?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> An alternate way to generate numbers without repeat, and avoid
>>>>>>>>>>>>> recalling the random number generator, is first generate the number
>>>>>>>>>>>>> between 0 and N-1,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then generate the second number between 0 and N-2, and if the result
>>>>>>>>>>>>> is greater than or equal the first number, increment it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then generate the third number between 0 and N-3, and if the result is
>>>>>>>>>>>>> greater than or equal to the first number, increment it. THen if it is
>>>>>>>>>>>>> greater than or equal to the second number, increment it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Just keep repeating the pattern with smaller and smaller ranges, and
>>>>>>>>>>>>> compare to the previous numbers in order, and increment if the value
>>>>>>>>>>>>> at that point is greater than or equoal.
>>>>>>>>>>>> I don't see how this does the job at all. For example, when picking 3
>>>>>>>>>>>> from, say, [0,5] we might pick 2 and then 1. Now if the third choice is
>>>>>>>>>>>> 1 it is not equal to 2 (so no increment) but it is equal to 1 so
>>>>>>>>>>>> increment to 2.
>>>>>>>>>>>
>>>>>>>>>>> As I think about it, if you increment, you need to restart the scan
>>>>>>>>>>> with the beginning number, but not repeat a test. Another way is have
>>>>>>>>>>> a sorted list of picks and work smallest to largest.
>>>>>>>>>>>
>>>>>>>>>>> So:
>>>>>>>>>>>
>>>>>>>>>>> #1
>>>>>>>>>>> From [0, 5] get 2
>>>>>>>>>>>
>>>>>>>>>>> #2
>>>>>>>>>>> From [0, 4] get 1
>>>>>>>>>>> 1 not >= 2 so ok.
>>>>>>>>>>>
>>>>>>>>>>> #3
>>>>>>>>>>>
>>>>>>>>>>> From [0, 3] get 1
>>>>>>>>>>> 1 not >= 2 so next
>>>>>>>>>>> 1 IS >= 1 so make 2 and restart
>>>>>>>>>>> 1 >= 2 so make 3
>>>>>>>>>> Presumably "2 >= 2 so make 3"
>>>>>>>>>>
>>>>>>>>>>> don't repeat test 2.
>>>>>>>>>> Now you just get highly biased results (if I've got then hang of it).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, it is unbiased, we skip the test of the second number, as that
>>>>>>>>> rule was already used for this number.
>>>>>>>>
>>>>>>>> What's the algorithm, then? My attempt to code it from your description
>>>>>>>> must have gone wrong.
>>>>>>>
>>>>>>> You choose a random number based on the number of UNCHOSEN numbers
>>>>>>> left.
>>>>>> Can you give the algorithm using some pseudo code?
>>>>>>
>>>>>>> since they weren't all the lowest numbers, you increase the value by
>>>>>>> one for every chosen value that is less than or equal to the number
>>>>>>> picked (including after any other increases).
>>>>>> Surely it's a few lines of pseudo code. I'm getting lost in the words.
>>>>>
>>>>> simplest version, which keeps a temp sorted array.
>>>>>
>>>>> function non_repeating_random_range(
>>>>> int npick, // number of picks to make
>>>>> int nchoice, // range of choices
>>>>> int* randoms): // array to return the answers in
>>>>>
>>>>> int ordered_list[npick]; // List of picks in acending order
>>>>> for i in 0 to npick-1
>>>>> random = random_number(nchoice-i); // Random unpicked slot
>>>>> for element in urdered_list:
>>>>> if random >= element: random++
>>>>> else break from loop
>>>>> *randoms++ = random;
>>>>> insert random into ordered_list
>>>> OK, I see what you were getting at.
>>>> That seems a little more fussy than Floyd's algorithm using a set:
>>>> set<int> S = {}
>>>> for j = nchoice - npick + 1 to nchoice
>>>> r = random_int(j) + 1
>>>> insert into S (if r in S then j else r)
>>>
>>> Because his method first only generates a "Set", which appears to not
>>> remember the order of insertion
>> I don't know what this "because" relates to.
>
> Do you understand the difference between a "List" and a "Set"

Seriously?

> A List has the POTENTIAL of dupicate entries, and keeps track of order.
>
> A Set (normally) can't hold duplicate entries, and doesn't keep track of order.
>
> The Set {1, 2, 3, 4} is the exact same Set as {4, 3, 2, 1}
> but the list [1, 2, 3, 4] isn't the same as [4, 3, 2, 1]
>
> Floyd's program give just a random Set of numbers (perhaps becuase the
> OP used the term "Set" in an informal manner to express his
> problem. It does NOT generate a uniform answer if the order was
> important.

Of course I understand all that.

>>> He is generating a random combination, not a random (partial)
>>> permutation. The original program seemed to make a distinction. The
>>> question comes is the answer 1, 2, 3, 4, 5 different than 5, 4, 3, 2,
>>> 1 ?
>>>
>>> If his set tries to remember order, then the first element CAN'T be
>>> from the whole set, as the random_int for that isn't from the whold
>>> nchoice option.
>> I'm lost again.
>>
>
> Floyd's program is based on math that assumes it doesn't matter what
> order the numbers are in, that the results are just considered a "Set"
> that doesn't consider the order of the numbers to be important.
>
> In Math, these sorts of assortments are often called combitorals. In
> combitorial math, STAR and RATS are "The Same" as they use the same
> SET of letters, so they are the same results of selecting 4 letters
> out of the alphabet.
>
> Permutations keep track of order, so STAR and RATS are different answers.
>
> A simple point to note, Floyd's generator when taking 6 picks out of
> 59 symbols will NEVER chose the number 59 as its first pick, so it
> does NOT generate permutations with uniform distribution. In fact, the
> ONLY pick that can have the value of 59 will be the last one, but that
> one will have a 6/59 chance of being 59.
>
> When treated as a combination, so order doesn't matter, the sets do
> turn out to be uniformly distrbuted.
>
> Ultimately, the question comes did the OP think order mattered or not.

Richard Damon <Richard@damon-family.org> wrote:
> On 12/27/22 8:32 PM, antispam@math.uni.wroc.pl wrote:
> > Albert <invalid@gmail.com> wrote:
> >> Is this the best way to generate unique random numbers in a set of 6
> >> numbers?
> >
> > "unique random numbers in a set of 6 numbers" is strange formulation
> > of the problem. In such a small set you get at most 6 numbers
>
> No, it is a classical problem, the physical model is drawing from a
> sack/bag without replacement.

Problem of "drawing without replacement" is classic. Formulating
this as "unique random numbers in a set of 6 numbers" is strange.

> > without repeating. If you want exactly 6, this is (random) permutation
> > of original numbers. There is standard, resonably efficient
> > algoritm for generating random permutations of N elements. Assuming
> > numbering starting from 1, as step 1, swap number at first position N
> > with number at random postion (if random position happens to be N this
> > is a no-op). Then recursively do generate random permutation of positions
> > 1 to N - 1. This is easy to implement as a loop, but presentation
> > is simpler in recursive way.
> >
> > If you need less numbers than N, then you can use firs k < N positions
> > of random permutation. Different methods make sense only if size
> > of your set (that in N) is much larger than number of random numbers
> > that you need (that is k). For N = 6 there is no reason to do
> > anything more complicated than generating random permutation.
> >
>
> The issue with the permutation methods is you need to set up the "bag"
> of ALL POSSIBLE numbers. In this case, 60 isn't THAT big, so not so
> much of an issue. If the "bag" (the universe being selected from) gets
> much larger, creating a copy of that set to do the permutation set
> becomes a lot of extra work that isn't needed.

Yes, this is different wording of what I wrote.

> If you are drawing a signifcant fraction of the set, then it becomes
> more reasonable.
>
> Note, in this case N = *60* and *k* = 6 (we are drawing 6 numbers from
> the set of 60, not out of just 6 numbers. Yes, the OP was a bit sloppy
> with his words, but from the code they gave, their intent was clear.

I admit that code looked so crappy that I did not want to analyse
it. And to say the truth, my approch is: first say clearly what
should be done, then code this. Without clear statement of intent
one never know if some irregularity is a bug or a feature.

--
Waldek Hebisch

On Mon, 26 Dec 2022 23:45:04 +0000, Albert <invalid@gmail.com> wrote:

>Is this the best way to generate unique random numbers in a set of 6
>numbers?
>
>
><******************************************************>
>
>void generateNumbers()
>{
> int val1, val2, val3, val4, val5, val6;
>
> val1 = rand() % 59 + 1;
> printf("%4d", val1);
>
> val2 = rand() % 59 + 1;
> while (val2 == val1)
> {
> val2 = rand() % 59 + 1;
> }
> printf("%4d", val2);
>
> val3 = rand() % 59 + 1;
> while (val3 == val1 || val3 == val2)
> {
> val3 = rand() % 59 + 1;
> }
> printf("%4d", val3);
>
> val4 = rand() % 59 + 1;
> while (val4 == val1 || val4 == val2 || val4 == val3)
> {
> val4 = rand() % 59 + 1;
> }
> printf("%4d", val4);
>
> val5 = rand() % 59 + 1;
> while (val5 == val1 || val5 == val2 || val5 == val3 || val5 == val4)
> {
> val5 = rand() % 59 + 1;
> }
> printf("%4d", val5);
>
> val6 = rand() % 59 + 1;
> while (val6 == val1 || val6 == val2 || val6 == val3 || val6 == val4
>|| val6 == val5)
> {
> val6 = rand() % 59 + 1;
> }
> printf("%4d", val6);
> printf("\n");
>}
><******************************************************>
>
>The main prog using this function:
>#include <stdio.h>
>#include <stdlib.h>
>#include<windows.h>
>
>int main(void)
>{
> for (int i = 0; i < 100; i++)
> {
> generateNumbers();
> Sleep(1000);
> }
> return 0;
>}

int array[6];

int*f(void)
{int i,j,c,t;
for(i=0;i<6;++i) array[i]=0;
srand((unsigned int)time(0));
for(c=0;c<10;++c)
{i=rand()%6; j=rand()%6;
if(i!=j){t=array[i];array[i]=array[j];array[j]=t;}
}
return array;
}

int main(void)
{int i, *a ;
a=f();
for(i=0;i<6;++i) printf("%d ", a[i]);
printf("\n");
return 0;
}

In article <todbqe$16sg$1@gioia.aioe.org>, Albert <invalid@gmail.com> wrote:
>Is this the best way to generate unique random numbers in a set of 6
>numbers?
>
>
><******************************************************>

Here's my contribution to this thread.

Note that this is both gcc- and Linux- specific, as well as being
hard-coded to OP's problem specification. Note also that I took the
liberty of assuming that OP actually, really, did want random numbers
between 0 and 59; this would be suitable if, say, OP was looking for a
random number of minutes or seconds (and we could be talking either about
time intervals or about locations/distances expressed in terms of latitude
and/or longitude).

--- Cut Here ---
#include <stdio.h>
#include <stdint.h>

int main(void)
{ uint64_t num = 0, j = 1;
FILE *fp = fopen("/dev/urandom","r");

while (__builtin_popcount(num) < 6)
num |= 1 << (fgetc(fp) % 60);

for (int i=0; i<60; i++, j *= 2)
if (num & j)
printf("i = %d, j = %ld\n",i,j);
return 0;
} --- Cut Here ---

The values printed out of the variable "i" are your random numbers.

--
People who say they'll vote for someone else because Obama couldn't fix
*all* of Bush's messes are like people complaining that he couldn't cure
cancer, so they'll go and vote for (more) cancer.

On Sun, 01 Jan 2023 21:06:50 +0100, Rosario19 <Ros@invalid.invalid>
wrote:

On Mon, 26 Dec 2022 23:45:04 +0000, Albert <invalid@gmail.com> wrote:

>Is this the best way to generate unique random numbers in a set of 6
>numbers?
>
>
><******************************************************>
>
>void generateNumbers()
>{
> int val1, val2, val3, val4, val5, val6;
>
> val1 = rand() % 59 + 1;
> printf("%4d", val1);
>
> val2 = rand() % 59 + 1;
> while (val2 == val1)
> {
> val2 = rand() % 59 + 1;
> }
> printf("%4d", val2);
>
> val3 = rand() % 59 + 1;
> while (val3 == val1 || val3 == val2)
> {
> val3 = rand() % 59 + 1;
> }
> printf("%4d", val3);
>
> val4 = rand() % 59 + 1;
> while (val4 == val1 || val4 == val2 || val4 == val3)
> {
> val4 = rand() % 59 + 1;
> }
> printf("%4d", val4);
>
> val5 = rand() % 59 + 1;
> while (val5 == val1 || val5 == val2 || val5 == val3 || val5 == val4)
> {
> val5 = rand() % 59 + 1;
> }
> printf("%4d", val5);
>
> val6 = rand() % 59 + 1;
> while (val6 == val1 || val6 == val2 || val6 == val3 || val6 == val4
>|| val6 == val5)
> {
> val6 = rand() % 59 + 1;
> }
> printf("%4d", val6);
> printf("\n");
>}
><******************************************************>
>
>The main prog using this function:
>#include <stdio.h>
>#include <stdlib.h>
>#include<windows.h>
>
>int main(void)
>{
> for (int i = 0; i < 100; i++)
> {
> generateNumbers();
> Sleep(1000);
> }
> return 0;
>}

int array[59];

int*f(void)
{int i,j,c,t;
for(i=0;i<59;++i) array[i]=i+1;
srand((unsigned int)time(0));
for(c=0;c<100;++c)
{i=rand()%59; j=rand()%59;
if(i!=j){t=array[i];array[i]=array[j];array[j]=t;}
}
return array;
}

int main(void)
{int i, *a ;
a=f();
for(i=0;i<6;++i) printf("%d ", a[i]);
printf("\n");
return 0;
}

Il 02/01/2023 00:19, Kenny McCormack ha scritto:
> In article <todbqe$16sg$1@gioia.aioe.org>, Albert <invalid@gmail.com> wrote:
>> Is this the best way to generate unique random numbers in a set of 6
>> numbers?
>>
>>
>> <******************************************************>
>
> Here's my contribution to this thread.
>
> Note that this is both gcc- and Linux- specific, as well as being
> hard-coded to OP's problem specification. Note also that I took the
> liberty of assuming that OP actually, really, did want random numbers
> between 0 and 59; this would be suitable if, say, OP was looking for a
> random number of minutes or seconds (and we could be talking either about
> time intervals or about locations/distances expressed in terms of latitude
> and/or longitude).
>
> --- Cut Here ---
> #include <stdio.h>
> #include <stdint.h>
>
> int main(void)
> {
> uint64_t num = 0, j = 1;
> FILE *fp = fopen("/dev/urandom","r");
>
> while (__builtin_popcount(num) < 6)
> num |= 1 << (fgetc(fp) % 60);
>
> for (int i=0; i<60; i++, j *= 2)
> if (num & j)
> printf("i = %d, j = %ld\n",i,j);
> return 0;
> }
> --- Cut Here ---
>
> The values printed out of the variable "i" are your random numbers.
>

HI,
I state that I have not worried about the randomization algorithm chosen
by the OP and, so I focused on data storage.
Your storage method is similar to mine because both algorithms use a
lookup table with the difference that mine uses an array of characters
while your use the bits of an uint64_t. However I found a few Issues in
your source code:

The first concerns the use of the "__builtin_popcount" function, this
function does not work with uint64_t but with unsigned int.

#include <stdio.h>
#include <stdint.h>

int main()
{ uint64_t n = ~0;

printf ("value: %#lX bits: %d", n, __builtin_popcount(n));

return 0;
}

output: value: 0XFFFFFFFFFFFFFFFF bits: 32

This will have as a consequence that you will never get values greater
than 32.

The second issue concerns that your program will print the values
archived in numerical order and not in extraction order but perhaps this
does not affect the OP even if reading his code this seemed important.

Il 02/01/2023 07:28, jak ha scritto:
> Il 02/01/2023 00:19, Kenny McCormack ha scritto:
>> In article <todbqe$16sg$1@gioia.aioe.org>, Albert  <invalid@gmail.com>
>> wrote:
>>> Is this the best way to generate unique random numbers in a set of 6
>>> numbers?
>>>
>>>
>>> <******************************************************>
>>
>> Here's my contribution to this thread.
>>
>> Note that this is both gcc- and Linux- specific, as well as being
>> hard-coded to OP's problem specification.  Note also that I took the
>> liberty of assuming that OP actually, really, did want random numbers
>> between 0 and 59; this would be suitable if, say, OP was looking for a
>> random number of minutes or seconds (and we could be talking either about
>> time intervals or about locations/distances expressed in terms of
>> latitude
>> and/or longitude).
>>
>> --- Cut Here ---
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> int main(void)
>> {
>>      uint64_t num = 0, j = 1;
>>      FILE *fp = fopen("/dev/urandom","r");
>>
>>      while (__builtin_popcount(num) < 6)
>>     num |= 1 << (fgetc(fp) % 60);
>>
>>      for (int i=0; i<60; i++, j *= 2)
>>     if (num & j)
>>         printf("i = %d, j = %ld\n",i,j);
>>      return 0;
>> }
>> --- Cut Here ---
>>
>> The values printed out of the variable "i" are your random numbers.
>>
>
> HI,
> I state that I have not worried about the randomization algorithm chosen
> by the OP and, so I focused on data storage.
> Your storage method is similar to mine because both algorithms use a
> lookup table with the difference that mine uses an array of characters
> while your use the bits of an uint64_t. However I found a few Issues in
> your source code:
>
> The first concerns the use of the "__builtin_popcount" function, this
> function does not work with uint64_t but with unsigned int.
>
>
> #include <stdio.h>
> #include <stdint.h>
>
> int main()
> {
>     uint64_t n = ~0;
>
>     printf ("value: %#lX bits: %d", n, __builtin_popcount(n));
>
>     return 0;
> }
>
> output:   value: 0XFFFFFFFFFFFFFFFF bits: 32
>
> This will have as a consequence that you will never get values greater
> than 32.
>

I said a wrong thing: you will have numbers greater than 32 but you will
only know when 6 of them are in range 1-32 so you could print more than
6 of them.

>
> The second issue concerns that your program will print the values
> archived in numerical order and not in extraction order but perhaps this
> does not affect the OP even if reading his code this seemed important.
>

jak <nospam@please.ty> writes:

> Il 02/01/2023 00:19, Kenny McCormack ha scritto:
>
>> In article <todbqe$16sg$1@gioia.aioe.org>, Albert wrote:
>>
>>> Is this the best way to generate unique random numbers in a set of
>>> 6 numbers?
>>>
>>>
>>> <******************************************************>
>>
>> Here's my contribution to this thread.
>>
>> Note that this is both gcc- and Linux- specific, as well as being
>> hard-coded to OP's problem specification. Note also that I took
>> the liberty of assuming that OP actually, really, did want random
>> numbers between 0 and 59; this would be suitable if, say, OP was
>> looking for a random number of minutes or seconds (and we could be
>> talking either about time intervals or about locations/distances
>> expressed in terms of latitude and/or longitude).
>>
>> --- Cut Here ---
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> int main(void)
>> {
>> uint64_t num = 0, j = 1;
>> FILE *fp = fopen("/dev/urandom","r");
>>
>> while (__builtin_popcount(num) < 6)
>> num |= 1 << (fgetc(fp) % 60);
>>
>> for (int i=0; i<60; i++, j *= 2)
>> if (num & j)
>> printf("i = %d, j = %ld\n",i,j);
>> return 0;
>> }
>> --- Cut Here ---
>>
>> The values printed out of the variable "i" are your random numbers.
>
> HI,

> I state that I have not worried about the randomization algorithm
> chosen by the OP and, so I focused on data storage. Your storage
> method is similar to mine because both algorithms use a lookup table
> with the difference that mine uses an array of characters while your
> use the bits of an uint64_t. However I found a few Issues in your
> source code:
>
> The first concerns the use of the "__builtin_popcount" function, this
> function does not work with uint64_t but with unsigned int. [...]
>
> The second issue concerns that your program will print the values
> archived in numerical order and not in extraction order but perhaps
> this does not affect the OP even if reading his code this seemed
> important.

A third problem is that the way the [ 0 .. 59 ] values are
chosen is horribly biased: some numbers are 25% more likely
than others.

On Monday, 2 January 2023 at 09:54:05 UTC+2, Tim Rentsch wrote:
> jak <nos...@please.ty> writes:
>
> > Il 02/01/2023 00:19, Kenny McCormack ha scritto:
> >
> >> In article <todbqe$16sg$1...@gioia.aioe.org>, Albert wrote:
> >>
> >>> Is this the best way to generate unique random numbers in a set of
> >>> 6 numbers?
> >>>
> >>>
> >>> <******************************************************>
> >>
> >> Here's my contribution to this thread.
> >>
> >> Note that this is both gcc- and Linux- specific, as well as being
> >> hard-coded to OP's problem specification. Note also that I took
> >> the liberty of assuming that OP actually, really, did want random
> >> numbers between 0 and 59; this would be suitable if, say, OP was
> >> looking for a random number of minutes or seconds (and we could be
> >> talking either about time intervals or about locations/distances
> >> expressed in terms of latitude and/or longitude).
> >>
> >> --- Cut Here ---
> >> #include <stdio.h>
> >> #include <stdint.h>
> >>
> >> int main(void)
> >> {
> >> uint64_t num = 0, j = 1;
> >> FILE *fp = fopen("/dev/urandom","r");
> >>
> >> while (__builtin_popcount(num) < 6)
> >> num |= 1 << (fgetc(fp) % 60);
> >>
> >> for (int i=0; i<60; i++, j *= 2)
> >> if (num & j)
> >> printf("i = %d, j = %ld\n",i,j);
> >> return 0;
> >> }
> >> --- Cut Here ---
> >>
> >> The values printed out of the variable "i" are your random numbers.
> >
> > HI,
>
> > I state that I have not worried about the randomization algorithm
> > chosen by the OP and, so I focused on data storage. Your storage
> > method is similar to mine because both algorithms use a lookup table
> > with the difference that mine uses an array of characters while your
> > use the bits of an uint64_t. However I found a few Issues in your
> > source code:
> >
> > The first concerns the use of the "__builtin_popcount" function, this
> > function does not work with uint64_t but with unsigned int. [...]
> >
> > The second issue concerns that your program will print the values
> > archived in numerical order and not in extraction order but perhaps
> > this does not affect the OP even if reading his code this seemed
> > important.
> A third problem is that the way the [ 0 .. 59 ] values are
> chosen is horribly biased: some numbers are 25% more likely
> than others.

Fourth problem is that 32 bit shift:
num |= 1 << (fgetc(fp) % 60);
should be:
num |= 1LL << (fgetc(fp) % 60);

On 26/12/2022 23:45, Albert wrote:
> Is this the best way to generate unique random numbers in a set of 6
> numbers?
>
>
> <******************************************************>
>
> void generateNumbers()
> {
> int val1, val2, val3, val4, val5, val6;
>
> val1 = rand() % 59 + 1;
> printf("%4d", val1);
>
> val2 = rand() % 59 + 1;
> while (val2 == val1)
> {
> val2 = rand() % 59 + 1;
> }
> printf("%4d", val2);
>
> val3 = rand() % 59 + 1;
> while (val3 == val1 || val3 == val2)
> {
> val3 = rand() % 59 + 1;
> }
> printf("%4d", val3);
>
> val4 = rand() % 59 + 1;
> while (val4 == val1 || val4 == val2 || val4 == val3)
> {
> val4 = rand() % 59 + 1;
> }
> printf("%4d", val4);
>
> val5 = rand() % 59 + 1;
> while (val5 == val1 || val5 == val2 || val5 == val3 || val5 == val4)
> {
> val5 = rand() % 59 + 1;
> }
> printf("%4d", val5);
>
> val6 = rand() % 59 + 1;
> while (val6 == val1 || val6 == val2 || val6 == val3 || val6 == val4
> || val6 == val5)
> {
> val6 = rand() % 59 + 1;
> }
> printf("%4d", val6);
> printf("\n");
> }
> <******************************************************>
>
> The main prog using this function:
> #include <stdio.h>
> #include <stdlib.h>
> #include<windows.h>
>
> int main(void)
> {
> for (int i = 0; i < 100; i++)
> {
> generateNumbers();
> Sleep(1000);
> }
> return 0;
> }

Assuming you want generate numbers in the range 1..59, then it seems to
work, in creating reasonably distributed values (I don't know about a
smaller range).

The function could do with some work however:

* Extract the rand()%59+1 into its own function

* Make val1..val6 into an array of 6 values (indexed 1..6 if your like,
just make sure it has 7 elements)

* Rewrite the body as a loop of loops, since there is a lot of
duplicatation at the moment. Think about how it would look if you wanted
val1 to val100 instead; it doesn't scale.

* Perhaps let generateNumbers() return an array of numbers, and let the
caller decide whether to print them or not (which can be done in another
loop).

In article <tot4eh$21qv0$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>In article <todbqe$16sg$1@gioia.aioe.org>, Albert <invalid@gmail.com> wrote:
>>Is this the best way to generate unique random numbers in a set of 6
>>numbers?
>>
>>
>><******************************************************>
>
>Here's my contribution to this thread.
>
>Note that this is both gcc- and Linux- specific, as well as being
>hard-coded to OP's problem specification. Note also that I took the
>liberty of assuming that OP actually, really, did want random numbers
>between 0 and 59; this would be suitable if, say, OP was looking for a
>random number of minutes or seconds (and we could be talking either about
>time intervals or about locations/distances expressed in terms of latitude
>and/or longitude).

Here is an updated version that addresses some of the concerns raised by
another poster:

--- Cut Here ---
#include <stdio.h>
#include <stdint.h>

int main(void)
{ union {
uint64_t num64;
struct { unsigned a,b; } num32;
} num;
uint64_t j = 1;
FILE *fp = fopen("/dev/urandom","r");

num.num64 = 0;
while (__builtin_popcount(num.num32.a)+__builtin_popcount(num.num32.b) < 6)
num.num64 |= 1L << (fgetc(fp) % 60);

for (int i=0; i<60; i++, j *= 2)
if (num.num64 & j)
printf("i = %d, j = %ld\n",i,j);
return 0;
} --- Cut Here ---

The values printed out of the variable "i" are your random numbers.

--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

Albert <invalid@gmail.com> writes:
>Subject: Compute Unique Numbers in a Set

In a set, every number is unique.

On 1/2/23 10:22 AM, Stefan Ram wrote:
> Albert <invalid@gmail.com> writes:
>> Subject: Compute Unique Numbers in a Set
>
> In a set, every number is unique.
>

Assuming you are using the right Technical definition of Set.

Richard Damon <Richard@Damon-Family.org> writes:

> On 1/2/23 10:22 AM, Stefan Ram wrote:
>> Albert <invalid@gmail.com> writes:
>>> Subject: Compute Unique Numbers in a Set
>> In a set, every number is unique.
>
> Assuming you are using the right Technical definition of Set.

I suspect there's a language problem here. Without thinking much about
it assumed the result was to be a set (as you know) but I now think the
OP probably meant "compute (i.e choose) unique numbers /from/ a set".
The term "in a set" makes no literal sense and, as noted, clashes with
unique. But someone might write "in a set" by analogy with mathematical
phrases like, "compute the roots in R".

--
Ben.

On 1/2/23 12:31 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 1/2/23 10:22 AM, Stefan Ram wrote:
>>> Albert <invalid@gmail.com> writes:
>>>> Subject: Compute Unique Numbers in a Set
>>> In a set, every number is unique.
>>
>> Assuming you are using the right Technical definition of Set.
>
> I suspect there's a language problem here. Without thinking much about
> it assumed the result was to be a set (as you know) but I now think the
> OP probably meant "compute (i.e choose) unique numbers /from/ a set".
> The term "in a set" makes no literal sense and, as noted, clashes with
> unique. But someone might write "in a set" by analogy with mathematical
> phrases like, "compute the roots in R".
>

The problem is some colloquial usages of "Set" are things like, get a
set of three numbers by rolling 3 six-sided dice.

This "Set" allows for duplicates, and more indicates just a collection,
and not the normal technical definition of a set being distinct members.

When statement are made in Natural Language, sometimes the difficulty is
determining which definition is needed to be used for each word.

This sort of imprecision is particularly likely from beginners, which
the OP sounds to be.

In article <87358sq1w7.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> I suspect there's a language problem here. Without thinking much about
> it assumed the result was to be a set (as you know) but I now think the
> OP probably meant "compute (i.e choose) unique numbers /from/ a set".
> The term "in a set" makes no literal sense and, as noted, clashes with
> unique. But someone might write "in a set" by analogy with mathematical
> phrases like, "compute the roots in R".

Taking a wild guess, the answer might be to sort them with useful
keys. You can then compare any element to all other elements in
single scan.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Chen sockpuppet. insults Islam. Mohammed

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 1/2/23 10:22 AM, Stefan Ram wrote:
>>
>>> Albert <invalid@gmail.com> writes:
>>>
>>>> Subject: Compute Unique Numbers in a Set
>>>
>>> In a set, every number is unique.

It seems likely that OP was speaking informally. Probably he
meant some sort of generic collection rather than specifically a
mathematical set.

>> Assuming you are using the right Technical definition of Set.
>
> I suspect there's a language problem here. Without thinking much about
> it assumed the result was to be a set (as you know) but I now think the
> OP probably meant "compute (i.e choose) unique numbers /from/ a set".
> The term "in a set" makes no literal sense and, as noted, clashes with
> unique. But someone might write "in a set" by analogy with mathematical
> phrases like, "compute the roots in R".

The original posting said

Is this the best way to generate unique random numbers
in a set of 6 numbers?

which reinforces my view that OP meant something like collection
rather than something having to do with set as the term is used
in mathematics.

I confess I paid more attention to the code than to how the
question was asked. As a result of that, the comments I gave
assumed that the ordering of the six numbers was relevant.
However, looking back on it now, if I had to bet my bet would
be that OP doesn't care about the order, but just wants six
unique numbers (chosen from the relevant range).

On 02/01/2023 18:31, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 1/2/23 10:22 AM, Stefan Ram wrote:
>>> Albert <invalid@gmail.com> writes:
>>>> Subject: Compute Unique Numbers in a Set
>>> In a set, every number is unique.
>>
>> Assuming you are using the right Technical definition of Set.
>
> I suspect there's a language problem here. Without thinking much about
> it assumed the result was to be a set (as you know) but I now think the
> OP probably meant "compute (i.e choose) unique numbers /from/ a set".
> The term "in a set" makes no literal sense and, as noted, clashes with
> unique. But someone might write "in a set" by analogy with mathematical
> phrases like, "compute the roots in R".
>

Given that the OP has apparently completely ignored all the help and
advice given here, and seems to have no intention of clarifying or
expounding upon the first post, I think it is pointless to speculate on
what the OP might have meant. Just take the question as inspiration -
interpret it any way that can lead to interesting code, algorithms or
discussions. (This is what has been going on so far in this thread.)

When the OP comes back with "Thanks for the help so far, but what I
really meant was ... ", then it is possible to give focused help.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard Damon <Richard@Damon-Family.org> writes:
[...]

>> [...]
>
> [...]

P.S. I want to add, I liked seeing the various alternative
approaches that were given, both by you and by Richard Damon
(and also by others). Some of them were new to me. In a way
it's good that there were language difficulties, as otherwise
these other approaches may not have come up.

In article <86fscrprhd.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>[...]
>
>>> [...]
>>
>> [...]
>
>P.S. I want to add, I liked seeing the various alternative
>approaches that were given, both by you and by Richard Damon
>(and also by others). Some of them were new to me. In a way
>it's good that there were language difficulties, as otherwise
>these other approaches may not have come up.

You have to consider the possibility that posts such as the OP here are
machine-generated. And that's not necessarily a bad thing. It gets
discussion going. It breathes life into an otherwise almost-dead medium
(Usenet).

I know of one "social media" site that openly has bot-written questions.
They are often silly/stupid, but they do keep discussion going.

--
If you don't have faith, it's because you are reading the Bible with an
honest, truthful, real-answer seeking heart.

- Rick C Hodgin -

On 03/01/2023 16:46, Kenny McCormack wrote:
> In article <86fscrprhd.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Richard Damon <Richard@Damon-Family.org> writes:
>> [...]
>>
>>>> [...]
>>>
>>> [...]
>>
>> P.S. I want to add, I liked seeing the various alternative
>> approaches that were given, both by you and by Richard Damon
>> (and also by others). Some of them were new to me. In a way
>> it's good that there were language difficulties, as otherwise
>> these other approaches may not have come up.
>
> You have to consider the possibility that posts such as the OP here are
> machine-generated. And that's not necessarily a bad thing. It gets
> discussion going. It breathes life into an otherwise almost-dead medium
> (Usenet).
>
> I know of one "social media" site that openly has bot-written questions.
> They are often silly/stupid, but they do keep discussion going.
>

I think the initial post would be fairly advanced for a
machine-generated post. That means significant time and effort - which
means significant money. And the question then is, why?

A technical Usenet group might have around 50 regular members, several
hundred lurkers who are mostly read-only, and be google-groups searched
by a few thousand. There is no advertising, and thus no income. So
there is nothing to be gained by making such machine-generated posts in
Usenet.

Compare that to insta-snapo-book social media, with millions of users,
valuable advertising, ranking and "liking" systems, and a far more
gullible readership. Some areas of these social medias are dominated by
bots making posts and liking each others posts to modify rankings and
generate artificial advertising income, or to push their political
agendas or crazy conspiracy theories, perhaps even as an attack on
another country. It is a different world entirely.

You get the odd vandal that uses automated software to make Usenet
posts, but these are mostly absurd posts. And there are a few cases
where people have made Usenet poster programs for fun, to imitate
particularly annoying posters.

The original post is much more likely to be homework than a bot of any kind.

What about this:

#include <iostream>
#include <array>
#include <random>

using namespace std;

int main()
{ constexpr size_t MAX = 6;
array<int, MAX> already;
mt19937_64 mt;
uniform_int_distribution<int> uid( 1, 60 );
auto base = already.cbegin();
for( size_t n = 0; n != MAX; )
{
int value;
while( find( base, base + n, value = uid( mt ) ) != base + n );
cout << (already[n++] = value) << endl;
}
}