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

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

Fair, truly random random number generator

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

Contents

  Fair, truly random random number generator "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-28 20:31 +0800
    Re: Fair, truly random random number generator "Osmium" <r124c4u102@comcast.net> - 2016-10-28 07:48 -0500
      Re: Fair, truly random random number generator "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-28 21:07 +0800
        Re: Fair, truly random random number generator Richard Heathfield <rjh@cpax.org.uk> - 2016-10-28 14:21 +0100
          Re: Fair, truly random random number generator Gareth Owen <gwowen@gmail.com> - 2016-10-28 16:22 +0100
            Re: Fair, truly random random number generator Richard Heathfield <rjh@cpax.org.uk> - 2016-10-28 16:30 +0100
              Re: Fair, truly random random number generator Gareth Owen <gwowen@gmail.com> - 2016-10-28 16:32 +0100
          Re: Fair, truly random random number generator "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-29 23:11 +0800
            Re: Fair, truly random random number generator Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 11:17 +0000
              Re: Fair, truly random random number generator "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-31 20:14 +0800
                Re: Fair, truly random random number generator Melzzzzz <Melzzzzz@zzzzz.com> - 2016-10-31 12:32 +0000
                  Re: Fair, truly random random number generator Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 12:48 +0000
                    Re: Fair, truly random random number generator "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-01 15:30 +0800
                Re: Fair, truly random random number generator Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 12:47 +0000
        Re: Fair, truly random random number generator "Osmium" <r124c4u102@comcast.net> - 2016-10-28 09:32 -0500
    Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-28 07:14 -0700
      Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-28 18:07 -0700
        Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-01 17:45 -0700
          Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-01 18:57 -0700
            Re: Fair, truly random random number generator David Brown <david.brown@hesbynett.no> - 2016-11-02 10:06 +0100
              Re: Fair, truly random random number generator "Osmium" <r124c4u102@comcast.net> - 2016-11-02 04:46 -0600
              Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-02 05:06 -0700
                Re: Fair, truly random random number generator David Brown <david.brown@hesbynett.no> - 2016-11-02 13:43 +0100
                  Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-02 06:02 -0700
                    Re: Fair, truly random random number generator David Brown <david.brown@hesbynett.no> - 2016-11-02 16:08 +0100
                      Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-02 08:21 -0700
                Re: Fair, truly random random number generator Mark Storkamp <mstorkamp@yahoo.com> - 2016-11-02 08:20 -0500
            Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-03 17:56 -0700
              Re: Fair, truly random random number generator Keith Thompson <kst-u@mib.org> - 2016-11-03 18:16 -0700
                Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-03 18:48 -0700
                Re: Fair, truly random random number generator supercat@casperkitty.com - 2016-11-04 09:17 -0700
                Re: Fair, truly random random number generator raltbos@xs4all.nl (Richard Bos) - 2016-11-04 17:59 +0000
                  Re: Fair, truly random random number generator Keith Thompson <kst-u@mib.org> - 2016-11-04 11:55 -0700
                    Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-04 12:43 -0700
                  Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-04 12:40 -0700
              Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-04 12:49 -0700
                Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-04 13:23 -0700
                  Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-04 13:32 -0700
                    Re: Fair, truly random random number generator ImperiusDamian <damianblack.wolf@gmail.com> - 2016-11-05 18:48 -0400
                      Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-05 16:03 -0700
                        Re: Fair, truly random random number generator "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-05 16:50 -0700
                        Re: Fair, truly random random number generator ImperiusDamian <damianblack.wolf@gmail.com> - 2016-11-05 19:52 -0400
                          Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-05 17:06 -0700
      Re: Fair, truly random random number generator "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-29 23:13 +0800
        Re: Fair, truly random random number generator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-10-29 12:12 -0400
          Re: Fair, truly random random number generator "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-30 00:22 +0800
          Re: Fair, truly random random number generator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-10-29 12:26 -0400
          Re: Fair, truly random random number generator supercat@casperkitty.com - 2016-10-29 09:44 -0700
            Re: Fair, truly random random number generator Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-01 08:13 -0700
              Re: Fair, truly random random number generator supercat@casperkitty.com - 2016-11-01 08:31 -0700
                Re: Fair, truly random random number generator Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-02 12:58 -0700
        Re: Fair, truly random random number generator "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-29 12:37 -0400
        Re: Fair, truly random random number generator Keith Thompson <kst-u@mib.org> - 2016-10-29 11:57 -0700
        Re: Fair, truly random random number generator David Brown <david.brown@hesbynett.no> - 2016-10-30 17:13 +0100
          Re: Fair, truly random random number generator "Osmium" <r124c4u102@comcast.net> - 2016-10-30 11:07 -0600
            Re: Fair, truly random random number generator supercat@casperkitty.com - 2016-10-30 12:20 -0700
        Re: Fair, truly random random number generator Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 11:18 +0000
        Re: Fair, truly random random number generator Ed Prochak <edprochak@gmail.com> - 2016-11-03 10:39 -0700
          Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-03 11:13 -0700
            [OT] gigawatts = gigaseconds correlation? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 02:36 +0800
              Re: [OT] gigawatts = gigaseconds correlation? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-03 12:07 -0700
                Re: [OT] gigawatts = gigaseconds correlation? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 12:02 +0800
            Re: Fair, truly random random number generator gazelle@shell.xmission.com (Kenny McCormack) - 2016-11-03 19:56 +0000
            Re: Fair, truly random random number generator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-03 16:21 -0700
    Re: Fair, truly random random number generator luser droog <luser.droog@gmail.com> - 2016-10-29 14:49 -0700
      Re: Fair, truly random random number generator jameskuyper@verizon.net - 2016-10-29 15:29 -0700
    Re: Fair, truly random random number generator Quadibloc <jsavard@ecn.ab.ca> - 2016-10-29 19:09 -0700
    Thank you all for the replies! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-31 18:42 +0800

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

#95573

"David Brown" wrote:

> So when you want really good random sequences, you use the least
> significant bits of a "natural" source to seed and occasionally re-seed
> your PRNG.  That's what Linux does with /dev/random, and it is also what
> cpu manufacturers do when they have a "hardware random number generator".

