Re: RND contest


Betov wrote:

You seem to be in very good company with Alex, ass-hole.

I would agree with this statement. Alex has a much better handle on
what it takes to test a random number generator than you do. And while
I am certainly no expert on the subject, clearly I know a little bit
more about the subject than you do, based on what you think is a "good"
test of a random number generator.


Yes, indeed, i am not used to read blablas, from guys
who never did anything but writing smocking Pdfs.

Actually, Knuth writes "smocking" TeX files :-)


When
i study something, i am used to take the _Code_, and
to _test_ it, and when i have something to say, i show
the facts.

And what facts does your little "rectangle" test show? About the only
thing it can do is show that a random number generator is *really bad*.
It cannot tell you whether the random number generator is good. Let's
consider the problems with your little "test":

1) If the sequence of numbers the RNG produces contains an odd number
of elements, then your two-dimensional test will plot points at twice
as many locations as it should.

2) Unless your rectangle is *really big*, you're going to have to apply
some function (like MOD) to the numbers the RNG returns, thus
invalidating the results you plot. If you have a *really good* RNG that
produces an n-bit result, and you use only m bits of that result (where
m < n), then the results are generally *NOWHERE NEAR AS GOOD*. So if
you produce a 32-bit random number and your rectangle isn't 4 billion
by 4 billion, you're not really testing the randome numbers the RNG
returns

3) The "rectangle" test may tell you something about the *distribution*
of the random numbers, but it doesn't tell you very much about sequence
lengths. Particularly if your rectangle is smaller than the range of
possible RNG values. And note that having a good distribution is
*easily* achieved by a number generator that is decidedly *not* random.

4) The rectangle test doesn't show how many hits each pixel in the
rectangle gets. If you get complete coverage, but certain pixels wind
up getting draw several orders of magnitude more often than others, the
two-dimensional rectangle test would make you think you've got a good
RNG when, in fact, is it *far* from random.

Bottom line is that if a RNG fails your rectangle test, we know that
it's a *really bad* RNG. But if it passes your rectangle test, we still
don't know much about the quality of your RNG. It could be absolutely
terrible, and pass your rectangle test with flying colors.

There is a reason so much research has been put into this subject. Just
because much of that research is beyond your understanding does not
invalidate that research.



Probably one of the reasons why RosAsm is the fastest
of the actual Assembler, why its Symbols CheckSum is
one of the best ever seen,

You've been given lots of examples in the past that prove this
statement to be false. Too bad you ignored those posts (by others, not
from me I might add) and continued to believe that you've got "one of
the best ever seen." Of course, you also believed that you would get
no collisions in your hash function too (and that was easy enough to
disprove). So it's not surprising to find that you think that a
rectangle test is a valid way to test a RNG.


why its Symbols Table accesses
are ones of the fastest ever seen, and so on...

Seen by you, perhaps. You can only make this statement because you've
not really looked at much else. Of course, it was really funny when I
found the bugs in your original implementation where collisions in the
hashing function were causing RosAsm to map two symbols to the same
symbol table entry. Back then your solution was to simply pick a
different symbol. My, what a clever algorithm. Thankfully, you finally
added collision checking to your hash function so that RosAsm users
didn't have to continue using such a kludgy trick.



Whereas an indecent nobody like you, who makes a living
from usurpated reputation, and BlaBla selling, has nothing
to show but but the slowest, and most weird, ever seen, HLL
Pre-Parser, written in Flex, Bison and C.

Whatever you say.
At least *I* picked up "The Art of Computer Programming, Vol 2" by
Donald Knuth and got a decent random number generator out of there for
the HLA standard library. I will freely admit that I'm not an expert on
analyzing random number generators; but at least I'm smart enough to
use those random number generators that people who *have* studied the
subject claim work pretty well. I don't try to pass off a lame test as
"proof" that the HLA RNG works well. I let the original designer's
research do that for me.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Agduria dungeon generation
    ... stage of the algorithm and rise appropriate error, ... A NTAE generator doesn't have to have any ... NTAE will happily accept all valid inputs and RNG states and produce ...
    (rec.games.roguelike.development)
  • Re: new /dev/random
    ... pick a well-known and well-analyzed RNG from the literature, ... Such RNGs typically combine well-known primitives in easily analyzed ... and have associated proofs that the quality of the generator is ... have that "automatic recovery from state compromise" property, ...
    (sci.crypt)
  • Re: random numbers function
    ... Since 5 and 7 have no common divider, you need to call the RNG 7 times, ... distribution the RNG provides for 5 random numbers). ... Calling the random number generator fewer times in certain ...
    (comp.programming)
  • Re: Non-random numbers generated by excels data analysis random gener
    ... > unlikely circumstance with a true RN generator. ... First, because you are seeding the RNG, it is not ... range of numbers generated, but also the apparent ... such guidance in the Help text. ...
    (microsoft.public.excel.worksheet.functions)