Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #35069 > unrolled thread
| Started by | Guillaume Dargaud <use_the_contact_form@www.gdargaud.net> |
|---|---|
| First post | 2013-08-07 11:07 +0200 |
| Last post | 2013-09-04 09:32 +0200 |
| Articles | 20 on this page of 119 — 22 participants |
Back to article view | Back to comp.lang.c
Random 64 bit number in stdc Guillaume Dargaud <use_the_contact_form@www.gdargaud.net> - 2013-08-07 11:07 +0200
Re: Random 64 bit number in stdc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-07 11:23 +0100
Re: Random 64 bit number in stdc Guillaume Dargaud <use_the_contact_form@www.gdargaud.net> - 2013-08-07 12:56 +0200
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-07 07:11 -0400
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-07 07:49 -0400
Re: Random 64 bit number in stdc jadill33@gmail.com - 2013-08-07 07:39 -0700
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 14:03 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-13 21:41 +0300
Re: Random 64 bit number in stdc Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-13 19:34 +0000
Re: Random 64 bit number in stdc Robert Wessel <robertwessel2@yahoo.com> - 2013-08-13 18:52 -0500
Re: Random 64 bit number in stdc "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2013-08-15 09:43 -0400
Re: Random 64 bit number in stdc Öö Tiib <ootiib@hot.ee> - 2013-08-13 19:23 -0700
Re: Random 64 bit number in stdc Nobody <nobody@nowhere.com> - 2013-08-14 07:30 +0100
Re: Random 64 bit number in stdc Geoff <geoff@invalid.invalid> - 2013-08-14 14:34 -0700
Re: Random 64 bit number in stdc Nobody <nobody@nowhere.com> - 2013-08-15 05:41 +0100
Re: Random 64 bit number in stdc Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-17 09:55 +0000
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-15 16:42 +0300
Re: Random 64 bit number in stdc Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-17 10:38 +0000
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-17 07:51 -0400
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-19 11:50 -0400
Re: Random 64 bit number in stdc Nobody <nobody@nowhere.com> - 2013-08-19 22:58 +0100
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-20 20:52 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-23 11:42 +0300
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-23 07:09 -0400
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-23 17:55 +0300
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-23 12:29 -0400
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-08-23 08:32 -0700
Re: Random 64 bit number in stdc Öö Tiib <ootiib@hot.ee> - 2013-08-23 09:32 -0700
Re: Random 64 bit number in stdc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-23 17:47 +0000
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-24 13:24 +0300
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-08-24 15:27 -0700
Re: Random 64 bit number in stdc "osmium" <r124c4u102@comcast.net> - 2013-08-25 19:05 -0500
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-08-25 19:54 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 17:14 +0300
[OT] Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-27 10:52 -0400
Re: [OT] Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 18:43 +0300
Re: [OT] Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-27 15:08 -0400
Re: Random 64 bit number in stdc "osmium" <r124c4u102@comcast.net> - 2013-08-27 10:59 -0500
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-27 12:27 -0400
Re: Random 64 bit number in stdc "osmium" <r124c4u102@comcast.net> - 2013-08-27 13:27 -0500
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-27 15:03 -0400
Re: Random 64 bit number in stdc "osmium" <r124c4u102@comcast.net> - 2013-08-27 19:02 -0500
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-27 22:14 -0400
OT:Re: Random 64 bit number in stdc "osmium" <r124c4u102@comcast.net> - 2013-08-28 07:36 -0500
Re: OT:Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-28 11:14 -0400
Re: OT:Re: Random 64 bit number in stdc "osmium" <r124c4u102@comcast.net> - 2013-08-28 10:59 -0500
Re: OT:Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-28 12:46 -0400
Re: OT:Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 21:13 +0300
Re: OT:Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-28 20:20 -0400
Re: OT:Re: Random 64 bit number in stdc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-28 18:07 +0100
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 21:10 +0300
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 21:08 +0300
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-08-27 12:21 -0700
Re: Random 64 bit number in stdc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-28 04:07 +0100
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 13:38 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-25 12:50 +0300
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 12:54 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-26 17:05 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 17:17 +0300
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-27 08:33 -0700
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-27 14:02 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-27 18:51 -0700
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 09:34 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-29 17:06 -0700
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-31 16:52 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-09-01 13:26 -0700
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-09-01 14:08 -0700
Re: Random 64 bit number in stdc Tim Rentsch <txr@alumni.caltech.edu> - 2013-09-02 12:41 -0700
Re: Random 64 bit number in stdc James Dow Allen <gmail@jamesdowallen.nospam> - 2013-08-19 04:19 +0000
Re: Random 64 bit number in stdc Rosario1903 <Rosario@invalid.invalid> - 2013-08-19 11:36 +0200
Re: Random 64 bit number in stdc James Dow Allen <gmail@jamesdowallen.nospam> - 2013-08-19 12:52 +0000
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-19 09:19 -0400
Re: Random 64 bit number in stdc James Dow Allen <jdallen2000@yahoo.com> - 2013-08-19 06:38 -0700
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-19 09:51 -0400
Re: Random 64 bit number in stdc James Dow Allen <jdallen2000@yahoo.com> - 2013-08-19 09:59 -0700
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-19 15:26 -0400
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-19 15:28 -0400
Re: Random 64 bit number in stdc James Dow Allen <jdallen2000@yahoo.com> - 2013-08-19 19:15 -0700
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 07:26 -0400
Re: Random 64 bit number in stdc James Dow Allen <gmail@jamesdowallen.nospam> - 2013-08-20 04:52 +0000
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 07:36 -0400
Re: Random 64 bit number in stdc Öö Tiib <ootiib@hot.ee> - 2013-08-21 00:29 -0700
Re: Random 64 bit number in stdc James Dow Allen <gmail@jamesdowallen.nospam> - 2013-08-21 11:35 +0000
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 08:30 -0400
Re: Random 64 bit number in stdc James Dow Allen <gmail@jamesdowallen.nospam> - 2013-08-21 13:08 +0000
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 10:08 -0400
Re: Random 64 bit number in stdc James Dow Allen <gmail@jamesdowallen.nospam> - 2013-08-21 14:41 +0000
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-08-19 11:03 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-25 10:15 -0700
Re: Random 64 bit number in stdc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-25 22:03 +0100
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-25 15:35 -0700
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-25 18:56 -0400
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-08-25 19:53 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-26 14:13 -0700
Re: Random 64 bit number in stdc James Kuyper <jameskuyper@verizon.net> - 2013-08-26 17:23 -0400
Re: Random 64 bit number in stdc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-26 02:18 +0100
Re: Random 64 bit number in stdc Richard Damon <Richard@Damon-Family.org> - 2013-08-25 21:25 -0400
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-27 17:03 +0300
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-08-27 14:45 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-28 21:18 +0300
Re: Random 64 bit number in stdc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-28 03:36 +0100
Re: Random 64 bit number in stdc Noob <root@localhost> - 2013-09-03 17:37 +0200
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-09-03 14:05 -0400
Re: Random 64 bit number in stdc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-03 20:11 +0000
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-09-03 16:29 -0400
Re: Random 64 bit number in stdc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-03 23:14 +0000
Re: Random 64 bit number in stdc Noob <root@localhost> - 2013-09-04 07:28 +0200
Re: Random 64 bit number in stdc Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-09-04 08:12 -0400
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-09-03 17:56 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-09-05 15:17 +0300
Re: Random 64 bit number in stdc Öö Tiib <ootiib@hot.ee> - 2013-09-05 06:22 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-09-05 08:20 -0700
Re: Random 64 bit number in stdc Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-09-06 15:13 +0300
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-09-06 13:23 -0700
Re: Random 64 bit number in stdc Noob <root@localhost> - 2013-09-07 08:20 +0200
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-09-07 01:06 -0700
Re: Random 64 bit number in stdc Chris DH <cdhorz@gmail.com> - 2013-09-07 02:19 -0700
Re: Random 64 bit number in stdc Keith Thompson <kst-u@mib.org> - 2013-09-07 14:41 -0700
Re: Random 64 bit number in stdc Noob <root@localhost> - 2013-09-04 09:32 +0200
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-27 15:03 -0400 |
| Message-ID | <521CF805.5070104@verizon.net> |
| In reply to | #35968 |
On 08/27/2013 02:27 PM, osmium wrote: > "James Kuyper" wrote: > >> On 08/27/2013 11:59 AM, osmium wrote: >> ... >>> them. I do not consider "The method used was flawed..." to be a >>> critique. >>> I think that is called "bitching". >> >> What do you consider inappropriate about complaining about the use of >> flawed methods? I could understand being annoyed if the complaint failed >> to identify the claimed flaws, or if there's no available alternative >> that's free of those flaws, but you didn't mention anything like that. > > I was responding to this in Carmody's post > >> Firstly, the method they used to generate those numbers is flawed. > > There is no substance there. It is simply an assertion by a Most High > Authority that the thing is flawed. That's odd. The message I saw containing that sentence followed it up with one mentioning a specific flaw: "I think it's at least 50 bits short of the maximum possible entropy in such a stream.", and citation of a place to look for more information about that flaw: "(See comp.compression from about 5-10 years ago.)". Were those parts missing from the message you received? I have to agree with Eric - 50 bits seems a very small complaint for such a large data set. But the fact that a specific flaw was identified means that there is some substance to the complaint, it is not "simply an assertion". The fact that discussion of the issue was cited means he's not trying to convince you on the sole basis of his "Most High Authority" - he's not only allowing you to see what the arguments for each side were, he's actively encouraging you to do so. I didn't get any hits using "million random digits", but when I told Google Groups to look for messages containing million, random, and digits separately, it found 38 hits during the specified time period in the specified newsgroup. Many of those hits contained the phrase "million random digits" - so the fact that the first search failed is another example of Google flakiness. Did you look at those threads? I haven't bothered, but this issue seems to be of interest to you, even if only in the negative sense.
[toc] | [prev] | [next] | [standalone]
| From | "osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2013-08-27 19:02 -0500 |
| Message-ID | <b84t0nF2tt3U1@mid.individual.net> |
| In reply to | #35974 |
"James Kuyper" wrote: > On 08/27/2013 02:27 PM, osmium wrote: >> "James Kuyper" wrote: >> >>> On 08/27/2013 11:59 AM, osmium wrote: >>> ... >>>> them. I do not consider "The method used was flawed..." to be a >>>> critique. >>>> I think that is called "bitching". >>> >>> What do you consider inappropriate about complaining about the use of >>> flawed methods? I could understand being annoyed if the complaint failed >>> to identify the claimed flaws, or if there's no available alternative >>> that's free of those flaws, but you didn't mention anything like that. >> >> I was responding to this in Carmody's post >> >>> Firstly, the method they used to generate those numbers is flawed. >> >> There is no substance there. It is simply an assertion by a Most High >> Authority that the thing is flawed. > > That's odd. The message I saw containing that sentence followed it up > with one mentioning a specific flaw: "I think it's at least 50 bits > short of the maximum possible entropy in such a stream.", and citation > of a place to look for more information about that flaw: "(See > comp.compression from about 5-10 years ago.)". Were those parts missing > from the message you received? > > I have to agree with Eric - 50 bits seems a very small complaint for > such a large data set. But the fact that a specific flaw was identified > means that there is some substance to the complaint, it is not "simply > an assertion". The fact that discussion of the issue was cited means > he's not trying to convince you on the sole basis of his "Most High > Authority" - he's not only allowing you to see what the arguments for > each side were, he's actively encouraging you to do so. > > I didn't get any hits using "million random digits", but when I told > Google Groups to look for messages containing million, random, and > digits separately, it found 38 hits during the specified time period in > the specified newsgroup. Many of those hits contained the phrase > "million random digits" - so the fact that the first search failed is > another example of Google flakiness. Did you look at those threads? I > haven't bothered, but this issue seems to be of interest to you, even if > only in the negative sense. I saw the full post you describe. As far as I was concerned he had wandered off into a discussion of how imperfect it was, I am quite sure the authors would be quite willing to agree it was imperfect. So what else is new? I did not read the link that the poster had trouble following, since he had problems it did not sound like a rewarding thing for *me* to follow. I did not search google groups, I searched google. People have had something like 50 years to present their findings and that's what I was looking for. But my google fu is not good enough to filter out the so called humor; all I find is attempts at humor. I looked at the internet because I wanted a mathematicians evaluation, a programming group on Usenet is going to give me programmers evaluations of the *technique*. The result is much more important to me than the technique If someone gives me a piece of metal he claims is flat, I want someone to tell me how flat it is, not talk about the qualities and merits of various polishing and honing compounds. It does sound like the people at Rand tried to juice the results a bit, I am not in favor of that at all.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-27 22:14 -0400 |
| Message-ID | <kvjmdn$p6e$1@dont-email.me> |
| In reply to | #35997 |
On 08/27/2013 08:02 PM, osmium wrote: > "James Kuyper" wrote: ... >> short of the maximum possible entropy in such a stream.", and citation >> of a place to look for more information about that flaw: "(See >> comp.compression from about 5-10 years ago.)". Were those parts missing ... >> I didn't get any hits using "million random digits", but when I told >> Google Groups to look for messages containing million, random, and >> digits separately, it found 38 hits during the specified time period in >> the specified newsgroup. Many of those hits contained the phrase >> "million random digits" - so the fact that the first search failed is >> another example of Google flakiness. Did you look at those threads? I >> haven't bothered, but this issue seems to be of interest to you, even if >> only in the negative sense. ... > I did not search google groups, I searched google. He cite a usenet newsgroup. You can find usenet messages using ordinary google searches, but that's not what google was designed for, and it doesn't do it very well. Google groups does is somewhat better (though it's still rather flaky). -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2013-08-28 07:36 -0500 |
| Subject | OT:Re: Random 64 bit number in stdc |
| Message-ID | <b8695qFblm4U1@mid.individual.net> |
| In reply to | #36002 |
"James Kuyper" wrote: >> I did not search google groups, I searched google. > > He cite a usenet newsgroup. You can find usenet messages using ordinary > google searches, but that's not what google was designed for, and it > doesn't do it very well. Google groups does is somewhat better (though > it's still rather flaky). Amazing! How long has this been going on? I typed in some more or less random stuff, waited a few minutes, got a message about a script running away, killed that, and got this from "Osmium" dated 2-27-2003 ---------------------- Allan Bruce writes: > > Bzzzt! Wrong. There's no such thing as "extended ASCII". There's ASCII, > > how do you explain this then? > http://www.asciitable.com/ That exposes one of the fundamental problems with the Internet. It is very easy to create misleading Web pages. And a pretty one it is too. I suspect that with a bit of patience even I could create a Web page. The glyphs shown there are the ones chosen by IBM or Microsoft for DOS to run on IBM clones. There are other, equally valid tables that could be made for the Atari ST, the Amiga, and the Mac of the same era. All equally valid and different from each other. -------------------- The French have a saying for this. Something like Plus la change, c'est la change. (Garbled of course) The ASCII table linked to is still there, too. But there is an advertisement for something called a '7" tablet'. Who knows what the page looked like in 2003? Today, at least, the page is not actually misleading, it *does* say "extended" but you have to read it carefully.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-28 11:14 -0400 |
| Subject | Re: OT:Re: Random 64 bit number in stdc |
| Message-ID | <521E13CC.4070106@verizon.net> |
| In reply to | #36015 |
On 08/28/2013 08:36 AM, osmium wrote:
> "James Kuyper" wrote:
>
>>> I did not search google groups, I searched google.
>>
>> He cite a usenet newsgroup. You can find usenet messages using ordinary
>> google searches, but that's not what google was designed for, and it
>> doesn't do it very well. Google groups does is somewhat better (though
>> it's still rather flaky).
>
> Amazing! How long has this been going on?
That sounds like sarcasm, but I can't quite figure out what your point
was, if that comment was intended to be sarcastic, so I'm going to
ignore it.
> I typed in some more or less random stuff, ...
Typing in non-random stuff, the 38 hits I mentioned earlier dropped to
19 when I actually looked at them (typical GG flakiness). Most of those
threads involved kooks claiming to have achieved lossless compression of
arbitrary files, using the million random digit file as a test case.
However, I also found the following seemingly relevant threads on
comp.compression between 5 and 10 years ago, just as he specified.
another go at RAND's one million random digits table
Compressing million random digits file
question related to RAND corp.'s "1 million random digits"
too much information!
Starting at the beginning.
So he did NOT present claims without substance. He didn't just assert
that there was problem, he identified it specifically. He did not ask
you to simply accept his authority - he directed you to discussions of
problem. The fact that you seem to have been unable to locate those
discussions is your problem, not his.
[toc] | [prev] | [next] | [standalone]
| From | "osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2013-08-28 10:59 -0500 |
| Subject | Re: OT:Re: Random 64 bit number in stdc |
| Message-ID | <b86l2pFe717U1@mid.individual.net> |
| In reply to | #36018 |
"James Kuyper" wrote:
> On 08/28/2013 08:36 AM, osmium wrote:
>> "James Kuyper" wrote:
>>
>>>> I did not search google groups, I searched google.
>>>
>>> He cite a usenet newsgroup. You can find usenet messages using ordinary
>>> google searches, but that's not what google was designed for, and it
>>> doesn't do it very well. Google groups does is somewhat better (though
>>> it's still rather flaky).
>>
>> Amazing! How long has this been going on?
>
> That sounds like sarcasm, but I can't quite figure out what your point
> was, if that comment was intended to be sarcastic, so I'm going to
> ignore it.
No that wasn't sarcasm, I really didn't know that. With the kinds of
queries I make any Usenet posts are going to be buried down in the noise.
>> I typed in some more or less random stuff, ...
>
> Typing in non-random stuff, the 38 hits I mentioned earlier dropped to
> 19 when I actually looked at them (typical GG flakiness). Most of those
> threads involved kooks claiming to have achieved lossless compression of
> arbitrary files, using the million random digit file as a test case.
> However, I also found the following seemingly relevant threads on
> comp.compression between 5 and 10 years ago, just as he specified.
>
> another go at RAND's one million random digits table
> Compressing million random digits file
> question related to RAND corp.'s "1 million random digits"
> too much information!
> Starting at the beginning.
>
> So he did NOT present claims without substance. He didn't just assert
> that there was problem, he identified it specifically. He did not ask
> you to simply accept his authority - he directed you to discussions of
> problem. The fact that you seem to have been unable to locate those
> discussions is your problem, not his.
OK, I was wrong. He specified that the answer to my objection was already
on the Web and I apologize..
-----
I looked at the first four pages of summaries for "compressing million
random digits file" and saw one hit that stood out, it spoke of a 1.36%
compression. Perhaps I should be impressed by that, but I am not - or maybe
that's the wrong post to look at. .
----
I made another attempt, with more of your keywords and noticed the name
Bruce Schneier in one of the summaries. He not only describes the method
used to produce the book, he says:
"I have a copy of the original book; it's one of
my library's prize possessions."
I think a recommendation from someone such as him elevates the book a few
notches above the Schildt comparison made in this thread.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-28 12:46 -0400 |
| Subject | Re: OT:Re: Random 64 bit number in stdc |
| Message-ID | <521E296D.8060203@verizon.net> |
| In reply to | #36019 |
On 08/28/2013 11:59 AM, osmium wrote: ... > OK, I was wrong. He specified that the answer to my objection was already > on the Web and I apologize.. > ----- > I looked at the first four pages of summaries for "compressing million > random digits file" and saw one hit that stood out, it spoke of a 1.36% > compression. Perhaps I should be impressed by that, but I am not - or maybe > that's the wrong post to look at. . No - as I said before, I agree with Eric's assessment that this is a very minor flaw. Object to it on those grounds, and I'm in full agreement with you. It was only your objections on other grounds (no substance, argument by assertion, argument from authority) that I disagreed with.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-28 21:13 +0300 |
| Subject | Re: OT:Re: Random 64 bit number in stdc |
| Message-ID | <87hae9wuoi.fsf@bazspaz.fatphil.org> |
| In reply to | #36019 |
"osmium" <r124c4u102@comcast.net> writes: > OK, I was wrong. He specified that the answer to my objection was already > on the Web and I apologize.. Accepted. No grudge borne. Let's get back to C! Phil -- If "law-abiding citizens have nothing to fear" from privacy-invading technologies and policies, then law-abiding governments should have nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-28 20:20 -0400 |
| Subject | Re: OT:Re: Random 64 bit number in stdc |
| Message-ID | <kvm443$va$1@dont-email.me> |
| In reply to | #36019 |
On 08/28/2013 11:59 AM, osmium wrote: > "James Kuyper" wrote: > >> On 08/28/2013 08:36 AM, osmium wrote: >>> "James Kuyper" wrote: ... >>>> He cite a usenet newsgroup. You can find usenet messages using ordinary >>>> google searches, but that's not what google was designed for, and it >>>> doesn't do it very well. Google groups does is somewhat better (though >>>> it's still rather flaky). >>> >>> Amazing! How long has this been going on? >> >> That sounds like sarcasm, but I can't quite figure out what your point >> was, if that comment was intended to be sarcastic, so I'm going to >> ignore it. > > No that wasn't sarcasm, I really didn't know that. With the kinds of > queries I make any Usenet posts are going to be buried down in the noise. It just occurred to me that your message suggested the possibility that you didn't know where to find it: <http://groups.google.com>. I normally prefer the advanced search <http://groups.google.com/advanced_search?q=&>, though many people find it to complicated. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-28 18:07 +0100 |
| Subject | Re: OT:Re: Random 64 bit number in stdc |
| Message-ID | <0.9fcf0392218399e72131.20130828180719BST.87bo4h7ni0.fsf@bsb.me.uk> |
| In reply to | #36015 |
"osmium" <r124c4u102@comcast.net> writes: <snip> > The French have a saying for this. Something like Plus la change, c'est la > change. "Plus ça change, plus c'est la même chose". Often just abbreviated to "plus ça change". Literally "the more things change, the more they say the same". I mention it because it's common enough, at least in the UK, to be considered an English phrase now (it's in the OED, for example). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-28 21:10 +0300 |
| Message-ID | <87li3lwus8.fsf@bazspaz.fatphil.org> |
| In reply to | #35997 |
"osmium" <r124c4u102@comcast.net> writes: > I saw the full post you describe. As far as I was concerned he had wandered > off into a discussion of how imperfect it was, First you claim it was an abrupt assertion, now you claim it was a discussion? Get your story straight! Phil -- If "law-abiding citizens have nothing to fear" from privacy-invading technologies and policies, then law-abiding governments should have nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-28 21:08 +0300 |
| Message-ID | <87ppsxwuwk.fsf@bazspaz.fatphil.org> |
| In reply to | #35960 |
"osmium" <r124c4u102@comcast.net> writes: > "Phil Carmody" wrote: > them. I do not consider "The method used was flawed..." to be a critique. > I think that is called "bitching". By the way, DES was flawed because it was not resistant to Linear Cryptanalysis. Fact, or bitching? I call it summarising a discussion, that's been done to death, very compactly. If you can't be bothered to research what the flaw was, then I've saved you effort, you should be thankful. If you did research it (such as by following the link I posted) and you didn't understand the arguments, then I've done you a favour, as I've told you the only sensible conclusion. So quit bitching about me educating you. On two things now, I should be charging for this. Phil -- If "law-abiding citizens have nothing to fear" from privacy-invading technologies and policies, then law-abiding governments should have nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-27 12:21 -0700 |
| Message-ID | <lny57ngcs9.fsf@nuthaus.mib.org> |
| In reply to | #35949 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> "osmium" <r124c4u102@comcast.net> writes:
>> "Öö Tiib" wrote:
>> > It is often (I would agree with Phil that almost idiomatically)
>> > seeded with wrong things like 'time(0)' that Wikipedia's article
>> > mentions several times: "The Mersenne Twister is sensitive to poor
>> > initialization and can take a long time to recover from a
>> > zero-excess initial state."
>>
>> Life is much too short to read this thread. But do you guys realize
>> that _A Million Random Digits_ is available for a free download?
>> That would seem to provide a decent seed.
>>
>> http://www.rand.org/pubs/monograph_reports/MR1418.html
>
> ARGH!!! I hope you're not trolling, as you've got a bite.
>
> Firstly, the method they used to generate those numbers is flawed.
> I think it's at least 50 bits short of the maximum possible entropy
> in such a stream. (See comp.compression from about 5-10 years ago.)
>
> Secondly, any randomly-generated stream of numbers, once written down,
> is no longer random. It's entirely predictable, just like the digits
> of pi.
True, but whether that's a problem depends on the application.
For many purposes, you really want both unpredictability and
good "random" qualities (passing various test criteria that you
undoubtedly understand better than I do).
But for some purposes, predictability either doesn't matter or is
actually desirable.
For example, suppose I'm testing an application, and I find that some
"random" inputs cause it to fail. If I can trigger the problem with
a perfectly reproducible pseudo-random sequence, that's probably
more useful than a cryptographically secure quantum-generated truly
random sequence.
A Mersenne Twister seeded with a chunk of _A Million Random Digits_
is probably pretty good for that kind of application.
Which I think is why rand(), poor though many implementations of
it are, is defined the way it is.
At the very least, though, you should be *aware* of whether the
pseudo-random numbers you're using are predictable or not.
--
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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-28 04:07 +0100 |
| Message-ID | <0.96cd31d4866a0aa78167.20130828040711BST.87ppsy7bts.fsf@bsb.me.uk> |
| In reply to | #35949 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes: <snip> > It's best to get out of the mindset of thinking about "random numbers" > but to instead think about "random sources/generators". Where the generator is algorithmic, I prefer the term "chaotic generator" but the standard terms are stuck firm now. It can help to think of it that way, even if you have to call it something else. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-08-24 13:38 -0700 |
| Message-ID | <kfnzjs6j02m.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #35616 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>> > Tim Rentsch <txr@alumni.caltech.edu> writes:
>> >> jadill33@gmail.com writes:
>> > ...
>> >> A better approach is to generate an appropriate value directly in
>> >> unsigned char units, eg
>> >>
>> >> #include <limits.h>
>> >>
>> >> #define INT_BIT /* .. number of bits in INT_MAX .. */
>> >> /* This can be done directly from INT_MAX using
>> >> the well known IMAX_BITS macro */
>> >>
>> >> int
>> >> uniform_nonnegative_int(){
>> >> unsigned mask_shift = (CHAR_BIT-1) - (INT_BIT-1) % CHAR_BIT;
>> >> unsigned mask = (unsigned char) -1 >> mask_shift;
>> >> int r = mask & (unsigned char) rand();
>> >> int i = (INT_BIT-1) / CHAR_BIT;
>> >>
>> >> while( i-- > 0 ) r = r << CHAR_BIT + (unsigned char) rand();
>> >
>> > Conventional wisdom, from decades of experience, says that the lower
>> > bits tend to be at least as crappy as the upper bits, so shifting
>> > them out is better than masking them in. I would also presume the
>> > "planes" property (relations between subseqent terms) is less likely
>> > to kick in too, but don't have the mathematical teeth to prove such
>> > a claim.
>>
>> Implementations of rand() may be of arbitrarily low quality, and I
>> grant you that some are pretty bad. Even so, I consider it a
>> disservice to promulgate folklore concerning deficiencies in rand(),
>> even if that folklore is known to have been (or even still be) correct
>> for some implementations.
>
> I consider it a public service. My advice is free and worth at least
> twice what you paid for it. [snip elaboration]
I respect the depth of understanding that underlies that
advice, which I believe you possess in greater measure than
most who would offer advice in this area.
At the same time, I suggest that it would be a better use of
your effort to provide a simple alternative PRNG, perhaps of
your own devising or perhaps a reference to an existing one,
that even if it isn't great is strong enough to be used
reliably (eg, passes all the dieharder tests) -- hopefully with
an accompanying implementation that is simple enough so people
can just pick it up and drop it in, and robust enough so it
isn't sensitive to the kinds of problems exhibited by other
widely used PRNG's (and mentioned elsethread). It would be
much nicer to see a simple "Use this!" message than a "If you
use rand(), which is bad anyway, at least don't use the low
order bits" kind of message. And I think it will make a
bigger difference for those seeking guidance - wouldn't it?
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-25 12:50 +0300 |
| Message-ID | <87wqnayu8w.fsf@bazspaz.fatphil.org> |
| In reply to | #35704 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
[SNIP - use of rand()]
> > I consider it a public service. My advice is free and worth at least
> > twice what you paid for it. [snip elaboration]
>
> I respect the depth of understanding that underlies that
> advice, which I believe you possess in greater measure than
> most who would offer advice in this area.
>
> At the same time, I suggest that it would be a better use of
> your effort to provide a simple alternative PRNG, perhaps of
> your own devising or perhaps a reference to an existing one,
> that even if it isn't great is strong enough to be used
> reliably (eg, passes all the dieharder tests) -- hopefully with
> an accompanying implementation that is simple enough so people
> can just pick it up and drop it in, and robust enough so it
> isn't sensitive to the kinds of problems exhibited by other
> widely used PRNG's (and mentioned elsethread). It would be
> much nicer to see a simple "Use this!" message than a "If you
> use rand(), which is bad anyway, at least don't use the low
> order bits" kind of message. And I think it will make a
> bigger difference for those seeking guidance - wouldn't it?
The problem with PRNGs is that they are almost as varied as
languages. I wouldn't think of recommending just one single
computer language, different ones have different features
that are more or less important in context.
And to be honest, for those who've not delved into PRNGs, and who are
likely to just run with rand(), which is probably the majority of
people, I do think that "don't use the low order bits" is pretty much
the single most useful message.
But if you want some blood from the stone, for simple short-period
PRNGs, I do quite like some of Marsaglia's KISS family of algorithms,
but I really dislike his coding style so wouldn't recommend them to
newbs. Most are no better than the better rand()s, but at least you
know what you're getting when you use them.
For longer period PRNGs, the seeding is critical. If you just seed
with calls to rand(), then you're quite likely just selecting one of
RAND_MAX possible sequences, and if that's good enough, then in truth
you probably didn't need the long period anyway, you were just showing
off by thowing keywords around. Ideal would be seeding from either
/dev/{,u}random or a saved entropy pool (remember to atexit() the
saving of the pool state though (and you might want to just delete the
pool immediately after reading so that you don't accidentally re-use
it)). But in the end almost nobody needs such long periods, and those
that do are probably highly numerate academics and are smart enough
to not need advice from me.
If rand() or the KISS one-liners are too crap, and seeding MT's
too much hassle, then the best middle ground I know of is the
8-word 7-xorshift from:
"On the xorshift random number generators" -- Panneton, Francois, in
ACM Transactions on Modeling and Computer Simulation Vol. 15 (Issue 4).
But you've still got the problem of finding 256 bits of entropy to
start it off (the same problem as MT, just smaller).
Phil
--
If "law-abiding citizens have nothing to fear" from privacy-invading
technologies and policies, then law-abiding governments should have
nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-08-26 12:54 -0700 |
| Message-ID | <kfnob8kgrdq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #35764 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> [SNIP - use of rand()]
>> > I consider it a public service. My advice is free and worth at least
>> > twice what you paid for it. [snip elaboration]
>>
>> I respect the depth of understanding that underlies that
>> advice, which I believe you possess in greater measure than
>> most who would offer advice in this area.
>>
>> At the same time, I suggest that it would be a better use of
>> your effort to provide a simple alternative PRNG, perhaps of
>> your own devising or perhaps a reference to an existing one,
>> that even if it isn't great is strong enough to be used
>> reliably (eg, passes all the dieharder tests) -- hopefully with
>> an accompanying implementation that is simple enough so people
>> can just pick it up and drop it in, and robust enough so it
>> isn't sensitive to the kinds of problems exhibited by other
>> widely used PRNG's (and mentioned elsethread). It would be
>> much nicer to see a simple "Use this!" message than a "If you
>> use rand(), which is bad anyway, at least don't use the low
>> order bits" kind of message. And I think it will make a
>> bigger difference for those seeking guidance - wouldn't it?
>
> The problem with PRNGs is that they are almost as varied as
> languages. I wouldn't think of recommending just one single
> computer language, different ones have different features
> that are more or less important in context. [snip extended
> discussion]
The extended discussion was interesting. What I was trying to
suggest though is more modest - a replacement for rand(), nothing
more than that. Here's what I imagine its characteristics
would be:
* portable across conforming C implementations (including
both C90 and C99 (and C11, naturally))
* return type is the lesser of unsigned int and unsigned
long, but width no less than 32 bits; results to be
uniformly distributed across the 2**32 values
* takes a single seed value of the same type as the
return type; any 32-bit seed value should give
reasonable results
* in the event that the implementation does not have
an unsigned type of exactly 32 bits, mask any
intermediate values as necessary so results are
consistent across implementations
* period for any seed value should be "large", let's
say 2**150 or more; it doesn't matter if the
sequences for different seed values overlap or
not as long as they aren't exactly the same
* not too slow (the RNG you mentioned looks sort
of interesting but it does look a little slow)
* results of good quality across all output bits
and all combinations of output bits
The idea is to say "if you're thinking about using rand(),
use X instead; if you need something better than that,
then more work needs to be done (and then a reference
presumably)." If you have more than one candidate for
X, it seems perfectly okay to say "use X or Y or Z"
rather than giving just one.
What do you say? Is this doable? Doesn't it seem
like steering neophytes to X (or Y or Z or ...)
would be better than trying to get them not to
use the low bits of rand()?
[toc] | [prev] | [next] | [standalone]
| From | Chris DH <cdhorz@gmail.com> |
|---|---|
| Date | 2013-08-26 17:05 -0700 |
| Message-ID | <kvgqgu$hh6$3@dont-email.me> |
| In reply to | #35865 |
On 8/26/2013 12:54 PM, Tim Rentsch wrote: > Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes: >> [SNIP - use of rand()] >>>> I consider it a public service. My advice is free and worth at least >>>> twice what you paid for it. [snip elaboration] >>> >>> I respect the depth of understanding that underlies that >>> advice, which I believe you possess in greater measure than >>> most who would offer advice in this area. >>> >>> At the same time, I suggest that it would be a better use of >>> your effort to provide a simple alternative PRNG, perhaps of >>> your own devising or perhaps a reference to an existing one, >>> that even if it isn't great is strong enough to be used >>> reliably (eg, passes all the dieharder tests) -- hopefully with >>> an accompanying implementation that is simple enough so people >>> can just pick it up and drop it in, and robust enough so it >>> isn't sensitive to the kinds of problems exhibited by other >>> widely used PRNG's (and mentioned elsethread). It would be >>> much nicer to see a simple "Use this!" message than a "If you >>> use rand(), which is bad anyway, at least don't use the low >>> order bits" kind of message. And I think it will make a >>> bigger difference for those seeking guidance - wouldn't it? >> >> The problem with PRNGs is that they are almost as varied as >> languages. I wouldn't think of recommending just one single >> computer language, different ones have different features >> that are more or less important in context. [snip extended >> discussion] > > The extended discussion was interesting. What I was trying to > suggest though is more modest - a replacement for rand(), nothing > more than that. Here's what I imagine its characteristics > would be: > > * portable across conforming C implementations (including > both C90 and C99 (and C11, naturally)) > > * return type is the lesser of unsigned int and unsigned > long, but width no less than 32 bits; results to be > uniformly distributed across the 2**32 values > > * takes a single seed value of the same type as the > return type; any 32-bit seed value should give > reasonable results > > * in the event that the implementation does not have > an unsigned type of exactly 32 bits, mask any > intermediate values as necessary so results are > consistent across implementations > > * period for any seed value should be "large", let's > say 2**150 or more; it doesn't matter if the > sequences for different seed values overlap or > not as long as they aren't exactly the same > > * not too slow (the RNG you mentioned looks sort > of interesting but it does look a little slow) > > * results of good quality across all output bits > and all combinations of output bits > > The idea is to say "if you're thinking about using rand(), > use X instead; if you need something better than that, > then more work needs to be done (and then a reference > presumably)." If you have more than one candidate for > X, it seems perfectly okay to say "use X or Y or Z" > rather than giving just one. > > What do you say? Is this doable? Doesn't it seem > like steering neophytes to X (or Y or Z or ...) > would be better than trying to get them not to > use the low bits of rand()? I don't really have a comment on positive campaigning (for any particular algorithm) vs negative campaigning (against those used in libc implementations which I agree are awful, and their low bits in particular, which I agree are way beyond awful). But I do have a number of other things to say on things mentioned in there... ** Dieharder: Note that dieharder, while it has some interesting algorithms in it, is not really a good practical test for PRNGs atm, particularly if you use the built-in arrangement of tests (the -a command line option). TestU01 Crush / BigCrush and PractRand (disclosure: the later is mine) are much more effective. ** PRNG requirements: Most of your requirements are trivially doable in a PRNG design, but you should think a bit about exactly what you mean there. Many people will not consider a PRNG portable unless it produces exactly the same sequence of numbers on all platforms it targets. You listed near-universal portability as a requirement, while simultaneously suggesting that its output format should be platform-dependent. Perhaps you should clarify "portable", or adjust the later requirement? You refer to a "period" of at least 2**150 casually, while explicitly permitting multi-cyclic PRNGs. This means you want a proven minimum cycle length of 2**150 for every cycle individually, but don't care how many cycles there are. There is no way a modern computer could exhaust a cycle of length of 2**64 in under a millennia. Of course, there are larger requirements needed to avoid collisions between threads, runs, computers, etc - but those are satisfied just as well by the combined length of all usable cycles rather than a minimum cycle length, and anything that cares about such scenarios will also require a lot more than the 2**32 possible seeds you required anyway. I gave code for a small PRNG in another post in this thread that offered a minimum cycle length of 2**64, an average cycle length of 2**255, very high speed, passing all general purpose statistical tests available today, 64 random bits per call, no invalid states, and fairly simple code. I would happily post other PRNGs that meet other sets of requirements if you care to clarify exactly what requirements you were looking for.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-27 17:17 +0300 |
| Message-ID | <87txibxlom.fsf@bazspaz.fatphil.org> |
| In reply to | #35903 |
Chris DH <cdhorz@gmail.com> writes: > I gave code for a small PRNG in another post in this thread that > offered a minimum cycle length of 2**64, an average cycle length of > 2**255, very high speed, passing all general purpose statistical tests > available today Even hamming weight correlation tests? Phil -- If "law-abiding citizens have nothing to fear" from privacy-invading technologies and policies, then law-abiding governments should have nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | Chris DH <cdhorz@gmail.com> |
|---|---|
| Date | 2013-08-27 08:33 -0700 |
| Message-ID | <kvigr9$hh6$5@dont-email.me> |
| In reply to | #35950 |
On 8/27/2013 7:17 AM, Phil Carmody wrote: > Chris DH <cdhorz@gmail.com> writes: >> I gave code for a small PRNG in another post in this thread that >> offered a minimum cycle length of 2**64, an average cycle length of >> 2**255, very high speed, passing all general purpose statistical tests >> available today > > Even hamming weight correlation tests? > > Phil > All tests of individual RNG output streams - the sort done by TestU01, PractRand, dieharder, STS, ENT, diehard, etc. It sounds like you're talking about avalanche-style testing though, in which PRNG instances are forced in to nearby (by hamming distance) states, and then the rate of divergence of either the states or the output streams is measured? If you start with 1 bit deltas in internal state (any bit of the internal state except those in the counter) and look for correlations, it takes maybe 6 calls for the correlation to become difficult to detect by eye, maybe 10 calls for the correlation to become difficult to detect with software tools. Good enough I wouldn't worry about it in typical parallel PRNG usage scenarios, but bad enough I would worry about it in exceptionally difficult parallel scenarios. Of course, doing well on that kind of test is neither necessary nor sufficient to be a good PRNG, though the results can be and usually are highly useful in PRNG design.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web