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

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

Re: Learn "elusive" and "reprimand" using C!

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Learn "elusive" and "reprimand" using C! Keith Thompson <kst-u@mib.org> - 2016-09-09 12:26 -0700
    Re: Learn "elusive" and "reprimand" using C! Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-09 13:55 -0700
      Re: Learn "elusive" and "reprimand" using C! Richard Heathfield <rjh@cpax.org.uk> - 2016-09-09 22:04 +0100
      Re: Learn "elusive" and "reprimand" using C! Keith Thompson <kst-u@mib.org> - 2016-09-09 15:26 -0700
        Re: Learn "elusive" and "reprimand" using C! Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-09 14:31 -0700
          Re: Learn "elusive" and "reprimand" using C! Keith Thompson <kst-u@mib.org> - 2016-09-09 17:02 -0700
          Re: Learn "elusive" and "reprimand" using C! gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-09 22:55 +0000
          Re: Learn "elusive" and "reprimand" using C! jameskuyper@verizon.net - 2016-09-09 17:01 -0700
    Re: Learn "elusive" and "reprimand" using C! Paul N <gw7rib@aol.com> - 2016-09-11 08:26 -0700
      Re: Learn "elusive" and "reprimand" using C! "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-11 11:49 -0400
      Re: Learn "elusive" and "reprimand" using C! Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 11:51 -0700
      Re: Learn "elusive" and "reprimand" using C! Keith Thompson <kst-u@mib.org> - 2016-09-11 13:58 -0700
      Re: Learn "elusive" and "reprimand" using C! David Brown <david.brown@hesbynett.no> - 2016-09-12 09:08 +0200

#93334 — Re: Learn "elusive" and "reprimand" using C!

ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]

I haven't studied the entire program, but your use of srand() stands
out.

> /** @brief returns a random number from a measurement of some
> random process.
> @details The overall quality of randomness of this function is
> not specified. In the worst case it might always return the same
> number. */
> unsigned int entropy( void )
> { return( unsigned int )( time( 0 )* time( 0 ) + time( 0 ) ); }

If time_t is a signed type (as it commonly is, this could easily
overflow, causing undefined behavior.

All three calls to time(0) will very likely return the same value, so
calling it three times probably doesn't add any more entropy.

> int main( void )
> {
>   srand( entropy() * entropy() + entropy() );
>   srand( ( unsigned int )rand() * entropy() );
>   rand(); rand(); rand();

It looks like you're arbitrarily making multiple calls to srand()
and rand() with arbitrary arguments, in the hope of getting behavior
that's somehow "more random".

If the implementation of srand() and rand() works well, then calling
srand(time(0)) once, then calling rand() once for each random number
you need, should be sufficient.  If it doesn't work well, then no
amount of tweaking is going to squeeze high-quality pseudo-random
numbers out of it.

You might consider wrapping srand() and rand() in functions that
you can update if necessary to use some system-specific PRNG.

[...]

-- 
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] | [next] | [standalone]

#93338

On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>
> All three calls to time(0) will very likely return the same value, so
> calling it three times probably doesn't add any more entropy.
> 
You've found a way of doing work without adding entropy to the
universe?
Congratulations. Nobel prize for this man.

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

#93339

On 09/09/16 21:55, Malcolm McLean wrote:
> On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>>
>> All three calls to time(0) will very likely return the same value, so
>> calling it three times probably doesn't add any more entropy.
>>
> You've found a way of doing work without adding entropy to the
> universe?
> Congratulations. Nobel prize for this man.

Not that kind of entropy, Malcolm.

See "A mathematical theory of communication", Claude Shannon, 1948, or 
look up Shannon entropy in your favourite search engine.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#93341

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>> All three calls to time(0) will very likely return the same value, so
>> calling it three times probably doesn't add any more entropy.
>> 
> You've found a way of doing work without adding entropy to the
> universe?
> Congratulations. Nobel prize for this man.

Glad to see that you're reading my posts, Malcolm.

Any response to my challenge to cite a reputable source that agrees with
your usage of the word "array"?

-- 
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]

#93342

