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

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

Re: x === x

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: x === x Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-30 16:21 +0200
    Re: x === x John G Harris <niam@jghnorth.org.uk.invalid> - 2017-05-30 19:16 +0100
    Re: x === x Dr J R Stockton <J.R.Stockton@physics.org> - 2017-05-31 08:39 -0700
      Re: x === x Stefan Weiss <krewecherl@gmail.com> - 2017-05-31 18:08 +0200
        Re: x === x Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-06-02 22:27 +0100
      Re: x === x Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-31 21:03 +0200
        Re: x === x Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-06-02 22:12 +0100
      Re: x === x Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-31 21:09 +0200
        Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 01:58 +0100
          Re: x === x Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-06-01 05:01 +0200
            Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 14:44 +0100
            Re: x === x Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-06-02 21:15 +0100
          Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 14:17 +0100
      Re: x === x Julio Di Egidio <julio@diegidio.name> - 2017-06-01 00:10 -0700
        Re: x === x Dr J R Stockton <reply1700@merlyn.demon.co.uk.invalid> - 2017-06-02 22:16 +0100

#33444 — Re: x === x

Stefan Ram wrote:

>   In mathematics, usually, when »...« is a certain term, we have
> 
> ... === ...
> 
>   for the same term left and right.
> 
>   In JavaScript, this does not always hold for expressions, albeit
>   possibly sometimes for different reasons:

Just “possibly” – are you serious?  You profess to teach, but apparently 
still do not understand the basics of, these programming *languages*; nor, 
it appears, programming in general.
 
> Math.random() === Math.random()

This should be obvious even to you: The return values of consecutive calls 
of Math.random() may be, but are not supposed to be, equal.  After all, the 
method is supposed to generate *random* numbers.

> NaN === NaN

This evaluating to “false” is due to the implementation of the ECMAScript 
Number type as a type of IEEE 754 “double-precision” floating-point values.

> [] === []

Left-hand side and right-hand side refer to different, consecutively 
constructed, Array instances, and the operator compares the reference 
values, not the syntax or object content.

    [To do the latter, Array.prototype.every() may be used:

       [1, 2, 3].every(function (e, i) { return this[i] === e }, [1, 2, 3])

     Note that arrow functions must not be used then, as “this” would not 
     be defined by the second argument then:

       [1, 2, 3].every((e, i) => (
         /* Does not work: “this” is “undefined” in strict mode
                           or refers to the global object */
        this[i] === e
       ), [1, 2, 3])

     That is IMHO an oversight in the Specification that precludes the use
     of arrow functions where they would be most useful for short syntax.]

> ( {} === {} )

Left-hand side and right-hand side refer to different, consecutively 
constructed, Object instances, and the operator compares the reference 
values, not the syntax or object content.

    [To do the latter, a custom equals() method may be defined, like in 
     Java.  Care must be taken to avoid augmenting the Object prototype; 
     otherwise, for-in and for-of loops must be filtered, and the “in” 
     operator either cannot be used in a simple manner, or can only be 
     applied to objects that do not have the Object prototype in their 
     prototype chain, such as those created with Object.create(null, …).

     The introduction of an Object.equals() method that compares object
     content, by calling the first referred object’s equals() method 
     unless the object is the same as referred by “Object” and if 
     such a method is defined, using simple comparison otherwise, is
     indicated:

       Object.equals = function (obj1, obj2, options) {
         if (obj1 != Object && typeof obj1.equals == "function")
         {
           return obj1.equals(obj2);
         }

         return (
           options && options.enumerableOnly
             ? Object.keys(obj1)
             : Object.getOwnPropertyNames(obj1)
         ).every(
           options && options.strict
             ? function (key) { return (obj1[key] === obj2[key]); }
             : function (key) { return (obj1[key] == obj2[key]); }
         );
       };

    ]

> ( ()=>0 )===( ()=>0 )

Left-hand side and right-hand side refer to different Function instances, 
and the operator compares the reference values, not the syntax or object 
content.

    [There is no reliable *and* *normatively* backwards-compatible way to do 
     the latter, however the string representations of both functions may be 
     compared in newer implementations.  See ECMAScript 2016, § 19.2.3.5 
     Function.prototype.toString(), “toString Representation Requirements”.]