I used to have a pocket calculator that produced random numbers.  I doubt 
very much they did what you describe. If anyone remembers analogue TV sets, 
the "snow" was a great manifestation of randomness. It doesn't take that 
much electronics to produce the equivalent.  The hiss between stations on an 
AM radio is another good generator.

I would expect a half hour or so on google would find a pretty darn good 
product of some sort from China. Note: The air mail from China may take a 
surprisingly long time to show up in your mail box, but it will come 
eventually.  I visualize something that plugs into a USB port. 

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

#95575

On Wednesday, November 2, 2016 at 5:06:55 AM UTC-4, David Brown wrote:
> On 02/11/16 02:57, Rick C. Hodgin wrote:
> > On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
> >> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
> >>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
> >>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
> >>>>> Anyone got an existing and truly random random number generator function
> >>>>> for me to copy? :)
> >>>>
> >>>> There are no such creations.  It's impossible in a software algorithm to
> >>>> create a truly random sequence without having truly random input.
> >>>
> >>> For fun, take a look at:
> >>>
> >>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
> >>> (read all please...)
> >>>
> >>> Is a mouse move a random event? How about a key press?
> >>>
> >>> I not saying this race infested thing I am messing around with is
> >>> random, I am saying its hard for it to hit a set period.
> >>>
> >>
> >> Did you take a look at my code Rick?
> > 
> > No.  But to answer your question, any input that's not from an algorithm-
> > generated source can be considered random input.
> > 
> 
> The number of cups of coffee I drink a day does not come from an
> algorithm, but it would be a very poor source of random input.
> 
> It is accurate to say that any sequence generated from a /deterministic/
> algorithm will not be random - but the converse is not correct.

From the point of view of the algorithm, the input coming in will be
random.  It has no way of predicting in advance what that number will
be.

The degree to which a particular random number source represents
sufficiently randomized data across the spectrum range ... that's a
completely different matter.

I remember the VIA C7 family of CPUs with their on-board random number
generators.  They would produce numbers heavily skewed toward 0 and 255
when they began to heat up 5C to 10C beyond the normal operating temps.
There was also a slight skew depending on how fast you sampled the value
through its "read random data" assembly instruction.

I had discussions with someone who worked at VIA at the time about this
and their position was (paraphrased), "it's still sufficiently random
because the sequence cannot be reproduced, and is truly random, it's
just skewed toward those particular values in those heat ranges."

> (Non-deterministic random algorithms are easy to devise - "roll a die,
> and write down the number it shows" is an algorithm for picking a number
> between 1 and 6.)
> 
> There are many pseudo-random number generator algorithms that give
> excellent non-determinism and very flat frequency distributions for long
> sequences.  Often they give much more useful sources of "randomness"
> than more "true" random sources such as the movement of mice (living
> mice or computer mice), because such external sources have complex
> distributions that are hard to compensate.
> 
> So when you want really good random sequences, you use the least
> significant bits of a "natural" source to seed and occasionally re-seed
> your PRNG.  That's what Linux does with /dev/random, and it is also what
> cpu manufacturers do when they have a "hardware random number generator".

"Hey.  That's great." :-)

Best regards,
Rick C. Hodgin

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

#95576

On 02/11/16 13:06, Rick C. Hodgin wrote:
> On Wednesday, November 2, 2016 at 5:06:55 AM UTC-4, David Brown wrote:
>> On 02/11/16 02:57, Rick C. Hodgin wrote:
>>> On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
>>>> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
>>>>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
>>>>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
>>>>>>> Anyone got an existing and truly random random number generator function
>>>>>>> for me to copy? :)
>>>>>>
>>>>>> There are no such creations.  It's impossible in a software algorithm to
>>>>>> create a truly random sequence without having truly random input.
>>>>>
>>>>> For fun, take a look at:
>>>>>
>>>>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
>>>>> (read all please...)
>>>>>
>>>>> Is a mouse move a random event? How about a key press?
>>>>>
>>>>> I not saying this race infested thing I am messing around with is
>>>>> random, I am saying its hard for it to hit a set period.
>>>>>
>>>>
>>>> Did you take a look at my code Rick?
>>>
>>> No.  But to answer your question, any input that's not from an algorithm-
>>> generated source can be considered random input.
>>>
>>
>> The number of cups of coffee I drink a day does not come from an
>> algorithm, but it would be a very poor source of random input.
>>
>> It is accurate to say that any sequence generated from a /deterministic/
>> algorithm will not be random - but the converse is not correct.
> 
> From the point of view of the algorithm, the input coming in will be
> random.  It has no way of predicting in advance what that number will
> be.

It is non-deterministic (difficult or impossible to predict), but is
that "random"?

Suppose you asked me for a sequence of random numbers between 1 and 10.
 I take a coin, and toss it many times.  For every head, I give you a 3,
and for every tail I give you a 5.  The sequence is non-deterministic -
you have no way of predicting the next number.  But is it "random"?
Certainly you would not be happy with it - the /distribution/ of the
numbers does not match your expectations (which would be for a linear
distribution, if not otherwise specified - you expect to get roughly as
many of each digit turning up).


Also note that many apparently non-deterministic "real world" events can
have a certain degree of predictability.  If you looked at my calendar
for a day, you might be able to partially predict my expected coffee
intake (more meetings means more coffee) - or if you tracked my sleep
patterns.  There are almost certainly periodic biases (more coffee on
Monday mornings).

These effects reduce the entropy, or "effective amount of randomness".

> 
> The degree to which a particular random number source represents
> sufficiently randomized data across the spectrum range ... that's a
> completely different matter.

It is of key importance, and is usually more important than how "truly
random" the sequence is.

Passing the external events (which have a certain amount of "true"
entropy, but usually also complicated biases, patterns and
distributions) through a good PRNG (which typically have very clear and
regular distributions) gives you the best of both worlds.

> 
> I remember the VIA C7 family of CPUs with their on-board random number
> generators.  They would produce numbers heavily skewed toward 0 and 255
> when they began to heat up 5C to 10C beyond the normal operating temps.
> There was also a slight skew depending on how fast you sampled the value
> through its "read random data" assembly instruction.
> 