On Friday, September 9, 2016 at 10:20:27 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
> >> All three calls to time(0) will very likely return the same value, so
> >> calling it three times probably doesn't add any more entropy.
> >> 
> > You've found a way of doing work without adding entropy to the
> > universe?
> > Congratulations. Nobel prize for this man.
> 
> Glad to see that you're reading my posts, Malcolm.
> 
> Any response to my challenge to cite a reputable source that agrees with
> your usage of the word "array"?
> 
Kenny has described the situation with cites.

Inevitably responding to such a challenge results in a claim that 
it has not been met.

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

#93347

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, September 9, 2016 at 10:20:27 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>> >> All three calls to time(0) will very likely return the same value, so
>> >> calling it three times probably doesn't add any more entropy.
>> >> 
>> > You've found a way of doing work without adding entropy to the
>> > universe?
>> > Congratulations. Nobel prize for this man.
>> 
>> Glad to see that you're reading my posts, Malcolm.
>> 
>> Any response to my challenge to cite a reputable source that agrees with
>> your usage of the word "array"?
>> 
> Kenny has described the situation with cites.

I wouldn't know about that.  In any case, I asked you.

> Inevitably responding to such a challenge results in a claim that 
> it has not been met.

It certainly hasn't so far.  I guess I'll just continue pointing
out when you misuse the word "array".

-- 
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]

#93348

In article <eeaba7ec-c331-466b-9aee-bb85e53b2f9e@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>On Friday, September 9, 2016 at 10:20:27 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>> >> All three calls to time(0) will very likely return the same value, so
>> >> calling it three times probably doesn't add any more entropy.
>> >> 
>> > You've found a way of doing work without adding entropy to the
>> > universe?
>> > Congratulations. Nobel prize for this man.
>> 
>> Glad to see that you're reading my posts, Malcolm.
>> 
>> Any response to my challenge to cite a reputable source that agrees with
>> your usage of the word "array"?
>> 
>Kenny has described the situation with cites.
>
>Inevitably responding to such a challenge results in a claim that 
>it has not been met.

Indeed.  But don't forget that one time, back in 1993, I believe, where
someone on Usenet did accept someone else's cite claim.

Hasn't happened since, of course.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain in
compliance with said RFCs, the actual sig can be found at the following web address:
	http://www.xmission.com/~gazelle/Sigs/Voltaire

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

#93350

Well, since I cannot remember ever seeing anyone else use your own special meaning for "array" in a C context, I think it will be difficult, maybe even impossible, to find a valid example.
You speak your own idiosyncratic dialect of English, in which many of the words used to describe computer programming have meanings that differ not only from those specified by the C standard (which are the only definitions relevant to a discussion of C), but also different from the way just about anyone else uses those words.
As a result, in the unlikely event that you do find someting you think is a valid example, I consider it extremely likely that your belief will be the result of misunderstanding something written in conventional English as if it had been written in Malcolm-English.
Therefore, I have to agree that it's likely to be a waste of your time to look for such an example. However, I reached that conclusion based upon my evaluation of tbe relevant evidence, leading me to the conclusion that you are wrong.
However, if you were in fact right, it would not be pointless. If your special meaning for "array" were on fact the conventional one, it should be trivial for you to locate hundreds of examples clearly demonstrating that fact, even to the satisfaction of skeptics like Keith and me.

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

#93375

On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
> If the implementation of srand() and rand() works well, then calling
> srand(time(0)) once, then calling rand() once for each random number
> you need, should be sufficient.  If it doesn't work well, then no
> amount of tweaking is going to squeeze high-quality pseudo-random
> numbers out of it.

Imagine a system where rand() returns n+1, where n is the number returned last time. The programmer thinks this looks a bit too predictable, so by suitably wrapping the function he gets a function that returns 2147001325 * n + 718136305 modulo 2^32. Would this contradict your last sentence?

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

#93377

On 09/11/2016 11:26 AM, Paul N wrote:
> On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>> If the implementation of srand() and rand() works well, then calling
>> srand(time(0)) once, then calling rand() once for each random number
>> you need, should be sufficient.  If it doesn't work well, then no
>> amount of tweaking is going to squeeze high-quality pseudo-random
>> numbers out of it.
>
> Imagine a system where rand() returns n+1, where n is the number returned last time. The programmer thinks this looks a bit too predictable, so by suitably wrapping the function he gets a function that returns 2147001325 * n + 718136305 modulo 2^32. Would this contradict your last sentence?

