Random numbers

[emf]

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

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

[Julio Di Egidio]

On Thursday, October 19, 2017 at 1:35:21 PM UTC+2, emf wrote:

> I am wondering if there is a better (but still not too complicated)
> way to generate random numbers then the Math.random().

Simplest and works across all recent browsers:

<https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues>

Here is the fine print:

<< The PRNG used differs from one implementation to the other but is
suitable for cryptographic usages. Implementations are [...] required
to use a seed with enough entropy, like a system-level entropy source. >>

Julio

[Thomas 'PointedEars' Lahn]

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

> 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,

^^^^^^^^^^^^
That is not possible.

> multiply them by, say 10000, bet the integer, and then the modulus of
> that. Wouldn't that give more random numbers?

That depends on what you mean by “bet the integer”.

--
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.

[Michael Haufe (TNO)]

On Thursday, October 19, 2017 at 2:06:16 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> emf wrote:
> ^^^
> It is considered polite here to posting using one’s real name.
>
> > 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,
> ^^^^^^^^^^^^
> That is not possible.

There is a new API:

https://developer.mozilla.org/en-US/docs/Web/API/Performance/now

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> On Thursday, October 19, 2017 at 2:06:16 PM UTC-5, Thomas 'PointedEars'
> Lahn wrote:

Attribution _line_, not attribution novel.

>> 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,
>> ^^^^^^^^^^^^
>> That is not possible.
>
> There is a new API:
>
> https://developer.mozilla.org/en-US/docs/Web/API/Performance/now

Thanks, but if you read more carefully: Although it *can* be accurate to *5*
microseconds *if the device supports it* ? it is only *guaranteed* to be
accurate to milliseconds ?, it does _not_ provide the *time from epoch* (or
anything like that) in microseconds then, and therefore makes for a *worse*
PRNG seed value than new Date().getTime().

Because it is intended to measure *performance*, _not_ to produce pseudo-
random numbers.

[Michael Haufe (TNO)]

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > On Thursday, October 19, 2017 at 2:06:16 PM UTC-5, Thomas 'PointedEars'
> > Lahn wrote:
>
> Attribution _line_, not attribution novel.

ACK

> >> 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,
> >> ^^^^^^^^^^^^
> >> That is not possible.
> >
> > There is a new API:
> >
> > https://developer.mozilla.org/en-US/docs/Web/API/Performance/now
>
> Thanks, but if you read more carefully: Although it *can* be accurate to *5*
> microseconds *if the device supports it* ? it is only *guaranteed* to be
> accurate to milliseconds ?, it does _not_ provide the *time from epoch* (or
> anything like that) in microseconds then, and therefore makes for a *worse*
> PRNG seed value than new Date().getTime().

More of an FYI of its existence to move the needle away from "That is not possible"

> Because it is intended to measure *performance*, _not_ to produce pseudo-
> random numbers.

Indeed

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Thanks, but if you read more carefully: Although it *can* be accurate to
>> *5* microseconds *if the device supports it* ? it is only *guaranteed* to
>> be accurate to milliseconds ?, it does _not_ provide the *time from
>> epoch* (or anything like that) in microseconds then, and therefore makes
>> for a *worse* PRNG seed value than new Date().getTime().
>
> More of an FYI of its existence to move the needle away from "That is not
> possible"

ACK.

Apropos, it had just occurred to me (when reading that the first time the
on-board cesium clocks of the GPS NTS-2 satellite were tested was on “day
190, 1977”) that you can obtain the date for day N of year Y using

new Date(Y, 0, N)

[Ben Bacarisse]

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

> r...@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.

[Julio Di Egidio]

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

[emf]

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

[Chris M. Thomasson]

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...

[Julio Di Egidio]

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

[Michael Haufe (TNO)]

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>

[Chris M. Thomasson]

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.

[Julio Di Egidio]

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

[Julio Di Egidio]

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

[emf]

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

[Chris M. Thomasson]

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.

[Julio Di Egidio]

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

[Dr J R Stockton]

On Thursday, October 19, 2017 at 9:58:26 PM UTC+1, Thomas 'PointedEars' Lahn wrote:

> Apropos, it had just occurred to me (when reading that the first time the
> on-board cesium clocks of the GPS NTS-2 satellite were tested was on “day
> 190, 1977”) that you can obtain the date for day N of year Y using
>
> new Date(Y, 0, N)

