LC53, a respectable random generator?

[Albert van der Horst]

In the wikipedia entry about Linear congruential generators there
is an entry with a Forth implementation : LC53.

There is no theoretical motivation or testresults behind it,
except a statement of Hugh Aguilar:
" invented it".
and
"
\ PRNG is not suitable for encryption; it is intended to be used in games and simulations.
"

It has nothing to offer over the first generator mentioned (from
Numerical Recipees) : less trusted source, slower implementation,
smaller period. It has with a high probability, never been used in
a program with some notoriety.

This may be a very poor generator, and it may reflect poorly on the
reputation of the Forth community. It may give a wrong impression about
the standing of Hugh's novice package in the Forth community.

I ask Hugh to remove the LC53 from the wikipedia entry, until such
time he has more explanation on his website about the quality of the
generator.

N.B. Numerical Recipees amounts to
: RAND SEED @ 1664525 * 1013904223 + DUP SEED ! ;
If you need a simple generator for games or graphics, why bother?

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[hughag...@yahoo.com]

On Saturday, November 23, 2013 9:25:28 AM UTC-7, Albert van der Horst wrote:
> In the wikipedia entry about Linear congruential generators there
> is an entry with a Forth implementation : LC53.
>
> There is no theoretical motivation or testresults behind it,
> except a statement of Hugh Aguilar:
> " invented it".
> and
> "
> \ PRNG is not suitable for encryption; it is intended to be used in games and simulations.
> "
>
> It has nothing to offer over the first generator mentioned (from
> Numerical Recipees) : less trusted source, slower implementation,
> smaller period. It has with a high probability, never been used in
> a program with some notoriety.

> This may be a very poor generator, and it may reflect poorly on the
> reputation of the Forth community. It may give a wrong impression about
> the standing of Hugh's novice package in the Forth community.
>
> I ask Hugh to remove the LC53 from the wikipedia entry, until such
> time he has more explanation on his website about the quality of the
> generator.

You don't need my permission to remove it --- anybody can edit Wikipedia pages. Just zap it on the grounds that it is "original research," which is the worst sin known in the Wikipedia world (the "original sin," so to speak). Don't forget to mention that my code "may" be of poor quality --- you never know!

I also have a link in the left-leaning red-black tree article, so you can go zap that one too, for the same reason. I had a link in the slide-rule article to my slide-rule program, but it has already been zapped for being original research, so you don't get the satisfaction of zapping it yourself.

Go for it Albert! Zapping my stuff on Wikipedia is your big opportunity to feel like a winner --- both the Wikipedia and the comp.lang.forth crowd will cheer you --- this will be your moment of glory!

> N.B. Numerical Recipees amounts to
> : RAND SEED @ 1664525 * 1013904223 + DUP SEED ! ;

What a moron you are! If you multiply a 32-bit number (SEED) by a 16-bit number (1664525), it will overflow.

But all is not lost! Those clever devils who wrote "Numerical Recipes" foresaw the overflow problem and made their multiplier a 16-bit number (1664525), and also made the divisor 2^32. In a language such as C or Pascal, a 16-bit compiler can implement this prng. The SEED is broken up into two 16-bit numbers, the low and the high parts. Each is multiplied by the 16-bit multiplier separately. Although these are 16x16 multiplications, 32x32 multiplication is used (the LONG INT type in C) so the product will be 32-bit. The product of the high multiplication is then shifted left by 16 bits, and the two products added together for a 32-bit result. This is effectively the same as multiplying the original SEED by the multiplier and taking the MOD of 2^32. It is still necessary to add in the C value, which is 32-bit, but is small enough that it won't overflow when added to any 32-bit number.

This is a lot of complicated rigmarole, but it allows the prng to be implemented on a 16-bit C compiler. In Forth, all of this rigmarole is not necessary, because we have mixed-precision arithmetic. Quite humorously however, the morons at Forth Inc. implemented their prng using the "Numerical Recipes" values, and they didn't use mixed-precision arithmetic --- they did the complicated rigmarole described above --- most likely, they just ported the algorithm directly from a C implementation without understanding how it worked, and without realizing that Forth's mixed-precision arithmetic could significantly simplify and speed up the implementation.

In my LC53, the multiplier does not fit in 16-bits, but it is a 32-bit number. Because of this, LC53 can't be implemented on a 16-bit C compiler (or a 16-bit Forth either). LC53 can only be implemented on a 32-bit C compiler by using LONG INT types, so all of the arithmetic is 64-bit. This is grossly slow, compared to using mixed-precision arithmetic on a 32-bit Forth system.

Wikipedia editors are, for the most part, morons who know nothing about any subject, but for psychological reasons want to be big experts on every subject. I think that you will fit right in Albert --- Wikipedia can be your new home!

C.L.F. is dying out. There are almost no posts with any technical content anymore. The C.L.F. crowd is so bored that they now respond to posts by Gavino and WJ etc., although those clowns are ignored on all of the other forums. I have left C.L.F. --- I only responded to this post because Albert specifically called me out regarding LC53 --- but I don't post here anymore. The C.L.F. crowd are going to need a new home after C.L.F. dies out --- so you can all go over to Wikipedia and edit articles there --- you can be big experts on every subject under the sun, and not just on Forth and linear-congruential prngs and stuff like that, which you are limited to here on C.L.F..

[hughag...@yahoo.com]

On Saturday, November 23, 2013 6:34:25 PM UTC-7, hughag...@yahoo.com wrote:
> On Saturday, November 23, 2013 9:25:28 AM UTC-7, Albert van der Horst wrote:
> > N.B. Numerical Recipees amounts to
> > : RAND SEED @ 1664525 * 1013904223 + DUP SEED ! ;
>
> What a moron you are! If you multiply a 32-bit number (SEED) by a 16-bit number (1664525), it will overflow.

Well, maybe I'm the moron --- 1664525 is not a 16-bit number, but is actually a 32-bit number. I was typing without thinking, as Albert's post and got my goat --- I just assumed that the LC prng he was advocating was one of the many floating around that use a 16-bit multiplier for the reason described.

This is the Wikipedia article where I included a link to my novice package, which Albert finds so offensive:
http://en.wikipedia.org/wiki/Linear_congruential_generator

Somewhat humorously, I found a mention of my LC53 in this Wikipedia article:
http://en.wikipedia.org/wiki/Lehmer_random_number_generator

I didn't put that there though, and I hadn't even noticed the article before (because I rarely read Wikipedia articles). My LC53 seems to spreading like a virus! Albert will have to track down every occurrence and zap them all --- this can be his new career!

[Albert van der Horst]

In article <40c88d42-05da-4ff6...@googlegroups.com>,

Of course I don't need not your permission, but it seems not a nice
thing to do.

>
>I also have a link in the left-leaning red-black tree article, so you
>can go zap that one too, for the same reason. I had a link in the
>slide-rule article to my slide-rule program, but it has already been
>zapped for being original research, so you don't get the satisfaction of
>zapping it yourself.

If you add a link to a Forth implementation of red-black trees, that
is totally in order.

>
>Go for it Albert! Zapping my stuff on Wikipedia is your big opportunity
>to feel like a winner --- both the Wikipedia and the comp.lang.forth
>crowd will cheer you --- this will be your moment of glory!
>
>> N.B. Numerical Recipees amounts to
>> : RAND SEED @ 1664525 * 1013904223 + DUP SEED ! ;
>
>What a moron you are! If you multiply a 32-bit number (SEED) by a 16-bit
>number (1664525), it will overflow.

Of course:
: * M* DROP ; \ Ignore m.s. part.
Also the + may overflow which doesn't lead to an exception in Forth,
because they could be interpreted as an unsigned number.
That is exactly how these random number generators work,
"silently ignore overflow".
(And 1664525 is not a 16 bit number, by the way.)

<SNIP>

>
>Wikipedia editors are, for the most part, morons who know nothing about
>any subject, but for psychological reasons want to be big experts on
>every subject. I think that you will fit right in Albert --- Wikipedia
>can be your new home!

An interesting remark ... from a Wikipedia editor!

[Rod Pemberton]

On Sat, 23 Nov 2013 11:25:28 -0500, Albert van der Horst
<alb...@spenarnc.xs4all.nl> wrote:

> In the wikipedia entry about Linear congruential generators
> there is an entry with a Forth implementation : LC53.
>

> There is no theoretical motivation or test results behind it,

> except a statement of Hugh Aguilar:
> " invented it".

LOL. Classic.

> and
> "
> \ PRNG is not suitable for encryption; it is intended to
> be used in games and simulations.
> "

...

> It has nothing to offer over the first generator mentioned (from
> Numerical Recipees) : less trusted source, slower implementation,
> smaller period. It has with a high probability, never been used in
> a program with some notoriety.

ROFL!

You wrote a "this has no purpose" clause for him! Or, was that
the obligatory "this sucks" clause? Now, I'm confused...

Sorry Hugh, too funny, not that you care...


Rod Pemberton

[Albert van der Horst]

In article <op.w61slwx45zc71u@localhost>,

I wrote an assesment for LC53 as it stands now, the disclaimer about
suitability is from Hugh.

You make it seem like I want to make fun of Hugh.
This is an invitation to back up his generator with some theory.
What he should do IMO is to run the tests from Knuth's TAO
and publish the results on his website. Even if the outcome is
soso, that would make the Wikipedia entry respectable.
If the outcome is really bad, then of course it is better to
remove the Wikipedia mention.

>
>Sorry Hugh, too funny, not that you care...

Hugh's novice thing is an honest effort. There may be flaws
in theoretical underpinnings (discussions with Passaniti come
to mind), as far as programming and documentation is concerned
it is pretty solid.

>
>
>Rod Pemberton

[m...@iae.nl]

On Sunday, November 24, 2013 3:17:27 PM UTC+1, Albert van der Horst wrote:
[..]

> This is an invitation to back up his generator with some theory.
> What he should do IMO is to run the tests from Knuth's TAO
> and publish the results on his website. Even if the outcome is
> soso, that would make the Wikipedia entry respectable.
> If the outcome is really bad, then of course it is better to
> remove the Wikipedia mention.

Marsaglia's Diehard test is more convenient.

The results are very bad. The birthday and gorilla tests
are even off the scale.

-marcel
-- -------------------------
FORTH> init-seeds diehard
DIEHARD is checking Ran-HA..

.---------------------------------------------------------------.
| This is the "tough" BIRTHDAY SPACINGS TEST |
| Choose 4096 birthdays in a "year" of 2^32 days. Thus each |
| birthday is a 32-bit integer and the test uses 2^12 of them, |
| so that j, the number of duplicate spacings, is asympotically |
| Poisson distributed with lambda=4. Generators that pass the |
| earlier tests for m=1024 and n=2^24 often fail this test, yet |
| those that pass this test seem to pass the "weaker" test. |
| Each set of 4096 birthdays provide a Poisson variate j, and |
| 500 such j's lead to a chisquare test to see if the result |
| is consistent with the Poisson distribution with lambda=16. |
`---------------------------------------------------------------'
Table of Expected versus Observed counts:
Duplicates 0 1 2 3 4 5 6 7 8 9 >=10
Expected 91 366 732 976 976 781 520 297 148 66 40
Observed 1102 1578 1274 661 277 79 23 3 2 1 0
(O-E)^2/E******4008.0 400.0 102.1 501.4 631.5 476.0 291.7 144.9 64.2 40.7
Birthday Spacings: Sum(O-E)^2/E = *******, p = 1.000
( 5.068 seconds elapsed. )

.-------------------------------------------------------------.
| This is the GCD TEST. Let the (32-bit) RNG produce two |
| successive integers u,v. Use Euclids algorithm to find the |
| gcd, say x, of u and v. Let k be the number of steps needed |
| to get x. Then k is approximately binomial with p=.376 |
| and n=50, while the distribution of x is very close to |
| Pr(x=i)=c/i^2, with c=6/pi^2. The gcd test uses ten |
| million such pairs u,v to see if the resulting frequencies |
| of k's and x's are consistent with the above distributions. |
| Congruential RNG's---even those with prime modulus---fail |
| this test for the distribution of k, the number of steps, |
| and often for the distribution of gcd values x as well. |
`-------------------------------------------------------------'
Euclid's algorithm:
p-value, steps to gcd: 0.640036
p-value, distance of gcd's: 0.892458
( 2.323 seconds elapsed. )

