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

Groups > comp.lang.c > #139043 > unrolled thread

Multi-channel rand()

Back to article view | Back to comp.lang.c

Contents

  Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 19:54 -0500
    Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-24 19:38 -0800
    Re: Multi-channel rand() nobody@example.org (Scott) - 2018-12-25 04:05 +0000
      Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-24 23:57 -0500
        Re: Multi-channel rand() Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-25 09:22 +0000
          Professional coders??? (Was: Multi-channel rand()) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-25 10:09 +0000
          Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-25 07:59 -0500
            Re: Multi-channel rand() Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2018-12-25 21:59 +0000
              Re: Multi-channel rand() nobody@example.org (Scott) - 2018-12-26 02:43 +0000
        Re: Multi-channel rand() rbowman <bowman@montana.com> - 2018-12-25 10:15 -0700
          Re: Multi-channel rand() Keith Thompson <kst-u@mib.org> - 2018-12-25 10:14 -0800
    Re: Multi-channel rand() Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-12-25 13:35 +0300
      Re: Multi-channel rand() fir <profesor.fir@gmail.com> - 2018-12-25 02:56 -0800
      Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-25 08:02 -0500
    Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-25 11:52 +0000
      Re: Multi-channel rand() Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-12-25 14:58 +0300
      Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-25 06:59 -0500
        Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-25 08:05 -0500
      Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-25 08:04 -0500
    Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-26 15:48 +0000
      Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 07:58 -0800
        Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 12:06 -0500
          Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 12:45 -0500
            Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 13:20 -0500
              Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 10:30 -0800
                Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-26 11:35 -0800
                  Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 14:52 -0500
                Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 16:31 -0500
                  Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 22:28 -0500
                  Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-30 20:42 -0800
              Re: Multi-channel rand() Keith Thompson <kst-u@mib.org> - 2018-12-26 15:32 -0800
            Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-26 19:38 +0000
              Re: Multi-channel rand() Keith Thompson <kst-u@mib.org> - 2018-12-26 15:35 -0800
          Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 12:59 -0500
            Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 16:05 -0500
          Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 13:08 -0500
            Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 15:50 -0500
        Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-26 17:42 +0000
          Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 12:48 -0500
          Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 12:58 -0500
            Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-26 19:03 +0000
              Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 14:45 -0500
                Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-26 20:46 +0000
                  Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 16:25 -0500
                    Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 17:13 -0500
                      Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-26 22:23 -0500
                    Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-26 23:39 +0000
                  Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 17:36 -0500
              Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 16:27 -0500
      Re: Multi-channel rand() rbowman <bowman@montana.com> - 2018-12-26 19:19 -0700
        Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-26 22:17 -0500
        Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-26 19:32 -0800
        Re: Multi-channel rand() Keith Thompson <kst-u@mib.org> - 2018-12-26 19:34 -0800
          Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-27 11:29 +0000
            Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 05:27 -0800
              Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 09:41 -0500
                Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 09:42 -0500
                  Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 07:01 -0800
                    Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 10:28 -0500
                      Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-27 10:48 -0500
                        Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 11:08 -0500
                          Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-27 13:49 -0800
                            Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 17:18 -0500
                              Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-29 13:59 -0800
                                Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-30 14:01 -0800
                                  Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-30 22:07 +0000
                                  Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-30 17:20 -0500
                          Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-27 17:47 -0500
                            Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-30 20:45 -0800
                      Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 08:22 -0800
                        Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 11:40 -0500
                          Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 09:21 -0800
                            Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 12:45 -0500
                              Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 10:57 -0800
                                Re: Multi-channel rand() "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 14:35 -0500
                                Re: Multi-channel rand() Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 09:25 -0800
                                  Re: Multi-channel rand() Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 09:55 -0800
                                Re: Multi-channel rand() Keith Thompson <kst-u@mib.org> - 2018-12-28 12:36 -0800
                        Re: Multi-channel rand() Robert Wessel <robertwessel2@yahoo.com> - 2018-12-27 20:34 -0600
                Re: Multi-channel rand() Richard Damon <Richard@Damon-Family.org> - 2018-12-27 10:37 -0500
              Re: Multi-channel rand() Bart <bc@freeuk.com> - 2018-12-27 14:46 +0000
                Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 07:05 -0800
                  Re: Multi-channel rand() Keith Thompson <kst-u@mib.org> - 2018-12-27 11:28 -0800
                    Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 12:07 -0800
                      Re: Multi-channel rand() Keith Thompson <kst-u@mib.org> - 2018-12-27 12:47 -0800
                        Re: Multi-channel rand() James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 14:47 -0800
    Re: Multi-channel rand() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-26 11:58 -0800

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#139129