Yes, that kind of effect was not uncommon.

> I had discussions with someone who worked at VIA at the time about this
> and their position was (paraphrased), "it's still sufficiently random
> because the sequence cannot be reproduced, and is truly random, it's
> just skewed toward those particular values in those heat ranges."

The typical source of "true" entropy for such hardware random number
generators is thermal noise in a resistor.  Unless you are /very/
careful with your setup, it will be biased or skewed by the temperature
of the resistor.  And if you measure too quickly, as you near the
bandwidth of the measurement system then you will get new biases -
values will not change as much as they would with longer periods.

Thus modern devices use samples that are spread out in time, taking only
the lowest few bits of the measurements (as these are less affected by
absolute temperature) and concatenating them, then using the combined
effects as seeds of a PRNG that gives you values as fast as you want them.

> 
>> (Non-deterministic random algorithms are easy to devise - "roll a die,
>> and write down the number it shows" is an algorithm for picking a number
>> between 1 and 6.)
>>
>> There are many pseudo-random number generator algorithms that give
>> excellent non-determinism and very flat frequency distributions for long
>> sequences.  Often they give much more useful sources of "randomness"
>> than more "true" random sources such as the movement of mice (living
>> mice or computer mice), because such external sources have complex
>> distributions that are hard to compensate.
>>
>> So when you want really good random sequences, you use the least
>> significant bits of a "natural" source to seed and occasionally re-seed
>> your PRNG.  That's what Linux does with /dev/random, and it is also what
>> cpu manufacturers do when they have a "hardware random number generator".
> 
> "Hey.  That's great." :-)
> 

Yes indeed.

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

#95578

On Wednesday, November 2, 2016 at 8:43:33 AM UTC-4, David Brown wrote:
> On 02/11/16 13:06, Rick C. Hodgin wrote:
> > On Wednesday, November 2, 2016 at 5:06:55 AM UTC-4, David Brown wrote:
> >> On 02/11/16 02:57, Rick C. Hodgin wrote:
> >>> On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
> >>>> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
> >>>>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
> >>>>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
> >>>>>>> Anyone got an existing and truly random random number generator function
> >>>>>>> for me to copy? :)
> >>>>>>
> >>>>>> There are no such creations.  It's impossible in a software algorithm to
> >>>>>> create a truly random sequence without having truly random input.
> >>>>>
> >>>>> For fun, take a look at:
> >>>>>
> >>>>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
> >>>>> (read all please...)
> >>>>>
> >>>>> Is a mouse move a random event? How about a key press?
> >>>>>
> >>>>> I not saying this race infested thing I am messing around with is
> >>>>> random, I am saying its hard for it to hit a set period.
> >>>>>
> >>>>
> >>>> Did you take a look at my code Rick?
> >>>
> >>> No.  But to answer your question, any input that's not from an algorithm-
> >>> generated source can be considered random input.
> >>>
> >>
> >> The number of cups of coffee I drink a day does not come from an
> >> algorithm, but it would be a very poor source of random input.
> >>
> >> It is accurate to say that any sequence generated from a /deterministic/
> >> algorithm will not be random - but the converse is not correct.
> > 
> > From the point of view of the algorithm, the input coming in will be
> > random.  It has no way of predicting in advance what that number will
> > be.
> 
> It is non-deterministic (difficult or impossible to predict), but is
> that "random"?
> 
> Suppose you asked me for a sequence of random numbers between 1 and 10.
>  I take a coin, and toss it many times.  For every head, I give you a 3,
> and for every tail I give you a 5.  The sequence is non-deterministic -
> you have no way of predicting the next number.  But is it "random"?
> Certainly you would not be happy with it - 

I would be happy with it.  I'd just be glad that we were friendly enough
to engage in such social banter. :-)  Of course, I might have to drop in
a line like, "I wonder if God really does play dice with the universe or
not?" ... quoting Einstein of course. :-)

> the /distribution/ of the
> numbers does not match your expectations (which would be for a linear
> distribution, if not otherwise specified - you expect to get roughly as
> many of each digit turning up).

As I understand it, random numbers do not require linear distribution.
I remember someone asking students to arrange the paper clips they have
in front them in a random order on their desk.  The students did this
and each was examined.  The conclusion was most people think random
means evenly distributed, but truly random values are not evenly
distributed over fixed small set sizes.  Drop a box of paperclips onto
a desk and you'll find groups and wide spaces and even distributions.

> Also note that many apparently non-deterministic "real world" events can
> have a certain degree of predictability.  If you looked at my calendar
> for a day, you might be able to partially predict my expected coffee
> intake (more meetings means more coffee) - or if you tracked my sleep
> patterns.  There are almost certainly periodic biases (more coffee on
> Monday mornings).

Past observation changes things.  Knowledge of the likelihood of specific
results changes things.  But for a blind sample input, any non-
algorithmically-generated random source would provide random input.  It
just may not be very good input.

> These effects reduce the entropy, or "effective amount of randomness".

They also make for long boring lectures in classroom settings. :-)

> > The degree to which a particular random number source represents
> > sufficiently randomized data across the spectrum range ... that's a
> > completely different matter.
> 
> It is of key importance, and is usually more important than how "truly
> random" the sequence is.

It's only of key importance to the application, for it has needs.  But
as a random source, it is still random.

The number of cups of coffee you drink each day cannot be predicted.
It can be reasonably predicted based on observation, but there are a
billion factors which enter in to that decision.  Was there traffic on
the way to work?  Is the coffee machine broken?  Did someone forget to
buy coffee?  Were all the cups taken or dirty?  Did you have a meeting
that required uninterrupted attention for four hours?  And so on.

It's not a good source of random distribution, but it's still random.

> Passing the external events (which have a certain amount of "true"
> entropy, but usually also complicated biases, patterns and
> distributions) through a good PRNG (which typically have very clear and
> regular distributions) gives you the best of both worlds.

I'm not saying it doesn't.  But all PRNGs are just that:  P.

