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


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

Unexpected value when using "<"

Started byRobG <rgqld@iinet.net.au>
First post2014-11-23 17:45 -0800
Last post2014-11-24 19:43 +0100
Articles 4 — 2 participants

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


Contents

  Unexpected value when using "<" RobG <rgqld@iinet.net.au> - 2014-11-23 17:45 -0800
    Re: Unexpected value when using "<" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-24 03:37 +0100
      Re: Unexpected value when using "<" RobG <rgqld@iinet.net.au> - 2014-11-23 19:53 -0800
        Re: Unexpected value when using "<" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-24 19:43 +0100

#26201 — Unexpected value when using "<"

FromRobG <rgqld@iinet.net.au>
Date2014-11-23 17:45 -0800
SubjectUnexpected value when using "<"
Message-ID<723cd8aa-caff-4530-9977-9884cddeb3c7@googlegroups.com>
Given the comparison:

  'foo' < 2
  
I was expectingt the result to be *undefined*, based on the abstract relational comparison algorithm[1].

In step 3a, the left hand side is converted to a number using ToNumber('foo'), which returns NaN. Step 3c of the algorithm says:

  If nx is NaN, return undefined

So I was expecting the result to be *undefined*. The introduction to the section also says that the comparison:

    "...produces true, false, or undefined (which indicates that at least one operand is NaN)".
  
However, in the couple of browsers I tested, the result was Boolean false. Can someone please explain, or point to a suitable explanation elsewhere, why the result is *false* and not *undefined*?


1. http://ecma-international.org/ecma-262/5.1/#sec-11.8.5


-- 
RobG

[toc] | [next] | [standalone]


#26202

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-11-24 03:37 +0100
Message-ID<2134606.TczYAlEYiD@PointedEars.de>
In reply to#26201
RobG wrote:

> Given the comparison:
> 
>   'foo' < 2
>   
> I was expectingt the result to be *undefined*, based on the abstract
> relational comparison algorithm[1].

A relational expression never evaluates to the “undefined” value; its 
evaluation result is (as it must be) of type Boolean.
 
> In step 3a, the left hand side is converted to a number using
> ToNumber('foo'), which returns NaN.

Correct.

> Step 3c of the algorithm says:
> 
>   If nx is NaN, return undefined

Also correct.
 
> So I was expecting the result to be *undefined*. The introduction to the
> section also says that the comparison:
> 
>     "...produces true, false, or undefined (which indicates that at least
>     one operand is NaN)".
>   
> However, in the couple of browsers I tested, the result was Boolean false.
> Can someone please explain, or point to a suitable explanation elsewhere,
> why the result is *false* and not *undefined*?

You have overlooked that the Abstract Relational Comparison Algorithm does 
not terminate the algorithm of the operator:

| 11.8.1 The Less-than Operator ( < )
| 
| […]
| 5. Let r be the result of performing abstract relational comparison
|    lval < rval. (see 11.8.5)
| 6. If r is undefined, return false. Otherwise, return r.

IOW, *that* algorithm always returns either “true” or “false”. ∎

Apropos: The ECMAScript Support Matrix includes – and will probably use in 
the future – a draft reference implementation of ECMAScript Ed. 5.1 (and 
probably later of Ed. 6) in ECMAScript which supports a trace mode that is 
intended to make it easier to see such behavior.  It does not include an 
implementation of the less-than operator or the Abstract Relational 
Comparison Algorithm yet.

You can enable trace mode with the assignment “es.enableTrace = true”.  
Specification-related symbols are properties of the object referred to by 
“es”, so you can see what is implemented by typing “es.” in most script 
consoles already (but at the point not necessarily fully).  Selecting an 
item from the usual auto-complete list would display the source code of the 
algorithm implementation (without comments).  The entire source code can be 
found in [2] (which I will switch to Git along with the rest of my public 
repositories).  Feedback and contributions are appreciated.

> 1. http://ecma-international.org/ecma-262/5.1/#sec-11.8.5

[2] <http://PointedEars.de/wsvn/es-matrix/trunk/application/scripts/es.js>
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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


#26203