.---------------------------------------------------------------.
| This is the GORILLA test, a strong version of the monkey |
| tests that I developed in the 70's. It concerns strings |
| formed from specified bits in 32-bit integers from the RNG. |
| We specify the bit position to be studied, from 0 to 31, |
| say bit 3. Then we generate 67,108,889 (2^26+25) numbers |
| from the generator and form a string of 2^26+25 bits by |
| taking bit 3 from each of those numbers. In that string of |
| 2^26+25 bits we count the number of 26-bit segments that |
| do not appear. That count should be approximately normal |
| with mean 24687971 and std. deviation 4170. This leads to |
| a normal z-score and hence to a p-value. The test is |
| applied for each bit position 0 (leftmost) to 31. |
| (Some older tests use Fortran's 1-32 for most- to least- |
| significant bits. Gorilla and newer tests use C's 0 to 31.) |
`---------------------------------------------------------------'
Gorilla test for 2^26 bits, positions 0 to 31:
Note: lengthy test -- ~20 minutes for 900 MHz PC
Bits 0 to 7 || 0.000 0.000 0.001 0.000 0.000 0.000 0.000 0.000
Bits 8 to 15 || 0.000 0.006 0.000 0.000 0.000 0.000 0.001 0.000
Bits 16 to 23 || 0.001 0.000 0.000 0.003 0.000 0.003 0.000 0.000
Bits 24 to 31 || 0.003 0.000 0.291 0.049 0.102 0.611 0.001 0.000
ADKS test for the above 32 p values: 1.000
( 49.874 seconds elapsed. )

.---------------------------------------------------------------.
| THE OVERLAPPING 5-PERMUTATION TEST |
| This is the OPERM5 test. It looks at a sequence of ten |
| million 32-bit random integers. Each set of five consecutive |
| integers can be in one of 120 states, for the 5! possible |
| orderings of five numbers. Thus the 5th, 6th, 7th,...numbers |
| each provide a state. As many thousands of state transitions |
| are observed, cumulative counts are made of the number of |
| occurences of each state. Then the quadratic form in the |
| weak inverse of the 120x120 covariance matrix yields a test |
| that the 120 cellcounts came from the specified (asymptotic) |
| distribution with the specified means and 120x120 covariance. |
`---------------------------------------------------------------'
The OPERM5 test for 10 million (overlapping) 5-tuples for Ran-HA.
p-values for 5 runs: 0.5952 0.9339 0.8200 0.5496 0.1751
( 7.197 seconds elapsed. ) ok

[Albert van der Horst]

In article <d5eb8f1b-1bcb-4bbb...@googlegroups.com>,

I hate to see that someone is doing Hughs homework, but anyway.

Now we have come this far. Would you publish your test on your website?
I will then proceed with the wikipedia article adding a note like:
"look what happens if you try to invent a random generator without
theoretical background." and a reference to your site.

This was a test of the LC53 random generator. (Adding this information
to the body of the article too.)

[hughag...@yahoo.com]

On Sunday, November 24, 2013 7:17:27 AM UTC-7, Albert van der Horst wrote:
> In article <op.w61slwx45zc71u@localhost>,

> Hugh's novice thing is an honest effort. There may be flaws
> in theoretical underpinnings (discussions with Passaniti come
> to mind), as far as programming and documentation is concerned
> it is pretty solid.

You say this as if I am striving to obtain your praise, which you are willing to dribble out for me. I don't care if you think that my novice package is "pretty solid" --- because you yourself are about as solid as a marshmellow (and Passaniti and Payson's discussion of "theoretical underpinnings" was the same).

This reminds me of a private discussion I had with Jeff Fox:

I said:
"I think that a lot of people ... purposely promote Forth as a toy to avoid offending E.R. --- apparently they think that so long as Forth is alive, that is a good result, even if it is not being taken seriously by anybody --- the result is that Forth is like a zombie that lurches forward indefinitely without dying completely, but yet never shows any real sign of life."

Jeff said:
"I think there is a simpler explanation. People who write those 1%
performance type Forth or the 0.1% type Forth are probably doing
the best they can. Look at ciForth from Albert Vanderhorst. It is
basically a FIG-FORTH copied from the 70s. He promotes it because
he wrote it, it is his. He also talks about his AI work which is basically
a disassembler."

I think that what I find most loathsome about people such as yourself, is that you pick up some work from somebody else, and then promote it as if it is your own. You just picked up an old FIG Forth and renamed it ciForth. This is the same thing that you are doing now --- promoting the "Numerical Recipes" prng as if it is your own. You actually don't have the slightest idea how those constants (the multiplier and additive) were originally derived, but you are capable of typing them in to your code, and there you go --- you become an instant expert!

This, of course, is also why I find Elizabeth Rather to be so loathsome. There is no evidence to indicate that she has ever written a program herself. She just picked up Charles Moore's program and made it her own. Same thing with Passaniti --- never wrote a program himself --- just read about Splay Trees and Hash Tables in some algortithms book and declared himself a big expert. All of you are total phonies.

Payson is another phony. He is promoting his "quotations" when they are just :NONAME with some syntactic sugar. He actually knows that a quotation is supposed to have access to the local variables in the creator function (that is what makes them useful), but he doesn't know how to implement quotations correctly, so he just fakes it.

Hans Bezemer says:
"Obviously, you can always argue that whatever solution I (or someone
else) provide isn't CONSIDERED to be the real thing by Hugh Aguilar. But who
cares? The issue of who considers what to be what is purely academic if one
can't agree on definitions."

Hans and Elizabeth don't know what quotations are, but they are willing to accept any definition that anybody on the Forth-200x committee may offer. Bernd does know what quotations are though, but he just fakes it with a "dead easy" implementation that is useless, because he doesn't know how to implement them correctly. I was the only person other than Payson on the Forth-200x mailing list who knows that quotations are supposed to have access to the creator function's local variables, but Payson succeeded in getting me kicked off the Forth-200x mailing list for pointing out that his "quotations" fail to do this --- so now he is the sole expert on quotations on the Forth-200x committee, and he can continue to get his butt kissed by Hans etc. --- meanwhile, the real world is totally ignoring Forth-200x because in the real world people actually do care that things are done right. There is no disagreement on definitions --- basic computer-science concepts such as this have been well-known for many decades --- if you fake it and expect nobody to notice, the result will be that everybody will just ignore Forth-200x (which is exactly what has happened).

Most of the comp.lang.forth crowd are total phonies! I am concerned that this "may reflect poorly on the reputation of the Forth community."

[hughag...@yahoo.com]

On Saturday, November 23, 2013 9:25:28 AM UTC-7, Albert van der Horst wrote:
> This may be a very poor generator, and it may reflect poorly on the
> reputation of the Forth community. It may give a wrong impression about
> the standing of Hugh's novice package in the Forth community.
>

> I ask Hugh to remove the LC53 from the wikipedia entry...

Okay, you win! I removed the reference to LC53 from both the linear-congruential generator page, and the Lehmer page where somebody had referenced it. I also removed the reference to ASSOCIATION.4TH from the left-leaning red-black tree page. In every case, I cited the fact that it was original research as grounds for its removal. I'm not aware of any other mention of my software or myself on Wikipedia, but if you find any, tell me about it and I will remove those too.

This is a total victory for Albert! First he got my goat and induced me to respond hastily to his post here on C.L.F., making a fool of myself because I thought he was promoting a prng with a 16-bit multiplier when it was actually 32-bit. Now he has succeeded in getting me to delete all reference to my novice package on Wikipedia, which he thinks reflects poorly on the reputation of the "Forth community" (which he apparently is the champion of).

[Bernd Paysan]

m...@iae.nl wrote:

> On Sunday, November 24, 2013 3:17:27 PM UTC+1, Albert van der Horst wrote:
> [..]
>> This is an invitation to back up his generator with some theory.
>> What he should do IMO is to run the tests from Knuth's TAO
>> and publish the results on his website. Even if the outcome is
>> soso, that would make the Wikipedia entry respectable.
>> If the outcome is really bad, then of course it is better to
>> remove the Wikipedia mention.
>
> Marsaglia's Diehard test is more convenient.
>
> The results are very bad. The birthday and gorilla tests
> are even off the scale.

To be honest, a linear congruental generator is supposed to fail quickly in
any serious random number test suite. This doesn't mean it's not a good LC
generator, it just means linear congruental is not a good way to produce
random numbers. Dieharder, Big Crush, and the AFAIK most recent TestU01
suite are even better finding weaknesses than the original Diehard (which
can be considdered out of date, as it doesn't find many weaknesses).

The only advantage of an LC generator is that it is written in one line, and
fast. That's all. If you want a simple random number generator in
software, and you don't care much about its quality, take it. If you want a
simple random number generator in hardware, take a long enough xorshift
generator. If you want perfect quality no matter the costs, take a
cryptographic one. Some of those, like RC4, aren't actually that expensive.
RC4 has a bias for the first few thousand bytes, but after that, it is still
considered "good enough" to pass at least the random number tests and any
attempts outside the NSA to crack it; more recent stream ciphers and all the
SHA-3 finalists will for sure produce something that not only passes the
tests, but also theoretical analysis. However, they are easily by a factor
10 slower than an LC generator (~10 cycles per produced byte).

The 128 bit xorshift generator here passes even the diehard test:

http://en.wikipedia.org/wiki/Xorshift

If Hugh wants a better, yet still very simple PRNG in his novice suite that
does pass a reasonable test suite and is fast and easy to implement, he
should implement that one; the German Wikipedia has even (relatively good)
variants for 32 and 64 bits:

http://de.wikipedia.org/wiki/Xorshift

The test I use for a first look at the quality is FFT. I generate 2^n
random numbers, pass them through FFT, and what I expect as output values is
something close to a Gauss distribution around the expected average with the
expected sigma. This test detects all kinds of repetitive patterns and
biases in the random numbers. If it passes that test, I let TestU01 run.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[m...@iae.nl]

On Sunday, November 24, 2013 11:53:14 PM UTC+1, Bernd Paysan wrote:
> m...@iae.nl wrote:
[..]

> The test I use for a first look at the quality is FFT. I generate 2^n
> random numbers, pass them through FFT, and what I expect as output values is
> something close to a Gauss distribution around the expected average with the
> expected sigma. This test detects all kinds of repetitive patterns and
> biases in the random numbers. If it passes that test, I let TestU01 run.

That's an (hardware) engineer's evaluation :-) You could also
look at a geometrical representation of the output or listen to it.

For a Forth random generator many sources are available,
e.g. this is a lits from the past 10 years:

' .RAN-MWC256
\ ' .RANKISS
\ ' .RANDOM
\ ' .RANNEXT
\ ' .RANNEXT2
\ ' .RANDNEXT
\ ' .RAN-APHWB
\ ' .RAN-FAKE
\ ' .RAN-GFORTH
\ ' .RAN-RANGE
\ ' .RAN-MT
\ ' .RAN4
\ ' .RANR250
\ ' .RANR250x2
\ ' .RANR250sx2
\ ' .RAN-HA
\ ' .RANGGUBS

Most of them pass the test. MCW256 is not much slower
than RANDOM (an LC variant that is reasonable). Most
have problems with 64 bit Forths and should be modernized.

-marcel

[hughag...@yahoo.com]

On Sunday, November 24, 2013 4:41:23 PM UTC-7, m...@iae.nl wrote:
> For a Forth random generator many sources are available,

Well, I looked up RAND in SwiftForth v2. Here it is:

VARIABLE BUD

: RAND ( -- u ) BUD @ 3141592621 * 1+ DUP BUD ! ;

It isn't any good, which is why I came up with LC53. I misremembered when I said that it had a 16-bit multiplier; it is 32-bit also.

They credit Wil Baden with this in the source-code. It doesn't provide a full period. His multiplier looks suspiciously close to pi --- most likely he just pulled that number out of the air with the vague idea that it looked randomish.

[hughag...@yahoo.com]

On Sunday, November 24, 2013 3:53:14 PM UTC-7, Bernd Paysan wrote:
> If Hugh wants a better, yet still very simple PRNG in his novice suite that
> does pass a reasonable test suite and is fast and easy to implement, he
> should implement that one; the German Wikipedia has even (relatively good)
> variants for 32 and 64 bits:

Don't tell me what I "should" do --- you're nobody that I consider worth listening to on any subject.

[Albert van der Horst]

In article <eeb67c72-d51b-44e9...@googlegroups.com>,

<hughag...@yahoo.com> wrote:
>On Saturday, November 23, 2013 9:25:28 AM UTC-7, Albert van der Horst wrote:
>> This may be a very poor generator, and it may reflect poorly on the
>> reputation of the Forth community. It may give a wrong impression about
>> the standing of Hugh's novice package in the Forth community.
>>
>> I ask Hugh to remove the LC53 from the wikipedia entry...

Full quote:

"
I ask Hugh to remove the LC53 from the wikipedia entry, until such
time he has more explanation on his website about the quality of the
generator.
"

You've seen Bernds comment. Congruential generators are not the state of
the art and can't stand the newest and thoughest tests.
This is widely recognized, and still they are widely used.
(E.g. ciforth's library contains a simple one, and I'm not going to
upgrade it.)
So as soon as you have an assesment on your website, I'll
add LC53 back on the wikipedia entry, if you're too modest to
do it yourself.

>
>........... original research .........................................

The original research rule in wikipedia is for when you publish a list
of US generals that knew about the My Lai massacre.
Not if you publish a fact or a technical result that can easily be checked
by anybody in the know.

>
<SNIPPED rant>

Instead of this why not doing some more programming, and publishing of
"original research". You know, not everybody is capable of doing that.

[hughag...@yahoo.com]

On Sunday, November 24, 2013 7:18:51 PM UTC-7, Albert van der Horst wrote:
> So as soon as you have an assesment on your website, I'll
> add LC53 back on the wikipedia entry, if you're too modest to
> do it yourself.

I'm not going to put an assessment on my webpage. That is just troll bait --- trolls such as Marcel Hendrix and yourself will attack it, saying that I haven't proven that LC53 is very random and that LC53 fails various tests (randomness is a pretty slippery target, after all). Bernd will say that he read about some other prng in a book that is supposedly wonderful (it was a hardcover book, after all!), and that I "should" implement that instead. I don't really have the patience for this nonsense, so to hell with it --- and to hell with all of you too.

