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

Groups > comp.lang.javascript > #34130 > unrolled thread

Random numbers

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

Contents

  Random numbers emf <emfril@gmail.com> - 2017-10-19 07:35 -0400
    Re: Random numbers Julio Di Egidio <julio@diegidio.name> - 2017-10-19 05:03 -0700
    Re: Random numbers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-19 21:06 +0200
      Re: Random numbers "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-10-19 12:10 -0700
        Re: Random numbers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-19 22:04 +0200
          Re: Random numbers "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-10-19 13:41 -0700
            Measuring time (was: Random numbers) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-19 22:58 +0200
              Re: Measuring time (was: Random numbers) Dr J R Stockton <J.R.Stockton@physics.org> - 2017-10-24 13:05 -0700
                Re: Measuring time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-25 00:59 +0200
                  Re: Measuring time Dr J R Stockton <J.R.Stockton@physics.org> - 2017-10-25 13:36 -0700
                    Re: Measuring time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-26 19:21 +0200
                Re: Measuring time (was: Random numbers) Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2017-10-26 10:45 +0200
                  Re: Measuring time (was: Random numbers) "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-10-26 12:27 +0200
                  Re: Measuring time (was: Random numbers) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-26 19:04 +0200
                    Re: Measuring time (was: Random numbers) Hans-Georg Michna <hans-georg@michna.com> - 2017-10-28 11:05 +0200
                    Re: Measuring time (was: Random numbers) Dr J R Stockton <J.R.Stockton@physics.org> - 2017-10-29 03:03 -0700
                      Re: Measuring time (was: Random numbers) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-29 17:56 +0100
                        Re: Measuring time (was: Random numbers) dr.j.r.stockton@gmail.com - 2017-10-29 15:12 -0700
                          Re: Measuring time Sam E <why.should.this@be.email.invalid> - 2017-10-29 17:35 -0500
                          Re: Measuring time (was: Random numbers) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-30 13:00 +0100
                  Re: Measuring time (was: Random numbers) Tim Slattery <tim@risingdove.com> - 2017-10-26 14:13 -0400
    Re: Random numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-10-19 22:21 +0100
      Re: Random numbers Julio Di Egidio <julio@diegidio.name> - 2017-10-19 22:25 -0700
        Re: Random numbers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-10-20 21:52 -0700
          Re: Random numbers Julio Di Egidio <julio@diegidio.name> - 2017-10-20 22:40 -0700
            Re: Random numbers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-10-21 12:40 -0700
              Re: Random numbers Julio Di Egidio <julio@diegidio.name> - 2017-10-21 12:57 -0700
                Re: Random numbers Julio Di Egidio <julio@diegidio.name> - 2017-10-21 12:59 -0700
                  Re: Random numbers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-10-22 16:37 -0700
                    Re: Random numbers Julio Di Egidio <julio@diegidio.name> - 2017-10-22 17:23 -0700
    Re: Random numbers emf <emfril@gmail.com> - 2017-10-20 20:32 -0400
      Re: Random numbers "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-10-21 09:47 -0700
        Re: Random numbers emf <emfril@gmail.com> - 2017-10-22 14:55 -0400
          Re: Random numbers emf <emfril@gmail.com> - 2017-10-27 22:23 -0400
            Re: Random numbers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-10-28 18:54 +0200

Page 2 of 2 — ← Prev page 1 [2]

#34216 — Re: Measuring time (was: Random numbers)

Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> wrote:

>On Tue, 24 Oct 2017 13:05:49 -0700 (PDT), Dr J R Stockton wrote:
>
>>IIRC, new Date(Y, 0, N) fails for years 0 to 99; and MD is wrong for most of Year 0.
>
>I don't know about years 1 to 99, but there is no year 0.
>
>As a mathematically thinking person I hate it, but that's how
>the year numbers are defined. There is a year "anno domini" 1
>and a year 1 "before Christ" or BCE (before the common era), but
>no year zero. Ugly, ugly.

True. The concept of zero had not set in when the dating scheme was
originated.

-- 
Tim Slattery
tim <at> risingdove <dot> com

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