> > I remember the VIA C7 family of CPUs with their on-board random number
> > generators.  They would produce numbers heavily skewed toward 0 and 255
> > when they began to heat up 5C to 10C beyond the normal operating temps.
> > There was also a slight skew depending on how fast you sampled the value
> > through its "read random data" assembly instruction.
> 
> Yes, that kind of effect was not uncommon.
> 
> > I had discussions with someone who worked at VIA at the time about this
> > and their position was (paraphrased), "it's still sufficiently random
> > because the sequence cannot be reproduced, and is truly random, it's
> > just skewed toward those particular values in those heat ranges."
> 
> The typical source of "true" entropy for such hardware random number
> generators is thermal noise in a resistor.  Unless you are /very/
> careful with your setup, it will be biased or skewed by the temperature
> of the resistor.  And if you measure too quickly, as you near the
> bandwidth of the measurement system then you will get new biases -
> values will not change as much as they would with longer periods.

They had specs published and it generated 32-bit or 64-bit random values,
IIRC.  The 32-bit was 2x that of 64-bit, but seemed to have a biased skew.

> Thus modern devices use samples that are spread out in time, taking only
> the lowest few bits of the measurements (as these are less affected by
> absolute temperature) and concatenating them, then using the combined
> effects as seeds of a PRNG that gives you values as fast as you want them.

Absolutely.  I'm not knocking PRNGs.  They have their place.  And I would
probably almost always use them as you can partially randomize their seeds
with sources that provide some periodic randomness.  But, they are not
truly random without that external nudging.

> >> (Non-deterministic random algorithms are easy to devise - "roll a die,
> >> and write down the number it shows" is an algorithm for picking a number
> >> between 1 and 6.)
> >>
> >> There are many pseudo-random number generator algorithms that give
> >> excellent non-determinism and very flat frequency distributions for long
> >> sequences.  Often they give much more useful sources of "randomness"
> >> than more "true" random sources such as the movement of mice (living
> >> mice or computer mice), because such external sources have complex
> >> distributions that are hard to compensate.
> >>
> >> So when you want really good random sequences, you use the least
> >> significant bits of a "natural" source to seed and occasionally re-seed
> >> your PRNG.  That's what Linux does with /dev/random, and it is also what
> >> cpu manufacturers do when they have a "hardware random number generator".
> > 
> > "Hey.  That's great." :-)
> 
> Yes indeed.

:-)

Best regards,
Rick C. Hodgin

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

#95591

On 02/11/16 14:02, Rick C. Hodgin wrote:
> On Wednesday, November 2, 2016 at 8:43:33 AM UTC-4, David Brown wrote:
>> On 02/11/16 13:06, Rick C. Hodgin wrote:
>>> On Wednesday, November 2, 2016 at 5:06:55 AM UTC-4, David Brown wrote:
>>>> On 02/11/16 02:57, Rick C. Hodgin wrote:
>>>>> On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
>>>>>> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
>>>>>>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
>>>>>>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
>>>>>>>>> Anyone got an existing and truly random random number generator function
>>>>>>>>> for me to copy? :)
>>>>>>>>
>>>>>>>> There are no such creations.  It's impossible in a software algorithm to
>>>>>>>> create a truly random sequence without having truly random input.
>>>>>>>
>>>>>>> For fun, take a look at:
>>>>>>>
>>>>>>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
>>>>>>> (read all please...)
>>>>>>>
>>>>>>> Is a mouse move a random event? How about a key press?
>>>>>>>
>>>>>>> I not saying this race infested thing I am messing around with is
>>>>>>> random, I am saying its hard for it to hit a set period.
>>>>>>>
>>>>>>
>>>>>> Did you take a look at my code Rick?
>>>>>
>>>>> No.  But to answer your question, any input that's not from an algorithm-
>>>>> generated source can be considered random input.
>>>>>
>>>>
>>>> The number of cups of coffee I drink a day does not come from an
>>>> algorithm, but it would be a very poor source of random input.
>>>>
>>>> It is accurate to say that any sequence generated from a /deterministic/
>>>> algorithm will not be random - but the converse is not correct.
>>>
>>> From the point of view of the algorithm, the input coming in will be
>>> random.  It has no way of predicting in advance what that number will
>>> be.
>>
>> It is non-deterministic (difficult or impossible to predict), but is
>> that "random"?
>>
>> Suppose you asked me for a sequence of random numbers between 1 and 10.
>>  I take a coin, and toss it many times.  For every head, I give you a 3,
>> and for every tail I give you a 5.  The sequence is non-deterministic -
>> you have no way of predicting the next number.  But is it "random"?
>> Certainly you would not be happy with it - 
> 
> I would be happy with it.  I'd just be glad that we were friendly enough
> to engage in such social banter. :-)  Of course, I might have to drop in
> a line like, "I wonder if God really does play dice with the universe or
> not?" ... quoting Einstein of course. :-)

I guess you are just easy to please!  Certainly /I/ would not be happy
with a sequence consisting entirely of digits 3 and 5 when I asked for
random numbers between 1 and 10.

> 
>> the /distribution/ of the
>> numbers does not match your expectations (which would be for a linear
>> distribution, if not otherwise specified - you expect to get roughly as
>> many of each digit turning up).
> 
> As I understand it, random numbers do not require linear distribution.

True.  But still, I would say that a (roughly) linear distribution is
what most people mean by "random" without further qualification.  If you
want a binomial distribution, or a bell curve distribution, that's what
you ask for.  If you just say "random", the linear distribution is implied.

> I remember someone asking students to arrange the paper clips they have
> in front them in a random order on their desk.  The students did this
> and each was examined.  The conclusion was most people think random
> means evenly distributed, but truly random values are not evenly
> distributed over fixed small set sizes.  Drop a box of paperclips onto
> a desk and you'll find groups and wide spaces and even distributions.

Very true - and people are notoriously bad at making true random
sequences or arrangements.  They think "the law of averages" is a rule
to be followed, rather than a misconception.

