> DEC64 is intended to be the only number type in the next generation of application programming languages.<p>Please no. There's a very solid case for integers in programming languages: <i>many</i> places in code call for a number which <i>must</i> be an integer: having the type enforce this is nice: you don't need to check and abort (or floor, or whatever) if someone passes you a non-integer. Basically, anything that does an array index, which is any for loop walking through a memory buffer (which might be an array, a string, a file, the list goes on and on. Anything that can be counted) wants an integer. x[i] where i is not an integer just doesn't make sense: ideally, let a type system enforce that.<p>Granted, of course, that many languages will just truncate a float in an integers context, and so funny stuff does happen (I don't really feel that this is a good thing). (Although interestingly, JS is not one of them.) Personally, I think JS <i>needs</i> an integer type. Especially when you see people start getting into bignum stuff in JS, it gets silly fast, as first you can only store so many bits before floating point loses precision, but even then, even if you have an "integer", JS will find funny ways to shoot you in the foot. For example:<p><pre><code> x | 0 === x
</code></pre>
does not hold true for all integers in JS.
This would benefit from a better comparison with IEEE 754-2008 decimal64; he dismisses it as being too inefficient but I don't see much other discussion about it, which is too bad since at least it's already implemented in hardware on some platforms.<p>Also, it's worth mentioning <a href="http://speleotrove.com/decimal/" rel="nofollow">http://speleotrove.com/decimal/</a> as a great repository of decimal float info. I hope it will be updated with some discussion of this proposed format.
Interesting approach, rather than normalize to 1 it normalizes to the largest whole number. The positives of this are that you don't run into issues with encoding things like .1 that you do in binary (or any repeating binary fraction), the downside is that you lose precision when you have more than 16 digits of precision. And the of course the complaint most folks will throw at it is that it fails differently depending on what 'end' of the number you're losing precision. The largest decimal number you can represent in 56 bits is 72,057,594,927,935 so the largest decimal number you can represent will any digit value is 9,999,999,999,999 (16 digits), and you have "extra" space at the top (0-6).<p>However, to Doug Crockfords credit, the number space it covers is pretty useful for a lot of different things and in scripted languages and other uses that aren't safety related I can see the advantage of an 'fractional integer' type.<p>Edit: Mike Cowlishaw, who is also quite interested in decimal arithmetic has a much deeper treatment here: <a href="http://speleotrove.com/decimal/" rel="nofollow">http://speleotrove.com/decimal/</a>
Instead of being stuck with yet another inaccurate number type for integers, I want to see hardware assisted bigints. Something like:<p>- A value is either a 63 bit signed integer or a pointer to external storage, using one bit to tell which.<p>- One instruction to take two operands, test if either is a pointer, do arithmetic, and test for overflow. Those cases would jump to a previously configured operation table for software helpers.<p>- A bit to distinguish bigint from trap-on-overflow, which would differ only in what the software helper does.<p>- Separate branch predictor for this and normal branches?<p>I don't know much about CPUs, but this doesn't seem unreasonable, and it could eliminate classes of software errors.
"DEC64 is intended to be the only number type in the next generation of application programming languages."<p>FFS, just because the designers of JS couldn't numerically compute their way out of a paper bag doesn't mean that FUTURE languages should be saddled with that mistake.
Where's exp(), log(), sin(), cos()? He did the bare minimum amount of work and left all the interesting functionality out. We have relatively fast ways of dealing with these in IEEE754, but I see no equivalent here.<p>I really don't want to rehash the arguments that applied 30 years ago, as they do today. Decimal floating point is good for some things, but to be considered the "only number type in the next generation of programming languages" is laughable.
<i>It can provide very fast performance on integer values, eliminating the need for a separate int type and avoiding the terrible errors than can result from int truncation.</i><p>What! I do not see how making a float fast on integers should ever eliminate the need for an int type. Ints and Real-approximations like Dec64 are simply different things entirely.<p>It's annoying enough that this happens in Javascript.
From the blog post<p>> DEC64 is a number type. It can precisely represent decimal fractions with 16 decimal places, which makes it well suited to all applications that are concerned with money.<p>From the reference code<p>> Rounding is to the nearest value. Ties are rounded away from zero.<p>Useful wikipedia entry regarding rounding (<a href="http://en.wikipedia.org/wiki/Rounding#Round_half_to_even" rel="nofollow">http://en.wikipedia.org/wiki/Rounding#Round_half_to_even</a>)<p>> This variant of the round-to-nearest method is also called unbiased rounding, convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, odd-even rounding, bankers' rounding, broken rounding, or DDR rounding and is widely used in bookkeeping. This is the default rounding mode used in IEEE 754 computing functions and operators.<p>Rounding towards zero isn't compatible with financial calculations (unless you're performing office space style bank theft), so this should never be used for numeric calculations involving money. I wonder what he was really trying to solve with this since he missed a fairly important aspect of the big picture. That being said, there's no problem statement on his entire website to address what actual problem he was trying to solve, so all we see is a half baked solution for some unknown problem. On the plus side, at least he didn't use the "for Good, not Evil" clause in the license this time.<p>edit: formatting
So is this primarily a performance vs. convenience thing?<p>If both base2 and base10 floating point are implemented in hardware, what makes base10 inherently less efficient?<p>Also, I don't have a good intuition for the difference in what numbers can be exactly represented. I'd love to see this represented visually somehow.<p>Double precision can exactly represent integers up to 2^53, then half of integers between 2^53 and 2^54, then a quarter of integers between 2^54 and 2^55, etc.<p>Dec64 would be able to exactly represent integers up to 2^55, then 1/10th of all integers between 2^55 and 10(2^55), then 1/100th of all integers between 10(2^55) and 100(2^55).<p>So the "holes" are different, so-to-speak. How would this affect accuracy of complicated expressions?
IBM also have a library called decNumber which has decent high level functions as well as 32/64/128 bit types.<p><a href="http://speleotrove.com/decimal/decnumber.html" rel="nofollow">http://speleotrove.com/decimal/decnumber.html</a><p>Have used this for a number of years for financial calculations.
> A later revision of IEEE 754 attempted to remedy this, but the formats it recommended were so inefficient that it has not found much acceptance.<p>The C and C++ standards committees have been drafting decimal support based on IEC 60559:2011 (previously IEEE 754-2008) since its creation.<p>Original C TR: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1312.pdf" rel="nofollow">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1312.pdf</a><p>Latest draft specification: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1781.pdf" rel="nofollow">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1781.pdf</a><p>Original C++ TR: <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf" rel="nofollow">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n284...</a><p>Update proposal for C++11: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html" rel="nofollow">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n340...</a><p>GCC, ICC, IBM C, and HP C have adopted the extension. Links to the respective software implementations can be found under "cost of implementation" in the C++11 proposal above, except GCC, which uses IBM's library. Its support is documented here: <a href="http://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html" rel="nofollow">http://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html</a><p>Meanwhile, hardware support so far exists in POWER6 and 7 and SPARC64 X.<p>This may seem like slow adoption if you aren't accustomed to the glacial pace of standards processes. Especially in the context of a component as critical as floating point numerics. If there is any holdup it would be lack of demand for this format, which the article's proposal doesn't affect.
Python has three basic numeric types, unbounded integers, floats (with the precision of C doubles), and complex (for example, 5+0.3j). However, its standard library includes both a decimal type and a fraction type. The decimal type has been in the language for over 9 years. The documentation is quite clear [1].<p>Python's decimal type conforms to IBM's General Decimal Arithmetic Specification [2] which is based on IEEE 754 and IEEE 854. Python's decimal type is very complete. For example Python supports the complete range of rounding options found in these specifications (ROUND_CEILING, ROUND_DOWN, ROUND_FLOOR, ROUND_HALF_DOWN, ROUND_HALF_EVEN, ROUND_HALF_UP, ROUND_UP, and ROUND_05UP). By comparison Dec64 supports only one.<p>Despite having used Python on and off for over 10 years, I've never felt a need to use this decimal type. Integers and floats seem to work for me (although it's nice to have a good decimal implementation available if I need it).<p>[1] <a href="http://docs.python.org/3.4/library/decimal.html" rel="nofollow">http://docs.python.org/3.4/library/decimal.html</a>
[2] <a href="http://speleotrove.com/decimal/decarith.html" rel="nofollow">http://speleotrove.com/decimal/decarith.html</a>
A specific thing I haven't seen anyone mention is that NaN is equal to NaN in this, which is quite different from IEEE FP. Although it's a thing that often seems counterintuitive at first glance, doesn't this kind of ruin the error-taint quality of NaN?
How does he explain storing simple integers in a reasonable amount of space? Any decent programmer will avoid using too many bits for a variable that never exceeds a certain value (short, int, etc). It seems rather foolish and arrogant to claim this one half-implemented number type can satisfy everyone's needs in every programming language.<p>Next week he'll have a number format with 48 mantissa bits, 8 exponent bits and 8 unsigned base bits to define a base value between 0 and 255. Look at all the performance and simplicity involved!
This is some serious amateur hour. The most glaring problem is this:<p>> There are 255 possible representations of zero. They are all considered to be equal.<p>There are also 255 representations of <i>almost all representable numbers</i>. 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:<p><a href="https://github.com/douglascrockford/DEC64/blob/master/dec64.asm#L1068-L1105" rel="nofollow">https://github.com/douglascrockford/DEC64/blob/master/dec64....</a><p>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:<p><a href="https://github.com/douglascrockford/DEC64/blob/master/dec64.asm#L631-L664" rel="nofollow">https://github.com/douglascrockford/DEC64/blob/master/dec64....</a><p>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.<p>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 <i>is</i> 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.<p>[1] <a href="http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html" rel="nofollow">http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.ht...</a><p>[2] <a href="http://en.wikipedia.org/wiki/Decimal64_floating-point_format" rel="nofollow">http://en.wikipedia.org/wiki/Decimal64_floating-point_format</a>
While i find the binary incomparability with with decimals somewhat annoying.<p>In the bigger picture what i fell we are generally missing in most programing languages is an EASY way to store and handle fractions.
I see a few flaws that would prevent this from being a decent hardware type:<p>1) The exponent bits should be the higher order bits. Otherwise, this type breaks compatibility with existing comparator circuitry.<p>2) This representation uses 10 as the exponent base. That will require quite a bit of extra circuitry, as opposed to what would be required if a base of 2 was used. Citing examples from COBOL and BASIC as reasons for using base 10 is not a very convincing.<p>3) With both fields being 2's compliment, you're wasting a bit, just to indicate sign. The IEEE single precision floating point standard cleverly avoids this by implicitly subtracting 127 from the exponent value.<p>4) 255 possible representations of zero? Wat?<p>5) This type may be suitable for large numbers, but there's no fraction support. In a lot of work that would require doing math on the large numbers that this "standard" affords, those large numbers are involved in division operations, and there's no type for the results of such an operation to cast into.<p>6) This data type seems to be designed to make efficient by-hand (and perhaps by-software) translation into a human-readable string. But who cares? That's not a reason to choose a data type, especially not a "scientific" one. You choose data types to represent the range of data you have in a format that makes for efficient calculation and conversion with the mathematical or logical operations you want to be able to perform.
A real alternative to floating points would be a Logarithmic number system (<a href="http://en.wikipedia.org/wiki/Logarithmic_number_system" rel="nofollow">http://en.wikipedia.org/wiki/Logarithmic_number_system</a>) which has been shown to be a "more accurate alternative to floating-point, with improved speed."
> DEC64 is intended to be the only number type in the next generation of application programming languages.<p>Is he seriously arguing that integer types should be eliminated? What the hell?<p>I really hope for the author's sake this is a joke.
Does look interesting.<p>However, one nit in terms of interesting architecture: <i>The Burroughs 5000 series had a floating point format in which an exponent of zero allowed the mantissa to be treated as an ordinary integer.</i> In fact, the whole addressing scheme was decimal. The addresses were stored in one decimal digit per nibble, so it was doing decimal at the hardware level.<p>While this looks interesting at first blush, good luck with <i>DEC64 is intended to be the only number type in the next generation of application programming languages.</i> I think float will be around for a while, what with the blinding speed in today's processors, and the availability of 80 bit intermediate precision.
I thought the advantage of 2's complement was that we only had one zero and no additional conversions to do arithmetic on negatives, simplifying operations and ALU implementations.
Without normalization, how would that work with DEC64? Set both numbers to the highest exponent?
>By giving programmers a choice of number types, programmers are required to waste their time making choices that don’t matter<p>So I guess making sure that you can never do array[0.5] before your program ever runs doesn't matter? At least not to Crockford apparently, who seems to have some kind of irrational hatred for static type systems.
The name is a bit confusing. I have seen dec32 and dec64 numbers in some mil std ICDs. I can't find any of the documents online but here [1] is a discussion about dec 32 that links to a pdf which briefly describes the dec32 and dec64 formats.<p>[1] <a href="http://stackoverflow.com/questions/1797806/parsing-a-hex-formated-dec-32-bit-single-precision-floating-point-value-in-pytho" rel="nofollow">http://stackoverflow.com/questions/1797806/parsing-a-hex-for...</a>
to view the description html page:
<a href="http://htmlpreview.github.io/?https://raw.github.com/douglascrockford/DEC64/master/dec64.html" rel="nofollow">http://htmlpreview.github.io/?https://raw.github.com/douglas...</a>
As a "specification" this document is laughable. For example, rounding modes and overflow behavior are not addressed. The comment that object pointers can be stuffed into the coefficient field (usually called 'mantissa') is completely non-sequitur. Frankly I am surprised to see such a big name behind it.<p>I imagine this project is inspired by the sad state of numerical computing in Javascript, but this proposal will surely only make it worse. The world certainly doesn't need a new, incompatible, poorly-thought-out floating point format.<p>Compare the level of thought and detail in this "specification" to the level of thought and detail in this famous summary overview of floating point issues: <a href="https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numerics/Double/paper.pdf" rel="nofollow">https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numer...</a> ("What every computer scientist should know...")<p>> DEC64 is intended to be the only number type in the next generation of application programming languages.<p>Jesus, I certainly hope not.
I think this is pretty interesting and appreciate that it's presented with working code.<p>I think people freaking out that they're taking our precious integers away are being a little brash. A natural number type could easily be built on top of a dec64 type for those cases where you really need only whole numbers.
I seem to remember that "wobble" which is how the relative roundoff error relates to the absolute error, becomes worse as the base becomes larger (the ratio being the base itself). So that may be one disadvantage in using a decimal base.
Can we please make fun of this "specification" very very loudly as a warning to people who might think this is even a <i>remotely</i> good idea?<p>Decimal floating point is actually a good, underutilized idea. However, there is a <i>VERY</i> good specification here:
<a href="http://speleotrove.com/decimal/dbspec.html" rel="nofollow">http://speleotrove.com/decimal/dbspec.html</a><p>It is written by people who understand the problem, and have thought quite deeply about the solutions.<p>As opposed to this pile of garbage ...
Here is the fixed point decimal implementation for Golang<p><a href="https://github.com/oguzbilgic/fpd" rel="nofollow">https://github.com/oguzbilgic/fpd</a>
“By giving programmers a choice of number types, programmers are required to waste their time making choices that don’t matter. Even worse, making a bad choice can lead to a loss of accuracy or destructive bugs. This is a bad practice that is very deeply ingrained.”<p>This is like saying that the sharp blades on scissors (diverse numeric types) make them prone to causing bodily harm to surrounding people(errors due to constraints of types), then concluding that we should replace all scissors (numeric types) with those rounded plastic scissors(dec64 play dough floats) which come with a play dough set.<p>Every time somebody has the idea that by deluding developers more we can save them trouble and make them feel safer, we pat that person on the back and follow their recipe.
Then two years later there's a HN post about why you really shouldn't be doing whatever was prescribed.