If you are so fired up to put a Forth implementation of an LC-prng in the Wikipedia LC-prng article, why don't you put this one in:

VARIABLE BUD

: RAND ( -- u ) BUD @ 3141592621 * 1+ DUP BUD ! ;

That comes from a "trusted source" (Wil Baden), it is used in a "program of some notoriety" (SwiftForth) --- and who could possibly have more "standing in the Forth community" than Elizabeth Rather? There you go!

Putting anything on Wikipedia is a waste of time. They have a strict rule against "original research," but everything that I do is original research, so that really excludes me from being a Wikipedia editor. I've already been through this with the slide-rule program. I tried to put a link to it in the External Links section of the slide-rule article, but an entire legion of trolls attacked me for it. I don't really have the patience for listening to non-programmers tell me that my program is trivial and that anybody could write it with a day's effort (their term was "arts and crafts"), so to hell with Wikipedia.

> Instead of this why not doing some more programming, and publishing of
> "original research". You know, not everybody is capable of doing that.

I originally wrote the novice package because I expected it to be used for writing Forth applications. Nobody is really writing Forth programs though. You just want me to upgrade the novice package so you can attack it. You have no intention of actually writing an application in Forth, either with or without the novice package. You started this thread because you were bored and wanted some attention --- well, congratufuckulations! --- you baited me and I responded, so it has been an entertaining weekend for you.

[Hans Bezemer]

hughag...@yahoo.com wrote:

> Payson is another phony. He is promoting his "quotations" when they are
> just :NONAME with some syntactic sugar. He actually knows that a quotation
> is supposed to have access to the local variables in the creator function
> (that is what makes them useful), but he doesn't know how to implement
> quotations correctly, so he just fakes it.
>
> Hans Bezemer says:
> "Obviously, you can always argue that whatever solution I (or someone
> else) provide isn't CONSIDERED to be the real thing by Hugh Aguilar. But
> who cares? The issue of who considers what to be what is purely academic
> if one can't agree on definitions."
>
> Hans and Elizabeth don't know what quotations are, but they are willing to
> accept any definition that anybody on the Forth-200x committee may offer.

Oohhhh, that's a big rant. Really your style. Still, I stand by my quote:
gimme a definition. Note that quotations are not that universal. The only
true definition I found was at the Factor page. I quote (pun intended):

"Quotations consist of several words enclosed in square brackets; they can
be stored on the stack without being executed and passed as parameters to
combinators".

An embedded :NONAME definition does just fine (if you ignore the "square
brackets" part of the definition).

A closure, however, is defined like this:

"In programming languages, a closure (also lexical closure or function
closure) is a function or reference to a function together with a
referencing environment—a table storing a reference to each of the
non-local variables (also called free variables or upvalues) of that
function. A closure—unlike a plain function pointer—allows a function to
access those non-local variables even when invoked outside its immediate
lexical scope."

So, I think you're mixing up both concepts, which makes you the phony here.

Hans Bezemer

[Matthias Koch]

Bernd Paysan:

> the German Wikipedia has even (relatively good)
> variants for 32 and 64 bits:
>
> http://de.wikipedia.org/wiki/Xorshift

\ Xorshift Random Number Generator, 32 Bits

314159265 variable seed

: random ( -- x )
seed @
dup 13 lshift xor
dup 17 rshift xor
dup 5 lshift xor
dup seed !
;

[m...@iae.nl]