The likelihood of that is fairly obvious on considering

ECMA-262-1, Jun 1997, 15.9.1.12 MakeDay(year, month, date), list entry 1
or
ECMA-262-7, Jun 2016, 20.3.1.13 MakeDay (year, month, date), list entry 1
or I suppose the corresponding parts of all other ECMA-262.

IIRC, new Date(Y, 0, N) fails for years 0 to 99; and MD is wrong for most of Year 0.

--
(c) John Stockton, near London, UK. Using Google, no spell-check. |
Mail: J.R.""""""""@physics.org |

[Thomas 'PointedEars' Lahn]

Dr J R Stockton wrote:

> On Thursday, October 19, 2017 at 9:58:26 PM UTC+1, Thomas 'PointedEars'
> Lahn wrote:

Attribution line, not attribution novel.

> > Apropos, it had just occurred to me (when reading that the first time
> > the
>> on-board cesium clocks of the GPS NTS-2 satellite were tested was on “day
>> 190, 1977”) that you can obtain the date for day N of year Y using
>>
>> new Date(Y, 0, N)
>
> The likelihood of that is fairly obvious on considering
>
> ECMA-262-1, Jun 1997, 15.9.1.12 MakeDay(year, month, date), list entry 1
> or
> ECMA-262-7, Jun 2016, 20.3.1.13 MakeDay (year, month, date), list entry 1
> or I suppose the corresponding parts of all other ECMA-262.

(You are preaching to the choir.) I thought that to be obvious.

> IIRC, new Date(Y, 0, N) fails for years 0 to 99;

It fails for those years in V8 JavaScript 5.7.492.63 in Chromium
57.0.2987.98 on Debian/Devuan GNU+Linux in that they are considered
the years 1900 to 1999 CE instead (also see below):

| -> new Date(99, 0, 1)
| <- Fri Jan 01 1999 00:00:00 GMT+0100 (CET)

However, while “new Date(0, 0, 1)” cannot be used to produce January 1,
1 BCE according to the Proleptic Gregorian calendar, it is apparently
possible to do that in another way:

| -> var d = new Date(0, 0, 1); console.log(d); d.setFullYear(0);
| console.log(d);
| Mon Jan 01 1900 00:00:00 GMT+0100 (CET)
| Sat Jan 01 0 00:00:00 GMT+0100 (CET)

<https://en.wikipedia.org/wiki/1_BC> says that it was a Saturday indeed.

> and MD is wrong for most of Year 0.

That is a matter of interpretation or, if understood as specified, it does
not appear to be the case in that implementation (see above). According to
Wikipedia, 1999-01-01 CE *was* a Monday indeed:

<https://en.wikipedia.org/wiki/January_1900#January_1.2C_1900_.28Monday.29>

Please clarify, or cite evidence to support, your assumption.

[Dr J R Stockton]

On Tuesday, October 24, 2017 at 11:59:40 PM UTC+1, Thomas 'PointedEars' Lahn wrote:
> Dr J R Stockton wrote:
>
> > On Thursday, October 19, 2017 at 9:58:26 PM UTC+1, Thomas 'PointedEars'
> > Lahn wrote:
>
> Attribution line, not attribution novel.

OAF.

> > > Apropos, it had just occurred to me (when reading that the first time
> > > the
> >> on-board cesium clocks of the GPS NTS-2 satellite were tested was on “day
> >> 190, 1977”) that you can obtain the date for day N of year Y using
> >>
> >> new Date(Y, 0, N)
> >
> > The likelihood of that is fairly obvious on considering
> >
> > ECMA-262-1, Jun 1997, 15.9.1.12 MakeDay(year, month, date), list entry 1
> > or
> > ECMA-262-7, Jun 2016, 20.3.1.13 MakeDay (year, month, date), list entry 1
> > or I suppose the corresponding parts of all other ECMA-262.
>
> (You are preaching to the choir.) I thought that to be obvious.

It is, and it was well known long ago to many of us here,
so why did you write "it had just occurred to me", which
implies surprise? Perhaps you meant "I had just remembered".

> > IIRC, new Date(Y, 0, N) fails for years 0 to 99;

<<< Of course, that is not a true failure, as can be seen
by searching the Standard for the string "1900". It is
just an inanity of the Originators, as is getYear not
doing what getFullYear was later added to do.