But in saying that the random arrangement of paper clips should be
evenly distributed, we are /not/ saying that a /particular/ sample
should be evenly or smoothly distributed (though that is what many
people think, as your experiment showed).  If the students were making
the arrangements randomly, with an even distribution, you would expect
some of them to have more clips on the left side, and some to have more
clips on the right side.  You would expect most to only have a slight
bias, but a few would have a more significant bias.

> 
>> Also note that many apparently non-deterministic "real world" events can
>> have a certain degree of predictability.  If you looked at my calendar
>> for a day, you might be able to partially predict my expected coffee
>> intake (more meetings means more coffee) - or if you tracked my sleep
>> patterns.  There are almost certainly periodic biases (more coffee on
>> Monday mornings).
> 
> Past observation changes things.  Knowledge of the likelihood of specific
> results changes things.  But for a blind sample input, any non-
> algorithmically-generated random source would provide random input.  It
> just may not be very good input.
> 

OK, I can accept that - with the nit-pick that when you write
"algorithm" you mean "deterministic algorithm".  As I said earlier,
"roll a dice and note down the number" is an algorithm which is very
good at generating random numbers.

>> These effects reduce the entropy, or "effective amount of randomness".
> 
> They also make for long boring lectures in classroom settings. :-)
> 
>>> The degree to which a particular random number source represents
>>> sufficiently randomized data across the spectrum range ... that's a
>>> completely different matter.
>>
>> It is of key importance, and is usually more important than how "truly
>> random" the sequence is.
> 
> It's only of key importance to the application, for it has needs.  But
> as a random source, it is still random.

The more biased a distribution is, the lower its entropy and it's
"randomness".

For example, consider the output of a Geiger counter.  Usually it will
produce zeros, with occasional ones (clicks) at random intervals.  It
might be that for any given sample, there is a 5% chance of getting a
one.  It is random - no argument there.  But the sequence of zeros and
ones is of little use to an application, and contains little entropy (in
relation to the sequence size) as a result of its highly skewed
distribution.  The data needs to be "whitened" in some way, to give it a
more useful distribution.

> 
> The number of cups of coffee you drink each day cannot be predicted.
> It can be reasonably predicted based on observation, but there are a
> billion factors which enter in to that decision.  Was there traffic on
> the way to work?  Is the coffee machine broken?  Did someone forget to
> buy coffee?  Were all the cups taken or dirty?  Did you have a meeting
> that required uninterrupted attention for four hours?  And so on.

I would not say there are a billion factors - at least, not a billion
with significant influence :-)

> 
> It's not a good source of random distribution, but it's still random.

Fair enough.

> 
>> Passing the external events (which have a certain amount of "true"
>> entropy, but usually also complicated biases, patterns and
>> distributions) through a good PRNG (which typically have very clear and
>> regular distributions) gives you the best of both worlds.
> 
> I'm not saying it doesn't.  But all PRNGs are just that:  P.
> 

If your PRNG gives results that you cannot distinguish from "true
random", is there really a difference?  (That is perhaps more philosophy
rather than computer science.)

>>> I remember the VIA C7 family of CPUs with their on-board random number
>>> generators.  They would produce numbers heavily skewed toward 0 and 255
>>> when they began to heat up 5C to 10C beyond the normal operating temps.
>>> There was also a slight skew depending on how fast you sampled the value
>>> through its "read random data" assembly instruction.
>>
>> Yes, that kind of effect was not uncommon.
>>
>>> I had discussions with someone who worked at VIA at the time about this
>>> and their position was (paraphrased), "it's still sufficiently random
>>> because the sequence cannot be reproduced, and is truly random, it's
>>> just skewed toward those particular values in those heat ranges."
>>
>> The typical source of "true" entropy for such hardware random number
>> generators is thermal noise in a resistor.  Unless you are /very/
>> careful with your setup, it will be biased or skewed by the temperature
>> of the resistor.  And if you measure too quickly, as you near the
>> bandwidth of the measurement system then you will get new biases -
>> values will not change as much as they would with longer periods.
> 
> They had specs published and it generated 32-bit or 64-bit random values,
> IIRC.  The 32-bit was 2x that of 64-bit, but seemed to have a biased skew.
> 
>> Thus modern devices use samples that are spread out in time, taking only
>> the lowest few bits of the measurements (as these are less affected by
>> absolute temperature) and concatenating them, then using the combined
>> effects as seeds of a PRNG that gives you values as fast as you want them.
> 
> Absolutely.  I'm not knocking PRNGs.  They have their place.  And I would
> probably almost always use them as you can partially randomize their seeds
> with sources that provide some periodic randomness.  But, they are not
> truly random without that external nudging.
> 
>>>> (Non-deterministic random algorithms are easy to devise - "roll a die,
>>>> and write down the number it shows" is an algorithm for picking a number
>>>> between 1 and 6.)
>>>>
>>>> There are many pseudo-random number generator algorithms that give
>>>> excellent non-determinism and very flat frequency distributions for long
>>>> sequences.  Often they give much more useful sources of "randomness"
>>>> than more "true" random sources such as the movement of mice (living
>>>> mice or computer mice), because such external sources have complex
>>>> distributions that are hard to compensate.
>>>>
>>>> So when you want really good random sequences, you use the least
>>>> significant bits of a "natural" source to seed and occasionally re-seed
>>>> your PRNG.  That's what Linux does with /dev/random, and it is also what
>>>> cpu manufacturers do when they have a "hardware random number generator".
>>>
>>> "Hey.  That's great." :-)
>>
>> Yes indeed.
> 
> :-)
> 
> Best regards,
> Rick C. Hodgin
> 

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

#95593

On Wednesday, November 2, 2016 at 11:08:14 AM UTC-4, David Brown wrote:
> On 02/11/16 14:02, Rick C. Hodgin wrote:
> > The number of cups of coffee you drink each day cannot be predicted.
> > It can be reasonably predicted based on observation, but there are a
> > billion factors which enter in to that decision.  Was there traffic on
> > the way to work?  Is the coffee machine broken?  Did someone forget to
> > buy coffee?  Were all the cups taken or dirty?  Did you have a meeting
> > that required uninterrupted attention for four hours?  And so on.
> 
> I would not say there are a billion factors - at least, not a billion
> with significant influence :-)

