Transcript from the "Numbers" Lesson
[00:00:25] We make numbers with number literals. All these number literals refer to the same object.
[00:00:44] The problem is that the one number type we have is the wrong one. It's based on 64-bit binary floating point from the IEEE-754 standard which is strangely called double in Java and other languages. Anybody care to know why it's called double? Why they picked such a silly name?
[00:01:03] It's something that comes from Fortran. Fortran had integer and real and later they added double precision, which was two reals put together in order to give you more precision. And C took Fortran's double precision and shortened it to double. And everyone else has been using double ever since then.
[00:01:30] So we don't have ints and I'm glad we don't have ints cuz I hate ints. Ints have some really strange properties. For example, we can have two ints which are both greater than zero. We can add them together and we can get results that are smaller than the original numbers, which is insane and inexcusable, and how can you have any confidence in the correctness and the perfection of your system if it's built on a number type which can do such insanely ridiculous things?
[00:02:49] When the integers get above 9 quadrillion they don't do the crazy wrap around thing that ints do, they just get fuzzy. So if I take a number above 9 quadrillion and add 1 to it, it's like I added 0 to it, which is not good but it's much less bad than what ints do.
[00:03:36] And binary floating point cannot accurately represent most of the decimal fractions. It can only approximate them, but it approximates them with infinite repeating bit patterns, but we're not allowed to have infinitely long numbers. And so they truncate, and so every number is gonna be slightly wrong. Which is only a problem if you're living on a planet that uses the decimal system.
[00:04:03] But on such a planet, you're counting people's money using this. When you're adding people's money, they have a reasonable expectation you're gonna get the right sum. And we're not guaranteed to get the right sum with binary floating point, which is a huge problem.
>> Douglas Crockford: Numbers are objects, and so numbers have methods.
[00:04:26] You don't have to box them in order to get object behavior. Every number is already an object. Every number inherits from number.prototype. So if we wanted to add new methods to numbers, we can do that by adding them to number.prototype. This is not something that applications should ever do, but it is a useful thing for libraries to do, and in fact this is how we evolve the language.
[00:05:47] That didn't happen because Moore's Law kept cranking on memory capacity so that turned out not to have been a good strategy. But it wouldn't have worked anyway because you'd be throwing away essential things like floor. There's no good way to get the integer part of a number if you get rid of the floor function so it couldn't have worked.
[00:06:11] There are also some constants stored in the math object as well. So, one of the worst, or one of the things that we get from the IEEE format is something called NaN, which stands for Not a Number. It's the result of confusing or erroneous operations. For example, if you're trying to divide zero by zero the result is NaN.
>> Douglas Crockford: The thing I hate about NaN is that NaN is not equal to anything including NaN, so NaN equal NaN is false. Which bugs the hell out of me and even worse than that is that NaN not equal NaN is true. Which I hate even more. So if you want to find out if something is NaN, there is a global isNaN function.
[00:07:15] And you can pass NaN to it and it will return true, which is good. Unfortunately, isNaN also does type coercion. So if you pass it a string like hello world, it'll try to convert the string into a number. The number that hello world turns into is NaN, so hello world is NaN, which is not true.
>> Douglas Crockford: So ever since Fortran, we've been writing statements that look like this, x = x + 1, which is mathematical nonsense. So ALGOL got this right. ALGOL came up with an assignment operator so this didn't look so ridiculous, and BCPL did the same thing as ALGOL which got it right.
[00:07:57] Unfortunately Thompson liked this better, and so we reverted back to it and we have not evolved away from this since. So we're stuck with this and it looks crazy, right? Because it looks like an equation but there's no value of x which equals x + 1 right. Except it turns out if you're using binary floating point, there's a value called infinity.
[00:08:51] In fact that is true for every number above 9 quadrillion. So there's a lot of values for which this holds.
>> Douglas Crockford: But not NaN. Even though NaN plus one is NaN, NaN is not equal to NaN. So I hate that and NaN, I hate that even more.