> It fails for those years in V8 JavaScript 5.7.492.63 in Chromium
> 57.0.2987.98 on Debian/Devuan GNU+Linux in that they are considered
> the years 1900 to 1999 CE instead (also see below):
>
> | -> new Date(99, 0, 1)
> | <- Fri Jan 01 1999 00:00:00 GMT+0100 (CET)
>
> However, while “new Date(0, 0, 1)” cannot be used to produce January 1,
> 1 BCE according to the Proleptic Gregorian calendar, it is apparently
> possible to do that in another way:
>
> | -> var d = new Date(0, 0, 1); console.log(d); d.setFullYear(0);
> | console.log(d);
> | Mon Jan 01 1900 00:00:00 GMT+0100 (CET)
> | Sat Jan 01 0 00:00:00 GMT+0100 (CET)

It is easier to use var d = new Date(100, -1200, 1) or some
variant thereof, such as var d = new Date(-100, 1200, 1) ;
one can indeed use var d = new Date(400, 0, 1-400*365.2425) .
And easier still : var d = new Date(-1, 12, 1) .

> <https://en.wikipedia.org/wiki/1_BC> says that it was a Saturday indeed.
>
> > and MD is wrong for most of Year 0.
>
> That is a matter of interpretation or, if understood as specified, it does
> not appear to be the case in that implementation (see above). According to
> Wikipedia, 1999-01-01 CE *was* a Monday indeed:

But, according to my relevant IoP diary, 1999-01-01 was a Friday.

The obvious handy authority for the secular proleptic Gregorian year
zero is the civil calendar for years 2000 += n*28, for |n|<4. That
IoP diary says that the year 2000 was Saturday to Sunday; therefore
2001-001 = 2001-W01-1 (sic) was a Monday, as was fairly well
known at the time.

[Hans-Georg Michna]

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.

Hans-Georg

[Evertjan.]

Hans-Georg Michna <hans-georgN...@michna.com> wrote on 26 Oct 2017
in comp.lang.javascript:

> 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.

Ugly, ugly, as, while bce exists, christ most probably did not,
and even the 'fake' story says he was born in 4 bce,
and that values 'above' 10000 bce did not.

btw, the same goes for storey, as in floor,
which while it can be negative,
has no zero in the US, while it has in Europe.

Mezzanines may or may not be counted as storeys,
13th are sometimes skipped by US superstition,
and Trump tower has 10 fake floors.

btw, I love a positive story, even when fixional.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Thomas 'PointedEars' Lahn]

Hans-Georg Michna 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. […]

In the Proleptic Gregorian calendar as specified in ISO 8601 and implemented
by implementations of ECMA-262-3 and later, year 0 is equivalent to 1 BCE:

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

AFAICS, the result for Y === 0 is only wrong (not as specified) if N < 366
and one expects a date that is not in 1900 CE. This behavior of the Date
constructor has historical reasons, but, as I showed, can be worked around.


Unfortunately, although your address header fields have changed, they are
still invalid, so I have augmented my killfile with their new values. Note
that you are not only disregarding Netiquette, but also violating the Terms
of Use of your service provider which “may result in immediate account
revocation”.

<http://albasani.net/info/terms_of_use.html.en>

[Thomas 'PointedEars' Lahn]

Dr J R Stockton wrote:

> On Tuesday, October 24, 2017 at 11:59:40 PM UTC+1, Thomas 'PointedEars'
> Lahn wrote:
>> Dr J R Stockton wrote:
>> > On Thursday, October 19, 2017 at 9:58:26 PM UTC+1, Thomas 'PointedEars'
>> > Lahn wrote:
>>
>> Attribution line, not attribution novel.
>
> OAF.

No, I do not think that the Open Access Framework has something to do with
it.

>> > > Apropos, it had just occurred to me (when reading that the first
>> > > time the
>> >> on-board cesium clocks of the GPS NTS-2 satellite were tested was on
>> >> “day 190, 1977”) that you can obtain the date for day N of year Y
>> >> using
>> >> new Date(Y, 0, N)
>> > The likelihood of that is fairly obvious on considering
>> >
>> > ECMA-262-1, Jun 1997, 15.9.1.12 MakeDay(year, month, date), list entry
>> > 1 or
>> > ECMA-262-7, Jun 2016, 20.3.1.13 MakeDay (year, month, date), list entry
>> > 1 or I suppose the corresponding parts of all other ECMA-262.
>>
>> (You are preaching to the choir.) I thought that to be obvious.
>
> It is, and it was well known long ago to many of us here,