>   In the first case, we cannot be sure that it will evaluate to
>   »false«, but this is is possibly.
                 ^^^^^^^^^^^^^^^^^^^
Parse error.
 
>   The last three cases are similar, but it is also remarkable
>   how one needs to add parentheses: no parens required for the
>   array, outer parens for the objects,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No parentheses are required there; the “===” operator marks “{}” as an 
expression as opposed to an empty Block statement.

  {} === {}

is equivalent.

Besides, arrays *are* objects in ECMAScript implementations.  The proper 
terms to use there to make the distinction are “Object initializer” to refer 
to the syntax element, and “Object instance reference” to refer to the 
evaluation value.

>   and two pairs of parens for the functions.

The parentheses there are required to satisfy the grammar and to avoid 
ambiguity:

The parentheses around the second arrow function are required to avoid 
defining an arrow function that attempts to compares 0 with a syntactically 
invalid expression, “()”, equivalent to

  () => ((0 === ()) => 0)
-----------------^

    [“=>” is not an operator; the greater-than-or-equal operator is “>=”. 
     Therefore, “0 === ()” is the longest possible match.]

The parentheses around the first arrow function are required to avoid the 
ambiguity of defining an arrow function that compares 0 and a Function 
instance reference created by the second arrow function, equivalent to

  () => (0 === (() => 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] | [next] | [standalone]

#33446

On Tue, 30 May 2017 16:21:13 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

  <snip>
>and “Object instance reference” to refer to the evaluation value.
  <snip>

Or "Object instance" to refer to the evaluation value if you want to
use the ECMA 262 terminology, as some people insist we must.

  John

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

#33449

On Tuesday, May 30, 2017 at 3:21:19 PM UTC+1, Thomas 'PointedEars' Lahn wrote:

> ...
 
> This should be obvious even to you: The return values of consecutive calls 
> of Math.random() may be, but are not supposed to be, equal.  After all, the 
> method is supposed to generate *random* numbers.

Standard ECMA-262, 6th Edition / June 2015, HTML, includes a
rather woolly "definition" :-

:   20.2.2.27 Math.random ( )

:   Returns a Number value with positive sign, greater than or
:   equal to 0 but less than 1, chosen randomly or pseudo
:   randomly with approximately uniform distribution over that
:   range, using an implementation-dependent algorithm or
:   strategy. This function takes no arguments.

Ideally, the possible values would be equi-probable and of the
form X/N where N is a sufficiently large positive integer and
X is an integer in the range from 0 to N-1 inclusive; and there
would be no correlations whatsoever within an infinitely-long
stream of such values.

An ordinary computer design provides no source of true randomness,
and the code for Math.random has a finite number of internal
states limited by the number of bits used to hold the state.  If
there are M state bits, the sequence of outputs must repeat after
at most 2^M values.

In a truly random sequence as above, for all Y, the probability
of the Yth number being equalled by the Y+1th must be 1/N, not
zero.

As I recall, there is or was, in at least one browser, a
peculiarity : the possible random numbers are not equi-spaced.
The range of values leas than 0.5 may be as probable as the
range of values not less than 0.5; but the former range can,
in IEEE 754, be more finely divided than the latter.

Consider <http://web.archive.org/web/20150905080518/http://www.merlyn.demon.co.uk/js-randm.htm>.

If something better than browser Math,random is needed,
do a Web search for    random baagoe    and consider
sufficient of the (Google: currently 6130) hits.



> > NaN === NaN
> 
> This evaluating to “false” is due to the implementation of the ECMAScript 
> Number type as a type of IEEE 754 “double-precision” floating-point values.

I think not. IEEE 754 provides that a large number of 64-bit
patterns represent NaN, and I think it provides that all of
the patterns have the same arithmetic value.  But in languages
in which an IEEE 754 double pattern can be viewed as a 64-bit
integer pattern, those NaNs are distinguishable - therefore
it might be that two NaNs may be equal in the "==" sense,
but not identical in the "===" sense.

The indistinguishability and inequality of NaNs in JavaScript
results from a choice taken by ECMA or by its relevant
predecessors.

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

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

#33451

Dr J R Stockton wrote:
> If something better than browser Math,random is needed,
> do a Web search for    random baagoe    and consider
> sufficient of the (Google: currently 6130) hits.

Or use the Web Crypto API, which is supported by most modern browsers. The
getRandomValues() method can generate cryptographically secure sequences of
random numbers.


- stefan

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

#33497

In comp.lang.javascript message <ogmppc$4kn$1@news.albasani.net>, Wed,
31 May 2017 18:08:12, Stefan Weiss <krewecherl@gmail.com> posted:

>Dr J R Stockton wrote:
>> If something better than browser Math,random is needed,
>> do a Web search for    random baagoe    and consider
>> sufficient of the (Google: currently 6130) hits.
>
>Or use the Web Crypto API, which is supported by most modern browsers. The
>getRandomValues() method can generate cryptographically secure sequences of
>random numbers.

Unless, of course, it contains a subtle insecurity inserted by order of
the CIA or other agency, not necessarily one of the USG.  The very act
of using something described as cryptographically secure will encourage
attempts to find what is hidden.


-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

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

#33455

Dr J R Stockton wrote:

> […] Thomas 'PointedEars' Lahn wrote:
>> This should be obvious even to you: The return values of consecutive
>> calls of Math.random() may be, but are not supposed to be, equal.  After
>> all, the method is supposed to generate *random* numbers.
> 
> Standard ECMA-262, 6th Edition / June 2015, HTML, includes a
> rather woolly "definition" :-

That may be so, however the current Edition is the 7th (ECMAScript 2016).
 
> […] 
>> > NaN === NaN
>> 
>> This evaluating to “false” is due to the implementation of the ECMAScript
>> Number type as a type of IEEE 754 “double-precision” floating-point
>> values.
> 
> I think not. IEEE 754 provides that a large number of 64-bit
> patterns represent NaN, and I think it provides that all of
> the patterns have the same arithmetic value. […]

IEEE 754-1985 (at least) and (probably) IEEE 754-2008 (too) basically 
specify that (the) NaN (values) is/are not equal to any other floating-point 
value.  That is, “In the syntax of C, the predicate x != y is True but all 
others, x < y , x <= y , x == y , x >= y and x > y, are False whenever x or 
y or both are NaN” [1].

That is one reason why ECMAScript 2015 (6th Ed.) introduced

  Object.is(NaN, NaN) === true

<http://www.ecma-international.org/ecma-262/6.0/#sec-object.is>
<http://www.ecma-international.org/ecma-262/7.0/#sec-object.is>

(I thought that would be common knowledge around here.)

> The indistinguishability and inequality of NaNs in JavaScript
> results from a choice taken by ECMA or by its relevant
> predecessors.

You are very likely mistaken there.

_________
[1] Kahan, William. "IEEE standard 754 for binary floating-point 
    arithmetic." Lecture Notes on the Status of IEEE 754.94720-1776 (1996):
    11.  
<http://li.mit.edu/Archive/Activities/Archive/CourseWork/Ju_Li/MITCourses/18.335/Doc/IEEE754/ieee754.pdf>

      [Et al.  I would rather have referred to the section of the standard 
       itself, but its text is not freely available from the original
       publisher:

       <http://ieeexplore.ieee.org/document/4610935/?part=1>

       I think it is a disgrace for organizations like the IEEE and ISO 
       to publish an industry standard and then hide it behind a paywall
       *despite* having a paying membership already.  Kudos to organizations
       like Ecma International, ISOC, and the W3C, that are not doing this.]
-- 
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] | [next] | [standalone]