That's not "tweaking". That's essentially writing your own replacement 
for rand(), ingeniously making use of the ridiculously badly implemented 
rand() that came with the system to achieve that result.

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

#93379

Paul N <gw7rib@aol.com> writes:

> On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>> If the implementation of srand() and rand() works well, then calling
>> srand(time(0)) once, then calling rand() once for each random number
>> you need, should be sufficient.  If it doesn't work well, then no
>> amount of tweaking is going to squeeze high-quality pseudo-random
>> numbers out of it.
>
> Imagine a system where rand() returns n+1, where n is the number
> returned last time.  The programmer thinks this looks a bit too
> predictable, so by suitably wrapping the function he gets a function
> that returns 2147001325 * n + 718136305 modulo 2^32.  Would this
> contradict your last sentence?

The transformation you describe is (IMO) minor enough to qualify
as a tweak.  Now let's look at the problems.

One, the resulting sequence of numbers is quite poor for the
output of a PRNG.  It fails even very simple statistical tests.

Two, the value of RAND_MAX may be as low as 32768.  If rand() is
doing a poor job, and RAND_MAX is only 32768, it may be
essentially impossible to transform rand() output values (ie, via
a pure function) to produce good random numbers.  The reason
there aren't enough distinct input values to provide sufficient
variation in the output.

Three, both of these last two problems may be overcome by adding
some state to the transformation function and using a more
elaborate mapping.  By the time you're done doing that though,
first, the result will be well outside of being a tweak, and
second, you might as well have just written a PRNG yourself.
Anything less and you'll find yourself in the same boat as
before, except some extra code had to be written to get there.
Better to just give up on rand() and get a good PRNG from
somewhere else - there are several fairly easily available.

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

#93380

Paul N <gw7rib@aol.com> writes:
> On Friday, September 9, 2016 at 7:21:37 PM UTC+1, Keith Thompson wrote:
>> If the implementation of srand() and rand() works well, then calling
>> srand(time(0)) once, then calling rand() once for each random number
>> you need, should be sufficient.  If it doesn't work well, then no
>> amount of tweaking is going to squeeze high-quality pseudo-random
>> numbers out of it.
>
> Imagine a system where rand() returns n+1, where n is the number
> returned last time. The programmer thinks this looks a bit too
> predictable, so by suitably wrapping the function he gets a function
> that returns 2147001325 * n + 718136305 modulo 2^32. Would this
> contradict your last sentence?

Not significantly.  No real-world implementation of rand() is
*that* bad -- and your wrapped function still isn't what I'd call
high-quality.  And I'm not sure I'd call that "tweaking".

(Some rand() implementations are quite bad, though.  For example,
in the NetBSD implementation the low-order bit alternates between 0
and 1, and in general the N low-order bits repeat in a cycle of 2**N
iterations. -- unless NetBSD has fixed this since I last checked.)

-- 
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]

#93383

On 11/09/16 17:43, Stefan Ram wrote:
> Paul N <gw7rib@aol.com> writes:
>> Imagine a system where rand() returns n+1, where n is the
>> number returned last time. The programmer thinks this looks a
>> bit too predictable, so by suitably wrapping the function he
>> gets a function that returns 2147001325 * n + 718136305
>> modulo 2^32. Would this contradict your last sentence?
> 
>   That's a good point, but it is possible (though unlikely)
>   that exactly this transformation applied to another rand()
>   function will transform a "more random" sequence into one
>   with consecutively incrementing numbers (i.e., next =
>   previous + 1).
> 
>   I think Donald Knuth wrote about his experience: He mixed
>   ten totally different random-number generators, so that for
>   the next random number, first one of those generators is
>   chosen at random. He was impressed by his own brilliant
>   idea, until - upon first tests - he observed that his
>   "ingenious meta generator" always returned the same number.
>   (That's what my memory made of it; you can read the
>   original story in The Art Of Computer Programming IIRC.)
> 

Combining different sources of random number can quickly fall foul of
the central limit theorem.  It depends on /how/ you combine them, of
course, but it is very easy to end up reducing the entropy and moving
your distribution towards a bell curve.

[toc] | [prev] | [standalone]

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

csiph-web