Asp Forum - Unexpected value when using "<"

RobG

11/24/2014 1:46:00 AM

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

--
RobG

6 Answers

paul

2/18/2014 10:23:00 PM

On Tuesday, February 18, 2014 4:07:53 PM UTC-5, HoneyMonster wrote:
> adambeneschan@gmail.com wrote:
>
> > weaker minor
>
> ..."an expression often heard when Hog cuts Hog"
>
> Seriously though, I agree. Pointless to bid two suits on a 4-3-3-3 hand.

Really? Since responder will be at least 4-4 if he raises spades, there will be a ruffing value. South's prime values scream "suit contract." Not to mention those lovely clubs, and of course no one ever leads clubs after you've opened the suit...

I think 2NT is plausible and may even be, in general, the better rebid but it is not glaringly obvious.

Ron Lel

2/19/2014 12:13:00 AM

On Wednesday, 19 February 2014 05:22:50 UTC+7, paul...@infi.net wrote:
> On Tuesday, February 18, 2014 4:07:53 PM UTC-5, HoneyMonster wrote:
>
> > adambeneschan@gmail.com wrote:
>
> >
>
> > > weaker minor
>
> >
>
> > ..."an expression often heard when Hog cuts Hog"
>
> >
>
> > Seriously though, I agree. Pointless to bid two suits on a 4-3-3-3 hand.
>
>
>
> Really? Since responder will be at least 4-4 if he raises spades, there will be a ruffing value. South's prime values scream "suit contract." Not to mention those lovely clubs, and of course no one ever leads clubs after you've opened the suit...
>
>
>
> I think 2NT is plausible and may even be, in general, the better rebid but it is not glaringly obvious.

1C 1H
2NT 3NT
looks glaringly obvious to me

Ron

Co Wiersma

2/19/2014 4:33:00 AM

RonfromLao schreef op 19-2-2014 1:13:
> On Wednesday, 19 February 2014 05:22:50 UTC+7, paul...@infi.net wrote:
>> On Tuesday, February 18, 2014 4:07:53 PM UTC-5, HoneyMonster wrote:
>>
>>> adambeneschan@gmail.com wrote:
>>
>>>
>>
>>>> weaker minor
>>
>>>
>>
>>> ..."an expression often heard when Hog cuts Hog"
>>
>>>
>>
>>> Seriously though, I agree. Pointless to bid two suits on a 4-3-3-3 hand.
>>
>>
>>
>> Really? Since responder will be at least 4-4 if he raises spades, there will be a ruffing value. South's prime values scream "suit contract." Not to mention those lovely clubs, and of course no one ever leads clubs after you've opened the suit...
>>
>>
>>
>> I think 2NT is plausible and may even be, in general, the better rebid but it is not glaringly obvious.
>
> 1C 1H
> 2NT 3NT
> looks glaringly obvious to me
>
> Ron
>

For me also

Co Wiersma

Thomas 'PointedEars' Lahn

11/24/2014 2:37:00 AM

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

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

RobG

11/24/2014 3:54:00 AM

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

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

--
RobG

Thomas 'PointedEars' Lahn

11/24/2014 6:43:00 PM

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...
>
> That seems interesting, but I can't connect to http://poin....

It is working again since several hours.

Please trim your quotes.

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

comp.lang.javascript

Unexpected value when using "<"

RobG

paul

Ron Lel

Co Wiersma

Thomas 'PointedEars' Lahn

RobG

Thomas 'PointedEars' Lahn

x Login to ForumsZone