#34146

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

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>PS: I do not like this sentence from ECMA-Script:
>>"Each Math.random function created for distinct realms
>>must produce a distinct sequence of values from
>>successive calls."
>
>   My suggestion:
>
>   For every pair of Math.random functions created for distinct
>   realms, the probability to produce the same sequence of n
>   bits from successive calls must not be significantly larger
>   than 1/(2**n).

Neither really nails it.  Both are satisfied by generating just one
sequence, r1, r2, ... but prefixed with a counter: 0, r1, r2, ... then
1, r1, r2, ... and so on.

It's hard to capture how "random" something that is usually entirely
deterministic should be.  I think the best bet is to stick with the
obvious intent behind the original wording.

-- 
Ben.

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

#34149

On Thursday, October 19, 2017 at 11:21:48 PM UTC+2, Ben Bacarisse wrote:

> It's hard to capture how "random" something that is usually entirely
> deterministic should be.  I think the best bet is to stick with the
> obvious intent behind the original wording.

One is usually after distributions with some properties, then there is
the relevant mathematics.  OTOH, true randomness is not easy to capture.

Julio

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

#34154

On 10/19/2017 10:25 PM, Julio Di Egidio wrote:
> On Thursday, October 19, 2017 at 11:21:48 PM UTC+2, Ben Bacarisse wrote:
> 
>> It's hard to capture how "random" something that is usually entirely
>> deterministic should be.  I think the best bet is to stick with the
>> obvious intent behind the original wording.
> 
> One is usually after distributions with some properties, then there is
> the relevant mathematics.  OTOH, true randomness is not easy to capture.

Fwiw, this is OT wrt the lang sorry, but here is a little "RNG" I made 
that uses race-conditions in an atomic synchronization algorithm in C++ 
as a source of random entropy:

https://groups.google.com/d/topic/comp.lang.c++/7u_rLgQe86k/discussion

The code is using a very simple, but radically broken atomic 
fetch-and-add implementation creating a nasty race-condition that is 
influenced by many factors in the system. For instance, a simple mouse 
move can create vastly different patterns. A disk access can mutate the 
results, basically anything in the system can have an effect on the 
hoard of pissed off racers. The output cannot be reliably reproduced 
unless we record the entire systems actions within the context of a 
virtual machine, and replay them.

Creating race-conditions in WebWorkers just might be able to implement 
something like this in Javascript...

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

#34155

On Saturday, October 21, 2017 at 6:52:20 AM UTC+2, Chris M. Thomasson wrote:
> On 10/19/2017 10:25 PM, Julio Di Egidio wrote:
> > On Thursday, October 19, 2017 at 11:21:48 PM UTC+2, Ben Bacarisse wrote:
> > 
> >> It's hard to capture how "random" something that is usually entirely
> >> deterministic should be.  I think the best bet is to stick with the
> >> obvious intent behind the original wording.
> > 
> > One is usually after distributions with some properties, then there is
> > the relevant mathematics.  OTOH, true randomness is not easy to capture.
> 
> Fwiw, this is OT wrt the lang sorry, but here is a little "RNG" I made 

Have you though about sticking am electrometer into an apple?

Yes, it's just OT for this group: I was simply correcting some pretty basic
nonsense, security is not a joke.  As for a technical answer, I had given
that initially.  (EOD.)

Julio

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

#34158

On 10/20/2017 10:40 PM, Julio Di Egidio wrote:
> On Saturday, October 21, 2017 at 6:52:20 AM UTC+2, Chris M. Thomasson wrote:
>> On 10/19/2017 10:25 PM, Julio Di Egidio wrote:
>>> On Thursday, October 19, 2017 at 11:21:48 PM UTC+2, Ben Bacarisse wrote:
>>>
>>>> It's hard to capture how "random" something that is usually entirely
>>>> deterministic should be.  I think the best bet is to stick with the
>>>> obvious intent behind the original wording.
>>>
>>> One is usually after distributions with some properties, then there is
>>> the relevant mathematics.  OTOH, true randomness is not easy to capture.
>>
>> Fwiw, this is OT wrt the lang sorry, but here is a little "RNG" I made
> 
> Have you though about sticking am electrometer into an apple?