#33494

In comp.lang.javascript message <5183822.MhkbZ0Pkbq@PointedEars.de>,
Wed, 31 May 2017 21:03:06, Thomas 'PointedEars' Lahn
<PointedEars@web.de> posted:

>Dr J R Stockton wrote:
>
>> […] Thomas 'PointedEars' Lahn wrote:
>>> This should be obvious even to you: The return values of consecutive
>>> calls of Math.random() may be, but are not supposed to be, equal.  After
>>> all, the method is supposed to generate *random* numbers.
>>
>> Standard ECMA-262, 6th Edition / June 2015, HTML, includes a
>> rather woolly "definition" :-
>
>That may be so, however the current Edition is the 7th (ECMAScript 2016).

Does the 7th edition differ in this respect?  I think not.  Both have a
missing hyphen.

>
>> […]
>>> > NaN === NaN
>>>
>>> This evaluating to “false” is due to the implementation of the
>>>ECMAScript
>>> Number type as a type of IEEE 754 “double-precision” floating-point
>>> values.
>>
>> I think not. IEEE 754 provides that a large number of 64-bit
>> patterns represent NaN, and I think it provides that all of
>> the patterns have the same arithmetic value. […]
>
>IEEE 754-1985 (at least) and (probably) IEEE 754-2008 (too) basically
>specify that (the) NaN (values) is/are not equal to any other floating-point
>value.