On 12/27/2018 10:48 AM, Richard Damon wrote:
> On 12/27/18 10:28 AM, Rick C. Hodgin wrote:
>>
>> I did.  It seems an undesirable solution due to the spill/fill overhead,
>> so I discounted it as a viable solution for me.
>>
>> I was able to get the solution working based on Chris Thomasson's link
>> to the Permuted Congruential Generator (say that five times fast).
>>
>>      https://en.wikipedia.org/wiki/Permuted_congruential_generator
>>
>> The code there can be modified easily to point to inputs for its "in-
>> ternal" values.  No spill/fill required.
>>
>> I think this type of solution is what should've been included in the
>> C standard's implementation.  I think the need to potentially draw
>> multiple independently seeded pseudo-random values is a real need in
>> some coding models.  And it's very little additional work to add the
>> ability natively.
> 
> In my experience, most of the time I want multiple independent random
> sequences, what I also need is stability of algorithm, so that the
> random number sequence will be consistent, even if I recompile with a
> new version, or different implementation. This means that I can't use a
> library function where the exact algorithm isn't specified, so I need to
> include my own function so I KNOW that sequence will be stable.

I think that could be a consideration.  Another view would be simply
that it has to be consistent, so if on one platform it's consistent
on that platform, and on another it's consistent there, even if the
two are different... it may be sufficient.

I think for general purpose prng a built-in rand() would be sufficient.
In my case, I've coded for nearly 30 years in C and this is the first
time I've ever needed a more advanced prng algorithm.  The type of cod-
ing I've done just didn't require it.

It was nice to find this algorithm.  I plan to examine its output and
possibly change again if it's insufficient.  But, I can tell you that
game play was markedly improved just by this one change.

BTW, I'm not a gamer.  Never have been.  My mind doesn't think quickly
on visual input.  I can't respond to things happening quickly (part of
my dyslexia I assume).  I actually get nauseous playing 3D games.  My
son shows me Minecraft scenes and I have to close my eyes until he gets
to the place to show me.

It's a matter of some irony I'm writing this game in the first place.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139142

On 12/27/2018 8:08 AM, Rick C. Hodgin wrote:
> On 12/27/2018 10:48 AM, Richard Damon wrote:
>> On 12/27/18 10:28 AM, Rick C. Hodgin wrote:
>>>
>>> I did.  It seems an undesirable solution due to the spill/fill overhead,
>>> so I discounted it as a viable solution for me.
>>>
>>> I was able to get the solution working based on Chris Thomasson's link
>>> to the Permuted Congruential Generator (say that five times fast).
>>>
>>>      https://en.wikipedia.org/wiki/Permuted_congruential_generator
>>>
>>> The code there can be modified easily to point to inputs for its "in-
>>> ternal" values.  No spill/fill required.
>>>
>>> I think this type of solution is what should've been included in the
>>> C standard's implementation.  I think the need to potentially draw
>>> multiple independently seeded pseudo-random values is a real need in
>>> some coding models.  And it's very little additional work to add the
>>> ability natively.
>>
>> In my experience, most of the time I want multiple independent random
>> sequences, what I also need is stability of algorithm, so that the
>> random number sequence will be consistent, even if I recompile with a
>> new version, or different implementation. This means that I can't use a
>> library function where the exact algorithm isn't specified, so I need to
>> include my own function so I KNOW that sequence will be stable.
> 
> I think that could be a consideration.  Another view would be simply
> that it has to be consistent, so if on one platform it's consistent
> on that platform, and on another it's consistent there, even if the
> two are different... it may be sufficient.

Fwiw, usually when I want a PRNG stream to be consistent, a given seed 
is used to reproduce the same data. Actually had to do this for each run 
of an experimental algorithm to get an animation that did not look like 
a bunch of jumping static. Fwiw, take a look at the difference between 
the two animations:

// seeds before each iteration - smoother
https://youtu.be/8mnjzIiizRU


// uses a random seed for each iteration - jumpy!
https://youtu.be/ljeN7dYNHhQ


Notice any differences wrt the graphics? One looks smooth, the other 
shows some artifacts indeed, it sort of sparkles. Humm...


Even in a per-thread instance of a prng, we can get consistency by 
seeding each thread with a seed derived from a known list of seeds. Or, 
for hard core debugging, seed each thread with the same state. :^o


> I think for general purpose prng a built-in rand() would be sufficient.
> In my case, I've coded for nearly 30 years in C and this is the first
> time I've ever needed a more advanced prng algorithm.  The type of cod-
> ing I've done just didn't require it.
Yeah, it has been perfectly fine for a lot of my programs as well.


> It was nice to find this algorithm.  I plan to examine its output and
> possibly change again if it's insufficient.  But, I can tell you that
> game play was markedly improved just by this one change.

So far, so good: That is great to hear Rick! :^)


