Generated 2M random dates via this code, compiled with:
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

//get random number from within range
int randNbr(int low, int high) {
return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
}

//test for leap year
int isleapyear(int yr) {
if(((yr%4==0) && (yr%100!=0)) || (yr%400==0))
{return 0;}
return -1;
}
//build random date in format YYYY-MM-DD
int mdays[12]={31,28,31,30,31,30,31,31,30,31,30,31}; //days in month
char *randDate() {
//year
int ryear = randNbr(2023,2023);
//random month
int rmth = randNbr(1,12);
//random day from that month
int rday = randNbr(1,mdays[rmth-1]);

//leap years
if((isleapyear(ryear)==0) && (rmth==2)) {
rday = randNbr(1,29);
}

char *randDt = malloc(sizeof(char) * 11);
sprintf(randDt,"%d-%02d-%02d",ryear, rmth, rday);
randDt[10] = '\0';
return randDt;
}

Results: https://imgur.com/a/yQHDyXf

The distribution of the dates is definitely FUBAR (it returns month = 2
way too often), so the randNbr() function code must be bad.

Oddly, the distribution of day = 2 is normal, while the counts of days
29,30,31 are also invalid.

Day|Count
01|65897
02|65890
03|65563
04|65743
05|65969
06|65904
07|65847
08|65285
09|65924
10|66052
11|65780
12|66071
13|66084
14|65670
15|66057
16|65810
17|66036
18|65845
19|65605
20|66024
21|65516
22|65638
23|65894
24|65726
25|65948
26|65506
27|65619
28|65980
29|59466
30|59983
31|37668
Total = 2M

Any ideas?

What do you use to get random numbers in a range?

On Sun, 10 Dec 2023 08:33:28 -0500, DFS wrote:

> Generated 2M random dates via this code, compiled with:
> gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
>
>
> //get random number from within range
> int randNbr(int low, int high) {
> return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
> }
>

Totally fucked right from the start, and totally expected from the
DuFuS Supremus.

You want a random date? Then generate a random "Julian Date"
integer and then convert to the YYYY-MM-DD format.

Today's (2023-12-10) Julian Date is 2460289.

Also, use an UNBIASED uniform random PRNG. The C rand()
suffers from modulo bias.

The problem is solved.

Now cue the code monkeys.

Ahahahahahahahahahahahahahahahaha!

On 12/10/2023 7:33 AM, DFS wrote:
>
> Generated 2M random dates via this code, compiled with:
> gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
>
>
> //get random number from within range
> int randNbr(int low, int high) {
>     return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
> }
>
>
> //test for leap year
> int isleapyear(int yr) {
>     if(((yr%4==0) && (yr%100!=0)) || (yr%400==0))
>         {return 0;}
>     return -1;
> }
>
> //build random date in format YYYY-MM-DD
> int mdays[12]={31,28,31,30,31,30,31,31,30,31,30,31};  //days in month
> char *randDate() {
>
>     //year
>     int ryear = randNbr(2023,2023);
>
>     //random month
>     int rmth = randNbr(1,12);
>
>     //random day from that month
>     int rday = randNbr(1,mdays[rmth-1]);
>
>     //leap years
>     if((isleapyear(ryear)==0) && (rmth==2)) {
>         rday = randNbr(1,29);
>     }
>
>
>     char *randDt = malloc(sizeof(char) * 11);
>     sprintf(randDt,"%d-%02d-%02d",ryear, rmth, rday);
>     randDt[10] = '\0';
>
>     return randDt;
> }
>
>
> Results: https://imgur.com/a/yQHDyXf
>
>
> The distribution of the dates is definitely FUBAR (it returns month = 2
> way too often), so the randNbr() function code must be bad.
>
> Oddly, the distribution of day = 2 is normal, while the counts of days
> 29,30,31 are also invalid.
>
> Day|Count
> 01|65897
> 02|65890
> 03|65563
> 04|65743
> 05|65969
> 06|65904
> 07|65847
> 08|65285
> 09|65924
> 10|66052
> 11|65780
> 12|66071
> 13|66084
> 14|65670
> 15|66057
> 16|65810
> 17|66036
> 18|65845
> 19|65605
> 20|66024
> 21|65516
> 22|65638
> 23|65894
> 24|65726
> 25|65948
> 26|65506
> 27|65619
> 28|65980
> 29|59466
> 30|59983
> 31|37668
> Total = 2M
>
> Any ideas?
>
> What do you use to get random numbers in a range?
>

