[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

null and NaN

ram

6/2/2015 5:29:00 PM

Sometimes, it has been questioned whether it was wise to
implement

typeof null
"object"

. However, I just became aware that this is echoing a
similar case:

typeof NaN
"number"

. NaN says its »Not a Number«, yet typeof says it is a
number!

It seems that sometimes people want an in »in band«
»non-value« to mark to lack of a »real value«. The value
must be »in band«, that is, it must be allowed where a value
is expected. Yet, it must then contain the information that
it is /not/ a real value. Similar with »NULL« in SQL or
»void« as a »type« in C.

A clean solution would be to always distinguish between
entities and meta-entities. For example: »0, 1, 2, ...« are
numbers, and »NaN, 0, 1, 2, ...« are meta-numbers. (This
distinction does not have to be implemented, but could be
used in descriptions of a programming language.) But people
also often do not want to use too many different words, even
if they have to pay the price of actual contradictions.

In JavaScript, we could even have:

meta-meta-objects
/ / / / / \
/ \
/ \
/ \
undefined meta-objects
/ / / / / \
/ \
/ \
/ \
null objects

17 Answers

Thomas 'PointedEars' Lahn

6/2/2015 8:51:00 PM

0

Stefan Ram wrote:

> Sometimes, it has been questioned whether it was wise to
> implement
>
> typeof null
> "object"

Cite evidence.

> . However, I just became aware that this is echoing a
> similar case:
>
> typeof NaN
> "number"
>
> . NaN says its »Not a Number«, yet typeof says it is a
> number!

It is a simple consequence of the Number type implementing most of the
IEEE 754 Specification for double-precision floating-point values.

As much too often before, your almost unreadable ramblings are
unsubstantiated, unsubstiantal, and ultimately pointless. I wished you
would stop them and actually start learning things.

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

Erwin Moller

6/3/2015 3:23:00 PM

0

On 6/2/2015 7:28 PM, Stefan Ram wrote:
> Sometimes, it has been questioned whether it was wise to
> implement
>
> typeof null
> "object"
>
> . However, I just became aware that this is echoing a
> similar case:
>
> typeof NaN
> "number"
>
> . NaN says its »Not a Number«, yet typeof says it is a
> number!


Do you think this is a problem?
Or unclear?
What is exactly your point? Do you think this is a shortcoming in
ECMAScript?

I never heard anybody complain about this (but it can be confusing to
newcomers).

Regards,
Erwin Moller

PS: You forgot:
console.log (typeof undefined);
which is....(drumrolls): undefined!



--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

JR

6/5/2015 3:56:00 AM

0

On 02/06/2015 14:28, Stefan Ram wrote:
> Sometimes, it has been questioned whether it was wise to
> implement
>
> typeof null
> "object"
>

It happens due to a bug in the first version of JS [1].

> . However, I just became aware that this is echoing a
> similar case:
>
> typeof NaN
> "number"
>
> . NaN says its »Not a Number«, yet typeof says it is a
> number!

This case is something else. I'd rather prefer the joke: "NaN stands for
Not a NaN" [2].

[1] <http://www.2ality.com/2013/10/typeof-nul...
[2]
<http://ariya.ofilabs.com/2014/05/the-curious-case-of-javascript-na...

--
Joao Rodrigues

Robert Heller

6/5/2015 11:58:00 AM

0

At Fri, 05 Jun 2015 00:55:31 -0300 Joao Rodrigues <groups_jr-1@yahoo.com.br> wrote:

>
> On 02/06/2015 14:28, Stefan Ram wrote:
> > Sometimes, it has been questioned whether it was wise to
> > implement
> >
> > typeof null
> > "object"
> >
>
> It happens due to a bug in the first version of JS [1].
>
> > . However, I just became aware that this is echoing a
> > similar case:
> >
> > typeof NaN
> > "number"
> >
> > . NaN says its »Not a Number«, yet typeof says it is a
> > number!
>
> This case is something else. I'd rather prefer the joke: "NaN stands for
> Not a NaN" [2].

'NaN' is a "feature" of IEEE floating point numbers. Unlike integers, where
every possible bit pattern represents a possible integer value (there are 2^32
bit patterns with a 32-bit value and there are in fact 2^32 possible integers
that can be represented in a 32-bit integer variable), *some* of the
bit patterns that are possible do NOT represent a legal floating point
value. That is, a 32-bit floating point number DOES NOT have 2^32 possible
legal values. Also, with floating point arithmetic, there are operations that
cannot have a 'legal' result (the result is mathematically 'undefined' for
various reasons). For arithmetic operations that result in undefined values
you get NaN. Note this is different fron INF (which is a special bit pattern
in the IEEE floating point representation).

JavaScript is a *weakly* typed language. Normally that means that variables
don't have declared types, but instead the *value* of variables have an
associated type, which can change. What is happening here is that the 'object'
is 'typed' as a floating point number (a number in the general sense) because
it is the result of some floating point math operation, like Math.sqrt(-1),
but the result is not a representable floating point value, like the square
root of -1. If one was programming in C, C++, or Java and declared a variable:

float i;

and then computed an floating point value that was not a legal floating point
number,

i = sqrt(-1.0);

the variable x would still be a float, and its value would be NaN, since
variable types cannot change in a strongly typed language like C, C++, or
Java. (FORTRAN cleverly solves this specific problem by having a complex type
and makes no attempt to actually represent the sqrt of -1, but simply assumes
it and provides a library of functions that dance around the irrational
values.)



>
> [1] <http://www.2ality.com/2013/10/typeof-nul...
> [2]
> <http://ariya.ofilabs.com/2014/05/the-curious-case-of-javascript-na...
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.dee... -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

Thomas 'PointedEars' Lahn

6/6/2015 6:39:00 AM

0

Joao Rodrigues wrote:

> On 02/06/2015 14:28, Stefan Ram wrote:
>> Sometimes, it has been questioned whether it was wise to
>> implement
>>
>> typeof null
>> "object"
>
> It happens due to a bug in the first version of JS [1].
>
> [1] <http://www.2ality.com/2013/10/typeof-nul...

Again, your research is flawed. You are still lacking the healthy
scepticism that is the mark of a good scientist. What you are citing is
*unsubstantiated*, *non-authoritative* *speculation*; likely a historianâ??s
fallacy. [1]

It could be a bug, but it could also have been *intentional*. Only Brendan
Eich, sole author of the first JavaScript version [2], can say for sure.

However, that the ECMAScript Language Specification [3], the standard which
is originally based on JavaScript 1.1 and JScript 1.0 (ibid.), says:

,-[1st edition]
|
| 4.3.11 Null
|
| Null is a primitive value that represents the null, empty, or nonexistent
| reference
^^^^^^^^^

,-[2nd Edition]
|
| 4.3.11 Null value
|
| The null value is a primitive value that represents the null, empty, or
| non-existent reference.
^^^^^^^^^

,-[Edition 3]
|
| 4.3.11 Null Value
|
| The null value is a primitive value that represents the null, empty, or
| non-existent reference.
^^^^^^^^^

,-[5th Edition]
|
| 4.3.11
|
| null value
| primitive value that represents the intentional absence of any
| object value.
^^^^^^

,-[5.1 Edition]
|
| 4.3.11 null value
|
| primitive value that represents the intentional absence
^^^^^^^^^^^^^^^^^^^
| of any object value
^^^^^

,-[6th Edition Final draft [4]]
|
| 4.3.12
|
| null value
| primitive value that represents the intentional absence of any
| object value
^^^^^^

indicates that it is _not_ a bug. â??nullâ? *has* something to do with objects
that other primitive values have not.

Whether it was a good idea to design the â??typeofâ? operator that way, and
make it hard to tell â??nullâ? from a valid object reference is a *separate*
issue. As Brendan Eich freely admits in hindsight, he made several *design*
errors in the creation of JavaScript, not least because the new language had
to be available soon. The JavaScript type system was one of them. [5]
(Employers, take this as a lesson: Rushing software developers for quick
profit, not allowing to let them think things through and to discuss them
with their peers, almost invariably leads to bad design decisions that bite
you even decades later. BTST.)

____________
[1] <http://en.wikipedia.org/wiki/Historian%27s_f...
[2] Krill, Paul (2008). â??JavaScript creator ponders past, futureâ?.
In: â??InfoWorld. Developer World.â?
<http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-futu...
[3] <http://www.ecma-international.org/publications/standards/Ecma-2...
p.
[4]
<http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:ecma-262_6th_edition_final_draft_-04-14-...
[5] <https://brendaneich.com/2005/11/js2-design-...

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

JR

6/7/2015 2:16:00 AM

0

On 06/06/15 03:39, Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:
>
>> On 02/06/2015 14:28, Stefan Ram wrote:
>>> Sometimes, it has been questioned whether it was wise to
>>> implement
>>>
>>> typeof null
>>> "object"
>>
>> It happens due to a bug in the first version of JS [1].
>>
>> [1] <http://www.2ality.com/2013/10/typeof-nul...
>
> Again, your research is flawed. You are still lacking the healthy
> scepticism that is the mark of a good scientist. What you are citing is
> *unsubstantiated*, *non-authoritative* *speculation*; likely a historianâ??s
> fallacy. [1]

Nonsense.

>
> It could be a bug, but it could also have been *intentional*. Only Brendan
> Eich, sole author of the first JavaScript version [2], can say for sure.

Yes, Brendan once considered the need to fix typeof [1], but rejected
that proposal stating: "I think it is too late to fix typeof. The change
proposed for typeof null will break existing code."

[1] <http://wiki.ecmascript.org/doku.php?id=proposals:...

In another discussion [2], he wrote: "In general, typeof seems like a
mess that will be hard to reform sensibly."

[2] <http://wiki.ecmascript.org/doku.php?id=discussion:...

>
> However, that the ECMAScript Language Specification [3], the standard which
> is originally based on JavaScript 1.1 and JScript 1.0 (ibid.), says:
>
> ,-[1st edition]
> |
> | 4.3.11 Null
> |
> | Null is a primitive value that represents the null, empty, or nonexistent
> | reference
> ^^^^^^^^^
>
> ,-[2nd Edition]
> |
> | 4.3.11 Null value
> |
> | The null value is a primitive value that represents the null, empty, or
> | non-existent reference.
> ^^^^^^^^^
>
> ,-[Edition 3]
> |
> | 4.3.11 Null Value
> |
> | The null value is a primitive value that represents the null, empty, or
> | non-existent reference.
> ^^^^^^^^^
>
> ,-[5th Edition]
> |
> | 4.3.11
> |
> | null value
> | primitive value that represents the intentional absence of any
> | object value.
> ^^^^^^
>
> ,-[5.1 Edition]
> |
> | 4.3.11 null value
> |
> | primitive value that represents the intentional absence
> ^^^^^^^^^^^^^^^^^^^
> | of any object value
> ^^^^^
>
> ,-[6th Edition Final draft [4]]
> |
> | 4.3.12
> |
> | null value
> | primitive value that represents the intentional absence of any
> | object value
> ^^^^^^
>
> indicates that it is _not_ a bug. â??nullâ? *has* something to do with objects
> that other primitive values have not.

These references only prove that JS was prematurely standardized, making
necessary corrections more difficult to be implemented.


--
Joao Rodrigues

Thomas 'PointedEars' Lahn

6/7/2015 7:59:00 AM

0

Joao Rodrigues wrote:

> On 06/06/15 03:39, Thomas 'PointedEars' Lahn wrote:
>> Joao Rodrigues wrote:
>>> [typeof null === "object] happens due to a bug in the first version of
>>> JS [1].
>>>
>>> [1] <http://www.2ality.com/2013/10/typeof-nul...
>> [â?¦]
>> It could be a bug, but it could also have been *intentional*. Only
>> Brendan Eich, sole author of the first JavaScript version [2], can say
>> for sure.
>
> Yes, Brendan once considered the need to fix typeof [1], but rejected
> that proposal stating: "I think it is too late to fix typeof. The change
> proposed for typeof null will break existing code."
>
> [1] <http://wiki.ecmascript.org/doku.php?id=proposals:...
>
> In another discussion [2], he wrote: "In general, typeof seems like a
> mess that will be hard to reform sensibly."
>
> [2] <http://wiki.ecmascript.org/doku.php?id=discussion:...

AISB, in hindsight Eich admitted *design* errors. That does not prove
that it was a *bug caused by the code itself* as claimed by Dr. Rauschmeyer,
and you, based only on his speculation. He committed a historianâ??s fallacy,
and you an /ipse dixit/ one.

>> However, that the ECMAScript Language Specification [3] [â?¦] says:
>> [â?¦]
>> indicates that it is _not_ a bug. â??nullâ? *has* something to do with
>> objects that other primitive values have not.
>
> These references only prove that JS was prematurely standardized, making
> necessary corrections more difficult to be implemented.

Assumption, not evidence.

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

Steven D'Aprano

6/7/2015 8:48:00 AM

0

On Fri, 5 Jun 2015 09:57 pm, Robert Heller wrote:

> 'NaN' is a "feature" of IEEE floating point numbers.

No need for the scare-quotes around feature, it actually is a feature. The
IEEE-754 standard brought order to chaos in the numerical computing world,
and NANs were a carefully thought out part of that standard.


> Unlike integers,
> where every possible bit pattern represents a possible integer value
> (there are 2^32 bit patterns with a 32-bit value and there are in fact
> 2^32 possible integers that can be represented in a 32-bit integer
> variable), *some* of the bit patterns that are possible do NOT represent a
> legal floating point
> value. That is, a 32-bit floating point number DOES NOT have 2^32
> possible
> legal values.

I wouldn't put it like that. NANs are certainly "legal floating point
values", they're just not numbers.

Out of the 2**32 bit patterns available in a 32-bit float, there are:

* two bit patterns which represent zero
* two bit patterns which represent a result which has overflowed,
or an actual mathematically infinite result;
* some large number of bit patterns which represent numbers in
floating point style;
* and some number of bit patterns which represent error conditions
or results of mathematically undefined calculations.

making a total of 2**32 valid floats in total (but somewhat less than that
represent actual numbers).


> Also, with floating point arithmetic, there are operations
> that cannot have a 'legal' result (the result is mathematically
> 'undefined' for
> various reasons). For arithmetic operations that result in undefined
> values
> you get NaN. Note this is different fron INF (which is a special bit
> pattern in the IEEE floating point representation).

I agree with this paragraph.

But not the following:

> JavaScript is a *weakly* typed language. Normally that means that
> variables don't have declared types, but instead the *value* of variables
> have an associated type, which can change.

No, you are thinking about the difference between static and dynamic typing.

Static typing: variables themselves have types. E.g. "x" is a float, even if
you haven't assigned a value to x yet.

Dynamic typing: variables are just names, and are not associated with a
type. The name "x" doesn't have a type, but the value assigned to x does:
if you assign x = 1.234, then (the value of) x is a float, and if you
assign x = "foo", then (the value of) x is a string.

Untyped: Usually refers to something like assembly language, where there are
no types at all (except in the programmer's own mind).

There are degrees of typing strength. A strongly typed language enforces
type rules strictly, with no automatic or implied coercions. A weakly typed
language enforces type rules in a lenient manner, with many automatic or
implied coercions. People can argue about the boundaries, but I think most
people will use automatic string conversions as the dividing line. If a
language automatically converts strings to numbers when doing arithmetic,
then the language is weakly typed; if not, then it's strongly typed.

Static/Dynamic, versus Weak/Strong, are independent.

For more, see http://cdsmith.wordpress.com/2011/01/09/an-old-artic...


> What is happening here is that
> the 'object' is 'typed' as a floating point number (a number in the
> general sense) because it is the result of some floating point math
> operation, like Math.sqrt(-1), but the result is not a representable
> floating point value, like the square root of -1.

I don't think that's actually what is happening. The OP wrote:

typeof NaN

I think that what happens is that NaN is a literal which evaluates to a
floating point number, just like 1.5 evaluates to the floating point 1.5,
except that NaN returns one of those bit patterns that don't represent a
number. I don't think that there are any objects involved here.

I welcome correction if I am wrong.



> If one was programming
> in C, C++, or Java and declared a variable:
>
> float i;
>
> and then computed an floating point value that was not a legal floating
> point number,
>
> i = sqrt(-1.0);
>
> the variable x would still be a float, and its value would be NaN, since
> variable types cannot change in a strongly typed language like C, C++, or
> Java.

> (FORTRAN cleverly solves this specific problem by having a complex
> type and makes no attempt to actually represent the sqrt of -1, but simply
> assumes it and provides a library of functions that dance around the
> irrational values.)

Fortran is strongly typed like C. If you want to use complex numbers in
Fortran, you have to declare i as a complex number, not a float.



--
Steven

JR

6/8/2015 1:31:00 AM

0

On 07/06/15 04:59, Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:
>
>> On 06/06/15 03:39, Thomas 'PointedEars' Lahn wrote:
>>> Joao Rodrigues wrote:
>>>> [typeof null === "object] happens due to a bug in the first version of
>>>> JS [1].
>>>>
>>>> [1] <http://www.2ality.com/2013/10/typeof-nul...
>>> [â?¦]
>>> It could be a bug, but it could also have been *intentional*. Only
>>> Brendan Eich, sole author of the first JavaScript version [2], can say
>>> for sure.
>>
>> Yes, Brendan once considered the need to fix typeof [1], but rejected
>> that proposal stating: "I think it is too late to fix typeof. The change
>> proposed for typeof null will break existing code."
>>
>> [1] <http://wiki.ecmascript.org/doku.php?id=proposals:...
>>
>> In another discussion [2], he wrote: "In general, typeof seems like a
>> mess that will be hard to reform sensibly."
>>
>> [2] <http://wiki.ecmascript.org/doku.php?id=discussion:...
>
> AISB, in hindsight Eich admitted *design* errors. That does not prove
> that it was a *bug caused by the code itself* as claimed by Dr. Rauschmeyer,
> and you, based only on his speculation. He committed a historianâ??s fallacy,
> and you an /ipse dixit/ one.

typeof null == "object" was considered a bug by Brendan Eich - the
father of JavaScript:

"We have reason to believe typeof null === â??objectâ? *is a bug* that
could bite real content, from our spidering of the web. We have no such
evidence in favor of breaking typeof String === â??functionâ?, and plenty
of reason to fear incompatibility. It might be best to leave typeof
utterly alone and deprecate it, *but Iâ??m still in favor of the null
bug-fix*.

â?? Brendan Eich 2006/03/31 16:34"

<http://wiki.ecmascript.org/doku.php?id=discussion:...

>
>>> However, that the ECMAScript Language Specification [3] [â?¦] says:
>>> [â?¦]
>>> indicates that it is _not_ a bug. â??nullâ? *has* something to do with
>>> objects that other primitive values have not.
>>
>> These references only prove that JS was prematurely standardized, making
>> necessary corrections more difficult to be implemented.
>
> Assumption, not evidence.


Evidence proven at:
<http://wiki.ecmascript.org/doku.php?id=discussion:...

--
Joao Rodrigues

ram

6/9/2015 5:03:00 AM

0

Joao Rodrigues <groups_jr-1@yahoo.com.br> writes:
>typeof null == "object" was considered a bug by Brendan Eich - the
>father of JavaScript:

Brendan Eich also wrote:

»The diktat from upper engineering management
was that the language must "look like Java".«.

And in Java, one also sometimes deems »null« to be an
object. For example, in the class »java.util.Objects«,
there is the method

static boolean isNull( Object obj )

. And, according to the parameter type and name, you
pass an »object«, and then this method will tell you
whether this »object« is null, or an, er, object.