I would say a billion is conservative.  The front end loader driver who
brought in a load of dopants to add to the raw steel mixture to alter
its properties for creating black pipe used in the building's sprinkler
water system ... did he grab from the right pile?  Perhaps there was a
defect that created a bit of pipe that would, when an unexpected shaking
from an unexpected earthquake happens because workman Joe forgot to
completely tighten one of the last bolts on the system before he went
to lunch, causes a shudder, and an impact, which causes the pipe to fail,
which evacuates the floor or building, etc.

There are well over a billion factors.  Are the likely to contribute to
some meaningful interruption in the expected results?  Not very likely
at all.  But, they can impact it, and therefore there is randomness at
work.

You can have a truly random sequence with only two digits.  Either it
outfeeds value A, or value B.  It does not need wide distribution or
linear distribution to be random ... it just needs to be completely
unpredictable.

As to whether PRNGs are as good as TRNGs if they are indistinguishable
from one another in any meaningful way ... sure.  I'd say, "Sure.  Why
not?" :-)  Except that the real answer is no ... they're not as good.
But, in probably every way that would mean something to everything we'd
be involved with, they are as good ... so if you are willing to lower
your standards in that way, then yes PRNGs are just as good as TNRGs.

Best regards,
Rick C. Hodgin

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

#95581

In article <4e33e549-09ac-4747-93d2-e36352e3d80a@googlegroups.com>,
 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> On Wednesday, November 2, 2016 at 5:06:55 AM UTC-4, David Brown wrote:
> > 
> > It is accurate to say that any sequence generated from a /deterministic/
> > algorithm will not be random - but the converse is not correct.
> 
> From the point of view of the algorithm, the input coming in will be
> random.  It has no way of predicting in advance what that number will
> be.
> 
> The degree to which a particular random number source represents
> sufficiently randomized data across the spectrum range ... that's a
> completely different matter.
> 

There are some good discussions of this at http://random.org 

They can also be used as a source to seed your PRNG.

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

#95708

On 11/1/2016 6:57 PM, Rick C. Hodgin wrote:
> On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
>> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
>>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
>>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
>>>>> Anyone got an existing and truly random random number generator function
>>>>> for me to copy? :)
>>>>
>>>> There are no such creations.  It's impossible in a software algorithm to
>>>> create a truly random sequence without having truly random input.
>>>
>>> For fun, take a look at:
>>>
>>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
>>> (read all please...)
>>>
>>> Is a mouse move a random event? How about a key press?
>>>
>>> I not saying this race infested thing I am messing around with is
>>> random, I am saying its hard for it to hit a set period.
>>>
>>
>> Did you take a look at my code Rick?
>
> No.  But to answer your question, any input that's not from an algorithm-
> generated source can be considered random input.

This is why I think race-conditions in multi-threaded programs can be 
considered random in the sense that its damn near impossible to hit a 
defined period of repetition.

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

#95710

"Chris M. Thomasson" <invalid@invalid.invalid> writes:
[...]
> This is why I think race-conditions in multi-threaded programs can be 
> considered random in the sense that its damn near impossible to hit a 
> defined period of repetition.

That's not all that "random" means.  It might be very difficult to
predict the next -- well, whatever numeric value you might derive from a
race condition.  But if it's possible to make *some* prediction at rates
better than chance, it's not random.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#95714

On 11/3/2016 6:16 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
> [...]
>> This is why I think race-conditions in multi-threaded programs can be
>> considered random in the sense that its damn near impossible to hit a
>> defined period of repetition.
>
> That's not all that "random" means.  It might be very difficult to
> predict the next -- well, whatever numeric value you might derive from a
> race condition.  But if it's possible to make *some* prediction at rates
> better than chance, it's not random.

If it is possible, then we can write algorithms that can possibly try to 
auto-correct horrifically terrible race-conditions in complicated 
existing multi-threaded programs. We tell the algorithm the correct 
output, then compare it to the race-infested output, and see if it can 
alter things to make it more accurate. Seems like some sort of AI.

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

#95760

On Thursday, November 3, 2016 at 8:16:20 PM UTC-5, Keith Thompson wrote:
> That's not all that "random" means.  It might be very difficult to
> predict the next -- well, whatever numeric value you might derive from a
> race condition.  But if it's possible to make *some* prediction at rates
> better than chance, it's not random.

A lot of things contain some amount of randomness.  If I have a coin which
lands tails-up ~70.71% of the time, with each flip being independent of the
previous one, someone who knew about the bias could make predictions far
better than the chance predictions of someone who didn't know about the
bias, but that wouldn't make the coin non-random.  The odds of a pair of
flips both coming up tails would be 50% [exactly 50% if the original
probability was exactly 100%/sqrt(2))

What's difficult in many cases is quantifying randomness and bias so as to
factor out the latter.

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

#95784

Keith Thompson <kst-u@mib.org> wrote:

> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
> [...]
> > This is why I think race-conditions in multi-threaded programs can be 
> > considered random in the sense that its damn near impossible to hit a 
> > defined period of repetition.
> 
> That's not all that "random" means.  It might be very difficult to
> predict the next -- well, whatever numeric value you might derive from a
> race condition.  But if it's possible to make *some* prediction at rates
> better than chance, it's not random.

That would mean that a stochastic, but bell-shaped distribution isn't
random. I don't think you're entirely wrong, but you're not entirely
right, either.

As for multi-threaded timings, they're not random because 
a) a sufficiently deep program could in theory predict them, and 
b) a sufficiently devious program could in theory manipulate them.

And all C programs are, of course, in a state of sin.

Richard

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

#95787

raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>> [...]
>> > This is why I think race-conditions in multi-threaded programs can be 
>> > considered random in the sense that its damn near impossible to hit a 
>> > defined period of repetition.
>> 
>> That's not all that "random" means.  It might be very difficult to
>> predict the next -- well, whatever numeric value you might derive from a
>> race condition.  But if it's possible to make *some* prediction at rates
>> better than chance, it's not random.
>
> That would mean that a stochastic, but bell-shaped distribution isn't
> random. I don't think you're entirely wrong, but you're not entirely
> right, either.