I hope not, as basically the word "other" should not be there.  It is
incorrectly restrictive.


>> The indistinguishability and inequality of NaNs in JavaScript
>> results from a choice taken by ECMA or by its relevant
>> predecessors.
>
>You are very likely mistaken there.

No.  IEEE 754 is only a local standard; it is not of itself
international, and in any case confers no legal obligation; and it was
the choice of ECMA/predecessors (and also of FPU designers) to follow
that standard.  Recall that ISO 8601 is an International Standard, yet
is generally ignored by the less intelligent, especially in the USA.

Borland Delphi, however, follows IEEE 754, and in arithmetic expressions
NaNs are indistinguishable.  But the language, unlike JavaScript, allows
(for example) any consecutive 8 bytes (possibly starting on a 2^K byte
boundary) to be used *NOT ONLY* as an IEEE 754 Double *BUT ALSO* as 8
unsigned 8-bit integers or (IIRC) a 64-bit integer, etc.  In those
views, all possible NaNs are distinguishable.

The ECMA choice that really matters here is not the adoption of IEEE
754, but the invisibility of the entrails of an Object.

Recall the slightly analogous situation of +0 & -0.  They have the same
value, by the usual tests for equality.  Nevertheless, they are
distinguishable; 1/(+0) is infinitely different from 1/(-0).  It seems
somewhat likely that NaN/(+0) and NaN/(-0) are indistinguishably
different in at least some implementations.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

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

#33457

Stefan Ram wrote:

> Dr J R Stockton <J.R.Stockton@physics.org> writes:
>>An ordinary computer design provides no source of true randomness,
> 
>   What is "true randomness"?

Uniform distribution of results independent of a start value (seed).
 
“Ordinary computers” can only produce *pseudo*random numbers using a 
pseudorandom number generator (PRNG) that is seeded with a start value.

See also: 

<https://en.wikipedia.org/wiki/Random_number_generation#.22True.22_vs._pseudo-random_numbers> pp.

-- 
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] | [next] | [standalone]

#33463

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Stefan Ram wrote:
>
>> Dr J R Stockton <J.R.Stockton@physics.org> writes:
>>>An ordinary computer design provides no source of true randomness,
>> 
>>   What is "true randomness"?
>
> Uniform distribution of results independent of a start value (seed).

A very simple function can generate numbers with a uniform distribution
that is independent of any seed.  For example, a function producing
1, 1, 1... meets that definition.  If you want some variation, so does,
1, 2, 3, 1, 2, 3, 1, 2, 3...

I don't know of an uncontroversial and universally agreed-upon definition,
so I won't try to offer one.

<snip>
-- 
Ben.

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

#33465

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Stefan Ram wrote:
>>> Dr J R Stockton <J.R.Stockton@physics.org> writes:
>>>>An ordinary computer design provides no source of true randomness,
>>>   What is "true randomness"?
>> Uniform distribution of results independent of a start value (seed).
> 
> A very simple function can generate numbers with a uniform distribution
> that is independent of any seed.  For example, a function producing
> 1, 1, 1... meets that definition.  If you want some variation, so does,
> 1, 2, 3, 1, 2, 3, 1, 2, 3...

Apparently you missed the important word “random” here.

> I don't know of an uncontroversial and universally agreed-upon definition,
> so I won't try to offer one.

One thing is clear, though: patterns are the opposite of randomness.

-- 
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] | [next] | [standalone]

