7 ms·

I've been a JavaScript developer for years and it's a surprise to me that there's a `Number.MAX_SAFE_INTEGER` and `Number.MIN_SAFE_INTEGER`. It seems that I've

I've been a JavaScript developer for years and it's a surprise to me that there's a `Number.MAX_SAFE_INTEGER` and `Number.MIN_SAFE_INTEGER`. It seems that I've never had the use case where I exceeded the maximum or minimum integer count. I figure there's a good amount of JavaScript developers that have the same experience. But good article nonetheless.

partycoder 8y ago
You may also be interested in learning about Number.EPSILON (the floating point epsilon) which is required when dealing with number equality... For example, this is an incorrect way to compare numbers: > 0.1 + 0.2 === 0.3 false This is the proper way to compare numbers: a = 0.1 + 0.2 b = 0.3 > Math.abs(a - b) < Number.EPSILON true This means the difference is smaller than the smallest quantity that can be represented in floating point number, and every JS number is a floating point number. Not knowing about this can cause many issues if you deal with values representing currency.
- strainer 8y ago
  Epsilon is not the smallest quantity that can be represented. Its the smallest amount that can be added to a number between 1 and 2. If its added to 2 the result is 2. We need to add 2 * Number.EPSILON to 2 to add anything. 4 * E to 4, 8 * E to 8, 16 * E to 16 etc. That kind of equality test should be: abs( a-b ) < Number.EPSILON * max( abs(a), abs(b) ) In practice I judge the scale of the quantization noise that may accrue and compare the difference to it. It may also be possible to kind of caste precision away by adding a trick value. eg. a + t == b + t If a and b are positive, that is somewhat similar to: abs( a-b ) < Number.EPSILON * t
  - partycoder 8y ago
    Thanks for pointing it out. A more popular definition is "the smallest number that yields a result different to 1 when added to 1".
    - strainer 8y ago
      Look out - I just now tested those two extra ideas which I added for equality testing and found they dont work. This version of adding a rounding value seems to though: ( a-b + rounder ) == rounder My apologies, be careful out there :)
edf13 8y ago
Badly needed for server side development
jsheard 8y ago
Anyone who's used the Twitter API from Javascript has probably encountered the integer limit, because Tweet IDs are 64-bit values that often exceed MAX_SAFE_INTEGER. Their JSON API works around that limitation by returning IDs as both "id" (a number that may not be representable in Javascript) and "id_str" (the same number in JS-friendly string form).
- hinkley 8y ago
  First Ajax app I worked on had the same problem and for similar reasons. We configured the JSON emitter to turn them into Strings, and back on inbound requests.
- BinaryIdiot 8y ago
  Wow, why would they ever send "id" as a number? Seems like a terrible idea when it doesn't fit in the medium's spec (JSON).
  - bonesss 8y ago
    Just in general: your employee ID is likely a 'number', but it's not a number, it's a unique series of digits.... You don't add employee IDs. You don't multiply them by the current month. You don't group employees in ID based sets, find the ID modulus, and do things. They're not numbers, they are an alphanumeric series that should be unique. And after seeing a hundred systems break when IDs started to overflow the 32 bit max, or struggle to handle a change to guids, or alphanumeric security codes, or a harmonization with another systems IDs, or freak out when their numbers get exposed through a URL and it turns out keeping leading-0 formatting has something to say: ... use a damned string. "00123" and 123 are different. Just use a string.
  - dragonwriter 8y ago
    JSON spec doesn't restrict the range of numbers [0], though it does note that because different platforms that may use JSON have different limitations and IEEE 754 doubles are widely supported, valued that aren't representable as IEEE 754 doubles may have interoperability issues. [0] https://tools.ietf.org/html/rfc8259#section-6 https://tools.ietf.org/html/rfc8259#section-6