Whatever way you choose, plot the results in 3D. If they don't spread
all over, it's not a good random number generator.

Most of the generators are bad :)

On 12/10/2023 1:09 PM, Physfitfreak wrote:
> On 12/10/2023 7:33 AM, DFS wrote:
>>
>> Generated 2M random dates via this code, compiled with:
>> gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
>>
>>
>> //get random number from within range
>> int randNbr(int low, int high) {
>>      return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
>> }
>>
>>
>> //test for leap year
>> int isleapyear(int yr) {
>>      if(((yr%4==0) && (yr%100!=0)) || (yr%400==0))
>>          {return 0;}
>>      return -1;
>> }
>>
>> //build random date in format YYYY-MM-DD
>> int mdays[12]={31,28,31,30,31,30,31,31,30,31,30,31};  //days in month
>> char *randDate() {
>>
>>      //year
>>      int ryear = randNbr(2023,2023);
>>
>>      //random month
>>      int rmth = randNbr(1,12);
>>
>>      //random day from that month
>>      int rday = randNbr(1,mdays[rmth-1]);
>>
>>      //leap years
>>      if((isleapyear(ryear)==0) && (rmth==2)) {
>>          rday = randNbr(1,29);
>>      }
>>
>>
>>      char *randDt = malloc(sizeof(char) * 11);
>>      sprintf(randDt,"%d-%02d-%02d",ryear, rmth, rday);
>>      randDt[10] = '\0';
>>
>>      return randDt;
>> }
>>
>>
>> Results: https://imgur.com/a/yQHDyXf
>>
>>
>> The distribution of the dates is definitely FUBAR (it returns month =
>> 2 way too often), so the randNbr() function code must be bad.
>>
>> Oddly, the distribution of day = 2 is normal, while the counts of days
>> 29,30,31 are also invalid.
>>
>> Day|Count
>> 01|65897
>> 02|65890
>> 03|65563
>> 04|65743
>> 05|65969
>> 06|65904
>> 07|65847
>> 08|65285
>> 09|65924
>> 10|66052
>> 11|65780
>> 12|66071
>> 13|66084
>> 14|65670
>> 15|66057
>> 16|65810
>> 17|66036
>> 18|65845
>> 19|65605
>> 20|66024
>> 21|65516
>> 22|65638
>> 23|65894
>> 24|65726
>> 25|65948
>> 26|65506
>> 27|65619
>> 28|65980
>> 29|59466
>> 30|59983
>> 31|37668
>> Total = 2M
>>
>> Any ideas?
>>
>> What do you use to get random numbers in a range?
>>
>
> Whatever way you choose, plot the results in 3D. If they don't spread
> all over, it's not a good random number generator.
>
> Most of the generators are bad :)
>
>

Use each three consecutively produced numbers as the coordinates for a
single dot in 3D plot. Then see they exhibit a rather uniform
distribution or are concentrated in a certain volume, or over a certain
surface or along a certain line. Truly random numbers aren't that easy
to generate. They may even be impossible to generate.

On 12/10/2023 12:19 PM, Relf wrote:
>> int isleapyear(int yr) { // test for leap year
>> if(((yr%4==0) && (yr%100!=0)) || (yr%400==0))
>> {return 0;}
>> return -1;
>> }
>
> #define isLeapYear( Yr ) ( !( Yr%400 ) || Yr%100 && !( Yr%4 ) )

That's a good shortie. You posted it before - I need to remember to use it.

>> it returns month = 2 too often https://imgur.com/a/yQHDyXf
>> Any ideas ?
>
> Use (__int64) Seconds Since The Start of 1970, "localtime()" & "mktime()".

I used that in the past. But it required strftime to get it to the
format I wanted, and was a hassle.

>> What do you use to get random numbers in a range ?
>
> #define Rand( Min, Max ) ( Min + ( Max - Min )*rand()/RAND_MAX )

I'm gonna try that. My results are bad:

* Feb (mth 2) way overrepresented
* days 29,30,31 of the month underrepresented