It turns out that the MakeDay() algorithm was never the reason, but the Date
constructor itself: From

<http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,
%201st%20edition,%20June%201997.pdf>

to

,-<http://www.ecma-international.org/ecma-262/8.0/#sec-date-year-month-date-hours-minutes-seconds-ms>
|
| […]
| h. If y is not NaN and 0 ≤ ToInteger(y) ≤ 99, then let yr be
| 1900+ToInteger(y); otherwise, let yr be y.

> so why did you write "it had just occurred to me",

That follows from my description.

> which implies surprise?

More like coincidence in this case.

> Perhaps you meant "I had just remembered".

No.

>> > IIRC, new Date(Y, 0, N) fails for years 0 to 99;
>
> <<< Of course, that is not a true failure, as can be seen
> by searching the Standard for the string "1900". It is
> just an inanity of the Originators, as is getYear not
> doing what getFullYear was later added to do.

ACK.

>> It fails for those years in V8 JavaScript 5.7.492.63 in Chromium
>> 57.0.2987.98 on Debian/Devuan GNU+Linux in that they are considered
>> the years 1900 to 1999 CE instead (also see below):
>>
>> | -> new Date(99, 0, 1)
>> | <- Fri Jan 01 1999 00:00:00 GMT+0100 (CET)
>>
>> However, while “new Date(0, 0, 1)” cannot be used to produce January 1,
>> 1 BCE according to the Proleptic Gregorian calendar, it is apparently
>> possible to do that in another way:
>>
>> | -> var d = new Date(0, 0, 1); console.log(d); d.setFullYear(0);
>> | console.log(d);
>> | Mon Jan 01 1900 00:00:00 GMT+0100 (CET)
>> | Sat Jan 01 0 00:00:00 GMT+0100 (CET)
>
> It is easier to use var d = new Date(100, -1200, 1) or some
> variant thereof, such as var d = new Date(-100, 1200, 1) ;
> one can indeed use var d = new Date(400, 0, 1-400*365.2425) .
> And easier still : var d = new Date(-1, 12, 1) .

Easier maybe, but not as reliable, and certainly harder to maintain.
A wrapper constructor that calls setFullYear() if necessary appears to be
the better approach.

>> <https://en.wikipedia.org/wiki/1_BC> says that it was a Saturday indeed.
>>
>> > and MD is wrong for most of Year 0.
>>
>> That is a matter of interpretation or, if understood as specified, it
>> does not appear to be the case in that implementation (see above).
>> According to Wikipedia, 1999-01-01 CE *was* a Monday indeed:

^^^^

> But, according to my relevant IoP diary, 1999-01-01 was a Friday.

Yes; this was a typo, as you can see if you consider the source code.

> The obvious handy authority for the secular proleptic Gregorian year
> zero is the civil calendar for years 2000 += n*28, for |n|<4. That
> IoP diary says that the year 2000 was Saturday to Sunday; therefore
> 2001-001 = 2001-W01-1 (sic) was a Monday, as was fairly well
> known at the time.

I do not follow.

[Tim Slattery]

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

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

[Hans-Georg Michna]

On Thu, 26 Oct 2017 19:04:59 +0200, Thomas 'PointedEars' Lahn
wrote:

>Unfortunately, although your address header fields have changed, they are
>still invalid, so I have augmented my killfile with their new values. Note
>that you are not only disregarding Netiquette, but also violating the Terms
>of Use of your service provider which “may result in immediate account
>revocation”.

Now valid. The reason I did it was that too many usenet users
customarily sent an additional email when replying.

My defense has worked very well through many years, although it
was kind of illegal.

I suspect that usenet is slowly going down, so perhaps the
problem shrinks along with this. I will check how it goes.

Hans-Georg

[emf]

On 2017-10-22 18:10, Stefan Ram wrote:

> emf <emf...@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

[Thomas 'PointedEars' Lahn]

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”.

[Dr J R Stockton]

On Thursday, October 26, 2017 at 6:05:06 PM UTC+1, Thomas 'PointedEars' Lahn 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.

> AFAICS, the result for Y === 0 is only wrong (not as specified) if N < 366
> and one expects a date that is not in 1900 CE.