Agreed.  What I should have said is that multithreaded timings might be
difficult to predict, but that doesn't make them *usefully* random.
There might be ways to generate, say, linearly distributed pseudo-random
numbers from the timings, but I'd be afraid that someone might find a
way to predict the results.

The word "random" is too often used as a synonym for "arbitrary".

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#95793

On 11/4/2016 11:55 AM, Keith Thompson wrote:
> raltbos@xs4all.nl (Richard Bos) writes:
>> Keith Thompson <kst-u@mib.org> wrote:
>>> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>>> [...]
>>>> This is why I think race-conditions in multi-threaded programs can be
>>>> considered random in the sense that its damn near impossible to hit a
>>>> defined period of repetition.
>>>
>>> That's not all that "random" means.  It might be very difficult to
>>> predict the next -- well, whatever numeric value you might derive from a
>>> race condition.  But if it's possible to make *some* prediction at rates
>>> better than chance, it's not random.
>>
>> That would mean that a stochastic, but bell-shaped distribution isn't
>> random. I don't think you're entirely wrong, but you're not entirely
>> right, either.
>
> Agreed.  What I should have said is that multithreaded timings might be
> difficult to predict, but that doesn't make them *usefully* random.
> There might be ways to generate, say, linearly distributed pseudo-random
> numbers from the timings, but I'd be afraid that someone might find a
> way to predict the results.

FWIW, I am not measuring the timings, but the raw data returned from a 
busted implementation of an atomic fetch-and-add operation. I am having 
trouble understanding how the data could ever hit a set period of 
repetition.


> The word "random" is too often used as a synonym for "arbitrary".

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

#95792

On 11/4/2016 10:59 AM, Richard Bos wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>
>> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>> [...]
>>> This is why I think race-conditions in multi-threaded programs can be
>>> considered random in the sense that its damn near impossible to hit a
>>> defined period of repetition.
>>
>> That's not all that "random" means.  It might be very difficult to
>> predict the next -- well, whatever numeric value you might derive from a
>> race condition.  But if it's possible to make *some* prediction at rates
>> better than chance, it's not random.
>
> That would mean that a stochastic, but bell-shaped distribution isn't
> random. I don't think you're entirely wrong, but you're not entirely
> right, either.
>
> As for multi-threaded timings, they're not random because
> a) a sufficiently deep program could in theory predict them, and
> b) a sufficiently devious program could in theory manipulate them.

True. However, I am more focused on the data returned from 
race-conditions being able to hit a 100% stable period of repetition. I 
am having trouble understanding how this can occur.


>
> And all C programs are, of course, in a state of sin.

;^D

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

#95794

On Thursday, November 3, 2016 at 8:56:46 PM UTC-4, Chris M. Thomasson wrote:
> On 11/1/2016 6:57 PM, Rick C. Hodgin wrote:
> > On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
> >> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
> >>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
> >>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
> >>>>> Anyone got an existing and truly random random number generator function
> >>>>> for me to copy? :)
> >>>>
> >>>> There are no such creations.  It's impossible in a software algorithm to
> >>>> create a truly random sequence without having truly random input.
> >>>
> >>> For fun, take a look at:
> >>>
> >>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
> >>> (read all please...)
> >>>
> >>> Is a mouse move a random event? How about a key press?
> >>>
> >>> I not saying this race infested thing I am messing around with is
> >>> random, I am saying its hard for it to hit a set period.
> >>>
> >>
> >> Did you take a look at my code Rick?
> >
> > No.  But to answer your question, any input that's not from an algorithm-
> > generated source can be considered random input.
> 
> This is why I think race-conditions in multi-threaded programs can be 
> considered random in the sense that its damn near impossible to hit a 
> defined period of repetition.

CPUs respond to interrupts triggered by external events of myriad form.
The independent systems on a machine are known, but impossible to predict
reliably.  You could predict by probability when certain events would
happen, but there's no way to know for certain.

They can be considered random.

Your observation here is actually why GNU never finished their HURD
kernel even to this day.  They chose a microkernel design with a host of
interfaces to communicate with all other pieces of hardware.  They could
not get the program debugged because the errors would crop up based on
whether or not this sent its data before or after that, and so on.

I came very close to completing the HURD kernel for them in 2012, but
when I found out some things about Richard Stallman's beliefs, as a
Christian I could not support him, so I created my current projects base
and the Liberty Software Foundation as a God-fearing alternative to the
Free Software Foundation.

Best regards,
Rick C. Hodgin

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

#95797

On 11/4/2016 12:49 PM, Rick C. Hodgin wrote:
> On Thursday, November 3, 2016 at 8:56:46 PM UTC-4, Chris M. Thomasson wrote:
>> On 11/1/2016 6:57 PM, Rick C. Hodgin wrote:
>>> On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
>>>> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
>>>>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
>>>>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
>>>>>>> Anyone got an existing and truly random random number generator function
>>>>>>> for me to copy? :)
>>>>>>
>>>>>> There are no such creations.  It's impossible in a software algorithm to
>>>>>> create a truly random sequence without having truly random input.
>>>>>
>>>>> For fun, take a look at:
>>>>>
>>>>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
>>>>> (read all please...)
>>>>>
>>>>> Is a mouse move a random event? How about a key press?
>>>>>
>>>>> I not saying this race infested thing I am messing around with is
>>>>> random, I am saying its hard for it to hit a set period.
>>>>>
>>>>
>>>> Did you take a look at my code Rick?
>>>
>>> No.  But to answer your question, any input that's not from an algorithm-
>>> generated source can be considered random input.
>>
>> This is why I think race-conditions in multi-threaded programs can be
>> considered random in the sense that its damn near impossible to hit a
>> defined period of repetition.
>
> CPUs respond to interrupts triggered by external events of myriad form.
> The independent systems on a machine are known, but impossible to predict
> reliably.  You could predict by probability when certain events would
> happen, but there's no way to know for certain.
>
> They can be considered random.
>
> Your observation here is actually why GNU never finished their HURD
> kernel even to this day.  They chose a microkernel design with a host of
> interfaces to communicate with all other pieces of hardware.  They could
> not get the program debugged because the errors would crop up based on
> whether or not this sent its data before or after that, and so on.