> BTW, I'm not a gamer.  Never have been.  My mind doesn't think quickly
> on visual input.  I can't respond to things happening quickly (part of
> my dyslexia I assume).  I actually get nauseous playing 3D games.  My
> son shows me Minecraft scenes and I have to close my eyes until he gets
> to the place to show me.
> 
> It's a matter of some irony I'm writing this game in the first place.

Is it a 2d or 3d game? Or, a little of both? ;^)

[toc] | [prev] | [next] | [standalone]

#139143

On 12/27/2018 4:49 PM, Chris M. Thomasson wrote:
> On 12/27/2018 8:08 AM, Rick C. Hodgin wrote:
>> It's a matter of some irony I'm writing this game in the first place.
> Is it a 2d or 3d game? Or, a little of both? ;^)

I'm slated to write 15 games.  This one is 2D.  Others will be 2D,
2.5D, and 3D.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139223

On 12/27/2018 2:18 PM, Rick C. Hodgin wrote:
> On 12/27/2018 4:49 PM, Chris M. Thomasson wrote:
>> On 12/27/2018 8:08 AM, Rick C. Hodgin wrote:
>>> It's a matter of some irony I'm writing this game in the first place.
>> Is it a 2d or 3d game? Or, a little of both? ;^)
> 
> I'm slated to write 15 games.  This one is 2D.  Others will be 2D,
> 2.5D, and 3D.
> 

The 2.5 sounds the most fractal indeed Rick. The infinite dimensions 
between two unsigned integer dimensions. The interval [2...4] can 
contain 2.5, 2.6, PI, an infinite amount of interesting things... sqrt(7)?

Think of a fractally generated level of a game, that can be described by 
a simple formula and a zoom level. Saving a game should be a fairly 
small chunk of data.

Btw, keep CAlive in mind while developing these games. New Years 2019!

:^)

[toc] | [prev] | [next] | [standalone]

#139262

On 12/29/2018 1:59 PM, Chris M. Thomasson wrote:
> On 12/27/2018 2:18 PM, Rick C. Hodgin wrote:
>> On 12/27/2018 4:49 PM, Chris M. Thomasson wrote:
>>> On 12/27/2018 8:08 AM, Rick C. Hodgin wrote:
>>>> It's a matter of some irony I'm writing this game in the first place.
>>> Is it a 2d or 3d game? Or, a little of both? ;^)
>>
>> I'm slated to write 15 games.  This one is 2D.  Others will be 2D,
>> 2.5D, and 3D.
>>
> 
> The 2.5 sounds the most fractal indeed Rick. The infinite dimensions 
> between two unsigned integer dimensions. The interval [2...4] can 
> contain 2.5, 2.6, PI, an infinite amount of interesting things... sqrt(7)?
> 
> Think of a fractally generated level of a game, that can be described by 
> a simple formula and a zoom level. Saving a game should be a fairly 
> small chunk of data.
> 
> Btw, keep CAlive in mind while developing these games. New Years 2019!

Wait a minute, are you developing these games using a private, pre-alpha 
in-house implementation of CAlive?

[toc] | [prev] | [next] | [standalone]

#139263

On 30/12/2018 22:01, Chris M. Thomasson wrote:
> On 12/29/2018 1:59 PM, Chris M. Thomasson wrote:
>> On 12/27/2018 2:18 PM, Rick C. Hodgin wrote:
>>> On 12/27/2018 4:49 PM, Chris M. Thomasson wrote:
>>>> On 12/27/2018 8:08 AM, Rick C. Hodgin wrote:
>>>>> It's a matter of some irony I'm writing this game in the first place.
>>>> Is it a 2d or 3d game? Or, a little of both? ;^)
>>>
>>> I'm slated to write 15 games.  This one is 2D.  Others will be 2D,
>>> 2.5D, and 3D.
>>>
>>
>> The 2.5 sounds the most fractal indeed Rick. The infinite dimensions 
>> between two unsigned integer dimensions. The interval [2...4] can 
>> contain 2.5, 2.6, PI, an infinite amount of interesting things... 
>> sqrt(7)?
>>
>> Think of a fractally generated level of a game, that can be described 
>> by a simple formula and a zoom level. Saving a game should be a fairly 
>> small chunk of data.
>>
>> Btw, keep CAlive in mind while developing these games. New Years 2019!
> 
> Wait a minute, are you developing these games using a private, pre-alpha 
> in-house implementation of CAlive?
> 

What do you think?

CAlive would have /had/ exactly the set of random functions needed.

[toc] | [prev] | [next] | [standalone]

#139266

On 12/30/2018 5:01 PM, Chris M. Thomasson wrote:
> Wait a minute, are you developing these games using a private, pre-alpha 
> in-house implementation of CAlive?