There is only one such date; there was no 1900-02-29.

But the following code yields merely 59 :-
S = ""
for (N=1 ; N<400 ; N++) {
D1 = new Date(0e3, 0, N).getDate()
D2 = new Date(2e3, 0, N).getDate()
S += "+" + +(D1==D2) }
eval(S)

In a normal year, January+February is 59 days; the rest are wrong.

[Thomas 'PointedEars' Lahn]

Dr J R Stockton wrote:

> […] Thomas 'PointedEars' Lahn 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.
>>
>> AFAICS, the result for Y === 0 is only wrong (not as specified) if N <
>> 366 and one expects a date that is not in 1900 CE.
>
> There is only one such date;

No, I meant if one expected a date in 1 BCE instead of 1900 CE.

> there was no 1900-02-29.

| -> new Date(0, 0, 1)
| <- Mon Jan 01 1900 00:00:00 GMT+0100 (CET)
|
| -> new Date(0, 1, 29)
| <- Thu Mar 01 1900 00:00:00 GMT+0100 (CET)

> But the following code yields merely 59 :-
> S = ""
> for (N=1 ; N<400 ; N++) {
> D1 = new Date(0e3, 0, N).getDate()
> D2 = new Date(2e3, 0, N).getDate()

Undeclared variable, unwise identifiers.

> S += "+" + +(D1==D2) }

An Array instance is a lot more efficient for this:

var a = [];

for (…)
{
a.push("…");
}

var s = a.join("+");

> eval(S)

Please don’t.

var count = 0;

for (var n = 1; n < 400; ++n)
{
var d1 = (new Date(0e3, 0, n)).getDate();
var d2 = (new Date(2e3, 0, n)).getDate();
count += +(d1 == d2);
}

console.log(count);

> In a normal year, January+February is 59 days; the rest are wrong.

I do not see your point.

[dr.j.r....@gmail.com]

On Sunday, 29 October 2017 16:56:30 UTC, Thomas 'PointedEars' Lahn wrote:
> Dr J R Stockton wrote:

> > there was no 1900-02-29.
>
> | -> new Date(0, 0, 1)
> | <- Mon Jan 01 1900 00:00:00 GMT+0100 (CET)
> |
> | -> new Date(0, 1, 29)
> | <- Thu Mar 01 1900 00:00:00 GMT+0100 (CET)

I prefer to rely on common knowledge of the Gregorian Reform;
IIRC, the 4/100/400-year rules were printed on the back
cover of school exercise books in my day.

But I suggest that section 9 of
<http://www.thelatinlibrary.com/gravissimas.html> is more
authoritative than relying on software.

> > But the following code yields merely 59 :-
> > S = ""
> > for (N=1 ; N<400 ; N++) {
> > D1 = new Date(0e3, 0, N).getDate()
> > D2 = new Date(2e3, 0, N).getDate()
>
> Undeclared variable, unwise identifiers.

Irrelevant; single-use code, not saved to disc.

> > S += "+" + +(D1==D2) }
>
> An Array instance is a lot more efficient for this:

No; it would take longer to type, and I had wanted to see
S in its full glory before completion. Execution was
effectively instantaneous.

var a = [];
>
> for (…)
> {
> a.push("…");
> }
>
> var s = a.join("+");
>
> > eval(S)
>
> Please don’t.
>
> var count = 0;
>
> for (var n = 1; n < 400; ++n)
> {
> var d1 = (new Date(0e3, 0, n)).getDate();
> var d2 = (new Date(2e3, 0, n)).getDate();
> count += +(d1 == d2);
> }
>
> console.log(count);
>
> > In a normal year, January+February is 59 days; the rest are wrong.
>
> I do not see your point.

Then think more deeply. Looking at S may help you.

[Sam E]

On 10/29/2017 05:12 PM, dr.j.r....@gmail.com wrote:

[snip]

> I prefer to rely on common knowledge of the Gregorian Reform;
> IIRC, the 4/100/400-year rules were printed on the back
> cover of school exercise books in my day.

Those 4/100/400 rules mean the number of days in a (mean) year =
365 + (1/4) - (1/100) + (1/400) = 365.2425 = 31,556,952 seconds.

It would be simpler if the year was a whole number of days, but the day
and the year are both natural cycles and we can't change that.

We could so something about the months and that %&#$! DST.

[snip]

[Thomas 'PointedEars' Lahn]