On 12/10/2023 5:04 PM, Relf wrote:
>> Re: https://imgur.com/a/yQHDyXf
>> * Feb (mth 2) overrepresented
>> * days 29,30,31 of the month underrepresented
>
> You (DFS) replied ( to me ):
>>> Use (__int64) Seconds Since The Start of 1970, "localtime()" & "mktime()".
>>
>> I used that in the past. But it required strftime to get it to the
>> format I wanted, and was a hassle.
>
> You don't need "strftime()".
>
> #define LoopJ( N ) int J = -1, eJ = N ; eJ-- ; while ( ++J <= eJ )
> #define LoopK( N ) int K = -1, eK = N ; eK-- ; while ( ++K <= eK )
>
> wchar_t Out[ 400 ], *D = Out; const int szBucket = 15 ;
> int Year[365/szBucket] = {}; tm rRandTime, rTimeB = {}, rTimeE ; __int64 RandTime, Min, Max ;
> rTimeB.tm_mday = 1, rTimeB.tm_year = 2023 - 1900, rTimeB.tm_isdst = -1 ;
> rTimeE = rTimeB, rTimeE.tm_year = 2024 - 1900 ;
> Min = mktime( &rTimeB ), Max = mktime( &rTimeE );
>
> LoopJ(2000000) { RandTime = Min + ( Max - Min )*rand()/RAND_MAX ;
> rRandTime = *localtime( ( time_t * ) &RandTime ), Year[ rRandTime.tm_yday / szBucket ]++ ; }
>
> LoopK(365/szBucket) D += swprintf( D, L"%5d, ", Year[ K ] ); Sh( L"%s\n\n", Out );
>
> // Output, each bucket holds 15 days:
> // 82445, 82322, 81810, 82482, 81621, 82347, 82275, 82281, 81993, 81771, 82151, 81956
> // 82327, 82463, 82122, 81660, 82791, 81764, 81933, 82255, 82550, 82232, 82323, 82699

That's not enough output to show the degree of randomness in the code.
Take a couple of thousands of them and make a 3D plot with them, each
three numbers forming one dot's coordinates. Then one can perhaps see
the quality of randomness in them.

On Sun, 10 Dec 2023 15:04:27 -0800 (Seattle), "Relf"
<Usenet@Jeff-Relf.Me> wrote in <Jeff-Relf.Me@Dec.10--3.04pm.Seattle.2023>:

>> Re: https://imgur.com/a/yQHDyXf * Feb (mth 2) overrepresented * days
>> 29,30,31 of the month underrepresented
>
> You (DFS) replied ( to me ):
>> > Use (__int64) Seconds Since The Start of 1970, "localtime()" &
>> > "mktime()".
>>
>> I used that in the past. But it required strftime to get it to the
>> format I wanted, and was a hassle.
>
> You don't need "strftime()".
>
> #define LoopJ( N ) int J = -1, eJ = N ; eJ-- ; while ( ++J <= eJ )
> #define LoopK( N ) int K = -1, eK = N ; eK-- ; while ( ++K <= eK )
>
> wchar_t Out[ 400 ], *D = Out; const int szBucket = 15 ;
> int Year[365/szBucket] = {}; tm rRandTime, rTimeB = {}, rTimeE ;
> __int64 RandTime, Min, Max ;
> rTimeB.tm_mday = 1, rTimeB.tm_year = 2023 - 1900, rTimeB.tm_isdst = -1 ;
> rTimeE = rTimeB, rTimeE.tm_year = 2024 - 1900 ;
> Min = mktime( &rTimeB ), Max = mktime( &rTimeE );
>
> LoopJ(2000000) { RandTime = Min + ( Max - Min )*rand()/RAND_MAX ;
> rRandTime = *localtime( ( time_t * ) &RandTime ), Year[
> rRandTime.tm_yday / szBucket ]++ ; }
>
> LoopK(365/szBucket) D += swprintf( D, L"%5d, ", Year[ K ] ); Sh(
> L"%s\n\n", Out );
>
> // Output, each bucket holds 15 days:
> // 82445, 82322, 81810, 82482, 81621, 82347, 82275, 82281, 81993,
> 81771, 82151, 81956 // 82327, 82463, 82122, 81660, 82791, 81764, 81933,
> 82255, 82550, 82232, 82323, 82699

BTW, you can get an int64_t integer definition
from #include <stdint.h>

(I believe it is making its way into the standard.)

Also:

"( time_t * ) &RandTime"

Why not make those variables "time_t" in the first place?

Also:

Why the wide characters? Are you just used to using them?

--
-v