No.  I am targeting other platforms and I'm using Visual Studio for
base development, and then a wide range of tools for their porting to
other platforms.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139145

On 12/27/18 11:08 AM, Rick C. Hodgin wrote:
> 
> BTW, I'm not a gamer.  Never have been.  My mind doesn't think quickly
> on visual input.  I can't respond to things happening quickly (part of
> my dyslexia I assume).  I actually get nauseous playing 3D games.  My
> son shows me Minecraft scenes and I have to close my eyes until he gets
> to the place to show me.
> 
> It's a matter of some irony I'm writing this game in the first place.

Ive found that it isn't that rare for a designer/coder for a game to not
be that good at playing them. They do need testers that are to see how
they got some of the details, but the reactions and processing needed to
play the games are not the key skills needed to play them.

[toc] | [prev] | [next] | [standalone]

#139276

On 12/27/2018 2:47 PM, Richard Damon wrote:
> On 12/27/18 11:08 AM, Rick C. Hodgin wrote:
>>
>> BTW, I'm not a gamer.  Never have been.  My mind doesn't think quickly
>> on visual input.  I can't respond to things happening quickly (part of
>> my dyslexia I assume).  I actually get nauseous playing 3D games.  My
>> son shows me Minecraft scenes and I have to close my eyes until he gets
>> to the place to show me.
>>
>> It's a matter of some irony I'm writing this game in the first place.
> 
> Ive found that it isn't that rare for a designer/coder for a game to not
> be that good at playing them. They do need testers that are to see how
> they got some of the details, but the reactions and processing needed to
> play the games are not the key skills needed to play them.
> 

Coder: what a game.

Gamer: Easy, whats next?

Coder: Ahh shi%

[toc] | [prev] | [next] | [standalone]

#139130

On Thursday, December 27, 2018 at 10:27:13 AM UTC-5, Rick C. Hodgin wrote:
> On 12/27/2018 10:01 AM, James Kuyper wrote:
> > On Thursday, December 27, 2018 at 9:41:20 AM UTC-5, Rick C. Hodgin wrote:
> >> On 12/27/2018 9:41 AM, Rick C. Hodgin wrote:
...
> >>> Given the implementation of the algorithm, I'm surprised they didn't
> >>> provide a native one that uses pointers to external values so you can
> >>> have multiple rand() seeds and sources all working together.
> > 
> > If POSIX functions are an acceptable solution, then, as Scott has
> > already pointed out, the initstate() and setstate() functions can be
> > used to make random() use different sets of state information, totally
> > under your control. You responded to his message with a message about a
> > Windows function, so it's not clear whether you noticed that part of
> > what he was saying.
> 
> I did.  It seems an undesirable solution due to the spill/fill overhead,
> so I discounted it as a viable solution for me.
> 
> I was able to get the solution working based on Chris Thomasson's link
> to the Permuted Congruential Generator (say that five times fast).
> 
>      https://en.wikipedia.org/wiki/Permuted_congruential_generator
> 
> The code there can be modified easily to point to inputs for its "in-
> ternal" values.  No spill/fill required.

I don't understand the spill/fill problem you're thinking of. Let me
give an example, and then you can use that example to show me where the
spilling and filling that is bothering you occurs:

    #define CHANNELS 25
    #define RANDOM_STATE_SIZE 64
    char random_state[CHANNELS][RANDOM_STATE_SIZE];

At startup:
    initstate(seed, random_state[channel],
        sizeof random_state[channel]);

When random numbers are needed for a given channel:

      setstate(random_state[channel]);
      for(die = 0; die < num_dice; die++)
          dice[die] = random()*6/0x8000000;

I'd guessed from your original question that you were thinking of
something like this:

    random_handle_type handle[CHANNELS];

At startup:
    handle[channel] = initialize_random_generator(seed);

When random numbers are needed:
    for(die=0; die < num_dice; die++)
        dice[die] = random_number(handle[channel]);

Please note that what random_number(handle[channel]) does internally
with it's handle[channel] might be exactly the same as what
set_state(random_state[channel]) does with random_state[channel].

[toc] | [prev] | [next] | [standalone]

#139132