dr.j.r....@gmail.com wrote:

> On Sunday, 29 October 2017 16:56:30 UTC, Thomas 'PointedEars' Lahn wrote:
>> Dr J R Stockton wrote:
>> > there was no 1900-02-29.
>>
>> | -> new Date(0, 0, 1)
>> | <- Mon Jan 01 1900 00:00:00 GMT+0100 (CET)
>> |
>> | -> new Date(0, 1, 29)
>> | <- Thu Mar 01 1900 00:00:00 GMT+0100 (CET)
>
> I prefer to rely on common knowledge of the Gregorian Reform;
> IIRC, the 4/100/400-year rules were printed on the back
> cover of school exercise books in my day.
>
> But I suggest that section 9 of
> <http://www.thelatinlibrary.com/gravissimas.html> is more
> authoritative than relying on software.

ISTM that you have not read my posting(s) carefully enough. The
implementation confirms your claim that there was no 1900-02-29 CE,
which disproves your claim that

>>> There is only one such date; there was no 1900-02-29.

in reply to my

>> AFAICS, the result for [new Date(0, 1, N)] is only wrong (not as

>> specified) if N < 366 and one expects a date that is not in 1900 CE.

which I have explained how it was meant.

>> > But the following code yields merely 59 :-
>> > S = ""
>> > for (N=1 ; N<400 ; N++) {
>> > D1 = new Date(0e3, 0, N).getDate()
>> > D2 = new Date(2e3, 0, N).getDate()
>>
>> Undeclared variable, unwise identifiers.
>
> Irrelevant; single-use code, not saved to disc.

Examples posted here should meeet the minimum standards of recommendable
ECMAScript code.

>> > S += "+" + +(D1==D2) }
>>
>> An Array instance is a lot more efficient for this:
>
> No; it would take longer to type,

It would not.

> and I had wanted to see S in its full glory before completion.

You do not have to see it as a *string* value.

> Execution was effectively instantaneous.

Addition is available directly as I showed, and indirectly through the
Array.prototype.reduce() method. There is no need for inefficient
concatenation or evil eval() [tm].

var a = Array.apply(null, {length: 10}).map((e, i) => i);

/* [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] */
console.log(a);

var notGauss = a.reduce((accu, e) => accu + e);

/* 45 */
console.log(notGauss);

>> > In a normal year, January+February is 59 days; the rest are wrong.
>> I do not see your point.
>
> Then think more deeply.

Likewise.

> Looking at S may help you.

It would not.

[First name Last name]

You don't need to get random numbers with a program. You create random numbers with your brain.

[John Harris]

On 14/05/2022 07:14, First name Last name wrote:
> You don't need to get random numbers with a program. You create random numbers with your brain.

Many experiments have shown that human brains are very bad at creating
"random" numbers.

John

[Mister Kristjan]

Try the below, guys

|
|
|
|
|
V

<html>
<body>
<div id="aa1" style="width: 100%;word-break:break-word;">
</div>
<script>
var a1=Math.random()*106875;
a1=Math.round(a1*100000000000)/1000000000000;
for(var i=0; i<9876; i++) {
var i01=i*0.8342626246475681396246346+i*0.767629578752464837134+0.13257568494264346234;
a1=a1*a1*0.563856787598547681531;
if(a1<0.1) a1=a1+4.37469234896;
if(a1>100000) a1=a1*0.000004398734756825426923475896;
var j=a1*9.4326974639679758456872875*i01;
j=Math.round(j*100000000000)/100000000000;
document.getElementById("aa1").append(j);
}
var aa001=document.getElementById("aa1").innerHTML;
aa001=aa001.replace(/\./g,'');
aa001=aa001.replace(/\+/g,'');
aa001=aa001.replace(/e/g,'');
aa001=aa001.replace(/\-/g,'');
document.getElementById("aa1").innerHTML=aa001;
</script>

</body>
</html>

[John Harris]

On 15/05/2022 10:51, Mister Kristjan wrote:
> John Harris kirjutas Laupäev, 14. mai 2022 kl 12:33:38 UTC+2:

> Okey, try then this