On Mon, 11 Dec 2023 00:38:14 -0000 (UTC), vallor <vallor@cultnix.org>
wrote in <ul5llm$2s7iu$1@dont-email.me>:

> On Sun, 10 Dec 2023 15:04:27 -0800 (Seattle), "Relf"
> <Usenet@Jeff-Relf.Me> wrote in <Jeff-Relf.Me@Dec.10--3.04pm.Seattle.2023>:
>
>>> Re: https://imgur.com/a/yQHDyXf * Feb (mth 2) overrepresented * days
>>> 29,30,31 of the month underrepresented
>>
>> You (DFS) replied ( to me ):
>>> > Use (__int64) Seconds Since The Start of 1970, "localtime()" &
>>> > "mktime()".
>>>
>>> I used that in the past. But it required strftime to get it to the
>>> format I wanted, and was a hassle.
>>
>> You don't need "strftime()".
>>
>> #define LoopJ( N ) int J = -1, eJ = N ; eJ-- ; while ( ++J <= eJ )
>> #define LoopK( N ) int K = -1, eK = N ; eK-- ; while ( ++K <= eK )
>>
>> wchar_t Out[ 400 ], *D = Out; const int szBucket = 15 ;
>> int Year[365/szBucket] = {}; tm rRandTime, rTimeB = {}, rTimeE ;
>> __int64 RandTime, Min, Max ;
>> rTimeB.tm_mday = 1, rTimeB.tm_year = 2023 - 1900, rTimeB.tm_isdst = -1 ;
>> rTimeE = rTimeB, rTimeE.tm_year = 2024 - 1900 ;
>> Min = mktime( &rTimeB ), Max = mktime( &rTimeE );
>>
>> LoopJ(2000000) { RandTime = Min + ( Max - Min )*rand()/RAND_MAX ;
>> rRandTime = *localtime( ( time_t * ) &RandTime ), Year[
>> rRandTime.tm_yday / szBucket ]++ ; }
>>
>> LoopK(365/szBucket) D += swprintf( D, L"%5d, ", Year[ K ] ); Sh(
>> L"%s\n\n", Out );
>>
>> // Output, each bucket holds 15 days:
>> // 82445, 82322, 81810, 82482, 81621, 82347, 82275, 82281, 81993,
>> 81771, 82151, 81956 // 82327, 82463, 82122, 81660, 82791, 81764, 81933,
>> 82255, 82550, 82232, 82323, 82699
>
> BTW, you can get an int64_t integer definition
> from #include <stdint.h>
>
> (I believe it is making its way into the standard.)
>
> Also:
>
> "( time_t * ) &RandTime"
>
> Why not make those variables "time_t" in the first place?
>
> Also:
>
> Why the wide characters? Are you just used to using them?

Incidentally, GNU indent is handy for reformatting C code, and
will even let you pick a favorite C indent style.

$ man indent
[...]
The indent program can be used to make code easier to
read. It can also convert from one style of writing C
to another.

indent understands a substantial amount about the syntax
of C, but it also attempts to cope with incomplete and
misformed syntax.

In version 1.2 and more recent versions, the GNU style
of indenting is the default.
_ _ _ _ _ _ _

--
-v

On Sun, 10 Dec 2023 18:24:12 -0800 (Seattle), "Relf"
<Usenet@Jeff-Relf.Me> wrote in <Jeff-Relf.Me@Dec.10--6.24pm.Seattle.2023>:

> ScottGNU tortured my source code thusly:
>> > > // Output, each bucket holds 15 days:
>> > > // 82445, 82322, 81810, 82482, 81621, 82347, 82275, 82281, 81993,
>> > > 81771, 82151, 81956 // 82327, 82463, 82122, 81660, 82791, 81764, 81933,
>> > > 82255, 82550, 82232, 82323, 82699
>
> Whitespace speaks to me, so it's always custom.
>
> Excessive whitespace/comments is a big, red flag.

It depends on the quality of the whitespacing and comments.

If someone is adhering to a programming standard, and
carefully commenting their code, there's not a
damned thing wrong with that -- good for them!

--
-v

Physfitfreak wrote this copyrighted missive and expects royalties:

> On 12/10/2023 7:33 AM, DFS wrote:
>>
>> Generated 2M random dates via this code, compiled with:
>> gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
>>
>> . . .
>> Any ideas?
>>
>> What do you use to get random numbers in a range?
>>
>
> Whatever way you choose, plot the results in 3D. If they don't spread
> all over, it's not a good random number generator.
>
> Most of the generators are bad :)

