LiveCode Forums.

I was not at all surprised that the Dictionary is completely silent about what algorithm the random() function uses.

For example, for Javascript, it depends on the web browser, but most seem to use xorshift128+.

Anyone know what algorithm LiveCode uses?

Why is that important?

Surely it does not matter vis-a-vis LiveCode whether my car has
a diesel, petrol, propane or electric engine: the thing will still get me to Berlin.

Of course it might be useful to know if LiveCode's random numbers are really
random numbers or merely pseudorandoms.

Randomness cannot exist in deterministic systems like computers (some argue that randomness doesn't exist anywhere in the universe as we know it).

So all computers simulate the concept of randomness with pseudorandomness.

Michael, I don't know offhand which pseudorandom algo LC uses, though I'm sure I can be discovered in the available source code.

But having devoted a fair bit of time to pondering randomness (for cryptography and games) I'm curious to learn what knowing the algo would provide you with.)

Randomness cannot exist in deterministic systems like computers

Quite: but a computer can pick up information from, for instance, a bit of Strontium as it decays.

You can roll your own random generator with a package of kludges.

Take a (standard) random digit from the milliseconds. Do that as many times as the number of digits you need. True randomness comes from the human interaction with the time.

Craig

dunbarx wrote: ↑

Mon Jul 12, 2021 7:57 pm

You can roll your own random generator with a package of kludges.

Take a (standard) random digit from the milliseconds. Do that as many times as the number of digits you need.

That's essentially what LC's random function does, using clock time for its default randseed.

Fun: if you need to have a pseudorandom sequence that's repeatable (such as for relatively even distribution), you can set LC's randseed to a given number, and subsequent calls to the random function will repeat exactly.

Richard.

I do understand that the randSeed is created from a virtually random source. But am I not correct in thinking that my silly little method would generate truly random numbers, by virtue of using something as "unstable" as the time, and a computer's having to live in the real world, to derive a truly random string? That extra stuff is because I have forgotten how to have LC give the milliseconds NOT in scientific notation.

Craig

A few years ago a professor created a new algorithm, PCG. On her website she details the various qualities desirable in an algorithm, and how the existing algorithms aren't as good as PCG. Granted that she could be biased, but I haven't seen any reputable criticism of her work or her claims.

I'd love to implement it in LiveCode, but I can't translate from the C-language example on the site, which is daunting.

Someone made a Javascript version, which is more understandable to me, but not completely understandable. Also, the author says that it requires a lot of code because Javascript doesn't handle 64-bit math natively like C does, and I imagine LiveCode would have that same limitation.

I remembered how I changed the scientific notation into a string: Craig

Good stuff, Michael. Thanks for those links.

Hopefully someone with more familiarity than myself can chime on the algo LC uses.

I'm sure the professor's algo is a very good one, but what may be "best" seems dependent on the application.

For example, emulating true randomness well would allow for the same choice appearing over and over each time it's called.

But while that would fit the philosophical definition of "random", it may not fit a user's mental model of how randomness *should* work.

This talk describes different types of distributions of uncertain outputs for different board game design purposes:
https://youtu.be/qXn3tGBztVc

There what he calls "white" noise is what most programmers think of as fitting a reasonable set of expectations for randomness, offering somewhat even distribution of values.

But in the natural world (weather, stock markets) we find far more examples of "pink" noise, which may handle the same range of options as white but with a clustering of results near a base value, with outliers rare in proportion to their distance from the base, like a bell curve.

And because we have more direct experience with pink noise than white, many game systems strive for that sort of constrained randomness as it feels more "fun", or at least better fits player expectations (or maybe just player desires <g>).

When designing tabletop games these things can help inform choices for number of dice and range on each.

In a software program recently I found myself thinking about handling randomness in terms of multi-dice throws, and wrote some "pink noise" algorithms that almost literally employ dice dynamics under the hood, summing smaller pseudorandom outputs.

I was not at all surprised that the Dictionary is completely silent about what algorithm the random() function uses.

Why weren't you surprised?

Because I rarely find what I'm looking for in the docs. That's why when I went to look up random(), I thought, "They're not even gonna bother to mention what algorithm they use." I was right for a reason.

I was right for a reason.

And what was that reason?

As most of us are aware that computers are just clunky machines that are (and should stay) the slaves of
humankind we are also aware that computers don't have hands and oposble thumbs so they cannot chuck dice around
and any 'random' number they come up with has got to be a fudge.

I would be very surprised indeed . . .
-

richmond62 wrote:And what was that reason?

I just told you. It's literally every sentence of my reply. That was the whole point.