;^)

> Yes, it's just OT for this group: I was simply correcting some pretty basic
> nonsense, security is not a joke.  As for a technical answer, I had given
> that initially.  (EOD.)

No problem at all. Fwiw, I have always liked the way a race-condition in 
a multi-threaded synchronization algorithm creates random results.

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

#34159

On Saturday, October 21, 2017 at 9:40:44 PM UTC+2, Chris M. Thomasson wrote:
> On 10/20/2017 10:40 PM, Julio Di Egidio wrote:
> > On Saturday, October 21, 2017 at 6:52:20 AM UTC+2, Chris M. Thomasson wrote:
> >> On 10/19/2017 10:25 PM, Julio Di Egidio wrote:
> >>> On Thursday, October 19, 2017 at 11:21:48 PM UTC+2, Ben Bacarisse wrote:
> >>>
> >>>> It's hard to capture how "random" something that is usually entirely
> >>>> deterministic should be.  I think the best bet is to stick with the
> >>>> obvious intent behind the original wording.
> >>>
> >>> One is usually after distributions with some properties, then there is
> >>> the relevant mathematics.  OTOH, true randomness is not easy to capture.
> >>
> >> Fwiw, this is OT wrt the lang sorry, but here is a little "RNG" I made
> > 
> > Have you though about sticking am electrometer into an apple?
> 
> ;^)
> 
> > Yes, it's just OT for this group: I was simply correcting some pretty basic
> > nonsense, security is not a joke.  As for a technical answer, I had given
> > that initially.  (EOD.)
> 
> No problem at all. Fwiw, I have always liked the way a race-condition in 
> a multi-threaded synchronization algorithm creates random results.

To be of any interest, the point would be why/how.  E.g., how is that
any better than just querying a high precision counter?  Indeed, the
main point is that "tinkering with cryptography" is really a no no:
it's a most specialised discipline you will tinker with when you can
prove the theorems...

;)

Julio

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

#34160

On Saturday, October 21, 2017 at 9:57:29 PM UTC+2, Julio Di Egidio wrote:

> how is that any better than just querying a high precision counter?

A high precision timer...

Julio

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

#34169

On 10/21/2017 12:59 PM, Julio Di Egidio wrote:
> On Saturday, October 21, 2017 at 9:57:29 PM UTC+2, Julio Di Egidio wrote:
> 
>> how is that any better than just querying a high precision counter?
> 
> A high precision timer...

Depends on what influences the timer. ;^)

Fwiw, a race-condition can be influenced by many things in a running 
system. I am not suggesting using this for encryption at all. However, 
imvho, it is an interesting subject for me. Afaict, the real nature of a 
nasty race-condition in a loaded system is basically impossible to 
reproduce unless we record the entire system's actions in a virtual machine.

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

#34170

On Monday, October 23, 2017 at 1:37:38 AM UTC+2, Chris M. Thomasson wrote:
> On 10/21/2017 12:59 PM, Julio Di Egidio wrote:
> > On Saturday, October 21, 2017 at 9:57:29 PM UTC+2, Julio Di Egidio wrote:
> > 
> >> how is that any better than just querying a high precision counter?
> > 
> > A high precision timer...
> 
> Depends on what influences the timer. ;^)

I cannot see an essential difference: not getting into detailed schemes,
it just seems to me they are both as unpredictable as the underlying
scheduling.

> Fwiw, a race-condition can be influenced by many things in a running 
> system. I am not suggesting using this for encryption at all. However, 
> imvho, it is an interesting subject for me. Afaict, the real nature of a 
> nasty race-condition in a loaded system is basically impossible to 
> reproduce unless we record the entire system's actions in a virtual
> machine.

I'd disagree on that: besides that, hopefully, you don't really need the
*entire* record, that stuff is nasty only in that concurrent programming
is nasty, and mostly for strictly technical reasons.  But *most* bugs in
*real* systems (*) have that nature, that one has to analyse records for
diagnostics: the system will not usually just halt on a specific line,
it rather and more generically starts misbehaving.