Check out C++:

class randomizer
{ private:

static const int s_upper_limit = std::numeric_limits<int>::max();

std::random_device m_rd; /* seed source for random number engine */
std::mt19937 m_mtwister; /* mersenne_twister_engine, maybe seeded */
std::uniform_int_distribution<int> m_distribution;

public:

randomizer (int seed = -1) :
m_rd (), /* random device (opt.) */
m_mtwister (m_rd()), /* internal generator */
m_distribution (0, s_upper_limit) /* uniform int range */
{
if (seed != (-1))
m_mtwister.seed(seed);
}

int generate ()
{
return m_distribution(m_mtwister);
}

int generate (int range)
{
int rnd = generate();
long result = 2 * range * long(rnd) / long(s_upper_limit);
return int(result) - range;
}

};

Hasn't had any heavy testing, though. The primitive linear congruential
function rand() is good enough for light randomizing.

--
You will get what you deserve.

On 12/10/2023 12:19 PM, Relf wrote:

>> What do you use to get random numbers in a range ?
>
> #define Rand( Min, Max ) ( Min + ( Max - Min )*rand()/RAND_MAX )

Have you tested this?

It always returns 1, so I get results like this when building a random
date in the range of (2023,2026).

DFS Relf
1 2025-10-10 2023-01-01
2 2026-09-10 2023-01-01
3 2024-12-13 2023-01-01
4 2026-12-04 2023-01-01
5 2023-09-05 2023-01-01
6 2026-12-22 2023-01-01
7 2025-09-06 2023-01-01
8 2026-10-23 2023-01-01
9 2024-04-05 2023-01-01
10 2023-03-15 2023-01-01
....

On Sun, 10 Dec 2023 08:33:28 -0500, the DuFuS Supremus wrote:

>
> Any ideas?
>

What a pack of stupid fucks!

Here is how the Lord Master does it. The whole thing can be done
is a SINGLE FUCKING LINE of C code, but I have teased it out over
several lines for the benefit of you dumb shits.

Firstly, we need a PRNG that does not exhibit modulo bias. The GNU
C Library provides "arc4random_uniform" just for this purpose.

Secondly, we select a random day either before or after the Unix Epoch
of 1970-01-01:00:00:00 UTC. I have chosen a hundred year range either
before or after but one could have any number up to the limit, in days,
of uint32_t. (This is actually the Modified Julian Date.)

The code automatically converts from UTC to the timezone specified in
the TZ variable and accounts for leap years as well and also for Daylight
Saving time.

A quiz question for you lamentable dumb-fucks:

The PRNG in the code below has not been seeded. Why the fuck not?

Now, the magnificent code from the from the C Programmer Extraordinaire:
(This is just a one-shot. If you want more, then put it in a loop yourself
-- if you could even manage that. Ahahahaha!)

==========================================
Begin C code
==========================================

#define _GNU_SOURCE
#include <time.h>
#include <stdio.h>
#include <stdlib.h>

int main()
{ time_t mjd;
struct tm *local_time;
char rnd_date[20];

// Select a time span around the Unix epoch
// The discrete uniform distribution is only shifted and therefore no bias is introduced.

mjd = ((time_t)(arc4random_uniform(365*100*2)) - (time_t)(365*100)) * (time_t)86400;

local_time = localtime(&mjd);

strftime(rnd_date, sizeof(rnd_date), "%F", local_time);

fprintf(stdout, "Random Date: %s\n", rnd_date);

exit(0);

}

==========================================
End C code
==========================================

I should charge y'all $15,000 for this fantastic and supremely
efficient code, but the spirit of FOSS has gotten the better of me.

Farley Flud

Perl guru.

C programmer extraordinaire.

Assembly language genius.

We do thank you.

Ahahahahahahahahahahahahahahahahahahahahahahaha!

On 12/11/23 14:32, Farley Flud wrote:
<snip>
> Firstly, we need a PRNG that does not exhibit modulo bias. The GNU
> C Library provides "arc4random_uniform" just for this purpose.
<snip>

Well, I learned something.
--
user <candycane> is generated from /dev/urandom

..

it said snip so i did