( I'll call it shrandom )
The gorilla certainly doesn't like it.

-marcel

-- ----------------------
FORTH> init-seeds diehard
DIEHARD is checking shrandom..

.---------------------------------------------------------------.
| This is the "tough" BIRTHDAY SPACINGS TEST |
| Choose 4096 birthdays in a "year" of 2^32 days. Thus each |
| birthday is a 32-bit integer and the test uses 2^12 of them, |
| so that j, the number of duplicate spacings, is asympotically |
| Poisson distributed with lambda=4. Generators that pass the |
| earlier tests for m=1024 and n=2^24 often fail this test, yet |
| those that pass this test seem to pass the "weaker" test. |
| Each set of 4096 birthdays provide a Poisson variate j, and |
| 500 such j's lead to a chisquare test to see if the result |
| is consistent with the Poisson distribution with lambda=16. |
`---------------------------------------------------------------'
Table of Expected versus Observed counts:
Duplicates 0 1 2 3 4 5 6 7 8 9 >=10
Expected 91 366 732 976 976 781 520 297 148 66 40

Observed 83 377 746 952 970 759 528 308 179 64 34
(O-E)^2/E 0.8 0.3 0.2 0.6 0.0 0.6 0.1 0.4 6.1 0.1 1.1
Birthday Spacings: Sum(O-E)^2/E = 10.404, p = 0.600
( 4.870 seconds elapsed. )

.-------------------------------------------------------------.
| This is the GCD TEST. Let the (32-bit) RNG produce two |
| successive integers u,v. Use Euclids algorithm to find the |
| gcd, say x, of u and v. Let k be the number of steps needed |
| to get x. Then k is approximately binomial with p=.376 |
| and n=50, while the distribution of x is very close to |
| Pr(x=i)=c/i^2, with c=6/pi^2. The gcd test uses ten |
| million such pairs u,v to see if the resulting frequencies |
| of k's and x's are consistent with the above distributions. |
| Congruential RNG's---even those with prime modulus---fail |
| this test for the distribution of k, the number of steps, |
| and often for the distribution of gcd values x as well. |
`-------------------------------------------------------------'
Euclid's algorithm:

p-value, steps to gcd: 0.494869
p-value, distance of gcd's: 0.162701
( 2.104 seconds elapsed. )

.---------------------------------------------------------------.
| This is the GORILLA test, a strong version of the monkey |
| tests that I developed in the 70's. It concerns strings |
| formed from specified bits in 32-bit integers from the RNG. |
| We specify the bit position to be studied, from 0 to 31, |
| say bit 3. Then we generate 67,108,889 (2^26+25) numbers |
| from the generator and form a string of 2^26+25 bits by |
| taking bit 3 from each of those numbers. In that string of |
| 2^26+25 bits we count the number of 26-bit segments that |
| do not appear. That count should be approximately normal |
| with mean 24687971 and std. deviation 4170. This leads to |
| a normal z-score and hence to a p-value. The test is |
| applied for each bit position 0 (leftmost) to 31. |
| (Some older tests use Fortran's 1-32 for most- to least- |
| significant bits. Gorilla and newer tests use C's 0 to 31.) |
`---------------------------------------------------------------'
Gorilla test for 2^26 bits, positions 0 to 31:
Note: lengthy test -- ~20 minutes for 900 MHz PC

Bits 0 to 7 || 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Bits 8 to 15 || 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Bits 16 to 23 || 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Bits 24 to 31 || 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000

ADKS test for the above 32 p values: 1.000

( 28.597 seconds elapsed. )

.---------------------------------------------------------------.
| THE OVERLAPPING 5-PERMUTATION TEST |
| This is the OPERM5 test. It looks at a sequence of ten |
| million 32-bit random integers. Each set of five consecutive |
| integers can be in one of 120 states, for the 5! possible |
| orderings of five numbers. Thus the 5th, 6th, 7th,...numbers |
| each provide a state. As many thousands of state transitions |
| are observed, cumulative counts are made of the number of |
| occurences of each state. Then the quadratic form in the |
| weak inverse of the 120x120 covariance matrix yields a test |
| that the 120 cellcounts came from the specified (asymptotic) |
| distribution with the specified means and 120x120 covariance. |
`---------------------------------------------------------------'

The OPERM5 test for 10 million (overlapping) 5-tuples for shrandom.
p-values for 5 runs: 0.2900 0.6235 0.7778 0.8739 0.7441
( 6.842 seconds elapsed. ) ok

[Bernd Paysan]

If you want one that passes Diehard, take the 128 bit version. The period
of the 32 bit version is way too short to fool that test.

[Albert van der Horst]

In article <c511a675-b363-45ec...@googlegroups.com>,

For tForth we used one published in EDN. I still use that one.
Which one do you supply as a standard in iForth?

I see that gForth as well as SwiftForth use a simple LCG.
As far as I can see, they don't supply a reference, testset, testdata
or other motivation.

I fear neither of those fare too well on the harsh tests you use.
Hugh suggests that the only difference with his LC53 is that
Anton Ertl and Elizabeth Rather inspire more confidence than he does.

It sounds like you have a whole machinery in place to tests rng's.
Would you mind adding LC53 to the list?

\ Comma for clarity, not a double number.
: LC53 -5 um* -333,333,333 + nip ;
( : doit seed @ LC53 dup seed ! ; )

>
>-marcel

[Howerd]

Hi Marcel,

Albert pointed out that you seem to have a test setup - how do encryption algorithms perform when used as a PRNG? I am assuming by incrementing a 64 bit value and encrypting it.

For example the Tiny Encryption Algorithm?

If you get a minute I would love to see the results for TEAN (appended below).

Best regards * TIA,
Howerd


The full file is available from http://www.inventio.co.uk/tean.f :

\ tean.f 2006 Jan 04
\ TEA is the Tiny Encryption Algorithm - a shared private key system
\ based on many iterations of a simple hashing function.
\ Created by David J. Wheeler and Roger M. Needham.
\ TEAN ( TEA New ) is an improved version of TEA which includes modifications
\ to TEA made after David Wagner discovered weaknesses in the key scheduling.
\ Based on C code from http://www.simonshepherd.supanet.com/source.htm#new_ansi
\ See also http://www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
\ TEA and TEAN are 64-bit block Feistel cyphers using a 128-bit key.

\ +tean encrypts d to d' using the given number of rounds and initial key
\ -tean decrypts d' to d using the same parameters.
\ You can use these to encrypt an array, adjusting the parameters
\ after each 64 bit value is encrypted if required.

\ This is a 32 bit Little Endian ANS Forth version ( PC ).
\ Usage : 123456. +tean 2dup d. -tean d.

decimal

\ user inputs - you choose the number of rounds and initial key :
\ #rounds holds the number of times round the loop :
\ should be > 8, increase for stronger encryption ( say 32 )
variable #rounds
4 cells Buffer: MyKey \ load this with the shared private key

\ The Golden Ratio ( 5 sqrt 1+ 2/ ) = 1.618033989, - 1 , scaled up to 32 bits
$9e3779b9 constant delta \ could be anything except "bad" values...

\ working variables
variable delta#rounds@* \ pre-calculated value, for speed
variable MySum
variable MyVar1
variable MyVar2

\ get a new key value ( two flavours )
: GetKey1 ( - u) MySum @ dup 3 and cells MyKey + @ + ;
: GetKey2 ( - u) MySum @ dup 11 rshift 3 and cells MyKey + @ + ;

\ mix the bits of the variables ( two flavours again )
: Mangle1 ( - u) MyVar1 @ 4 lshift MyVar1 @ 5 rshift xor MyVar1 @ + ;
: Mangle2 ( - u) MyVar2 @ 4 lshift MyVar2 @ 5 rshift xor MyVar2 @ + ;

\ one round of the encryption algorithm
: (+tean) ( a b - a' b' )
Mangle1
GetKey1 \ key
xor \ mangled 1 and key
MyVar2 +! \ add to 2
delta MySum +! \ add to sum
Mangle2
GetKey2 \ key
xor \ mangled 2 and key
MyVar1 +! \ add to 1
;

\ encrypt d to d' using the number of rounds and private key values
: +tean ( d - d' )
MyVar2 ! MyVar1 !
0 MySum !
#rounds @ 0 do (+tean) loop
MyVar1 @ MyVar2 @
;

[m...@iae.nl]

On Monday, November 25, 2013 12:41:23 AM UTC+1, m...@iae.nl wrote:
> On Sunday, November 24, 2013 11:53:14 PM UTC+1, Bernd Paysan wrote:
> > m...@iae.nl wrote:
> For a Forth random generator many sources are available,

> e.g. this is a list from the past 10 years:
[..]

And don't forget to read Skip's papers here :- ftp://ftp.taygeta.com/pub/Forth/Literature/ .

-marcel

[m...@iae.nl]

On Monday, November 25, 2013 8:32:44 PM UTC+1, Albert van der Horst wrote:
> In article <c511a675-b363-45ec...@googlegroups.com>,
> <m...@iae.nl> wrote:
> >On Sunday, November 24, 2013 11:53:14 PM UTC+1, Bernd Paysan wrote:
> >> m...@iae.nl wrote:
[..]

[..]

> For tForth we used one published in EDN. I still use that one.
> Which one do you supply as a standard in iForth?

The same:

: RANDOM seed 1078373 * 2311527 + 9 ROL DUP TO seed ;

As you can see, I added 9 ROL , because the common criticism
is that the low bits of such a generator are not very random.
This cleans up the result remarkably well for the single cycle
it costs (see below).

> I see that gForth as well as SwiftForth use a simple LCG.
> As far as I can see, they don't supply a reference, testset, testdata
> or other motivation.

The iForth dist has the diehard suite (in Forth) to take care of
that.

> I fear neither of those fare too well on the harsh tests you use.
> Hugh suggests that the only difference with his LC53 is that
> Anton Ertl and Elizabeth Rather inspire more confidence than he does.

Anybody passes that test :-)

All the simple generators mentioned by you were analyzed in TAO
and a very simple recipe was given there to make the best of them
(which does not make them perfect). The iForth and Baden generators
follow that rule, but I don't remember it now and can't check if
the others do.

> It sounds like you have a whole machinery in place to tests rng's.
> Would you mind adding LC53 to the list?
>
> \ Comma for clarity, not a double number.
> : LC53 -5 um* -333,333,333 + nip ;
> ( : doit seed @ LC53 dup seed ! ; )>

That is .RAN-HA .

-marcel
-- -----------
FORTH> diehard
DIEHARD is checking RANDOM..

.---------------------------------------------------------------.
| This is the "tough" BIRTHDAY SPACINGS TEST |
| Choose 4096 birthdays in a "year" of 2^32 days. Thus each |
| birthday is a 32-bit integer and the test uses 2^12 of them, |
| so that j, the number of duplicate spacings, is asympotically |
| Poisson distributed with lambda=4. Generators that pass the |
| earlier tests for m=1024 and n=2^24 often fail this test, yet |
| those that pass this test seem to pass the "weaker" test. |
| Each set of 4096 birthdays provide a Poisson variate j, and |
| 500 such j's lead to a chisquare test to see if the result |
| is consistent with the Poisson distribution with lambda=16. |
`---------------------------------------------------------------'
Table of Expected versus Observed counts:
Duplicates 0 1 2 3 4 5 6 7 8 9 >=10
Expected 91 366 732 976 976 781 520 297 148 66 40

Observed 101 333 727 1006 974 788 500 290 180 61 40
(O-E)^2/E 1.0 3.0 0.0 0.9 0.0 0.1 0.8 0.2 6.5 0.4 0.0
Birthday Spacings: Sum(O-E)^2/E = 12.951, p = 0.775
( 4.739 seconds elapsed. )

.-------------------------------------------------------------.
| This is the GCD TEST. Let the (32-bit) RNG produce two |
| successive integers u,v. Use Euclids algorithm to find the |
| gcd, say x, of u and v. Let k be the number of steps needed |
| to get x. Then k is approximately binomial with p=.376 |
| and n=50, while the distribution of x is very close to |
| Pr(x=i)=c/i^2, with c=6/pi^2. The gcd test uses ten |
| million such pairs u,v to see if the resulting frequencies |
| of k's and x's are consistent with the above distributions. |
| Congruential RNG's---even those with prime modulus---fail |
| this test for the distribution of k, the number of steps, |
| and often for the distribution of gcd values x as well. |
`-------------------------------------------------------------'
Euclid's algorithm:

p-value, steps to gcd: 0.588402
p-value, distance of gcd's: 0.434185
( 2.130 seconds elapsed. )

.---------------------------------------------------------------.
| This is the GORILLA test, a strong version of the monkey |
| tests that I developed in the 70's. It concerns strings |
| formed from specified bits in 32-bit integers from the RNG. |
| We specify the bit position to be studied, from 0 to 31, |
| say bit 3. Then we generate 67,108,889 (2^26+25) numbers |
| from the generator and form a string of 2^26+25 bits by |
| taking bit 3 from each of those numbers. In that string of |
| 2^26+25 bits we count the number of 26-bit segments that |
| do not appear. That count should be approximately normal |
| with mean 24687971 and std. deviation 4170. This leads to |
| a normal z-score and hence to a p-value. The test is |
| applied for each bit position 0 (leftmost) to 31. |
| (Some older tests use Fortran's 1-32 for most- to least- |
| significant bits. Gorilla and newer tests use C's 0 to 31.) |
`---------------------------------------------------------------'
Gorilla test for 2^26 bits, positions 0 to 31:
Note: lengthy test -- ~20 minutes for 900 MHz PC

Bits 0 to 7 || 0.334 0.163 0.375 0.400 0.523 0.755 0.120 0.905
Bits 8 to 15 || 0.051 0.785 0.259 0.232 0.034 0.984 0.668 0.991
Bits 16 to 23 || 0.820 0.461 0.188 0.283 0.446 0.432 0.525 0.183
Bits 24 to 31 || 0.274 0.837 0.463 0.363 0.137 0.254 0.844 0.882
ADKS test for the above 32 p values: 0.381
( 27.467 seconds elapsed. )

.---------------------------------------------------------------.
| THE OVERLAPPING 5-PERMUTATION TEST |
| This is the OPERM5 test. It looks at a sequence of ten |
| million 32-bit random integers. Each set of five consecutive |
| integers can be in one of 120 states, for the 5! possible |
| orderings of five numbers. Thus the 5th, 6th, 7th,...numbers |
| each provide a state. As many thousands of state transitions |
| are observed, cumulative counts are made of the number of |
| occurences of each state. Then the quadratic form in the |
| weak inverse of the 120x120 covariance matrix yields a test |
| that the 120 cellcounts came from the specified (asymptotic) |
| distribution with the specified means and 120x120 covariance. |
`---------------------------------------------------------------'

The OPERM5 test for 10 million (overlapping) 5-tuples for RANDOM.
p-values for 5 runs: 0.5366 0.1736 0.2796 0.9093 0.0519
( 6.873 seconds elapsed. ) ok

[m...@iae.nl]

On Monday, November 25, 2013 10:43:36 PM UTC+1, Howerd wrote:
> On Monday, 25 November 2013 18:23:12 UTC, m...@iae.nl wrote:

[..]

> Albert pointed out that you seem to have a test setup - how do
> encryption algorithms perform when used as a PRNG? I am assuming
> by incrementing a 64 bit value and encrypting it.
>
> For example the Tiny Encryption Algorithm?
>
> If you get a minute I would love to see the results for TEAN (appended below).

[..]

For 1 SetRounds it is not better than the LCGs,
but upwards of 4 it starts to become acceptable.
Unfortunately, I didn't muster enough patience to
document it properly -- the thing is DOG-SLOW.

-marcel
-- ----------------
FORTH> 4 SetRounds diehard
DIEHARD is checking RAN-TEAN..

.---------------------------------------------------------------.
| This is the "tough" BIRTHDAY SPACINGS TEST |
| Choose 4096 birthdays in a "year" of 2^32 days. Thus each |
| birthday is a 32-bit integer and the test uses 2^12 of them, |
| so that j, the number of duplicate spacings, is asympotically |
| Poisson distributed with lambda=4. Generators that pass the |
| earlier tests for m=1024 and n=2^24 often fail this test, yet |
| those that pass this test seem to pass the "weaker" test. |
| Each set of 4096 birthdays provide a Poisson variate j, and |
| 500 such j's lead to a chisquare test to see if the result |
| is consistent with the Poisson distribution with lambda=16. |
`---------------------------------------------------------------'
Table of Expected versus Observed counts:
Duplicates 0 1 2 3 4 5 6 7 8 9 >=10
Expected 91 366 732 976 976 781 520 297 148 66 40

Observed 87 377 746 934 1001 778 523 287 151 63 53
(O-E)^2/E 0.2 0.3 0.2 1.9 0.6 0.0 0.0 0.4 0.0 0.2 3.7
Birthday Spacings: Sum(O-E)^2/E = 7.595, p = 0.354
( 5.364 seconds elapsed. )

.-------------------------------------------------------------.
| This is the GCD TEST. Let the (32-bit) RNG produce two |
| successive integers u,v. Use Euclids algorithm to find the |
| gcd, say x, of u and v. Let k be the number of steps needed |
| to get x. Then k is approximately binomial with p=.376 |
| and n=50, while the distribution of x is very close to |
| Pr(x=i)=c/i^2, with c=6/pi^2. The gcd test uses ten |
| million such pairs u,v to see if the resulting frequencies |
| of k's and x's are consistent with the above distributions. |
| Congruential RNG's---even those with prime modulus---fail |
| this test for the distribution of k, the number of steps, |
| and often for the distribution of gcd values x as well. |
`-------------------------------------------------------------'
Euclid's algorithm:

p-value, steps to gcd: 1.000000
p-value, distance of gcd's: 0.166675
( 2.703 seconds elapsed. )

.---------------------------------------------------------------.
| This is the GORILLA test, a strong version of the monkey |
| tests that I developed in the 70's. It concerns strings |
| formed from specified bits in 32-bit integers from the RNG. |
| We specify the bit position to be studied, from 0 to 31, |
| say bit 3. Then we generate 67,108,889 (2^26+25) numbers |
| from the generator and form a string of 2^26+25 bits by |
| taking bit 3 from each of those numbers. In that string of |
| 2^26+25 bits we count the number of 26-bit segments that |
| do not appear. That count should be approximately normal |
| with mean 24687971 and std. deviation 4170. This leads to |
| a normal z-score and hence to a p-value. The test is |
| applied for each bit position 0 (leftmost) to 31. |
| (Some older tests use Fortran's 1-32 for most- to least- |
| significant bits. Gorilla and newer tests use C's 0 to 31.) |
`---------------------------------------------------------------'
Gorilla test for 2^26 bits, positions 0 to 31:
Note: lengthy test -- ~20 minutes for 900 MHz PC

Bits 0 to 7 || 1.000 1.000 1.000 0.534 0.840 0.304 0.564 0.925
Bits 8 to 15 || 0.889 0.986 0.128 0.864 0.383 0.085 0.472 0.150
Bits 16 to 23 || 0.322 0.535 0.017 0.394 0.681 0.643 0.568 0.768
Bits 24 to 31 || 0.447 0.326 0.886 0.585 0.376 0.303 0.506 0.209

ADKS test for the above 32 p values: 1.000

( 109.599 seconds elapsed. )

.---------------------------------------------------------------.
| THE OVERLAPPING 5-PERMUTATION TEST |
| This is the OPERM5 test. It looks at a sequence of ten |
| million 32-bit random integers. Each set of five consecutive |
| integers can be in one of 120 states, for the 5! possible |
| orderings of five numbers. Thus the 5th, 6th, 7th,...numbers |
| each provide a state. As many thousands of state transitions |
| are observed, cumulative counts are made of the number of |
| occurences of each state. Then the quadratic form in the |
| weak inverse of the 120x120 covariance matrix yields a test |
| that the 120 cellcounts came from the specified (asymptotic) |
| distribution with the specified means and 120x120 covariance. |
`---------------------------------------------------------------'

The OPERM5 test for 10 million (overlapping) 5-tuples for RAN-TEAN.
p-values for 5 runs: 1.0000 1.0000 1.0000 1.0000 1.0000
( 8.469 seconds elapsed. ) ok

[Bernd Paysan]

Albert van der Horst wrote:

> It sounds like you have a whole machinery in place to tests rng's.
> Would you mind adding LC53 to the list?
>
> \ Comma for clarity, not a double number.
> : LC53 -5 um* -333,333,333 + nip ;

Hm, wasn't Hugh's LC53

: lc53 -333333333 um* -5 um/mod drop ;

? Don't make Hugh look more stupid than he actually is ;-).

The linear congruent random number generator in Gforth is a mod 2^n
generator, which has the known (and pretty awful) weakness that the least n
bits have a period of 2^n each. LC53 does not have this particular
weakness, because it uses a prime (2^32-5) as modulus. In so far, there's
nothing fundamentally wrong with LC53, other than linear congruent
generators just can't be that good.

I took the opportunity to replace the standard random number generator in
Gforth with one based on our new hash function, which uses a combination of
multiplication, rotate, add, and xor as primitives. This has a 128 bit
state, and should survive stringent tests (SmallCrush already passed and
RabbitFile on a 8MB sample, too).

[Ed]

Albert van der Horst wrote:

> ...

> This may be a very poor generator, and it may reflect poorly on the
> reputation of the Forth community.

Wikipedia doesn't claim to be truth or authority. Entries are made by
individuals with all that implies. If reputation be affected, it's their own.

The LCG in 'Starting Forth' is poor by most measures. Despite huge
sales of the book, it rarely gets a criticism. We accept simple RNG's
as being less than perfect. LC53 will be better than some and worse
than others.

> I ask Hugh to remove the LC53 from the wikipedia entry, until such
> time he has more explanation on his website about the quality of the
> generator.

The appropriate (and less volatile) place for that discussion would be
Wikipedia itself.

With the possible exception of its creator, IMO it's of little consequence
what an individual posts about Forth. An individual voice is easy to dismiss.
Much harder to ignore is what's done by formal committees in Forth's name.
The impact of that continues for decades and for all the world to see. This
is what affects the reputation of Forth and its community more than any
Wikipedia entry.

[Albert van der Horst]

In article <l70lve$2jq$1...@online.de>, Bernd Paysan <bernd....@gmx.de> wrote:
>Albert van der Horst wrote:
>> It sounds like you have a whole machinery in place to tests rng's.
>> Would you mind adding LC53 to the list?
>>
>> \ Comma for clarity, not a double number.
>> : LC53 -5 um* -333,333,333 + nip ;
>
>Hm, wasn't Hugh's LC53
>
>: lc53 -333333333 um* -5 um/mod drop ;

Oops.

>
>? Don't make Hugh look more stupid than he actually is ;-).

Whatever he is, he is not stupid.
I just read the documentation of the slide rule (You know with the time
capsule). After about 55 pages (of 300) it turns into a cross between
Nostradamus and the Book of Relevation, with proposals to change the
rules of poker thrown in for good measure. Absolutely intriguing.
On its technical merits the slide rule program could be mentioned in
wikipedia, but I can see why the reference was deleted.

>
>The linear congruent random number generator in Gforth is a mod 2^n
>generator, which has the known (and pretty awful) weakness that the least n
>bits have a period of 2^n each. LC53 does not have this particular
>weakness, because it uses a prime (2^32-5) as modulus. In so far, there's
>nothing fundamentally wrong with LC53, other than linear congruent
>generators just can't be that good.

I'm I right that LC53 is about as good as the lcg in Gforth (before the
change) albeit with different strength and weaknesses?

>
>I took the opportunity to replace the standard random number generator in
>Gforth with one based on our new hash function, which uses a combination of
>multiplication, rotate, add, and xor as primitives. This has a 128 bit
>state, and should survive stringent tests (SmallCrush already passed and
>RabbitFile on a 8MB sample, too).

The wcm proposed by Marsaglia for 64 bits, has a 121 bit state, with
the multiplier 0x4000..001.

So everybody is making their own tweaks on rng's, with the 9 ROL of
mhx and all. As long as they pass enough tests, you're in the clear.
Seems like Hugh could join the club if only he was willing to
run some tests.

>
>--
>Bernd Paysan

[hughag...@yahoo.com]

On Monday, November 25, 2013 12:32:44 PM UTC-7, Albert van der Horst wrote:
> Hugh suggests that the only difference with his LC53 is that
> Anton Ertl and Elizabeth Rather inspire more confidence than he does.

You specifically asked for a "respectable" LCG from a "trusted source" with great "standing in the Forth community."

This is from SwiftForth:

VARIABLE BUD

: RAND ( -- u ) BUD @ 3141592621 * 1+ DUP BUD ! ;

Now that I've removed LC53 from the Wikipedia LCG list, there is no Forth representative in there. I recommend that you put the SwiftForth LCG in LC53's place. If you fail to do this, that would imply that you don't consider Forth Inc. to be a respectable trusted-source with great standing in the Forth community. It is not a big deal to offend me, but I don't think you want to offend Elizabeth Rather --- now that you have gone so far as to demand that I remove LC53, you are pretty much obliged to replace it with the Forth Inc. LCG. To fail to replace mine with hers implies that you think Elizabeth Rather is at the same level of stupidity as myself --- she is going to be offended!

There doesn't need to be any discussion of the technical aspects at all --- you just replace my LCG with Forth Inc.'s and you've got your respectable trusted-source --- it is as simple as that!

[hughag...@yahoo.com]

On Monday, November 25, 2013 4:20:14 PM UTC-7, Bernd Paysan wrote:
> Albert van der Horst wrote:
> > \ Comma for clarity, not a double number.
> > : LC53 -5 um* -333,333,333 + nip ;
>
> Hm, wasn't Hugh's LC53
>
> : lc53 -333333333 um* -5 um/mod drop ;
>
> ? Don't make Hugh look more stupid than he actually is ;-).

I have removed LC53 from the Wikipedia LCG article. This means that there is no evidence anywhere (except the novice package itself, which is irrelevant on C.L.F.) as to what LC53 is (was). It is irrelevant how you define LC53 on C.L.F. now. Albert can make up anything that he wants --- getting me to remove LC53 was a total victory for Albert --- and, as you know, history is written by the victors.

I don't really care --- it took me only one day to write all of that prng stuff in the novice package, and most of the day was spent writing the support code --- I have already wasted more time than that posting in his thread.

[Elizabeth D. Rather]

On 11/25/13 9:32 AM, Albert van der Horst wrote:
...

> I see that gForth as well as SwiftForth use a simple LCG.
> As far as I can see, they don't supply a reference, testset, testdata
> or other motivation.
>
> I fear neither of those fare too well on the harsh tests you use.
> Hugh suggests that the only difference with his LC53 is that
> Anton Ertl and Elizabeth Rather inspire more confidence than he does.

Thank you, but I never wrote a random number generator and don't intend
to! I've been blessed by having some brilliant programmers around me.
But most of FORTH, Inc.'s customers aren't in fields where a strong RNG
is a necessity, so we keep it simple.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[thomas.b...@gmail.com]

> Whatever he is, he is not stupid.
> I just read the documentation of the slide rule (You know with the time
> capsule). After about 55 pages (of 300) it turns into a cross between
> Nostradamus and the Book of Relevation, with proposals to change the
> rules of poker thrown in for good measure. Absolutely intriguing.
> On its technical merits the slide rule program could be mentioned in
> wikipedia, but I can see why the reference was deleted.

Thank you for the recommendation. Will read.

[hughag...@yahoo.com]

If you do read it, you will be disappointed to discover that I make no mention of Nostradamus or the Book of Revelation. I don't believe in Nostradamus or divining the future from the Book of Revelation (aka "End-Times"). I don't even believe that the Bible is anything more than a book written by people with an agenda. Albert is a liar --- he is just making this stuff up.

I have always considered Albert to be a harmless fool, roughly comparable to Arthur Murray (aka Mentifex). Both of them have written a Forth program which they claim to be a big Artificial Intelligence break-through (ciForth means "Computer Intelligence Forth" and Albert refers to it as "she," and Mentifex has his Singularity on the way). Given this thread however, I no longer consider Albert to be harmless. Arthur Murray has always been a gentleman though, and I've never known him to attack anybody on the internet (Jeff Fox has helped Arthur with his Forth and has also described Arthur as being a gentleman).

Why is Albert attacking me? What did I ever do to him? Did somebody shoot his dog, and he thinks that it was me?

Apparently Albert is aware that Bernd Payson had booted me off the Forth-200x mailing list because I said that quotations need to have access to the creator function's local variables in order to be useful. Now he wants to kick me when I'm down, and boost his own "standing in the Forth community." This isn't working very well. For one thing, I'm not really down; getting booted off the Forth-200x mailing list is like getting fired from Taco Bell --- it is not a total heart-breaker for me. For another thing, I don't really care about LC53 or the LLRB tree --- inventing LC53 was the work of one day, and I didn't invent LLRB trees at all, but just implemented them (although that was the work of several days).

So far, the only people who have supported Albert are these:

Bernd Payson --- He wants people to think that I'm "stupid" so he can continue to fake up his quotation code that doesn't work.

Marcel Hendrix --- He is the guy who posted my LC53 encryption-cracking program on C.L.F. with my name removed from the copyright notice:
https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53%7Csort:relevance/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ

Elizabeth Rather --- She wants people to believe that she is important enough to be "blessed by having some brilliant programmers around me" --- Wil Baden in this case.

None of these people have my respect, so their support for Albert's attack isn't a heart-breaker for me. Honestly, the whole attack seems foolish to me --- the more they call me "stupid" (Bernd's term) for my LC53, the more foolish they make themselves appear. I already deleted the reference to LC53 from the Wikipedia LCG article, so why do they continue to attack me here --- isn't it true that Albert's original demand was only that I delete the reference to LC53 from the Wikipedia LCG article?

[hughag...@yahoo.com]

On Monday, November 25, 2013 10:24:00 PM UTC-7, Elizabeth D. Rather wrote:
> On 11/25/13 9:32 AM, Albert van der Horst wrote:
> > Hugh suggests that the only difference with his LC53 is that
> > Anton Ertl and Elizabeth Rather inspire more confidence than he does.

> Thank you, but I never wrote a random number generator and don't intend
> to! I've been blessed by having some brilliant programmers around me.

Well, that settles it! Albert can post the SwiftForth LCG on the Wikipedia LCG page:

VARIABLE BUD

: RAND ( -- u ) BUD @ 3141592621 * 1+ DUP BUD ! ;

If anybody objects, he can justify this by saying that it was written by a "brilliant programmer" (Wil Baden) and accepted as being brilliant by the "respectable" Elizabeth Rather.

If Albert will go ahead and update the Wikipedia LCG page with the brilliant SwiftForth code, then I think that we are done with this thread.

Cheers!

[Albert van der Horst]

In article <12486958-6ccf-433e...@googlegroups.com>,

<hughag...@yahoo.com> wrote:
>On Tuesday, November 26, 2013 12:08:12 AM UTC-7, thomas.b...@gmail.com wrote:
>> > Whatever he is, he is not stupid.
>> > I just read the documentation of the slide rule (You know with the time
>> > capsule). After about 55 pages (of 300) it turns into a cross between
>> > Nostradamus and the Book of Relevation, with proposals to change the
>> > rules of poker thrown in for good measure. Absolutely intriguing.
>>
>> > On its technical merits the slide rule program could be mentioned in
>> > wikipedia, but I can see why the reference was deleted.
>
>> Thank you for the recommendation. Will read.
>
>If you do read it, you will be disappointed to discover that I make no
>mention of Nostradamus or the Book of Revelation. I don't believe in

<SNIP>
Can't you just take it for what it is? Being compared to well-known
and revered books is a compliment.

>
>I have always considered Albert to be a harmless fool, roughly
>comparable to Arthur Murray (aka Mentifex). Both of them have written a
>Forth program which they claim to be a big Artificial Intelligence
>break-through (ciForth means "Computer Intelligence Forth" and Albert
>refers to it as "she," and Mentifex has his Singularity on the way).

I don't care about your insults, but I can't let this factual
incorrectness stand. My plan was to do work in ai with ciforth, hence
the name. I've accomplished no break-through and have all but given up
to do worthwile research on the subject. Even if I should claim
worthwile results, that it is a long cry from the grandiose claims of
Mentifex.

<gratuitous insults deleted>

[Albert van der Horst]

In article <ivudnSVTlIfurQnP...@supernews.com>,

Elizabeth D. Rather <era...@forth.com> wrote:
>On 11/25/13 9:32 AM, Albert van der Horst wrote:
>...
>> I see that gForth as well as SwiftForth use a simple LCG.
>> As far as I can see, they don't supply a reference, testset, testdata
>> or other motivation.
>>
>> I fear neither of those fare too well on the harsh tests you use.
>> Hugh suggests that the only difference with his LC53 is that
>> Anton Ertl and Elizabeth Rather inspire more confidence than he does.
>
>Thank you, but I never wrote a random number generator and don't intend
>to! I've been blessed by having some brilliant programmers around me.
>But most of FORTH, Inc.'s customers aren't in fields where a strong RNG
>is a necessity, so we keep it simple.

Hugh can learn something from this.

Why does this answer inspire confidence?
1. Offloading work to experts
2. A conscious decision about quality
3. polite, well formulated and to the point

Am I prejudiced? (Impression before this discussion.)
Seeing the FORTH inc. rng:
"It can be too shabby. Surely someone has looked into this."
Seeing LC53 in the wikipedia:
"Someone is promoting his crap abusing wikipedia."


>
>Cheers,
>Elizabeth

[Bernd Paysan]

hughag...@yahoo.com wrote:
> Apparently Albert is aware that Bernd Payson had booted me off the
> Forth-200x mailing list

You have issued a request for beeing bootet (yes, you really asked for it,
you said we should get a spine, it was not just by misbehaving), and it was
granted. Peter Knaggs is the owner of the list and the only one who can
actually boot somebody. You received a mail from him, not from me. We had
a formal discussion and it was a consensus that to prevent further damage
(several people had already left the list, as they couldn't stand your
repeated insults), we need to grant your request for beeing booted. The
list has become a much better place since then.

We knew you would completely misrepresent this to the outside world, as you
always do. But fortunately, the outside world knows who's the troublemaker.

We have a spine, and we do kick incurable troublemakers like you in the ass
if we are forced to. Otherwise, we are polite to everybody.

[Howerd]

Thanks :-)
H.

[hughag...@yahoo.com]

On Tuesday, November 26, 2013 7:21:20 AM UTC-7, Albert van der Horst wrote:
> In article <ivudnSVTlIfurQnP...@supernews.com>,
> Elizabeth D. Rather <era...@forth.com> wrote:
> >On 11/25/13 9:32 AM, Albert van der Horst wrote:
> >> Hugh suggests that the only difference with his LC53 is that
> >> Anton Ertl and Elizabeth Rather inspire more confidence than he does.
>
> >Thank you, but I never wrote a random number generator and don't intend
> >to! I've been blessed by having some brilliant programmers around me.
> >But most of FORTH, Inc.'s customers aren't in fields where a strong RNG
> >is a necessity, so we keep it simple.

> Hugh can learn something from this.
>
> Why does this answer inspire confidence?
> 1. Offloading work to experts
> 2. A conscious decision about quality
> 3. polite, well formulated and to the point
>
> Am I prejudiced? (Impression before this discussion.)
> Seeing the FORTH inc. rng:
> "It can be too shabby. Surely someone has looked into this."
> Seeing LC53 in the wikipedia:
> "Someone is promoting his crap abusing wikipedia."

I think you meant "can't be too shabby."

Anyway, what are you waiting for? Put the SwiftForth LCG on the Wikipedia LCG article in place of my "crap" which I have already removed.

When you started this thread, I assumed that you had invented your own LCG that you wanted to replace mine with in the Wikipedia list, but you apparently haven't done so. You are quite impressed by Elizabeth Rather's LCG however --- so that is obviously the one that you should replace mine with.

As I said before, all that you have to do is post the SwiftForth LCG on the Wikipedia LCG page, and your work here will be complete. Once again, here it is:

VARIABLE BUD

: RAND ( -- u ) BUD @ 3141592621 * 1+ DUP BUD ! ;

To make it easy for you:
You set Source to: SwiftForth (make this a link to www.forth.com)
You set M to: 2^32
You set A to: 3141592621
You set C to: 1

I promise not to undo your addition to the Wikipedia LCG article --- I have no intention of getting into an "edit war" on Wikipedia. Your victory will be complete --- a new kind of alchemy in which you turn crap into gold!

[hughag...@yahoo.com]

On Monday, November 25, 2013 6:57:32 PM UTC-7, Ed wrote:
> With the possible exception of its creator, IMO it's of little consequence
> what an individual posts about Forth. An individual voice is easy to dismiss.

I agree. Posting code in a language reflects upon the programmer, not on the language. I don't think that the quality of SwiftForth reflects upon me as a Forth programmer.

Wikipedia itself is pretty easy to dismiss. Wikipedia is primarily used by high-school students trying to fake up some expertise on a subject that they know nothing about, so they will get an 'A' on their report from a teacher who also knows nothing about the subject (it takes 8 years of college to become a teacher, but it is all about teaching technique, and not about learning the subject).

Essentially all of those articles are just a weird jumble of buzzwords and academic-sounding nonsense. They appear to be impressive at first glance, but it is actually impossible to learn anything from them. The idea is to just paste that pseudo-intellectual blather into a school report to make it look impressive. Nobody actually cares about details such as whether any of that stuff actually works.

Notice how my LC53 jumped like a virus from the LCG article to the Lehmer article. Did anybody check to see that it worked before citing it? I doubt it. All of those editors routinely cite sources which they haven't read, or if they did read, didn't understand. Nonsense spreads throughout Wikipedia unchecked, and nobody cares. Nonsense spreads throughout the world too, most of it originating on Wikipedia or television, and it fills people's heads --- this eventually results in dementia.

> Much harder to ignore is what's done by formal committees in Forth's name.
> The impact of that continues for decades and for all the world to see. This
> is what affects the reputation of Forth and its community more than any
> Wikipedia entry.

This is really the crux of the matter. If Bernd Payson was just a GForth programmer, then his failure to implement quotations would not be a problem --- GForth is just a toy, and it is not used for commercial development --- I can and do ignore GForth and ciForth and the myriad other bad Forth implementations. The problem is that Bernd is a member of the Forth-200x committee. When he fakes up his "quotations," and pretends that it is not necessary for them to have access to the creator function's local variables, then he drags all Forth-200x programmers down. This is really why I asked to be kicked off the Forth-200x mailing list --- I just don't want to be an ignoramus, which is what they require of everybody who uses Forth-200x --- I'll stick with being an "incurable troublemaker."

BTW: Do you know why quotations need access to the creator function's local variables? Can I have a show of hands, as to everybody reading this thread who knows the answer to this question? I really hope that I'm not the only one on C.L.F. who knows this basic concept --- that would be just too depressing.

[hughag...@yahoo.com]

On Tuesday, November 26, 2013 2:38:09 PM UTC-7, Howerd wrote:
> On Monday, 25 November 2013 23:16:36 UTC, m...@iae.nl wrote:

> > [a lot of statistics]
>
> Thanks :-)
>
> H.

This whole thread is joke, because none of us know anything about the subject. Who cares about statistical analysis, if we don't know how the LCG parameters are derived? This has been a remarkably lengthy thread, without even a tiny flicker of intelligence yet...

I'll tell you how I invented LC53. I just set the size of the field to a big prime number (2*32-5). Then I guessed at various multipliers until I found one that provided a full period. I had a lucky guess early on, so the whole invention only took about 1 or 2 hours.

This only works for a 32-bit LCG. The field is approximately 4.2 billion, so it is possible to cycle through the whole period of the LCG in a few minutes on a fast computer. This "by guess and by golly" method doesn't work with a 64-bit LCG however, because modern computers aren't fast enough to cycle through the whole period in a reasonable amount of time.

I notice that Donald Knuth has a 64-bit LCG in his MMIX project. How did he come up with those numbers? How can we verify that they provide a full period? I don't know, and nobody else here does either. Running the Gorilla or the DieHard or what-not statistical tests, is just pseudo-intellectual baloney --- none of this makes the tester an expert on the subject of how an LCG works --- it makes the person an ignoramus.

But I suppose that saying this makes me an "incurable troublemaker" --- so shoot the messenger!

[Mark Wills]

On Saturday, November 23, 2013 4:25:28 PM UTC, Albert van der Horst wrote:
>This may be a very poor generator, and it may reflect poorly on the

>reputation of the Forth community. It may give a wrong impression about
>the standing of Hugh's novice package in the Forth community.

"This *may* be a very poor generator" - And it *may* be a very good generator. Did you test it?

"and it *may* reflect poorly on the reputation of the Forth community." - There again, it *may* not. Perhaps nobody actually cares. Did you solicit an opinion?

"It *may* give a wrong impression about the standing of Hugh's novice package in the Forth community." - Hmmm... Now we're getting down to the brass tacks of it. I wonder if this is simple envy, or if not, bias due to your personal dislike of Hugh. Whatever the reason, asking someone to remove an article over a bunch of "mays" is, with respect, quite rude, and I don't believe you should have done it. In fact I'll go further and state that, in my opinion, you should retract your request. Putting Hugh's contraversial presence and opinions on CLF to one side, you have produced no evidence in support of your request. Only a bunch of maybes. If your request was based on some sort of research "I tried Hugh's LC53, and actually it doesn't perform too well" then that would be a different matter entirely.

"There is no theoretical motivation or test results behind it" - and equally there are no test results backing up your assertion that it *may* be a poor algorithm. Just an opinion.

Respectfully.

[Andrew Haley]

hughag...@yahoo.com wrote:

> I notice that Donald Knuth has a 64-bit LCG in his MMIX project. How
> did he come up with those numbers? How can we verify that they
> provide a full period? I don't know, and nobody else here does
> either.

Yes we do, because he wrote a book about it. If you want to know how
to choose a multiplier so as to produce a period of maximum length,
that's in 3.2.1.2. It's Theorem A, and here it is:

The LC sequence defined by the modulus m, multiplier a, increment c,
and starting value X[0] has period length m if and only if:

1. c is relatively prime to m.

2. b = a - 1 is a multiple of p, for every prime dividing m.

3. b is a multiple of 4 if m is a multiple of 4.

> Running the Gorilla or the DieHard or what-not statistical tests, is
> just pseudo-intellectual baloney --- none of this makes the tester
> an expert on the subject of how an LCG works --- it makes the person
> an ignoramus.

More of an ignoramus than a person who publishes a random number
generator without testing it or reading Knuth? I don't think so.

Andrew.


@book{knuth2012art,
title={The Art of Computer Programming: Seminumerical algorithms. Vol. 2},
author={Knuth, D.E.},
isbn={9780321751041},
url={http://books.google.co.uk/books?id=BpBRlAEACAAJ},
year={2012},
publisher={Addison-Wesley}
}

[Andrew Haley]

Mark Wills <markrob...@yahoo.co.uk> wrote:

> Whatever the reason, asking someone to remove an article over a
> bunch of "mays" is, with respect, quite rude, and I don't believe
> you should have done it.

It is quite rude. However, it also turned out to be correct in every
way.

> In fact I'll go further and state that, in my opinion, you should
> retract your request. Putting Hugh's contraversial presence and
> opinions on CLF to one side, you have produced no evidence in
> support of your request.

Plenty of other people have, though.

Andrew.

[Albert van der Horst]

In article <4b2f456f-3bcc-4bda...@googlegroups.com>,
<hughag...@yahoo.com> wrote:

<SNIP>

>
>I promise not to undo your addition to the Wikipedia LCG article --- I
>have no intention of getting into an "edit war" on Wikipedia. Your
>victory will be complete --- a new kind of alchemy in which you turn
>crap into gold!

Will you keep that promise also in case of the following:

I intend to add a balanced view of Forth LCG's plus some
general comments about LCG's. This will include your LCG
and not as an example of a bad lcg.

Promised?

[Albert van der Horst]

In article <07bc57a5-4595-4c58...@googlegroups.com>,

<hughag...@yahoo.com> wrote:
>On Tuesday, November 26, 2013 2:38:09 PM UTC-7, Howerd wrote:
>> On Monday, 25 November 2013 23:16:36 UTC, m...@iae.nl wrote:
>> > [a lot of statistics]
>>
>> Thanks :-)
>>
>> H.
>
>This whole thread is joke, because none of us know anything about the
>subject. Who cares about statistical analysis, if we don't know how the
>LCG parameters are derived? This has been a remarkably lengthy thread,
>without even a tiny flicker of intelligence yet...

So you think that I edit a Wikipedia entry about a subject I don't
know about? Actually that is an insult.

>
>I'll tell you how I invented LC53. I just set the size of the field to a
>big prime number (2*32-5).

You stumbled upon a method suggested by Knuth in TAO vol. 2.

> Then I guessed at various multipliers until I
>found one that provided a full period. I had a lucky guess early on, so
>the whole invention only took about 1 or 2 hours.

This can't be true. All multipliers except 0 and 1 give a full period.
This is an elementary fact from number theory.

<SNIPped snear about testing>

I know Marcel Hendrix and compared to him I'm an expert in number theory,
but he runs all the tests he can lays his hands on.
This makes iforth's random generator trustworthy.

Running tests and be honest about it goes a long way in making a rng
like LC53 respectable. Different tests apply to different applications.
E.g. all lng's considered are plenty good enough for games.

[Albert van der Horst]

In article <o8ednS474d0GJAjP...@supernews.com>,

Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>hughag...@yahoo.com wrote:
>
>> I notice that Donald Knuth has a 64-bit LCG in his MMIX project. How
>> did he come up with those numbers? How can we verify that they
>> provide a full period? I don't know, and nobody else here does
>> either.
>
>Yes we do, because he wrote a book about it. If you want to know how
>to choose a multiplier so as to produce a period of maximum length,
>that's in 3.2.1.2. It's Theorem A, and here it is:
>
>The LC sequence defined by the modulus m, multiplier a, increment c,
>and starting value X[0] has period length m if and only if:
>
>1. c is relatively prime to m.
>
>2. b = a - 1 is a multiple of p, for every prime dividing m.
>
>3. b is a multiple of 4 if m is a multiple of 4.

If you look into LC53 you will see that it has a c of 0 which
makes the theorem inapplicable.

Now it is even simpler:

The rng cycles through the numbers a^0 a^1 a^2 a^3 .. a^(p-1) a^p ..
mod p. By Fermats theorem a^(p-1)=1=a^0 so we're back home.
E.g. 3^(5-1)=81 = 1 (mod 5). (Trust me it works all the time.)

Now it may be that a^n = 1 for 0<n<p-1. Then the multiplier is not
so good.
If they are all different a is called a primitive root.
The way to find a primitive root is basically trial and error,
and that is what Hugh did.
Or at least that is what I expected him to do...

But 333,333,333 is not a p.r.

I do a simple test with x^x which does powers modulo.
p-1 is divisable by 10. This makes (p-1)/10 a potential period.
Guess what?

"
AMDX86 ciforth beta $RCSfile: ci86.gnr,v $ $Revision: 5.112 $

OK
1 32 LSHIFT 5 - CONSTANT P
OK
P .
4294967291 OK
1 LOAD
OK
WANT x^x
OK
333,333,333 P 1- .S

S[ 333333333 4294967290 ] OK
10 / .S
S[ 333333333 429496729 ] OK
P x^x
OK
.

1 OK

"

So after (p-1)/10 cycles we are back at 1. It may be worse
but it is sufficient to shoot the multiplier down in view of
the fact that p.r. are abundant and easy to come by.

(I cancelled a post where I said that an LC53 type always has
a period of p-1. What was I thinking?)

<SNIP>

>
>Andrew.

[Albert van der Horst]

In article <l70vbc$95v$1...@speranza.aioe.org>, Ed <inv...@invalid.com> wrote:
>Albert van der Horst wrote:
>> ...
>> This may be a very poor generator, and it may reflect poorly on the
>> reputation of the Forth community.
>
>Wikipedia doesn't claim to be truth or authority. Entries are made by
>individuals with all that implies. If reputation be affected, it's their own.

If I read an entry and it is wrong, I edit it. That is the responsible thing
to do. So every entry I've read is to an extent endorsed by me.
Multiply that by millions and you have it.
The results is that wikipedia contains truth and wields a lot of authority.

[Albert van der Horst]

In article <5295e1b8$0$3182$e4fe...@dreader36.news.xs4all.nl>,

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>In article <07bc57a5-4595-4c58...@googlegroups.com>,
> <hughag...@yahoo.com> wrote:
>>On Tuesday, November 26, 2013 2:38:09 PM UTC-7, Howerd wrote:
>>> On Monday, 25 November 2013 23:16:36 UTC, m...@iae.nl wrote:
>>> > [a lot of statistics]
>>>
>>> Thanks :-)
>>>
>>> H.
>>
>>This whole thread is joke, because none of us know anything about the
>>subject. Who cares about statistical analysis, if we don't know how the
>>LCG parameters are derived? This has been a remarkably lengthy thread,
>>without even a tiny flicker of intelligence yet...
>
>So you think that I edit a Wikipedia entry about a subject I don't
>know about? Actually that is an insult.


>
>>
>>I'll tell you how I invented LC53. I just set the size of the field to a
>>big prime number (2*32-5).
>
>You stumbled upon a method suggested by Knuth in TAO vol. 2.
>
>> Then I guessed at various multipliers until I
>>found one that provided a full period. I had a lucky guess early on, so
>>the whole invention only took about 1 or 2 hours.
>
>This can't be true. All multipliers except 0 and 1 give a full period.
>This is an elementary fact from number theory.

Egg on my face! Only primitive roots give a maximal period, of length
p-1 in this case. See my other answer.
So you remembered right that you may have tried a few.
What is not true that you've found a multiplier with a maximal period,
see the other post.

[Bernd Paysan]

Albert van der Horst wrote:

> (I cancelled a post where I said that an LC53 type always has
> a period of p-1. What was I thinking?)

Don't know, but actually it is pretty simple to check candidates for
primitive roots of LC53. Faktor p-1:

22605091*19*5*2 = 2^32-5

So for all four prime factors q, you have to test if your candidate g is

g^{(p-1)/q} mod p !== 1.

This can be done quickly. You don't have to search that long to find a
primitive root.

Note that Hugh's g is 2^32-333333333, don't confuse things, the sign matters
(writing it as a negative number as Hugh does is confusing, though). It
*is* a primitive root of 2^32-5. If you want to find primitive roots for
LC53-style generators quickly, here's some code (factoring done by an
external program, you migth want to add a sieve up to 2^16 to do the
factoring right in the program itself):