On 12/27/2018 11:22 AM, James Kuyper wrote:
> On Thursday, December 27, 2018 at 10:27:13 AM UTC-5, Rick C. Hodgin wrote:
>> On 12/27/2018 10:01 AM, James Kuyper wrote:
>>> On Thursday, December 27, 2018 at 9:41:20 AM UTC-5, Rick C. Hodgin wrote:
>>>> On 12/27/2018 9:41 AM, Rick C. Hodgin wrote:
> ...
>>>>> Given the implementation of the algorithm, I'm surprised they didn't
>>>>> provide a native one that uses pointers to external values so you can
>>>>> have multiple rand() seeds and sources all working together.
>>>
>>> If POSIX functions are an acceptable solution, then, as Scott has
>>> already pointed out, the initstate() and setstate() functions can be
>>> used to make random() use different sets of state information, totally
>>> under your control. You responded to his message with a message about a
>>> Windows function, so it's not clear whether you noticed that part of
>>> what he was saying.
>>
>> I did.  It seems an undesirable solution due to the spill/fill overhead,
>> so I discounted it as a viable solution for me.
>>
>> I was able to get the solution working based on Chris Thomasson's link
>> to the Permuted Congruential Generator (say that five times fast).
>>
>>       https://en.wikipedia.org/wiki/Permuted_congruential_generator
>>
>> The code there can be modified easily to point to inputs for its "in-
>> ternal" values.  No spill/fill required.
>
> I don't understand the spill/fill problem you're thinking of. Let me
> give an example, and then you can use that example to show me where the
> spilling and filling that is bothering you occurs:
> 
>      #define CHANNELS 25
>      #define RANDOM_STATE_SIZE 64
>      char random_state[CHANNELS][RANDOM_STATE_SIZE];
> 
> At startup:
>      initstate(seed, random_state[channel],
>          sizeof random_state[channel]);
> 
> When random numbers are needed for a given channel:
> 
>        setstate(random_state[channel]);
>        for(die = 0; die < num_dice; die++)
>            dice[die] = random()*6/0x8000000;


I did not investigate initstate() and setstate().  I assumed they
were copying external values into the internal state used by the
rand() function, so that rand() would work on its own internal
variables.  What you show above indicates it stores pointers to
the external data and is similar to what I was searching for.

I would prefer to use similar to as you indicate below:

     // An actual type called random_state which includes every-
     // thing it needs for its internal processing.
     random_state rs[CHANNELS];

     // Initialize them at startup
     for (i = 0; i < CHANNELS; ++i)
         initstate(seed, &rs[i]);

     // Use them in code as needed
     whatever = random(&rs[CHANNEL_2]);

Although in reality I would have it be like this:

     random_state input1;
     random_state input2;

And would use them in code:

     whatever1 = random(&input1);
     whatever2 = random(&input2);

> I'd guessed from your original question that you were thinking of
> something like this:
> 
>      random_handle_type handle[CHANNELS];
> 
> At startup:
>      handle[channel] = initialize_random_generator(seed);
> 
> When random numbers are needed:
>      for(die=0; die < num_dice; die++)
>          dice[die] = random_number(handle[channel]);
> 
> Please note that what random_number(handle[channel]) does internally
> with it's handle[channel] might be exactly the same as what
> set_state(random_state[channel]) does with random_state[channel].

Very similar.

I forget sometimes that C doesn't require explicit casting. :-)
There are times I miss that using my C++ compiler for mostly C
code.  It's one of the things I allow in CAlive (an option to
turn off explicit cast requirements), and I also create a new
void type called "any" that allows casting to any other type
without needing to have an explicit cast if you keep explicit
cast requirements enabled.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139133

On Thursday, December 27, 2018 at 11:39:30 AM UTC-5, Rick C. Hodgin wrote:
> On 12/27/2018 11:22 AM, James Kuyper wrote:
...
> > I don't understand the spill/fill problem you're thinking of. Let me
> > give an example, and then you can use that example to show me where the
> > spilling and filling that is bothering you occurs:
> > 
> >      #define CHANNELS 25
> >      #define RANDOM_STATE_SIZE 64
> >      char random_state[CHANNELS][RANDOM_STATE_SIZE];
> > 
> > At startup:
> >      initstate(seed, random_state[channel],
> >          sizeof random_state[channel]);
> > 
> > When random numbers are needed for a given channel:
> > 
> >        setstate(random_state[channel]);
> >        for(die = 0; die < num_dice; die++)
> >            dice[die] = random()*6/0x8000000;
> 
> 
> I did not investigate initstate() and setstate().  I assumed they
> were copying external values into the internal state used by the
> rand() function, so that rand() would work on its own internal
> variables.  What you show above indicates it stores pointers to
> the external data and is similar to what I was searching for.

Nit: this is a POSIX feature, which controls the behavior of random(),
not rand().
I would guess that random() has, internally, a pointer to the the state
array that it uses, and that setstate() does nothing more complicated
than resetting the value of the pointer, and returning the value it
previously held.