On 12/11/2023 7:12 AM, Chris Ahlstrom wrote:
> Physfitfreak wrote this copyrighted missive and expects royalties:
>
>> On 12/10/2023 7:33 AM, DFS wrote:
>>>
>>> Generated 2M random dates via this code, compiled with:
>>> gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
>>>
>>> . . .
>>> Any ideas?
>>>
>>> What do you use to get random numbers in a range?
>>>
>>
>> Whatever way you choose, plot the results in 3D. If they don't spread
>> all over, it's not a good random number generator.
>>
>> Most of the generators are bad :)
>
> Check out C++:
>
> class randomizer
> {
> private:
>
> static const int s_upper_limit = std::numeric_limits<int>::max();
>
> std::random_device m_rd; /* seed source for random number engine */
> std::mt19937 m_mtwister; /* mersenne_twister_engine, maybe seeded */
> std::uniform_int_distribution<int> m_distribution;
>
> public:
>
> randomizer (int seed = -1) :
> m_rd (), /* random device (opt.) */
> m_mtwister (m_rd()), /* internal generator */
> m_distribution (0, s_upper_limit) /* uniform int range */
> {
> if (seed != (-1))
> m_mtwister.seed(seed);
> }
>
> int generate ()
> {
> return m_distribution(m_mtwister);
> }
>
> int generate (int range)
> {
> int rnd = generate();
> long result = 2 * range * long(rnd) / long(s_upper_limit);
> return int(result) - range;
> }
>
> };
>
> Hasn't had any heavy testing, though. The primitive linear congruential
> function rand() is good enough for light randomizing.
>

Show me the 3D distribution of a few thousand output numbers and I'd be
able to evaluate it. You would too :)

On 12/11/2023 2:32 PM, Farley Flud wrote:
> On Sun, 10 Dec 2023 08:33:28 -0500, the DuFuS Supremus wrote:
>
>>
>> Any ideas?
>>
>
> What a pack of stupid fucks!
>
> Here is how the Lord Master does it. The whole thing can be done
> is a SINGLE FUCKING LINE of C code, but I have teased it out over
> several lines for the benefit of you dumb shits.
>
> Firstly, we need a PRNG that does not exhibit modulo bias. The GNU
> C Library provides "arc4random_uniform" just for this purpose.
>
> Secondly, we select a random day either before or after the Unix Epoch
> of 1970-01-01:00:00:00 UTC. I have chosen a hundred year range either
> before or after but one could have any number up to the limit, in days,
> of uint32_t. (This is actually the Modified Julian Date.)
>
> The code automatically converts from UTC to the timezone specified in
> the TZ variable and accounts for leap years as well and also for Daylight
> Saving time.
>
> A quiz question for you lamentable dumb-fucks:
>
> The PRNG in the code below has not been seeded. Why the fuck not?
>
> Now, the magnificent code from the from the C Programmer Extraordinaire:
> (This is just a one-shot. If you want more, then put it in a loop yourself
> -- if you could even manage that. Ahahahaha!)
>
> ==========================================
> Begin C code
> ==========================================
>
> #define _GNU_SOURCE
> #include <time.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
> time_t mjd;
> struct tm *local_time;
> char rnd_date[20];
>
>
> // Select a time span around the Unix epoch
> // The discrete uniform distribution is only shifted and therefore no bias is introduced.
>
> mjd = ((time_t)(arc4random_uniform(365*100*2)) - (time_t)(365*100)) * (time_t)86400;
>
> local_time = localtime(&mjd);
>
> strftime(rnd_date, sizeof(rnd_date), "%F", local_time);
>
> fprintf(stdout, "Random Date: %s\n", rnd_date);
>
> exit(0);
>
> }
>
> ==========================================
> End C code
> ==========================================
>
> I should charge y'all $15,000 for this fantastic and supremely
> efficient code, but the spirit of FOSS has gotten the better of me.
>
> Farley Flud
>
> Perl guru.
>
> C programmer extraordinaire.
>
> Assembly language genius.
>
> We do thank you.
>
> Ahahahahahahahahahahahahahahahahahahahahahahaha!
>

Talk and code don't matter. Show me a 3D distribution of numbers
generated by it (each three consecutive, making the coordinates of one
point), then something about quality of the generator can be seen. Use
at least a few thousand points.

On Mon, 11 Dec 2023 18:46:17 -0600, Physfitfreak wrote:

>
> Talk and code don't matter. Show me a 3D distribution of numbers
> generated by it (each three consecutive, making the coordinates of one
> point), then something about quality of the generator can be seen. Use
> at least a few thousand points.
>

That kind of test applies only to a sequence of random numbers.
Exploring multi-dimensional distributions will indicate if there
are patters within the sequence.

The PRNG here, the arc4random_uniform(), produces a discrete
uniform distribution of integers. The only test is that, for
a very large sample size, each sample has equal frequency and
the average and variance match that of a DUD:

https://en.wikipedia.org/wiki/Discrete_uniform_distribution

On 12/11/2023 3:32 PM, Farley Flud wrote:

> we select a random day either before or after the Unix Epoch
> of 1970-01-01:00:00:00 UTC. I have chosen a hundred year range either
> before or after

You "chose" because of your inability to pass in a year-range:

2021,2025

> this fantastic

(without installing libbsd-dev your code wouldn't compile on my Ubuntu
install running on WSL. After installing the library, it still throws
warning "implicit declaration of function ‘arc4random_uniform’")

--------------------------------------------------------------
$ gcc -Wall speedtest_random_dates.c -o speeddates -lbsd
$ ./speeddates
generating random dates...

2000000 DFS dates generated in 0.25 seconds
2000000 Feeb dates generated in 1.72 seconds
done
--------------------------------------------------------------

> and supremely efficient code

0.25 vs 1.72? Looks extremely INefficient.

But... the arc4random() code is fewer lines and - even without my stupid
Feb anomaly - gives a better random distribution than rand(), so I would
use it (after altering it to accept any starting and ending year).

https://imgur.com/a/fw3L1Ag

On Tuesday, December 12, 2023 at 8:15:09 AM UTC-5, DFS wrote:

> You "chose" because of your inability to pass in a year-range:
>
> 2021,2025
>

Wrong yet again. I "chose" because that's the correct and proper way to do it.
The stupid string "20xx" means nothing in the digital context. Computer systems
are designed to deal with time as numbers of seconds from epoch.

You program like a fucking dress maker.

>
> (without installing libbsd-dev your code wouldn't compile on my Ubuntu
> install running on WSL. After installing the library, it still throws
> warning "implicit declaration of function ‘arc4random_uniform’")
>

What kind of shit, FUBAR system are you using?

That's what the first definition is for:

#define _GNU_SOURCE

The arc4random_uniform() function is a GNU extension and it requires that
definition.

Moreover, it does NOT require libbsd. That's why you got that stupid oddball
warning in the first place.

You program like a fucking dress maker.

You'll never get anywhere with anything.

> --------------------------------------------------------------
> $ gcc -Wall speedtest_random_dates.c -o speeddates -lbsd
>

OMFG! It's hard to believe that anybody could fuck this up so
fucking much!

Where the hell did that "-lbsd" shit come from?

Libbsd is NOT needed! Total idiot!

>
> 2000000 DFS dates generated in 0.25 seconds
> 2000000 Feeb dates generated in 1.72 seconds
> done
> --------------------------------------------------------------
>

This is also fucked up to high heaven.

The arc4random_uniform() requires system entropy in order to function.
On that piece-of-shit Microslop/Ubuntu set-up the entropy must be FUBAR
along with everything else.

You program like a fucking dress maker.

Furthermore, stay away from my fantastic, inimitable code. I don't want
a demented imbecile using even small parts of it.

On 12/12/2023 8:41 AM, Lord Master wrote:
> On Tuesday, December 12, 2023 at 8:15:09 AM UTC-5, DFS wrote:
>
>> You "chose" because of your inability to pass in a year-range:
>>
>> 2021,2025
>>
>
> Wrong yet again. I "chose" because that's the correct and proper way to do it.
> The stupid string "20xx" means nothing in the digital context. Computer systems
> are designed to deal with time as numbers of seconds from epoch.

wtf? epoch +- N years is NOT the right way to generate random dates in
a range.

You did it like a newb because you're too LAME to do it right: accept a
starting and ending year.

> You program like a fucking dress maker.

You mewled "If you want more, then put it in a loop yourself" because
you didn't know how to do it in a loop.

Nor do you know how to generate rands for a range, or write them to a
file, or to a database, or speedtest them, or measure their dispersion,
or do anything more than generate ONE random date at a time via
copy/pasting a few lines you found on a website that you pretend you wrote.