\ Check primitive roots for lc53

$100000000 5 - Constant m

: *z ( a b -- c ) um* m um/mod drop ;
: a^b ( a b -- result ) >r 1 swap
BEGIN r@ 1 and IF tuck *z swap THEN
dup *z r> 2/ dup WHILE >r REPEAT
2drop ;

: u/ ( a b -- q ) 0 swap um/mod nip ;

: checkprim ( a -- flag )
dup m 1- 22605091 u/ a^b 1 = >r
dup m 1- 19 u/ a^b 1 = r> or >r
dup m 1- 5 u/ a^b 1 = r> or >r
m 1- 2 u/ a^b 1 = r> or 0= ;

BTW: Chances are good that the prime factors of p-1 are primitive roots. In
this case, only 5 isn't a primitive root. This is why people who calculate
numbers for Diffie Hellman key exchange use a prime p in the form that
(p-1)/2 is another prime, *and* a primitive root of p (that's just one check
more). This reduces the search space, and you can transmit the two
parameters needed for Diffie Hellman in just one number - you derive the
root g from the modulus p.

In these cases, p is a number with several thousand bits, and we still know
that (p-1)/2 is a primitive root, and can check that quite fast.

LC53 is a maximum period linear congruent random number generator - so far,
so good. It has the usual problems of LCGs, so it doesn't pass any serious
randomness test suite. It is certainly not worse than others, but it
definitely is slower than the mod 2^cellbits ones. It is just a bit faster
as the hash-based PRNG I use in Gforth-git now (benchmarked on 64 bit
machines), which does return 64 bit numbers on a 64 bit machine, and so far
passed all randomness tests I ran from the TestU01 suite (I didn't run the
very time consuming DieHarder test).

