Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #148203

Re: Bart, a tcc "issue"

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>

Show all headers | View raw


"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


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