ramensea 8y ago
I have run into the issue a few times. I've run into it most frequently when doing binary operations on 64bit numbers. When I first ran into the issue with going over `Number.MAX_SAFE_INTEGER`, it took me a long time to figure out that was the issue. I can imagine this is an especially important advancement for server side JS. Not something I personally care about tho.
hinkley 8y ago
Send 64 bit numbers from the server and you’ll run into trouble sooner or later. If the numbers are random (like IDs) you’ll hit it about every 1000th ID. Solution: IDs are strings not numbers.

partycoder 8y ago

You may also be interested in learning about Number.EPSILON (the floating point epsilon) which is required when dealing with number equality... For example, this is an incorrect way to compare numbers: > 0.1 + 0.2 === 0.3 false This is the proper way to compare numbers: a = 0.1 + 0.2 b = 0.3 > Math.abs(a - b) < Number.EPSILON true This means the difference is smaller than the smallest quantity that can be represented in floating point number, and every JS number is a floating point number. Not knowing about this can cause many issues if you deal with values representing currency.

strainer 8y ago
Epsilon is not the smallest quantity that can be represented. Its the smallest amount that can be added to a number between 1 and 2. If its added to 2 the result is 2. We need to add 2 * Number.EPSILON to 2 to add anything. 4 * E to 4, 8 * E to 8, 16 * E to 16 etc. That kind of equality test should be: abs( a-b ) < Number.EPSILON * max( abs(a), abs(b) ) In practice I judge the scale of the quantization noise that may accrue and compare the difference to it. It may also be possible to kind of caste precision away by adding a trick value. eg. a + t == b + t If a and b are positive, that is somewhat similar to: abs( a-b ) < Number.EPSILON * t
- partycoder 8y ago
  Thanks for pointing it out. A more popular definition is "the smallest number that yields a result different to 1 when added to 1".
  - strainer 8y ago
    Look out - I just now tested those two extra ideas which I added for equality testing and found they dont work. This version of adding a rounding value seems to though: ( a-b + rounder ) == rounder My apologies, be careful out there :)

edf13 8y ago

Badly needed for server side development

jsheard 8y ago

Anyone who's used the Twitter API from Javascript has probably encountered the integer limit, because Tweet IDs are 64-bit values that often exceed MAX_SAFE_INTEGER. Their JSON API works around that limitation by returning IDs as both "id" (a number that may not be representable in Javascript) and "id_str" (the same number in JS-friendly string form).

hinkley 8y ago
First Ajax app I worked on had the same problem and for similar reasons. We configured the JSON emitter to turn them into Strings, and back on inbound requests.
BinaryIdiot 8y ago
Wow, why would they ever send "id" as a number? Seems like a terrible idea when it doesn't fit in the medium's spec (JSON).
- bonesss 8y ago
  Just in general: your employee ID is likely a 'number', but it's not a number, it's a unique series of digits.... You don't add employee IDs. You don't multiply them by the current month. You don't group employees in ID based sets, find the ID modulus, and do things. They're not numbers, they are an alphanumeric series that should be unique. And after seeing a hundred systems break when IDs started to overflow the 32 bit max, or struggle to handle a change to guids, or alphanumeric security codes, or a harmonization with another systems IDs, or freak out when their numbers get exposed through a URL and it turns out keeping leading-0 formatting has something to say: ... use a damned string. "00123" and 123 are different. Just use a string.
- dragonwriter 8y ago
  JSON spec doesn't restrict the range of numbers [0], though it does note that because different platforms that may use JSON have different limitations and IEEE 754 doubles are widely supported, valued that aren't representable as IEEE 754 doubles may have interoperability issues. [0] https://tools.ietf.org/html/rfc8259#section-6 https://tools.ietf.org/html/rfc8259#section-6

ramensea 8y ago

I have run into the issue a few times. I've run into it most frequently when doing binary operations on 64bit numbers. When I first ran into the issue with going over `Number.MAX_SAFE_INTEGER`, it took me a long time to figure out that was the issue. I can imagine this is an especially important advancement for server side JS. Not something I personally care about tho.

hinkley 8y ago

Send 64 bit numbers from the server and you’ll run into trouble sooner or later. If the numbers are random (like IDs) you’ll hit it about every 1000th ID. Solution: IDs are strings not numbers.