[Albert van der Horst]

In article <l75q3m$fq9$1...@online.de>, Bernd Paysan <bernd....@gmx.de> wrote:
>Albert van der Horst wrote:
>
>> (I cancelled a post where I said that an LC53 type always has
>> a period of p-1. What was I thinking?)
>
>Don't know, but actually it is pretty simple to check candidates for
>primitive roots of LC53. Faktor p-1:
>
>22605091*19*5*2 = 2^32-5
>
>So for all four prime factors q, you have to test if your candidate g is
>
>g^{(p-1)/q} mod p !== 1.
>
>This can be done quickly. You don't have to search that long to find a
>primitive root.
>
>Note that Hugh's g is 2^32-333333333, don't confuse things, the sign matters
>(writing it as a negative number as Hugh does is confusing, though). It
>*is* a primitive root of 2^32-5. If you want to find primitive roots for
>LC53-style generators quickly, here's some code (factoring done by an
>external program, you migth want to add a sieve up to 2^16 to do the
>factoring right in the program itself):

Apologies to Hugh for the mistake about the multiplier.
I stand corrected. I'm still interested how he found this
without the benefit of some theory.

Bottom line:

********************************************************************
** The LC53 lng is respectable **
********************************************************************

(as far as lcg's go.)

>--
>Bernd Paysan

[hughag...@yahoo.com]

On Wednesday, November 27, 2013 4:46:44 AM UTC-7, Albert van der Horst wrote:
> In article <4b2f456f-3bcc-4bda...@googlegroups.com>,
> <hughag...@yahoo.com> wrote:
> >I promise not to undo your addition to the Wikipedia LCG article

> ...

> Will you keep that promise also in case of the following:
>
> I intend to add a balanced view of Forth LCG's plus some
> general comments about LCG's. This will include your LCG
> and not as an example of a bad lcg.
>
> Promised?

I intend to remove any reference to myself or my code from any Wikipedia article.

I'm not going to touch anything that doesn't involve me directly --- because I'm not a Wikipedia editor --- I already said that I consider Wikipedia editors to be people who know nothing about anything but who for psychological reasons want to be experts on everything.

Enjoy your career as a Wikipedia editor --- write all of the "balanced views" that you want to, about any subject that you want to be an expert on --- except myself or my work.

[hughag...@yahoo.com]

On Wednesday, November 27, 2013 2:29:12 AM UTC-7, Andrew Haley wrote:
> Mark Wills <markrob...@yahoo.co.uk> wrote:
>
> > Whatever the reason, asking someone to remove an article over a
> > bunch of "mays" is, with respect, quite rude, and I don't believe
> > you should have done it.
>
> It is quite rude. However, it also turned out to be correct in every
> way.

Well, thanks for the support Mark --- finally somebody with some decency!

I had abandoned C.L.F. because it is just a platform for people to fake up expertise on subjects that they know nothing about (Bernd Payson's "quotations" being the last straw, because he was doing that as a representative of the Forth-200x committee, rather than just as a yahoo working with a bad Forth implementation that can be ignored).

Then I got drawn back into C.L.F. with this thread because it was a direct attack on me. I shouldn't have responded at all though. The only result was that I removed the Wikipedia references to my LC53 and LLRB-tree code. I could have done that without comment --- the result would have been the same, with a lot less aggravation.

> > In fact I'll go further and state that, in my opinion, you should
> > retract your request. Putting Hugh's contraversial presence and
> > opinions on CLF to one side, you have produced no evidence in
> > support of your request.
>
> Plenty of other people have, though.

Don't bother pressuring him to retract his request. I have already removed the Wikipedia references to my LC53 and my LLRB-tree code. I'm not going to put them back, even if Albert deigns to give them his "respectable" blessing. This is the same bozo who praises Elizabeth Rather for not writing any code, but instead delegating the work, which he considers to be confidence-inspiring --- his opinion isn't worth anything, pro or con.

Albert is just a typical Wikipedia troll though --- there are tens of thousands like him. There will always be some troll telling me that my code is "crap," and some other troll saying that this has turned out to be correct in every way --- that "plenty of people" have provided evidence that it is, in fact, "crap."

I've already been through this with trying to provide a link to my slide-rule image generator in the slide-rule article. One troll will attack it, saying that it is "arts and crafts." Then other trolls will join in on the fun. Pretty soon I've got a whole swarm of trolls attacking me like sharks in a feeding frenzy. For the trolls, smelling pride-of-accomplishment on a person, is like blood in the water --- they attack! --- pride-of-accomplishment is what they hate and fear the most in life.

Wikipedia has made the world worse rather than better. I am old enough to remember a time before Wikipedia existed --- there were trolls then too, but it wasn't an epidemic like it is nowadays.

The whole thing is much ado about nothing. The only really dumb thing that you can do with an LCG is to design one that doesn't provide the full period (SwiftForth's). My LCG does have a full period however --- it took a few guesses, but I found a set of parameters that work. I also made my field size a prime number, which makes it more randomish than just using 2^32 as the size, although slightly slower (not that much slower though, as the modern x86 does division almost as fast as addition). My multiplier has no particular binary pattern, so I'm done --- like I said, the work of 1 or 2 hours. The LLRB tree took several days, but I didn't invent anything myself, so there isn't much pride-of-accomplishment at stake for me there. Wikipedia doesn't allow original research, so I can't post references to any of my code where I did invent something myself.

[thomas.b...@gmail.com]

I am not disappointed, sorry to disappoint you.
Just accept that your slide rule documentation is a worthwhile read, even if not
for the reason you intended it to be.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
>
> LC53 is a maximum period linear congruent random number generator -
> so far, so good. It has the usual problems of LCGs, so it doesn't
> pass any serious randomness test suite. It is certainly not worse
> than others,

Did you really mean to say that? All we know is that it is not
certainly worse. I doubt very much that a generator chosen without
any theoretical justification or testing is as good as any. It's not
impossible, but it would be a fantastic stroke of luck.

Despite all of the theoretical work that has been done, I think it's
still true that the best way to find a "good" LC generator is to
search for one using an automated test procedure.

> but it definitely is slower than the mod 2^cellbits ones. It is
> just a bit faster as the hash-based PRNG I use in Gforth-git now
> (benchmarked on 64 bit machines), which does return 64 bit numbers
> on a 64 bit machine, and so far passed all randomness tests I ran
> from the TestU01 suite (I didn't run the very time consuming
> DieHarder test).

Sure, any LCRNG that uses division isn't going to be fast. A 64-bit
computer can turn that modulo operation into a couple of
multiplications, a shift, and a subtraction, but it's still not going
to be fast. 2^31 - 1 is prime, so that's a much better choice for a
modulus.

Andrew.

[Albert van der Horst]

In article <eqKdnSUOWM1xtgrP...@supernews.com>,

Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>Bernd Paysan <bernd....@gmx.de> wrote:
>>
>> LC53 is a maximum period linear congruent random number generator -
>> so far, so good. It has the usual problems of LCGs, so it doesn't
>> pass any serious randomness test suite. It is certainly not worse
>> than others,
>
>Did you really mean to say that? All we know is that it is not
>certainly worse. I doubt very much that a generator chosen without
>any theoretical justification or testing is as good as any. It's not
>impossible, but it would be a fantastic stroke of luck.

Sure Hugh got lucky, but it is not as fantastic as you might think.
The choice of a prime just under 2^32 is a bit of sound reasoning,
as soon as you're willing to pay the price for a mod operation.
It is known that in the row 'a' 'a^2' mod p etc. 'a' cannot be recovered
easily from 'a^2'. Square root of 'a' modulo a prime is as hard as
factoring, so if you choose a random looking 'a' larger than the root,
the second number is pretty unrelated.
Then test for a large period. This can be done without even the
knowledge that there are multipliers with a large period, or realizing
what the period is. Brute force will do it.

>
>Despite all of the theoretical work that has been done, I think it's
>still true that the best way to find a "good" LC generator is to
>search for one using an automated test procedure.

Especially in view of the following. You're using the generator for
something. Now some tests will be especially relevant to what you do,
others are not. If you plan to select Tetris blocks, the
correlation test probably matters, and you want an even distribution.
Pass would do, flying colours is not necessary. (I've a cross, so
I've a 0.1% larger chance of getting an L next.)
You can ignore other tests. E.g. the birthday test, requires that
with 32 bits random numbers you get two same numbers once in a
run of about 65,000. No lcg can pass that test, because same numbers are
2^32 apart. Not relevant for Tetris though.

>
>> but it definitely is slower than the mod 2^cellbits ones. It is
>> just a bit faster as the hash-based PRNG I use in Gforth-git now
>> (benchmarked on 64 bit machines), which does return 64 bit numbers
>> on a 64 bit machine, and so far passed all randomness tests I ran
>> from the TestU01 suite (I didn't run the very time consuming
>> DieHarder test).
>
>Sure, any LCRNG that uses division isn't going to be fast. A 64-bit
>computer can turn that modulo operation into a couple of
>multiplications, a shift, and a subtraction, but it's still not going
>to be fast. 2^31 - 1 is prime, so that's a much better choice for a
>modulus.

So to our consolation we can conclude that LC53 has probably a poor
price-performance ratio (We set out to prove that you get nowhere
without theory, right? ;-) ) This remains to be tested.

However performance is not the starting point. It was ease of use for
novices.
A novice will do `` RAND 6 MOD 1+ '' for a dice roll, and gets disappointed
with most rng, as even and odd dice rolls alternate.
Not so with LC53 though.

Most Forth rng are complemented with a choose function
: CHOOSE RAND UM* DROP ;
This is proper for a choice from few alternatives like a dice roll,
but it is another thing for a novice to learn.

>
>Andrew.

[Bernd Paysan]

hughag...@yahoo.com wrote:

> I had abandoned C.L.F. because it is just a platform for people to fake up
> expertise on subjects that they know nothing about (Bernd Payson's
> "quotations" being the last straw, because he was doing that as a
> representative of the Forth-200x committee, rather than just as a yahoo
> working with a bad Forth implementation that can be ignored).

I only was explaining to you the difference of three technical terms.
Quotation, nested function, and closure. You want nested functions, fine.
You called them closures, not fine. And you confuse quotations with them,
even worse.

These are different things, and they have different names for good reasons.
To get your actions right, you need to set the words right first, because
otherwise, everybody will be confused.

To use quotations well, you have to take the effort in a higher order
function so that the quotation can access the stack. To use nested
functions right, you have to take the effort so that the nested function can
access the surrounding locals. Both is effort, at different places.

I think all three approaches have their place: Closures in functional
programming languages that support the necessary garbage collection. Nested
functions in Algol-like languages that have locals everywhere. And
quotations in stack languages where you have the stack to pass your
parameters and results.

Yes, it's totally easy to implement quotations, as they are just :noname
within another function. That's the Forth way: Do something very simple and
ignore that other people use more complex ways to achieve about the same.
Therefore, the suggestion is as always: If you feel so bad with Forth, and
want something different, go and leave. We are not stopping you, rather the
contrary, we will celebrate it!

[Andrew Haley]

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:

> In article <eqKdnSUOWM1xtgrP...@supernews.com>,
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>
>>Sure, any LCRNG that uses division isn't going to be fast. A 64-bit
>>computer can turn that modulo operation into a couple of
>>multiplications, a shift, and a subtraction, but it's still not going
>>to be fast. 2^31 - 1 is prime, so that's a much better choice for a
>>modulus.
>
> So to our consolation we can conclude that LC53 has probably a poor
> price-performance ratio (We set out to prove that you get nowhere
> without theory, right? ;-) )

