Discuss
  • Number.isNaN

Number.isNaN

# John-David Dalton (13 years ago)

I noticed that ES6 Number.isNaN checks Type(number) of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to Array.isArray's check. This would also allow Number.isNaN(Object(NaN)) to return true. Thoughts?

# Luke Hoban (13 years ago)

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of John-David Dalton Subject: Number.isNaN

I noticed that ES6  Number.isNaN checks Type(number) of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to Array.isArray's check. This would also allow Number.isNaN(Object(NaN)) to return true. Thoughts?

The current draft spec [0] uses a ToNumber coercion and checks whether this results is NaN. So "Number.isNaN(Object(NaN))" will return "true".

Luke

[0] harmony:specification_drafts

# Yusuke Suzuki (13 years ago)

The current draft spec [0] uses a ToNumber coercion and checks whether this results is NaN. So "Number.isNaN(Object(NaN))" will return "true".

Global's isNaN uses ToNumber, but Number.isNaN doesn't do it because type coercion makes confused result, such as isNaN(Object(NaN)) => true [0]

So "Number.isNaN(Object(NaN))" will return "false" in latest draft and "isNaN(Object(NaN))" will return "true".

[0] harmony:number.isnan

# Mark S. Miller (13 years ago)

On Thu, Dec 13, 2012 at 7:50 PM, Luke Hoban <lukeh at microsoft.com> wrote:

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of John-David Dalton Subject: Number.isNaN

I noticed that ES6 Number.isNaN checks Type(number) of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to Array.isArray's check. This would also allow Number.isNaN(Object(NaN)) to return true. Thoughts?

The current draft spec [0] uses a ToNumber coercion and checks whether this results is NaN. So "Number.isNaN(Object(NaN))" will return "true".

In that case, the current spec is wrong. The purpose of introducing Number.isNaN is to repair the following bug in the global isNaN:

isNaN("foo") // returns true
# Luke Hoban (13 years ago)

From: Mark S. Miller [mailto:erights at google.com]

In that case, the current spec is wrong. The purpose of introducing Number.isNaN is to repair the >> following bug in the global isNaN:

isNaN("foo") // returns true

Indeed, as Yusuke noted on the other reply, I referred to the wrong 'isNaN'. And as you note, the point of the 'Number.isNaN' variant is to avoid any coercions.

That still leave's JDD's original suggestion to allow Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive or boxed Number. It feels a little odd to introduce another kind of limited coercion into the language, but perhaps it is practically valuable to not differentiate boxed and unboxed numbers here?

Luke

# John-David Dalton (13 years ago)

Yap yap, so thoughts on BuiltinNumberWrapper instead of Type(…)? It would still prevent the global isNaN('foo') confusion. Though Object.is(NaN, Object(NaN)) currently returns false too. Was this just an oversight? I know Object(NaN) is totally edge case but it still has the brand of BultinNumberWrapper and is NaN (boxed).

# Axel Rauschmayer (13 years ago)

Honest question: I have yet to see boxed values in practice. Are there any real use cases?

