This is some serious amateur hour. The most glaring problem is this: > There are 255 possible representations of zero. They are all considered to be equal. Th

This is some serious amateur hour. The most glaring problem is this: > There are 255 possible representations of zero. They are all considered to be equal. There are also 255 representations of almost all representable numbers. For example, 10 is 1 x 10^1 or 10 x 10^0 – or any one of 253 other representations. Aside from the fact that you're wasting an entire byte of your representation, this means that you can't check for equality by comparing bits. Take a look at the the assembly implementation of equality checking: https://github.com/douglascrockford/DEC64/blob/master/dec64.asm#L1068-L1105 https://github.com/douglascrockford/DEC64/blob/master/dec64.... The "fast path" (which is ten instruction) applies only if the two numbers have the same exponent. The slow path calls subtraction and returns true if the result is zero. The implementation of subtraction falls back on yet another function, which jumps around even more: https://github.com/douglascrockford/DEC64/blob/master/dec64.asm#L631-L664 https://github.com/douglascrockford/DEC64/blob/master/dec64.... For most comparisons (no, comparing numbers with the same exponent is not the norm) it will take around FIFTY INSTRUCTIONS TO CHECK IF TWO NUMBERS ARE EQUAL OR NOT. Many of these instructions are branches – and inherently unpredictable ones at that, which means that pipeline stalls will be normal. All told, I would expect equality comparison to typically take around 100 cycles. It's not even clear to me that this implementation is correct because at the end of the subtraction, it compares the result to the zero word, which is only one of the 255 possible representations of zero. The lack of a single canonical representation of any number is just as bad for other arithmetic operations and comparisons, if not worse. Crockfords bugaboo with IEEE 754 floating-point is bizarre, verging on pathological. He devoted a section in his book "JavaScript: The Good Parts" to a rather ill-informed rant against it. When I saw him give a talk, I took the opportunity to ask him what he thought would be a good alternative to using IEEE 754. His answer was – I shit you not – "I don't know". Apparently this proposal is the answer. No thanks, I will stick with the amazingly successful, ubiquitous, thoroughly thought out standard, that was spearheaded by William Kahan – one of the greatest numerical analysts of all time. Anyone who doesn't appreciate how good we have it with IEEE 754 should really read "An Interview with the Old Man of Floating-Point" [1], in which Kahan relates just how messed up this stuff was before the IEEE 754 standardization process. It should also be noted that there already is an IEEE standard for decimal floating-point [2], which is not only infinitely better thought out than this drivel, but also is already implemented in hardware on many systems sold by IBM and others, specifically for financial applications. [1] http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.ht... [2] http://en.wikipedia.org/wiki/Decimal64_floating-point_format http://en.wikipedia.org/wiki/Decimal64_floating-point_format