Did we?

> This remains to be tested.

I don't think so.

> However performance is not the starting point. It was ease of use for
> novices.
> A novice will do `` RAND 6 MOD 1+ '' for a dice roll, and gets disappointed
> with most rng, as even and odd dice rolls alternate.

But an LC generator mod 2^31 - 1 would be fine and doesn't involve a
division. And so would an xor-shift generator. In the end, bang for
the buck is what matters.

Andrew.

[Bernd Paysan]

Andrew Haley wrote:

> Bernd Paysan <bernd....@gmx.de> wrote:
>>
>> LC53 is a maximum period linear congruent random number generator -
>> so far, so good. It has the usual problems of LCGs, so it doesn't
>> pass any serious randomness test suite. It is certainly not worse
>> than others,
>
> Did you really mean to say that? All we know is that it is not
> certainly worse. I doubt very much that a generator chosen without
> any theoretical justification or testing is as good as any. It's not
> impossible, but it would be a fantastic stroke of luck.

Not really, the likelyhood to find a prime root is ~O(log^6 n), so there are
really very, very many prime roots if n is just 2^32.

> Despite all of the theoretical work that has been done, I think it's
> still true that the best way to find a "good" LC generator is to
> search for one using an automated test procedure.

The theoretical work reduces the search time. Maximum period is just one
condition a LC generator must pass. This is not enough, e.g. 2 is a prime
root of 2^32-5. 2 would be a very bad choice for g, though.