FromRobG <rgqld@iinet.net.au>
Date2014-11-23 19:53 -0800
Message-ID<ea9250aa-0675-4d93-926b-36dc33b49904@googlegroups.com>
In reply to#26202
On Monday, November 24, 2014 12:37:32 PM UTC+10, Thomas 'PointedEars' Lahn wrote:
> RobG wrote:
> 
> > Given the comparison:
> > 
> >   'foo' < 2
> >   
> > I was expectingt the result to be *undefined*, based on the abstract
> > relational comparison algorithm[1].
> 
> A relational expression never evaluates to the "undefined" value; its 
> evaluation result is (as it must be) of type Boolean.
>  
> > In step 3a, the left hand side is converted to a number using
> > ToNumber('foo'), which returns NaN.
> 
> Correct.
> 
> > Step 3c of the algorithm says:
> > 
> >   If nx is NaN, return undefined
> 
> Also correct.
>  
> > So I was expecting the result to be *undefined*. The introduction to the
> > section also says that the comparison:
> > 
> >     "...produces true, false, or undefined (which indicates that at least
> >     one operand is NaN)".
> >   
> > However, in the couple of browsers I tested, the result was Boolean false.
> > Can someone please explain, or point to a suitable explanation elsewhere,
> > why the result is *false* and not *undefined*?
> 
> You have overlooked that the Abstract Relational Comparison Algorithm does 
> not terminate the algorithm of the operator:
> 
> | 11.8.1 The Less-than Operator ( < )
> | 
> | [...]
> | 5. Let r be the result of performing abstract relational comparison
> |    lval < rval. (see 11.8.5)
> | 6. If r is undefined, return false. Otherwise, return r.
> 
> IOW, *that* algorithm always returns either "true" or "false". 

Ah, I skipped a step. Thank you. 


> Apropos: The ECMAScript Support Matrix includes - and will probably use in 
> the future - a draft reference implementation of ECMAScript Ed. 5.1 (and 
> probably later of Ed. 6) in ECMAScript which supports a trace mode that is 
> intended to make it easier to see such behavior.  It does not include an 
> implementation of the less-than operator or the Abstract Relational 
> Comparison Algorithm yet.
> 
> You can enable trace mode with the assignment "es.enableTrace = true".  
> Specification-related symbols are properties of the object referred to by 
> "es", so you can see what is implemented by typing "es." in most script 
> consoles already (but at the point not necessarily fully).  Selecting an 
> item from the usual auto-complete list would display the source code of the 
> algorithm implementation (without comments).  The entire source code can be 
> found in [2] (which I will switch to Git along with the rest of my public 
> repositories).  Feedback and contributions are appreciated.
>
> [2] <http://PointedEars.de/wsvn/es-matrix/trunk/application/scripts/es.js>

That seems interesting, but I can't connect to http://pointedears.de.


-- 
RobG

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


#26205

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-11-24 19:43 +0100
Message-ID<19416251.oVA11F6UJe@PointedEars.de>
In reply to#26203
RobG wrote:

> Thomas 'PointedEars' Lahn wrote:
>> You have overlooked that the Abstract Relational Comparison Algorithm
>> does not terminate the algorithm of the operator:
>> 
>> | 11.8.1 The Less-than Operator ( < )
>> | 
>> | [...]
>> | 5. Let r be the result of performing abstract relational comparison
>> |    lval < rval. (see 11.8.5)
>> | 6. If r is undefined, return false. Otherwise, return r.
>> 
>> IOW, *that* algorithm always returns either "true" or "false".
> 
> Ah, I skipped a step. Thank you.

You are welcome.

>> Apropos: The ECMAScript Support Matrix includes - and will probably use
>> in the future - a draft reference implementation of ECMAScript Ed. 5.1
>> (and probably later of Ed. 6) in ECMAScript which supports a trace mode
>> that is intended to make it easier to see such behavior.  […]  The entire
>> source code can be found in [2] (which I will switch to Git along with
>> the rest of my public repositories).  Feedback and contributions are
>> appreciated.
>>
>> [2]
>> [<http://PointedEars.de/wsvn/es-matrix/trunk/application/scripts/es.js>
> 
> That seems interesting, but I can't connect to http://pointedears.de.

It is working again since several hours.

Please trim your quotes.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]


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


csiph-web