> I would prefer to use similar to as you indicate below:
> 
>      // An actual type called random_state which includes every-
>      // thing it needs for its internal processing.
>      random_state rs[CHANNELS];
> 
>      // Initialize them at startup
>      for (i = 0; i < CHANNELS; ++i)
>          initstate(seed, &rs[i]);
> 
>      // Use them in code as needed
>      whatever = random(&rs[CHANNEL_2]);

I don't see any significant difference between those interfaces -
random_state could be a typedef for char[RANDOM_STATE_SIZE] - looking at
it the other way around, RANDOM_STATE_SIZE could equal
sizeof(random_state). The main difference is that POSIX allows you to
specify the size of the state array: the speed of random() should be
roughly linear with the array size, while the repetition period of the
resulting sequence of random numbers should be exponential with the
array size: you can choose the size/period trade-off that's optimum for
your application.

> Although in reality I would have it be like this:
> 
>      random_state input1;
>      random_state input2;
> 
> And would use them in code:
> 
>      whatever1 = random(&input1);
>      whatever2 = random(&input2);

That's no problem - the equivalent would be 
       char[RANDOM_STATE_SIZE1] input1;
       char[RANDOM_STATE_SIZE2] input2;

       setstate(input1);
       whatever1 = random();
       setstate(input2);
       whatever2 = random();

It's slightly more complicated, but not much (and if that bothers you,
you could always create a wrapper function to hide the complications).
       
> > I'd guessed from your original question that you were thinking of
> > something like this:
> > 
> >      random_handle_type handle[CHANNELS];
> > 
> > At startup:
> >      handle[channel] = initialize_random_generator(seed);
> > 
> > When random numbers are needed:
> >      for(die=0; die < num_dice; die++)
> >          dice[die] = random_number(handle[channel]);
> > 
> > Please note that what random_number(handle[channel]) does internally
> > with it's handle[channel] might be exactly the same as what
> > set_state(random_state[channel]) does with random_state[channel].
> 
> Very similar.
> 
> I forget sometimes that C doesn't require explicit casting. :-)

It often does require explicit casting, when types differ, depending
upon how they differ and the context. I deliberately implied that
everything was defined to have precisely the required type, so there was
no need for any type conversions (which, when feasible, is a good idea
in both C and C++). I'm curious - where would you have expected casting
to have occurred, if this hadn't been C?

[toc] | [prev] | [next] | [standalone]

#139135

On 12/27/2018 12:21 PM, James Kuyper wrote:
> ...I'm curious - where would you have expected casting
> to have occurred, if this hadn't been C?

Nowhere.  In my code I always use things like &rs[i] so that it's
conveyed on the source code line that it's a pointer.  And in CAlive
there's an option to require that type of explicit casting.  I even
added the @ symbol in CAlive to convey something that's conveyed
using an reference type:

     void example(int& v)
     {
         printf("%d\n", v);
     }

     // Use in code:
     int i = 5;
     example(@v);

It lets the developer know it's being passed by reference, or that
it's a pointer, from the source code line without looking into the
target.

Seeing no "&" there in your code reminded me that it's auto-convert-
ing, and then I had the follow-on thought about C not requiring ex-
plicit casting.  Made me smile for a moment.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139137

On Thursday, December 27, 2018 at 12:44:31 PM UTC-5, Rick C. Hodgin wrote:
> On 12/27/2018 12:21 PM, James Kuyper wrote:
> > ...I'm curious - where would you have expected casting
> > to have occurred, if this hadn't been C?
> 
> Nowhere.  In my code I always use things like &rs[i] so that it's
> conveyed on the source code line that it's a pointer.  And in CAlive
> there's an option to require that type of explicit casting.

That's not casting. All casting is explicit, and always involves a type
name surrounded by parentheses. It's also not a type conversion, which
can occur implicitly. The expression &rs[0] has a different type than rs
itself, and implicitly going from rs to &rs[0] is described by 6.3.2.1p3
as a conversion, but it's not a type conversion.

...
> Seeing no "&" there in your code reminded me that it's auto-convert-
> ing, and then I had the follow-on thought about C not requiring ex-
> plicit casting.  Made me smile for a moment.

I think I understand what you're referring to now: I used
setstate(random_channel[channel]), whereas I suspect that you would have
used setstate(&random_channel[channel][0]). Because expressions of the
form &array[0] and &array[i] would otherwise have been annoyingly
common, the designers of C specified that, in most circumstances,
lvalues of array type get implicitly converted into pointers to their
initial element, which simplified the use of the language, by allowing
such expressions to be replaced by array and array+i, respectively. It
also allows subscripting an array to be described as nothing more than a
special case of pointer subscripting. The cost of this decision has been
a little bit of confusion for C newbies (and an immense amount of
confusion for BartC).

