Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


JavaScript: Playing the Numbers Game : Page 3

Built-in type-conversion in JavaScript makes using numbers so easy that developers rarely even think about using them. Surely that simplicity isn't as perfect as it seems! Just how good is the number support in JavaScript anyway? In this article you'll explore the edges of the world of numbers in JavaScript.

Three Number Formats: JavaScript Number Implementation
JavaScript has a second number standard at work, a common format used in many computer languages called 32-bit twos-compliment, or in C typically just int. This is a 4 octet (4 byte) value used to store small integers with no error. Although you probably benefit from this representation, you can't declare it yourself in JavaScript. It's hidden.

You can store JavaScript numbers in three ways: as decimal content of a string, as an IEEE double precision floating point, or as an integer.

Why does JavaScript have a hidden int-like type? Three reasons:
  1. For bit operations such as or (|) and shift (>>).
  2. For array use
  3. For accuracy
Consider arrays. The ECMAScript standard for JavaScript allows 4294967295 array elements per array—that's one less than 32 bits can hold. The remaining one is used for the length value. When you specify an array index, the JavaScript interpreter decides if the variable item holds a 32 bit integer or not.

var arr = []; var item = 2; arr[item] = 5;

If so, then the third statement is equivalent to:

arr[2] = 5;

But if item looks like a floating point value (or something other than a number), then it is equivalent to:

arr["2"] = 5;

This can confuse you greatly. It appears to allow negative and partial indices, like arr[-6] and arr[2.35]. In fact, these unusual indices are converted to strings. Listing 2 (view output) shows non-integers being silently converted to strings but looking like numeric indices.

The last few lines of Listing 2 illustrate what happens if you forget this is an illusion. The array slot at index also11 initially holds 1.1. The code takes the twentieth root and raises the result back to the twentieth power, which should return 1.1 again. But the tiny errors in floating point arithmetic add up and 1.100019—not 1.1—is the result. It is no use using this to recall the 1.1 array element, because as an index it refers to an entirely different array member, arr[1.100019]. Be sure your array indices never take part in floating-point calculations.

As well as array indices, there are accuracy needs for integer values. Listing 3 (view output) shows what can happen if a for loop increments too many times by a real value.

You don't want to deal with this every time you construct a loop. Fortunately, the JavaScript interpreter has a preference for integers. If the interpreter spots a new number, it will first try reading the number as an integer. If that's possible, then it stores the number as a 31 bit integer, not as a 64 bit IEEE 754. Yes, that's 31 bits, not 32 bits. If the number cant be read as an integer or it won't fit in 31 bits, then it is stored in 64 bit IEEE 754. Similar logic applies to all calculations.

Numbers can get into scripts from many places in the browser. XML, XHTML, DOM, and CSS standards all provide places where numbers creep into scripts. In all cases, such numbers end up as String or Number types. In the latter case they may be stored as integers. But those other standards also allow very long number literals, which JavaScript will truncate to fit the Number type if necessary.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date