> |
> |
> |
> |
> V
>
>
> <html>
> <body>
> <div id="aa1" style="width: 100%;word-break:break-word;">
> </div>
> <script>
> var a1=Math.random()*106875;
> a1=Math.round(a1*100000000000)/1000000000000;
> for(var i=0; i<9876; i++) {

> var i01=i*0.1342626246475681396246346+i*0.267629578752464837134+0.13257568494264346234;
> a1=a1*a1*0.263856787598547681531;

> if(a1<0.1) a1=a1+4.37469234896;
> if(a1>100000) a1=a1*0.000004398734756825426923475896;

> var j=a1*2.4326974639679758456872875*i01;

> j=Math.round(j*100000000000)/100000000000;
> document.getElementById("aa1").append(j);
> }
> var aa001=document.getElementById("aa1").innerHTML;
> aa001=aa001.replace(/\./g,'');
> aa001=aa001.replace(/\+/g,'');
> aa001=aa001.replace(/e/g,'');
> aa001=aa001.replace(/\-/g,'');
> document.getElementById("aa1").innerHTML=aa001;
> </script>
>
> </body>
> </html>
>

Here's a simpler version :-

<html>

<title> Random digits </title>

<body>
<div id="aa1" style="width: 100%;word-break:break-word;">
</div>

<script>

var s = ""; // Random digit sequence

for(var i = 0; i<160000; i++)
{
var d = Math.floor(10*Math.random());
if (d < 10) // In case random = 1.0 (Shouldn't be)
s += d;
}

document.getElementById("aa1").innerHTML = s;

</script>

</body>
</html>


John

[Jon Ribbens]

On 2022-05-18, John Harris <ni...@jghnorth.org.uk.invalid> wrote:
> Here's a simpler version :-

Here's a less simple version:

Array(160000).fill(0).map(_=>10*Math.random()|0).join('')

[John Harris]

On 29/05/2022 17:12, Ingel wrote:

<snip>
> j=Math.round(j*7456896368674)/7456896368674;
<snip>

Never use round!

John

[V V V V V]

The latest

|
|
|
|
|
|
|
V

<html>
<body>
<div id="aa1" style="width: 100%;word-break:break-word;">
</div>
<script>

var a1=Math.random()*754234711;
a1=Math.round(a1*100000000)/1000000000;
for(var i=0; i<507777; i++) {
var i01=i*0.73142627471096247698275431743696346+0.0132542709641827386927342746234;
a1=a1*a1*2.6875961902437860984278546302;
if(a1<0.001) a1=a1+0.346989016742698173234896;
if(a1>10000000) a1=(a1%10000000)*0.035439873198467428963279406273498673469234896;
var j=a1*0.54326974673472134921438965875*i01;
j=Math.round(j*100000000)/100000000;

document.getElementById("aa1").append(j);
}
var aa001=document.getElementById("aa1").innerHTML;
aa001=aa001.replace(/\./g,'');
aa001=aa001.replace(/\+/g,'');
aa001=aa001.replace(/e/g,'');
aa001=aa001.replace(/\-/g,'');
document.getElementById("aa1").innerHTML=aa001;
</script>

</body>
</html>

On Sunday, May 29, 2022 at 7:12:51 PM UTC+3, Ingel wrote:
> Newer try

> |
> |
> |
> |
> |
> V
>
> <html>
> <body>
> <div id="aa1" style="width: 100%;word-break:break-word;">
> </div>
> <script>
> var a1=Math.random()*106875;

> a1=Math.round(a1*7456896368674)/7456896368674;

> for(var i=0; i<9876; i++) {

> var i01=i*0.8342626246475681396246346+i*0.767629578752464837134+0.13257568494264346234;
> a1=a1*a1*0.563856787598547681531;

> if(a1<0.1) a1=a1+4.37469234896;
> if(a1>100000) a1=a1*0.000004398734756825426923475896;

> var j=a1*9.4326974639679758456872875*i01;
> j=Math.round(j*7456896368674)/7456896368674;

[V]

<html>
<body>
<div id="aa1" style="width: 100%;word-break:break-word;">
</div>
<script>

var a1=67395;
a1=Math.round(a1*100000000000)/1000000000000;

for(var i=0; i<9876; i++) {

var i01=i*0.8342626246475681396246346+0.13257568494264346234;

a1=a1*a1*0.563856787598547681531;
if(a1<0.1) a1=a1+4.37469234896;
if(a1>100000) a1=a1*0.000004398734756825426923475896;
var j=a1*9.4326974639679758456872875*i01;

j=Math.round(j*100000000000)/100000000000;