#33472

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Stefan Ram wrote:
>>>> Dr J R Stockton <J.R.Stockton@physics.org> writes:
>>>>>An ordinary computer design provides no source of true randomness,
>>>>   What is "true randomness"?
>>> Uniform distribution of results independent of a start value (seed).
>> 
>> A very simple function can generate numbers with a uniform distribution
>> that is independent of any seed.  For example, a function producing
>> 1, 1, 1... meets that definition.  If you want some variation, so does,
>> 1, 2, 3, 1, 2, 3, 1, 2, 3...
>
> Apparently you missed the important word “random” here.

It does not appear in the definition you offered.  If it had done (for
example if you had offered "uniform distribution of random results
independent of a start value") then the definition would have been
partly circular -- leaving "random" to be defined.

>> I don't know of an uncontroversial and universally agreed-upon definition,
>> so I won't try to offer one.
>
> One thing is clear, though: patterns are the opposite of randomness.

Yes.  This is why you need more than simply a uniform distribution and
independence from any seed.

-- 
Ben.

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

#33493

In comp.lang.javascript message <1917432.Icojqenx9y@PointedEars.de>,
Thu, 1 Jun 2017 05:01:42, Thomas 'PointedEars' Lahn <PointedEars@web.de>
posted:

>One thing is clear, though: patterns are the opposite of randomness.

No.  All possible output sequences must be equi-probable; and a random
fifteen-digit generator must be just as likely to generate
238462643383279 as to generate 141592653589793 or 111112222233333.

A PRNG is cannot be deemed faulty because it produces any such sequence
- only if it does so too often or not often enough.

The string 3477151372431 may look random; but it is actually 1e12 to
base 9.  It pseudo-unexpectedly contains no instances of 0 6 8 - and as
expected it contains no 9.

As I recall, all finite decimal digit sequences occur infinitely often
in the exact decimal value of Pi.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

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

#33471

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>I don't know of an uncontroversial and universally agreed-upon definition,
>>so I won't try to offer one.
>
>   I'd say, a bit source is truly random when the probability
>   of any party to correctly guess the next bit is 0.5.

I think that's pretty reasonable, but what about an algorithmic PRNG,
seeded by (unobserved) thermal noise and distributed in a tamper-proof
hardware package?

<snip>
-- 
Ben.

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

#33467

On Wednesday, 31 May 2017 17:40:10 UTC+2, Dr J R Stockton  wrote:
<snipped>

> Standard ECMA-262, 6th Edition / June 2015, HTML, includes a
> rather woolly "definition" :-
> 
> :   20.2.2.27 Math.random ( )
> 
> :   Returns a Number value with positive sign, greater than or
> :   equal to 0 but less than 1, chosen randomly or pseudo
> :   randomly with approximately uniform distribution over that
> :   range, using an implementation-dependent algorithm or
> :   strategy. This function takes no arguments.

There is nothing "woolly" about that definition, it's even pretty customary
to leave that kind of stuff implementation-dependent, and for quite obvious
reasons.

> Ideally, the possible values would be equi-probable and of the

Ideally, one would at least get a grasp on the basic definitions involved
before venturing into comments.

> An ordinary computer design provides no source of true randomness,

Nonsense...

> The indistinguishability and inequality of NaNs in JavaScript
> results from a choice taken by ECMA or by its relevant
> predecessors.

Nope, it's just due to the rules of the floating-point arithmetic.  Indeed,
notice that the same is in all languages.

Julio

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

#33495

In comp.lang.javascript message <ddf720b1-7dcb-4c3b-94c2-a0049e286471@go
oglegroups.com>, Thu, 1 Jun 2017 00:10:36, Julio Di Egidio
<julio@diegidio.name> posted:

>On Wednesday, 31 May 2017 17:40:10 UTC+2, Dr J R Stockton  wrote:
><snipped>

...

>> The indistinguishability and inequality of NaNs in JavaScript
>> results from a choice taken by ECMA or by its relevant
>> predecessors.
>
>Nope, it's just due to the rules of the floating-point arithmetic.  Indeed,
>notice that the same is in all languages.


Your naivety is, as is customary, manifest.


-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

[toc] | [prev] | [standalone]

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

csiph-web