Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #148203
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Bart, a tcc "issue" |
| Date | 2019-11-28 16:03 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <86r21r8s75.fsf@linuxsc.com> (permalink) |
| References | <uRIwF.17878$kE3.891@fx36.iad> <bYoxF.132400$Ko9.64189@fx48.iad> <86k189ejbd.fsf@linuxsc.com> <qqbe35$lq0$1@gioia.aioe.org> |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 11/8/2019 8:59 PM, Tim Rentsch wrote:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 11/6/19 6:40 PM, DFS wrote:
>>>
>>>> I wrote a distribution of characters counter, and on tcc (0.9.26) on
>>>> Windows it always undercounts the last character in the set (9). If you
>>>> have tcc on Windows maybe you could test it. Doesn't happen on
>>>> gcc/MSYS2/Windows.
>>>
>>> This is a fundamental problem. A very simple version of it would be to
>>> try to take 12 apples and divide them into 5 (or 7) equal piles (without
>>> cutting any of them).
>>>
>>> The 12 apples are the RAND_MAX possible values.
>>>
>>> The 5 piles are the buckets you are putting them into.
>>>
>>> If the number of buckets doesn't exactly divide into the number of
>>> results you can get from the random number generator, the output won't
>>> be equally likely. This most noticeable when the number of possible
>>> numbers is smaller.
>>>
>>> The simplest solution would be to throw away a few of the random
>>> numbers, so that the number of 'usable' random numbers is a multiple of
>>> the number of buckets.
>>>
>>> The simple modification to the code is rather than using:
>>> (low + rand() / (RAND_MAX / (high - low + 1) + 1))
>>> use
>>> (low + rand() / (RAND_MAX / (high - low + 1)))
>>> and redraw if the result is > high.
>>
>> It's interesting -- three different people posted corrections or
>> improvements to the uniform interval code, and all of the revisions
>> have been a little bit off in one way or another. Care is needed to
>> deal with edge cases correctly.
>>
>> int
>> uniform_less_than( unsigned k ){
>> unsigned d, r;
>>
>> if( k-1 > RAND_MAX || k == 0 ) oops_someone_messed_up();
>>
>> d = (RAND_MAX - (k-1)) / k + 1;
>> do r = rand()/d; while( r >= k );
>>
>> return r;
>> }
>>
>> int
>> uniform_on_closed_interval( int a, int b ){
>> if( a > b ) return uniform_on_closed_interval( b, a );
>>
>> return a + uniform_less_than( b + 1u - a );
>> }
>>
>> A good test for a uniform closed-interval RNG is to check that
>> it handles the interval 0..RAND_MAX, including both endpoints,
>> correctly.
>
> Fwiw, off topic wrt integers, a while ago I just used an epsilon to
> deal with random intervals wrt rand(). Sometimes RAND_MAX does not get
> hit often enough for my needs, so I adjusted epsilon. Heck, is rand()
> even guaranteed to return RAND_MAX at all? [...]
Two comments.
One, if you want a random number generator with some guaranteed
minimal level of quality, don't use rand(). It's easy enough to
write a simple PRNG with an adequate minimal level of quality.
Two, if you want good floating-point values (of precision double
or higher), don't use rand(). The outputs of rand() are too
coarse to be a good source of 'double' values.
Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread
Bart, a tcc "issue" DFS <nospam@dfs.com> - 2019-11-06 18:40 -0500
Re: Bart, a tcc "issue" Bart <bc@freeuk.com> - 2019-11-07 00:03 +0000
Re: Bart, a tcc "issue" Bart <bc@freeuk.com> - 2019-11-07 00:06 +0000
Re: Bart, a tcc "issue" Bart <bc@freeuk.com> - 2019-11-07 01:44 +0000
Re: Bart, a tcc "issue" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-07 10:05 -0500
Re: Bart, a tcc "issue" DFS <nospam@dfs.com> - 2019-11-07 13:22 -0500
Re: Bart, a tcc "issue" DFS <nospam@dfs.com> - 2019-11-08 09:19 -0500
Re: Bart, a tcc "issue" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-08 11:03 -0500
Re: Bart, a tcc "issue" Manfred <noname@add.invalid> - 2019-11-07 18:22 +0100
Re: Bart, a tcc "issue" Manfred <noname@add.invalid> - 2019-11-07 18:30 +0100
Re: Bart, a tcc "issue" Richard Damon <Richard@Damon-Family.org> - 2019-11-08 20:51 -0500
Re: Bart, a tcc "issue" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 20:59 -0800
Re: Bart, a tcc "issue" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 23:16 +0000
Re: Bart, a tcc "issue" Richard Damon <Richard@Damon-Family.org> - 2019-11-09 20:27 -0500
Re: Bart, a tcc "issue" Bart <bc@freeuk.com> - 2019-11-10 01:38 +0000
Re: Bart, a tcc "issue" Richard Damon <Richard@Damon-Family.org> - 2019-11-09 20:59 -0500
Re: Bart, a tcc "issue" Keith Thompson <kst-u@mib.org> - 2019-11-09 19:22 -0800
Re: Bart, a tcc "issue" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 03:04 +0000
Re: Bart, a tcc "issue" Richard Damon <Richard@Damon-Family.org> - 2019-11-09 23:04 -0500
Re: Bart, a tcc "issue" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 13:15 +0000
Re: Bart, a tcc "issue" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 06:04 -0800
Re: Bart, a tcc "issue" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 07:49 -0800
Re: Bart, a tcc "issue" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 17:49 +0000
Re: Bart, a tcc "issue" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-11 02:44 -0800
Re: Bart, a tcc "issue" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-11 13:57 -0500
Re: Bart, a tcc "issue" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 16:51 -0800
Re: Bart, a tcc "issue" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:03 -0800
csiph-web