This is exactly what happens when trying to debug a threaded program 
loaded with race-conditions. Every run of gives different results: its a 
total nightmare!

:^)


> I came very close to completing the HURD kernel for them in 2012, but
> when I found out some things about Richard Stallman's beliefs, as a
> Christian I could not support him, so I created my current projects base
> and the Liberty Software Foundation as a God-fearing alternative to the
> Free Software Foundation.

Fair enough.

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

#95799

On Friday, November 4, 2016 at 4:23:18 PM UTC-4, Chris M. Thomasson wrote:
> On 11/4/2016 12:49 PM, Rick C. Hodgin wrote:
> > On Thursday, November 3, 2016 at 8:56:46 PM UTC-4, Chris M. Thomasson wrote:
> >> On 11/1/2016 6:57 PM, Rick C. Hodgin wrote:
> >>> On Tuesday, November 1, 2016 at 8:45:26 PM UTC-4, Chris M. Thomasson wrote:
> >>>> On 10/28/2016 6:07 PM, Chris M. Thomasson wrote:
> >>>>> On 10/28/2016 7:14 AM, Rick C. Hodgin wrote:
> >>>>>> On Friday, October 28, 2016 at 8:31:47 AM UTC-4, Mr. Man-wai Chang wrote:
> >>>>>>> Anyone got an existing and truly random random number generator function
> >>>>>>> for me to copy? :)
> >>>>>>
> >>>>>> There are no such creations.  It's impossible in a software algorithm to
> >>>>>> create a truly random sequence without having truly random input.
> >>>>>
> >>>>> For fun, take a look at:
> >>>>>
> >>>>> https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion
> >>>>> (read all please...)
> >>>>>
> >>>>> Is a mouse move a random event? How about a key press?
> >>>>>
> >>>>> I not saying this race infested thing I am messing around with is
> >>>>> random, I am saying its hard for it to hit a set period.
> >>>>>
> >>>>
> >>>> Did you take a look at my code Rick?
> >>>
> >>> No.  But to answer your question, any input that's not from an algorithm-
> >>> generated source can be considered random input.
> >>
> >> This is why I think race-conditions in multi-threaded programs can be
> >> considered random in the sense that its damn near impossible to hit a
> >> defined period of repetition.
> >
> > CPUs respond to interrupts triggered by external events of myriad form.
> > The independent systems on a machine are known, but impossible to predict
> > reliably.  You could predict by probability when certain events would
> > happen, but there's no way to know for certain.
> >
> > They can be considered random.
> >
> > Your observation here is actually why GNU never finished their HURD
> > kernel even to this day.  They chose a microkernel design with a host of
> > interfaces to communicate with all other pieces of hardware.  They could
> > not get the program debugged because the errors would crop up based on
> > whether or not this sent its data before or after that, and so on.
> 
> This is exactly what happens when trying to debug a threaded program 
> loaded with race-conditions. Every run of gives different results: its a 
> total nightmare!

Exactly.  This is why I'm a big proponent of the idea of having dedicated
soft virtual machines for debugging software during development.  They can
be soft triggered to reproduce a complete environment states time and time
again, even taking snapshots from a prior saved state and restarting them
with an updated software image.  And, by introducing artificial randomness,
you can fuzzy test things iteratively to try and weed out those bugs.

I also believe in edit-and-continue, something I call LiveCode, so you can
fix and repeat again and again without the need of recompiling everything,
but only the few lines that failed.  And, when the fix is big enough, then,
and only then, do the full rebuild during debugging.

I have a minimal number of people who are in this camp, but we remain
quite certain that ours is the correct camp to be in (with regards to
the edit-and-continue and debugging-in-a-soft-vm environments).

:-)

Best regards,
Rick C. Hodgin

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

#95876

On 2016-11-04 16:32, Rick C. Hodgin wrote:
>
> I also believe in edit-and-continue, something I call LiveCode, so you can
> fix and repeat again and again without the need of recompiling everything,
> but only the few lines that failed.  And, when the fix is big enough, then,
> and only then, do the full rebuild during debugging.
>

That would definitely be a much more efficient way of coding! I've seen 
a couple of "live IDEs" online that do this but I'm not sure if they 
have C or other compiled languages. Mainly I see it done with 
Javascript, Python or HTML.

-- 
A computer is like an Old Testament god, with a lot of rules and no
mercy. - Joseph Campbell

SweetSpearGirl stories and Gemstone Mod:
http://imperium.elementfx.com/ - Now With Forums

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

#95880

On Saturday, November 5, 2016 at 6:49:10 PM UTC-4, ImperiusDamian wrote:
> On 2016-11-04 16:32, Rick C. Hodgin wrote:
> >
> > I also believe in edit-and-continue, something I call LiveCode, so you can
> > fix and repeat again and again without the need of recompiling everything,
> > but only the few lines that failed.  And, when the fix is big enough, then,
> > and only then, do the full rebuild during debugging.
> 
> That would definitely be a much more efficient way of coding! I've seen 
> a couple of "live IDEs" online that do this but I'm not sure if they 
> have C or other compiled languages. Mainly I see it done with 
> Javascript, Python or HTML.

Microsoft's Visual Studio 2015 is free for use on open source projects.  It
has a really nice and advanced edit-and-continue ability which, IIRC, also
works for 64-bit code, whereas their older products only worked for 32-bit
code.

Microsoft has had edit-and-continue in their Visual line of developer tools
since 1998.  Visual Studio's 2015 version also has a really amazing code
analyzer.  It does static unit testing on your code by assuming branches
taken, and branches not taken, to see if there are places where you could
access a NULL pointer, access memory after it was released, etc.

Best regards,
Rick C. Hodgin

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

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

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

csiph-web