You have extremely weak programming skills, but you're a decent plagiarizer.

>> (without installing libbsd-dev your code wouldn't compile on my Ubuntu
>> install running on WSL. After installing the library, it still throws
>> warning "implicit declaration of function ‘arc4random_uniform’")
>>
>
> What kind of shit, FUBAR system are you using?

Linux.

> That's what the first definition is for:
>
> #define _GNU_SOURCE
>
> The arc4random_uniform() function is a GNU extension and it requires that
> definition.

> Moreover, it does NOT require libbsd. That's why you got that stupid oddball
> warning in the first place.

I installed libbsd AFTER your code threw that warning and failed to
compile. Someone online said it worked for them.

But it may have been due to the state of my new Ubuntu install.

> You program like a fucking dress maker.
>
> You'll never get anywhere with anything.

Get real. You claim to be a "C Programmer Extraordinaire" and in real
life you've gotten absolutely NOWHERE with C. Or perl. Or assembly.

Lucky you have Access and VBA to muddle through with.

On Tuesday, December 12, 2023 at 9:10:30 AM UTC-5, DFS wrote:

>
> wtf? epoch +- N years is NOT the right way to generate random dates in
> a range.
>

Post your retarded ideas on comp.lang.c and you will get ridiculed to death..

Well, actually you won't. Those people are far too inhibited to give you what
you deserve.

Unfortunately, C.O.L.A. does not contain any highly competent programmers
(other than myself) to tell you exactly what an abysmally stupid freak you
really are.

On 12/11/23 15:06, Relf wrote:
> DetroitsFinest:
>>> Firstly, we need a PRNG that does not exhibit modulo bias.
>
> Why ? no one is doing: "Rand%MaxRand" (modulo).
>
> "arc4random_uniform()" has more precision ( 32 bits, instead of 15 ).
> How does that help ?

Some people are bothered by modulo not having an equal chance to roll
each number, it tends to lower ones slightly. I don't personally care
but eh.

> Arter:

If you're going to shorten my name, I'd prefer candy or candycane

>> Well, I learned something.
>
> Did you ? Really ?

Yeah, I didn't know about the arc4 stuff. Seems useful, even if I don't
need it.
--
user <candycane> is generated from /dev/urandom

On 12/12/2023 9:44 AM, Lord Master wrote:
> On Tuesday, December 12, 2023 at 9:10:30 AM UTC-5, DFS wrote:
>
>>
>> wtf? epoch +- N years is NOT the right way to generate random dates in
>> a range.
>>
>
> Post your retarded ideas on comp.lang.c and you will get ridiculed to death.

"Select a time span around the Unix epoch"
"I have chosen a hundred year range"

LMFAO!!!!

The job is to generate random dates in any user-specified year range
begin..end, not start at 1970 and go +/- N years.

The result of generating 10M random dates with your 100-year shit-code
is dates between 1870-01-24 and 2069-12-05.

OMFG! What a fucking idiot.

You did it your bogus way because you didn't know how to set a start and
end year. Meaning the webpage you copied from didn't have such an example.

> Well, actually you won't. Those people are far too inhibited to give you what
> you deserve.

They're not inhibited. They're normal, helpful, decent people not angry
with the world like you are.

> Unfortunately, C.O.L.A. does not contain any highly competent programmers
> (other than myself) to tell you exactly what an abysmally stupid freak you
> really are.

Why do you think you're competent if you can't answer the actual
question ("What do you use to get random numbers in a range?"), but
instead try to morph it into something else and "solve" that?

On Tuesday, December 12, 2023 at 12:23:15 PM UTC-5, DFS wrote:

>
> The job is to generate random dates in any user-specified year range
> begin..end, not start at 1970 and go +/- N years.
>

I don't give a flying fuck about "the job." I gave an example of the correct
way to do it that can be applied to any situation.

If given a year as a string, e.g. "2020", then simply convert this string value
into the Unix time and go from there.

I won't show you how to do this. Let's see if you can figure it out.

The GNU C Library contains comprehensive facilities for processing time data
and these facilities automatically compensate for leap years, time zones, and
even leap seconds.

Only an idiot like you wastes effort by clumsily writing code to check for leap
years. Ahahahahaha! What a chump!

You also quite likely NEVER heard of Julian Dates or Modified Julian Dates
before I mentioned them in this thread. Again, that just shows how far removed
you actually are from the art of programming.