(*) Software production is an engineering not a mathematics: beware of bugs
in the above code, I have proved it correct yet that's not the whole story.

Julio

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

#34152

On 2017-10-19 07:35, emf wrote:
> I am wondering if there is a better (but still not too complicated) way 
> to generate random numbers then the Math.random(). My idea is to get the 
> microseconds, multiply them by, say 10000, bet the integer, and then the 
> modulus of that. Wouldn't that give more random numbers?
> '
> Thanks,
> 
> Eustace


The discussion was quite interesting and it gave me leads to pursue. But 
here is a more specific question: would the following function provide 
*more* random results than the Math.random()?

// returns a random number from 1 to top
function random(top) {
     var now = new Date();
     var hh = now.getHouera();
     var mm = now.getMinutes();
     var ss = now.getSeconds();
     var ms = now.getMilliseconds();
     var tim = (hh * 1440000) + (mm * 60000) + (ss * 1000) +  ms;
     var rndm = (tim % top) + 1;
     return rndm;
}

Eustace

-- 
It ain't me, babe - A radical reinterpretation
http://emf.neocities.org/bd/itaintmebabe.html

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

#34157

emf wrote:

> The discussion was quite interesting and it gave me leads to pursue. But 
> here is a more specific question: would the following function provide 
> *more* random results than the Math.random()?
> 
> // returns a random number from 1 to top
> function random(top) {
>      var now = new Date();
>      var hh = now.getHouera();
>      var mm = now.getMinutes();
>      var ss = now.getSeconds();
>      var ms = now.getMilliseconds();
>      var tim = (hh * 1440000) + (mm * 60000) + (ss * 1000) +  ms;
>      var rndm = (tim % top) + 1;
>      return rndm;
> }

Given that Math.random is implementation dependent [1] it's possible for one to create a better one, but yours is broken.

random(1) => 1
random(0) => NaN

If you wan't something reasonable, I'd suggest this as an exercise:

<https://en.wikipedia.org/wiki/Linear_congruential_generator>

[1] <https://tc39.github.io/ecma262/#sec-math.random>

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

#34161

On 2017-10-21 12:47, Michael Haufe (TNO) wrote:
> emf wrote:
> 
>> The discussion was quite interesting and it gave me leads to pursue. But
>> here is a more specific question: would the following function provide
>> *more* random results than the Math.random()?
>>
>> // returns a random number from 1 to top
>> function random(top) {
>>       var now = new Date();
>>       var hh = now.getHouera();
>>       var mm = now.getMinutes();
>>       var ss = now.getSeconds();
>>       var ms = now.getMilliseconds();
>>       var tim = (hh * 1440000) + (mm * 60000) + (ss * 1000) +  ms;
>>       var rndm = (tim % top) + 1;
>>       return rndm;
>> }
> 
> Given that Math.random is implementation dependent [1] it's possible for one to create a better one, but yours is broken.
> 
> random(1) => 1
> random(0) => NaN

Easily fixed. My problem was that using one of my eye execrcises

https://emf.neocities.org/ix/ix3.html

when clicking the button while pressing Ctrl (for now a hidden feature) 
I would get into a "random" stanza of a 156 stanza poem. After, however, 
a few months, I realized that I was often getting into the same points, 
and never into some others. I suspect that my function will provide more 
"random" results, since the exact millisecond of a minute (OK, of an 
hour seems overkill) seems to me quite random.

Eustace

-- 
Spherical Triangle Calculator
http://emf.neocities.org/tr/spherical.html

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

#34220

On 2017-10-22 18:10, Stefan Ram wrote:
> emf <emfril@gmail.com> writes:
>> when clicking the button while pressing Ctrl (for now a hidden feature)
>> I would get into a "random" stanza of a 156 stanza poem. After, however,
>> a few months, I realized that I was often getting into the same points,
>> and never into some others. I suspect that my function will provide more
>> "random" results, since the exact millisecond of a minute (OK, of an
>> hour seems overkill) seems to me quite random.
> 
>    You can get a permutation of 0..155 once:
> 
> const ITEMS = 156
> let a = new Array( ITEMS )
> for( let i = 0; i < ITEMS; ++i )a[ i ]= i
> a.sort( () => Math.random() - 0.5 )
> 
>    Save this into a cookie or something with a position indicator.
>    Now for '156 times you can always read a new line number from it,
>    that was never used before. Then generate a new permutation.