>> but it definitely is slower than the mod 2^cellbits ones. It is
>> just a bit faster as the hash-based PRNG I use in Gforth-git now
>> (benchmarked on 64 bit machines), which does return 64 bit numbers
>> on a 64 bit machine, and so far passed all randomness tests I ran
>> from the TestU01 suite (I didn't run the very time consuming
>> DieHarder test).
>
> Sure, any LCRNG that uses division isn't going to be fast. A 64-bit
> computer can turn that modulo operation into a couple of
> multiplications, a shift, and a subtraction, but it's still not going
> to be fast.

Actually, even a 32 bit computer can turn *that* particular modulo operation
into two multiplications by 5, and some addition/subtractions. (a*2^32+b)
mod 2^32-5 = (b + a*5) mod 2^32-5.

Thus you only need to iterate this until it's smaller than 2^32-5. The
multiplication by 5 itself is pretty cheap, especially on architectures like
x86, where you can use lea for that (be aware that you also need the higher
order part, so you need a shift right by 30, too, and keep track of your
carry!).

> 2^31 - 1 is prime, so that's a much better choice for a
> modulus.

Yes, Mersenne primes are quicker, because you don't need any further
multiplication for the addition above: a*2^n+b mod 2^n-1 = b+a mod 2^n-1.
For 64 bit systems, 2^61-1 is a Mersenne prime, and 2^127-1 is also one;
with a prime root that is just 64 bit, you could do with 2 um*s to produce a
LCRNG with a 2^127-1 period.

It will still have the other problems of LCRNGs, so if you want a high-
quality PRNG, don't use that approach.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>
>> Bernd Paysan <bernd....@gmx.de> wrote:
>>>
>>> LC53 is a maximum period linear congruent random number generator -
>>> so far, so good. It has the usual problems of LCGs, so it doesn't
>>> pass any serious randomness test suite. It is certainly not worse
>>> than others,
>>
>> Did you really mean to say that? All we know is that it is not
>> certainly worse. I doubt very much that a generator chosen without
>> any theoretical justification or testing is as good as any. It's not
>> impossible, but it would be a fantastic stroke of luck.
>
> Not really, the likelyhood to find a prime root is ~O(log^6 n), so
> there are really very, very many prime roots if n is just 2^32.

Sure, but there is a lot more to a quality linear congruential
generator than a maximum period. Set a = c = 1 and you've got a full
period but a very bad generator.

Andrew.

[hughag...@yahoo.com]

On Thursday, November 28, 2013 7:57:31 AM UTC-7, Bernd Paysan wrote:
> hughag...@yahoo.com wrote:
>
> > I had abandoned C.L.F. because it is just a platform for people to fake up
> > expertise on subjects that they know nothing about (Bernd Payson's
> > "quotations" being the last straw, because he was doing that as a
> > representative of the Forth-200x committee, rather than just as a yahoo
> > working with a bad Forth implementation that can be ignored).
>
> I only was explaining to you the difference of three technical terms.
> Quotation, nested function, and closure. You want nested functions, fine.
> You called them closures, not fine. And you confuse quotations with them,
> even worse.

> These are different things, and they have different names for good reasons.
> To get your actions right, you need to set the words right first, because
> otherwise, everybody will be confused.

Java's "closures" are fake too. These terms get mixed around all the time.

Also, my nested functions aren't named, so "nested function" as per Algol isn't a good term for them either. I'm just sticking with "quotation" so the Factor crowd will know what I'm talking about.

Ultimately, what matters is that what you have does something useful. This is the part that you are totally dodging --- your :NONAME with syntactic sugar is useless because it has no good way to communicate with the creator function.

> To use quotations well, you have to take the effort in a higher order
> function so that the quotation can access the stack. To use nested
> functions right, you have to take the effort so that the nested function can
> access the surrounding locals. Both is effort, at different places.

My novice package has EACH etc. that use quotation-like functions (called "touchers" in the documentation). The "place" where all the heavy lifting is being done, is inside of EACH etc.. These words have to be written in such a way that they hold all of their internal data on the return stack while the toucher is being executed --- this is so the toucher has access to the creator function's parameter stack. This is the technique that has to be done with your "quotations" too (although I've never seen any example code from you that shows that you know how to write code like this).

Anyway, it is a horrible technique for these reasons:
1.) All the complexity is in EACH etc., and there are a lot of these words (specific to every data structure), so the complication is getting dumped on the user rather than being built-in to the language.
2.) It only works when the creator function calls EACH directly, so its data is still on the top of parameter stack. The whole thing is very fragile, as calling intermediate functions will likely put temporary data on the parameter stack, messing everything up.
3.) It makes for very hard to read code, especially when there are more than one datum being communicated through.

All in all, this is a horrible technique. I only did this in the novice package because ANS-Forth doesn't support any better technique. Now you have carried the same horrible technique over to Forth-200x and standardized it. This alone is reason to ignore Forth-200x, which is what I expect the whole world to do.

> I think all three approaches have their place: Closures in functional
> programming languages that support the necessary garbage collection. Nested
> functions in Algol-like languages that have locals everywhere. And
> quotations in stack languages where you have the stack to pass your
> parameters and results.

Your technique has a place --- in the garbage bin of history! --- it is useless!

Closures, as done in Scheme/Lisp etc., do require GC. I don't support these --- this is done only so the closure can still be used after its creator function has gone out of scope --- this is a solution to a non-problem, and is one of the many reasons why Scheme/Lisp are too inefficient to be used in most applications.

The only technique that is actually useful in your list above, is the "nested functions" that I support. You don't need to have "locals everywhere" --- just one or two local in the creator function is necessary for communication between the quotation and its creator function --- using this technique does not result in a lot of gratuitous locals (as done in Algol, C, etc., and often done by recalcitrant programmers of those languages writing Forth code).

> Yes, it's totally easy to implement quotations, as they are just :noname
> within another function. That's the Forth way: Do something very simple and
> ignore that other people use more complex ways to achieve about the same.

I'm not "achieving about the same" that you are achieving --- you are achieving exactly nothing! --- I am achieving something useful.

You are giving yourself way to much credit; you have really achieved nothing with your "quotations." Your way (not the Forth way), is to do something very simple and pretend that it is useful when it is not --- that is to say: "fake it." The same thing is true of your B16 processor --- you are doing something very simple and pretending that it is useful --- you are faking it.

> Therefore, the suggestion is as always: If you feel so bad with Forth, and
> want something different, go and leave. We are not stopping you, rather the
> contrary, we will celebrate it!

You assume that you are a big leader in the Forth community, and that Forth is whatever you say that it is. You assume that I am a born follower, and that if I don't like your baloney then I should abandon Forth and take up another language (Rod suggests C), and swallow their baloney instead.

This isn't true. I am writing my own language. It is Forth --- but you and your baloney are irrelevant to it --- Forth will continue without you, and Forth will start making a lot more sense after you have been dumped by the wayside.

> Bernd Paysan
>
> "If you want it done right, you have to do it yourself"

By far, the funniest thing about you is this quote that you tack onto the end of all of your posts. LOL

More honestly, you, Elizabeth Rather, Albert van der Horst, etc., should use this quote: "If you want it done right, you have to delegate it to a brilliant programmer that you hopefully find around you."

[hughag...@yahoo.com]

On Thursday, November 28, 2013 8:22:08 AM UTC-7, Bernd Paysan wrote:
> > Sure, any LCRNG that uses division isn't going to be fast. A 64-bit
> > computer can turn that modulo operation into a couple of
> > multiplications, a shift, and a subtraction, but it's still not going
> > to be fast.

> Actually, even a 32 bit computer can turn *that* particular modulo operation
> into two multiplications by 5, and some addition/subtractions. (a*2^32+b)
> mod 2^32-5 = (b + a*5) mod 2^32-5.
>
> Thus you only need to iterate this until it's smaller than 2^32-5. The
> multiplication by 5 itself is pretty cheap, especially on architectures like
> x86, where you can use lea for that (be aware that you also need the higher
> order part, so you need a shift right by 30, too, and keep track of your
> carry!).

My original motivation for inventing LC53 was so I would have an LCG that was difficult to implement in C (without descending into assembly-language), but which would be easy to implement in ANS-Forth.

I wanted an LCG because my interest in the whole thing was to write an encryption-cracking program, and LCGs are the easiest to crack, so I expected that this would be a good introduction to crypto-analysis for me.

I only recommend using LCGs for games. My LC53 is okay for that, especially if you only need random numbers in a small range, so you are only using the upper bits of LC53 which are pretty random --- this is typical for games, because they don't need a lot of precision (they are mostly just moving images around on a small screen, after all).

There are many prngs that work a lot better than LCGs. In my language, I will make the prng a standard part of the language, so it will be written in assembly-language while yet being standard --- I'll most likely use Donald Knuth's 64-bit LCG from MMIX, as that is plenty fast, and it is adequate for simulation when only the upper 32-bits are used (which should be adequate for most simulations, as they don't require all that much precision either).

> > 2^31 - 1 is prime, so that's a much better choice for a
> > modulus.

The period for this is about half of the period for LC53, so it is about half as good. I could have used this for my encryption-cracking program though, as I wanted something fairly easy to crack.

The reason why I invented LC53 rather than use one of the common LCGs based on 2^31-1, is because I was at my father's ranch and he doesn't have internet access, and it was the weekend so I couldn't drive into town and use the library wifi, and my book on cryptography wasn't handy --- so I invested 2 hours on inventing my own --- but now I have invested more than 2 hours on this ridiculous thread...

[hughag...@yahoo.com]

On Monday, November 25, 2013 10:24:00 PM UTC-7, Elizabeth D. Rather wrote:
> On 11/25/13 9:32 AM, Albert van der Horst wrote:
> > Hugh suggests that the only difference with his LC53 is that
> > Anton Ertl and Elizabeth Rather inspire more confidence than he does.
>
> Thank you, but I never wrote a random number generator and don't intend
> to! I've been blessed by having some brilliant programmers around me.
> But most of FORTH, Inc.'s customers aren't in fields where a strong RNG
> is a necessity, so we keep it simple.

The mark of a great sales-person is the ability to say "thank you" with a straight face for work done by somebody else.

Today is Thanksgiving! A day when we are supposed to count our blessings! Elizabeth Rather has been blessed by having brilliant programmers around her --- she can thank God for that.

I have never had any brilliant programmers around me (I was working at Testra when I wrote MFX) --- and I don't believe that God (the creator of the universe) cares if I succeed as a programmer, or write code that doesn't work, or get run over by a cement-truck --- so I just rely on my own programming skills to make my code work, and look both ways before crossing the street.

BTW: My own tradition is to fast throughout the whole Thanksgiving weekend, as I think that fasting is good for the soul --- am I the only person in the world who does this on the Thanksgiving holiday?