Of course, both pieces of code perform that same implicit conversion on
random_channel itself. However, neither version of this code involves a
cast which always involves a type name surrounded by parentheses, nor a
type conversion - it's just array element selection and taking an
address.

[toc] | [prev] | [next] | [standalone]

#139139

On 12/27/2018 1:57 PM, James Kuyper wrote:
> Of course, both pieces of code perform that same implicit conversion on
> random_channel itself. However, neither version of this code involves a
> cast which always involves a type name surrounded by parentheses, nor a
> type conversion - it's just array element selection and taking an
> address.

I appreciate your explanation, but like Bartc, I think of things dif-
ferently because I have not come from a C-way-of-doing-things back-
ground, but rather an assembly background (not saying that's how Bartc
came into things, but only me) ...  I look at how inside the CPU it-
self it wields data, and what's required mechanically to make it happen.
As such, I often say things wrong, or think of things differently, than
would a C developer / compiler author.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#139179

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> The expression &rs[0] has a different type than rs itself, and
> implicitly going from rs to &rs[0] is described by 6.3.2.1p3 as a
> conversion, but it's not a type conversion.

You may not think of it as a type conversion, but the ISO C
standard does refer to it using that phrase.

Reference:  N1570, page 660, top of left right-hand column
(index entry for 'array' continued from previous page).

[toc] | [prev] | [next] | [standalone]

#139182

Tim Rentsch <txr@alumni.caltech.edu> writes:

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> The expression &rs[0] has a different type than rs itself, and
>> implicitly going from rs to &rs[0] is described by 6.3.2.1p3 as a
>> conversion, but it's not a type conversion.
>
> You may not think of it as a type conversion, but the ISO C
> standard does refer to it using that phrase.
>
> Reference:  N1570, page 660, top of left right-hand column
> (index entry for 'array' continued from previous page).

Of course that was supposed to be top of left-hand column.

[toc] | [prev] | [next] | [standalone]

#139190

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On Thursday, December 27, 2018 at 12:44:31 PM UTC-5, Rick C. Hodgin wrote:
>> On 12/27/2018 12:21 PM, James Kuyper wrote:
>> > ...I'm curious - where would you have expected casting
>> > to have occurred, if this hadn't been C?
>> 
>> Nowhere.  In my code I always use things like &rs[i] so that it's
>> conveyed on the source code line that it's a pointer.  And in CAlive
>> there's an option to require that type of explicit casting.
>
> That's not casting. All casting is explicit, and always involves a type
> name surrounded by parentheses. It's also not a type conversion, which
> can occur implicitly. The expression &rs[0] has a different type than rs
> itself, and implicitly going from rs to &rs[0] is described by 6.3.2.1p3
> as a conversion, but it's not a type conversion.
[...]

The standard's use of the word "conversion" is a bit tricky.  My own
preference would be for it to refer only to a run-time operation
that takes a value of one type and yields a corresponding value
of a possibly different type, but the standard uses it in a wider
sense than that.

6.3.2.1p2 defines an *lvalue conversion*, which converts an lvalue
(an expression that designates an object) to "the value stored in
the designated object".

6.3.2.1p3 defines the notorious array-to-pointer conversion, and
p4 defines the conversion of a function designator to a pointer
expression.

All these conversions operate on *expressions*, not on *values*,
and they all occur at compile time.  They don't act like other
type conversions; for example, the result of an array-to-pointer
conversion has nothing to do with the value of the original array
expression.

6.7.6.3 says that parameters of array or function type are "adjusted"
to pointer type.  In my opinion, it would have made more sense for
the expression-to-expression "conversions" defined in 6.3.2.1 to
be described instead as "adjustments".

Note also that these conversions/adjustments cannot be expressed as
casts.