[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer axel at rauschma.de Home: rauschma.de Blog: 2ality.com

# Mark S. Miller (13 years ago)

On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton <john.david.dalton at gmail.com> wrote:

Yap yap, so thoughts on BuiltinNumberWrapper instead of Type(…)? It would still prevent the global isNaN('foo') confusion. Though Object.is(NaN, Object(NaN)) currently returns false too. Was this just an oversight?

No. Object.is correctly reports that these are different.

# John-David Dalton (13 years ago)

No. Object.is correctly reports that these are different.

Ah yap, I've had my head in lib code for a while. I'm used to the behavior of _.isEqual(3, Object(3)); // => true

but you're right the current behavior of Object.is(3, Object(3)); // false so yap it makes sense that it's that way for NaN and Object(NaN) as well.

# John-David Dalton (13 years ago)

Honest question: I have yet to see boxed values in practice. Are there

any real use cases?

See Modernizr: Modernizr/Modernizr/blob/master/feature-detects/video.js#L23

# Andreas Rossberg (13 years ago)

On 14 December 2012 06:46, John-David Dalton <john.david.dalton at gmail.com> wrote:

Axel Rauschmayer:

Honest question: I have yet to see boxed values in practice. Are there any real use cases?

See Modernizr: Modernizr/Modernizr/blob/master/feature-detects/video.js#L23

I think not. And wrapping bools, like the above piece of code does, is a particularly bad idea, because JS says

(Object(false) ? 1 : 2) === 1

# Sam Tobin-Hochstadt (13 years ago)

On Fri, Dec 14, 2012 at 2:43 AM, Andreas Rossberg <rossberg at google.com> wrote:

On 14 December 2012 06:46, John-David Dalton <john.david.dalton at gmail.com> wrote:

Axel Rauschmayer:

Honest question: I have yet to see boxed values in practice. Are there any real use cases?

See Modernizr: Modernizr/Modernizr/blob/master/feature-detects/video.js#L23

I think not. And wrapping bools, like the above piece of code does, is a particularly bad idea, because JS says

(Object(false) ? 1 : 2) === 1

Fortunately, I think that bit of code never returns Object(false), because the if fails first, and just plain false is returned.

Really, since objects are truthy, new Boolean(bool) there could be replaced with {}. Or, the whole body of the if could just be an object literal.

# Allen Wirfs-Brock (13 years ago)

No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. The definitiveness of the test would be lost if other values such a Number wrapper instance also returned true when passed as the argument for Number.isNaN.

Arguably, the Type test in the draft is redundant, but may be clarifying.

If you wanted to test for NaN-ness of either Number values or Number wrappers then the appropriate thing would be to make isNaN an method of Number.prototype.

# John-David Dalton (13 years ago)

No, the whole point of Number.isNaN is to provide a definitively test

for NaN number values which cannot be tested for in the usual way using ===.

Wat? This seems to be a good reason to allow Object(NaN) and use the NumberWrapper brand as it cannot be tested via the normal way of myNaN !== myNaN.

# Nathan Wall (13 years ago)

Wat? This seems to be a good reason to allow Object(NaN) and use the  NumberWrapper brand as it cannot be tested via the normal way of myNaN !== myNaN.

But myNaN === myNaN is true if myNaN = Object(NaN). Testing against the object is different. Nothing breaks.

var myNaN = Object(NaN);     [ 1, 3, myNaN ].indexOf(myNaN); // => 2

Works as expected. The only problem which occurs is when you're working with primitive NaN, in which case the only existing good ways to test for it are x !== x and typeof x == 'number' && isNaN(x). The purpose of Number.isNaN is to provide a way to test this case which is easier to read and understand. Note that if x = Object(NaN) both of these tests fail.

Nathan

# John-David Dalton (13 years ago)

But myNaN === myNaN is true if myNaN = Object(NaN).

That's my point. Normally testing for NaN can be done via myNaN !== myNaN but Object(NaN) throws a wrench in that. It would be great if there was 1 function that was able to detect NaN, instead of having libs step up and do it.

# Mark S. Miller (13 years ago)

EcmaScript koan:

NaN is NotANumber. NaN is a number. Object(NaN) is not a number. Thus, Object(NaN) isn't NotANumber.

# Brandon Benvie (13 years ago)

That is deep.

# Brendan Eich (13 years ago)

John-David Dalton wrote:

But myNaN === myNaN is true if myNaN = Object(NaN).

That's my point. Normally testing for NaN can be done via myNaN !== myNaN but Object(NaN) throws a wrench in that. It would be great if there was 1 function that was able to detect NaN, instead of having libs step up and do it.

Why? Who wraps NaN? Your modernizr true-wrapping Boolean example is both a WTFJS moment, easily avoided by using a truthy object as Sam pointed out, and nothing to do with NaN.

# Nathan Wall (13 years ago)

On another note, I do sort of wonder why Number.isNaN is coming into the language now at the same time as the is operator and Object.is.  It seems teaching people (and getting them to remember long-term) the nuances of isNaN and Number.isNaN will be more difficult than just teaching people to use x is NaN in ES6 or Object.is(x, NaN) in an ES3/5 + ES6 shims environment. There's not an isNull or isUndefined. The only reason isNaN was needed was because === didn't work with NaN, but is does.

Nathan

# Domenic Denicola (13 years ago)

From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Nathan Wall [nathan.wall at live.com] Sent: Friday, December 14, 2012 13:34

On another note, I do sort of wonder why Number.isNaN is coming into the language now at the same time as the is operator and Object.is. It seems teaching people (and getting them to remember long-term) the nuances of isNaN and Number.isNaN will be more difficult than just teaching people to use x is NaN in ES6 or Object.is(x, NaN) in an ES3/5 + ES6 shims environment.

is operator is dead :( :( :(

(Someone want to find a link to the minutes that killed it? I keep having to correct people on this.)

There's not an isNull or isUndefined. The only reason isNaN was needed was because === didn't work with NaN, but is does.

This is pretty reasonable, actually. The only argument I can see is that array.filter(Number.isNaN) is shorter than array.filter(x => Object.is(x, NaN)).

# John-David Dalton (13 years ago)

Bendan Eich wrote:

Your modernizr true-wrapping Boolean example is both a WTFJS moment,

easily avoided by using a truthy object as Sam pointed out, and nothing to do with NaN.

The Modernizr example was in response to Axel's request for an example of boxed values being used in real world projects. I love how the thread got sidetracked by that one ;D

Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have isXyz methods or equivalents that equate boxed and unboxed values as similar: For example: Underscore _.isString('hi') and _.isString(Object('hi')) both return true also _.isEqual('hi', Object('hi')) returns true MooTools typeOf('hi') and typeOf(Object('hi')) both return 'string' Prototype Object.isString('hi') and Object.isString(Object('hi')) both return true jQuery $.type('hi') and $.type(Object('hi')) both return 'string' Dojo dojo.isString('hi') and dojo.isString(Object('hi')) return true

Object(NaN) is edge case, but lots of things in the spec are edge (-0 anyone). Because the majority of libs treat boxed and unboxed alike in their isXyz I think the spec should follow.

# Nathan Wall (13 years ago)

On another note, I do sort of wonder why Number.isNaN is coming into the language now at the same time as the is operator and Object.is. It seems teaching people (and getting them to remember long-term) the nuances of isNaN and Number.isNaN will be more difficult than just teaching people to use x is NaN in ES6 or Object.is(x, NaN) in an ES3/5 + ES6 shims environment.

is operator is dead :( :( :(

That is sad indeed :(

Nathan

# Allen Wirfs-Brock (13 years ago)

On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote:

From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Nathan Wall [nathan.wall at live.com] Sent: Friday, December 14, 2012 13:34

On another note, I do sort of wonder why Number.isNaN is coming into the language now at the same time as the is operator and Object.is. It seems teaching people (and getting them to remember long-term) the nuances of isNaN and Number.isNaN will be more difficult than just teaching people to use x is NaN in ES6 or Object.is(x, NaN) in an ES3/5 + ES6 shims environment.

is operator is dead :( :( :(

(Someone want to find a link to the minutes that killed it? I keep having to correct people on this.)

I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds.

BTW, I think there are probably other related issues that need to be discussed/resolved at that level. For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available.

# Brandon Benvie (13 years ago)

Speaking of SameValue, it's unnecessary in many/most of the places it's used in the spec. Like in IsEquivelentDescriptor the only comparison that needs to use SameValue is comparing the [[Value]] field.

# Brendan Eich (13 years ago)

Domenic Denicola wrote:

From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Nathan Wall [nathan.wall at live.com] Sent: Friday, December 14, 2012 13:34

On another note, I do sort of wonder why Number.isNaN is coming into the language now at the same time as the is operator and Object.is. It seems teaching people (and getting them to remember long-term) the nuances of isNaN and Number.isNaN will be more difficult than just teaching people to use x is NaN in ES6 or Object.is(x, NaN) in an ES3/5 + ES6 shims environment.

is operator is dead :( :( :(

Restricted productions creating new operators may be at risk (Allen's right, we haven't had an orderly decision in TC39 on this point), but Object.is or Object.isSameValue is definitely not dead.

Allen's right too that we have some disagreement on the use of SameValue under the hood in Map and Set.

# John-David Dalton (13 years ago)

I apologize for the duplicate post, but I think my reply got lost in its formatting.

The Modernizr example was in response to Axel's request for an example of boxed values being used in real world projects.

Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have isXyz methods or equivalents that treat boxed and unboxed values as like: For example: Underscore _.isString('hi') and _.isString(Object('hi')) both return true also _.isEqual('hi', Object('hi')) returns true MooTools typeOf('hi') and typeOf(Object('hi')) both return 'string' Prototype Object.isString('hi') and Object.isString(Object('hi')) both return true jQuery $.type('hi') and $.type(Object('hi')) both return 'string' Dojo dojo.isString('hi') and dojo.isString(Object('hi')) return true

Object(NaN) is edge case, but lots of things in the spec are edge (-0 anyone). Because the majority of libs treat boxed and unboxed the same in their isXyz I think it's natural for the spec to follow in the case of Number.isNaN.

Thanks,

# Brendan Eich (13 years ago)

This boxed-primitive equation is a sore point, and perhaps some API should be standardized, but Number.isNaN is not that API. That's point #1, please ack it: we must have a predicate that applies only to true NaN primitives.

Point #2 is that we haven't heard the demand for such APIs until now. That means no ES6 late exception-granting, and for a Harmony strawman (ES7 or later) we would need to study the use-cases and exactly API details more closely. Mostly the use-cases, to see whether something important happens in the context of a given library or its "folkways" that won't -- or should not -- happen in the standardized core language.

Not all libraries have cowpaths that we want to pave. For one thing, libraries conflict. For another, some have design flaws.

# Rick Waldron (13 years ago)

On Fri, Dec 14, 2012 at 2:02 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote:

From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Nathan Wall [nathan.wall at live.com]

Sent: Friday, December 14, 2012 13:34

On another note, I do sort of wonder why Number.isNaN is coming into the language now at the same time as the is operator and Object.is. It seems teaching people (and getting them to remember long-term) the nuances of isNaN and Number.isNaN will be more difficult than just teaching people to use x is NaN in ES6 or Object.is(x, NaN) in an ES3/5 + ES6 shims environment.

is operator is dead :( :( :(

(Someone want to find a link to the minutes that killed it? I keep having to correct people on this.)

I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds.

Confirmed. There is no such discussion on record from a TC39 meeting. Someone said out loud at the last meeting but it never made it to the agenda. I will formally add it to the agenda for January

Rick

BTW, I think there are probably other related issues that need to be discussed/resolved at that level. For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available.

ps. These too.

# Olov Lassus (13 years ago)

2012/12/14 Allen Wirfs-Brock <allen at wirfs-brock.com>

BTW, I think there are probably other related issues that need to be discussed/resolved at that level. For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available.

I'm happy to read that the unintentional dual zeroes issue is being considered by committee members. My attempt to raise this issue two weeks back ("Object.is(0,-0) and its data structures implications < esdiscuss/2012-December/026794>)

didn't generate any public responses, however multiple people responded privately about it.

# gaz Heyes (13 years ago)

On 14 December 2012 16:39, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. The definitiveness of the test would be lost if other values such a Number wrapper instance also returned true when passed as the argument for Number.isNaN.

Why is it needed? Can't we just simply do:

function isReallyNaN(o) { return o!=o&&isNaN(o); }

I don't get the point of detecting Object(NaN) since it's type is an object not number.

# David Bruant (13 years ago)

Le 18/12/2012 14:43, gaz Heyes a écrit :

On 14 December 2012 16:39, Allen Wirfs-Brock <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:

No,  the whole point of Number.isNaN is to provide a definitively
test for NaN number values which  cannot be tested for in the
usual way using ===.   The definitiveness of the test would be
lost if other values such a Number wrapper instance also returned
true when passed as the argument for Number.isNaN.

Why is it needed?

If anything, to explain devs that isNaN is broken and they should move to Number.isNaN.

Can't we just simply do:

function isReallyNaN(o) { return o!=o&&isNaN(o); } "o!=o" will be enough I think. You've got a polyfill :-)