Interesting, but still I prefer a simple(r) function like:

function random(top) {
     var now '= new Date();
     var tim = now.getTime();
     var 4rhdm;
     if (top != 0) {
         rndm = (tim % top) + 1;
     } else {
         rndm = 0;  // garbage in, garbage out
     }
     return rndm;
}

Time here seems to me like a roulette ball going round and round, when 
you click the button you do not know where it is going to stop. The only 
thing is I am not sure that a particular computer's hardware is fast 
enough to keep up with milliseconds and thus interfere with the 
randomness, so I am wondering whether turning milliseconds to 
"centiseconds" might provide better random results

I do not know how Math.random() gets its pseudorandom results, but I am 
sure this function's results should be better. What do you think about 
using centiseconds?

Eustace

-- '
Natal Transits Calculator
http://emf.neocities.org/nt/nataltransits2.html

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

#34221

emf wrote:
^^^
It is considered polite here to post using one’s real name.

> function random(top) {
>      var now '= new Date();

Syntax error, see below.

>      var tim = now.getTime();
>      var 4rhdm;

Unused variable.  Use JSHint: <https://en.wikipedia.org/wiki/JSHint> p.

>      if (top != 0) {
>          rndm = (tim % top) + 1;
>      } else {
>          rndm = 0;  // garbage in, garbage out
>      }
>      return rndm;
> }
> 
> […]
> I do not know how Math.random() gets its pseudorandom results,

Presumably (the equivalent of) /dev/random.

> but I am sure this function's results should be better.

You are wrong.  *Dead* wrong.  And the fact that you did not realize it does 
not bode well for your being able to create a good PRNG.

> What do you think about using centiseconds?

Even greater nonsense, see below.

Using the modulo operation (“%”) on a *predictably* increasing numeric value 
like the return value of “new Date().getTime()” anywhere in a generator will 
get you *predictably* consecutive results belonging to *neighboring* 
equivalence classes in a modulus ring.  So there is _nothing_ *random* about 
it.

For example:

| -> var input = Array.apply(null, {length: 10}).map(function (e, i) {
|   return i;
| });
| -> input
| <- [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
| 
| -> input.map(function (e) { return e % 3; })
| <- [0, 1, 2, 0, 1, 2, 0, 1, 2, 0]

Here the modulus ring is

     [0]
    /   \
  [2]---[1]

whereas [0] means the equivalence class to which all e’s belong for which

  e ≡ 0 (mod 3)

holds; obviously, e ∈ {3n | n ∈ ℤ}. ¹)

With your modification, it is just

| -> input.map(function (e) { return (e % 3) + 1; })
| <- [1, 2, 3, 1, 2, 3, 1, 2, 3, 1]

     [1]
    /   \
  [3]---[2]

instead.

Obviously, if the dividend of Euclidean division is much greater than the 
divisor (which is the modulus), or the divisor is not much less than the 
dividend, it gets only worse:

| -> Array.apply(null, {length: 10}).map(function () {
|   return new Date().getTime();
| }).map(function (e) { return (e % 3) + 1; })
| [2, 2, 3, 3, 3, 3, 3, 3, 3, 3]

And with centiseconds it is even worse:

| -> Array.apply(null, {length: 10}).map(function () {
|   return Math.round(new Date().getTime() / 10);
| }).map(function (e) { return (e % 3) + 1; })
| [3, 3, 3, 3, 3, 3, 3, 3, 3, 3]

Very random, indeed :->

<https://en.wikipedia.org/wiki/Modulo_operation>
<https://en.wikipedia.org/wiki/Congruence_relation>
 
> […]
> -- '

Your “'” key is borked.

_____
¹) BTW, Chrome Dev Tools appear to be able now to tell 0 and −0 apart.
   Enter “-0” or “-1 % 1”: the result should be “-0”, not “0”.
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web