(And of course "%d" is a "conversion specification", but I don't
think anyone is confused by that.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139151

On Thu, 27 Dec 2018 08:22:49 -0800 (PST), James Kuyper
<jameskuyper@alumni.caltech.edu> wrote:

>On Thursday, December 27, 2018 at 10:27:13 AM UTC-5, Rick C. Hodgin wrote:
>> On 12/27/2018 10:01 AM, James Kuyper wrote:
>> > On Thursday, December 27, 2018 at 9:41:20 AM UTC-5, Rick C. Hodgin wrote:
>> >> On 12/27/2018 9:41 AM, Rick C. Hodgin wrote:
>...
>> >>> Given the implementation of the algorithm, I'm surprised they didn't
>> >>> provide a native one that uses pointers to external values so you can
>> >>> have multiple rand() seeds and sources all working together.
>> > 
>> > If POSIX functions are an acceptable solution, then, as Scott has
>> > already pointed out, the initstate() and setstate() functions can be
>> > used to make random() use different sets of state information, totally
>> > under your control. You responded to his message with a message about a
>> > Windows function, so it's not clear whether you noticed that part of
>> > what he was saying.
>> 
>> I did.  It seems an undesirable solution due to the spill/fill overhead,
>> so I discounted it as a viable solution for me.
>> 
>> I was able to get the solution working based on Chris Thomasson's link
>> to the Permuted Congruential Generator (say that five times fast).
>> 
>>      https://en.wikipedia.org/wiki/Permuted_congruential_generator
>> 
>> The code there can be modified easily to point to inputs for its "in-
>> ternal" values.  No spill/fill required.
>
>I don't understand the spill/fill problem you're thinking of. Let me
>give an example, and then you can use that example to show me where the
>spilling and filling that is bothering you occurs:
>
>    #define CHANNELS 25
>    #define RANDOM_STATE_SIZE 64
>    char random_state[CHANNELS][RANDOM_STATE_SIZE];
>
>At startup:
>    initstate(seed, random_state[channel],
>        sizeof random_state[channel]);
>
>When random numbers are needed for a given channel:
>
>      setstate(random_state[channel]);
>      for(die = 0; die < num_dice; die++)
>          dice[die] = random()*6/0x8000000;
>
>I'd guessed from your original question that you were thinking of
>something like this:
>
>    random_handle_type handle[CHANNELS];
>
>At startup:
>    handle[channel] = initialize_random_generator(seed);
>
>When random numbers are needed:
>    for(die=0; die < num_dice; die++)
>        dice[die] = random_number(handle[channel]);
>
>Please note that what random_number(handle[channel]) does internally
>with it's handle[channel] might be exactly the same as what
>set_state(random_state[channel]) does with random_state[channel].


Potentially a simpler approach is to not generate random numbers based
on state, but to perform a difficult to predict transformation of an
input.  That input would just be a 32-bit number (or whatever suits
your purpose), and you'd have some transformation applied to that.  To
generate pretty high quality pseudo random numbers, you could use that
value as input to AES in CTR mode, for example.  A simpler generator,
but of lower quality, would be to bit-reverse the input, and take the
modulus.

The seeds just become the initial values of 32-bit counters for each
generator, and each successive PR number for each generator are
computed by incrementing the counter and applying the transformation.
This has the interesting side effect that you can generate events in
any order - forwards, backwards, randomly, since when you pass "43" to
the transformation function, it'll always produce the same result.

A discussion of the approach from a few years ago:

https://groups.google.com/d/topic/comp.programming/xGbNfu4KVH0/discussion

[toc] | [prev] | [next] | [standalone]

#139126

On 12/27/18 9:41 AM, Rick C. Hodgin wrote:
> On 12/27/2018 8:27 AM, James Kuyper wrote:
>> The documentation for random() says:
>> "Threaded applications should use erand48(), nrand48(), or jrand48()
>> instead of random() when an independent random number sequence in
>> multiple threads is required."
> 
> In my particular case I'm not running a single thread.  I just happen
> to need multiple random sources.
> 
> Given the implementation of the algorithm, I'm surprised they didn't
> provide a native one that uses pointers to external values so you can
> have multiple rand() seeds and sources all working together.
> 

C started as a single threaded languge, with no thoughts about making it
multi-thread capable. This meant that functions that had internal state,
typically just kept it as static variables in the file implementing
them, as that is simplest.

When applications started to become multi-threaded (even though the
Standard had yet recognize it) a couple of solutions appeared to handle
these functions.

One, was to move this stored data into Thread Local Storage, so each
thread kept its own state, and the application would just work. One
problem with this was that for some implementations, it was hard to omit
that TLS if a thread (or the whole application) didn't need it, so this
was mostly used for only the most core functions.

A second solution that developed was to create 're-entrant' versions of
the functions (typically ending in _r) that took as a parameter an
opaque block of memory of specified type that held that state. This
happened a lot with the POSIX specification. While this works, it does
create the problem that if you want to share that instance of the
library function over multiple scopes, you need to share that parameter,
often ending up as a at least somewhat global (maybe just file scoped)
variable, and the code is a bit ugly with the extra parameter
everywhere. This means that this type of function isn't created unless
it is really needed.

rand() wasn't that popular in multi-threaded applications (its quality
was under-specified, so most applications that really needed it used
something better), so when the Standard defined operation with
threading, it wasn't made thread safe with TLS, nor defined with a _r
version.

While in your case it sounds like what you need isn't 'multi-threading',
the _r version, if it was defined, would do what you want. but as I
commented it wasn't seen as needed enough to define in a standard. I
believe POSIX does define some of the more advanced random number
generators with that form.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web