4 ms·

As a "specification" this document is laughable. For example, rounding modes and overflow behavior are not addressed. The comment that object pointers can be

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. 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. 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: https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numerics/Double/paper.pdf https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numer... ("What every computer scientist should know...") > DEC64 is intended to be the only number type in the next generation of application programming languages. Jesus, I certainly hope not.

norswap 13y ago
At the least, overflow is addressed: > nan is also the result of operations that produce results that are too large to be represented.
- GyrosOfWar 13y ago
  It's addressed, but in the wrong way. IEEE 754 has positive and negative infinity for a reason. Why do there have to be 255 zero values? Also, what about rounding modes? Floating point math is really, really hard and this specification makes it look too easy.
  - kzrdude 13y ago
    They want to allow fast "addition with equal exponents" in a single cycle and that requires a zero value for each possible exponent.
    - GyrosOfWar 13y ago
      I see, that makes sense.
austinz 13y ago
> The BASIC language eliminated much of the complexity of FORTRAN by having a single number type. This simplified the programming model and avoided a class of errors caused by selection of the wrong type. The efficiencies that could have gained from having numerous number types proved to be insignificant. I don't agree with that, and I don't think BASIC has much (if anything) to offer in terms of good language design.
- Someone 13y ago
  I tried finding out whether that "having a single number type" actually were true (the microcomputer versions used a percentage sign suffix (I%, J%) to denote integers). From http://bitsavers.trailing-edge.com/pdf/dartmouth/BASIC_Oct64.pdf http://bitsavers.trailing-edge.com/pdf/dartmouth/BASIC_Oct64..., that appears to be the case. Off topic: in that PDF (page 4) the letter "Oh" is distinguished from the numeral "Zero" by having a diagonal slash through the"Oh". Yes, that program printed "NØ UNIQUE SØLUTIØN". That made me think of the periodic rants here on HN about the supposedly neigh insurmountable inconsistencies in mathematical notation.
  - spc476 13y ago
    Not all microcomputer versions of BASIC used the percent sign to designate integers. The one I grew up using (Microsoft BASIC on the TRS-80 Color Computer) used only one representation for numbers, floating point (5 byte value, not IEEE 754 based).
  - glurgh 13y ago
    Probably mean 'nigh'. Neigh is a sound horses make.
    - Someone 13y ago
      Yep, let's see whether I can blaim iOS autocorrect: nigh. No. Thanks for the feedback.
    - lttlrck 13y ago
      or nay...
dhimes 13y ago
Where's the spec? I can't find it. Certainly the linked web page isn't the spec...
- ics 13y ago
  Not a spec, but the reference implementation here: https://github.com/douglascrockford/DEC64 https://github.com/douglascrockford/DEC64
  - dhimes 13y ago
    Thanks, I saw that. I thought maybe Ersatz was complaining about a spec I couldn't find. It seems he may be addressing the linked description instead.
solarexplorer 13y ago
> rounding modes and overflow behavior are not addressed He provides a reference implementation. That means this and many other details are defined by code. Quoting dec64.asm: "Rounding is to the nearest value. Ties are rounded away from zero. Integer division is floored." > Compare the level of thought and detail in this "specification" to ... [Goldberg] I don't think this comparison is fair. David Goldberg's text is an introduction to the topic. Douglas Crockford describes an idea and gives you a reference implementation.
- chimeracoder 13y ago
  > He provides a reference implementation. That means this and many other details are defined by code. I dream of a day when we stop thinking of "reference implementations" as proper specifications. The whole concept of a "reference implementation" leads to an entire class of nightmarish problems. What happens if there is an unintentional bug in the reference implementation that causes valid (but incorrect) output for certain inputs? What if feeding it certain input reliably produces a segfault? Does that mean that other implementations should mimic that behavior? What if a patch is issued to the reference implementation that changes the behavior of certain inputs? Is this the same as issuing an amendment to the specification? Does this mean that other implementations now need to change their behavior as well? Or, worse, what if there is certain behavior that should be explicitly left undefined in a proper specification? A reference implementation cannot express this concept - by definition, everything is defined based on the output that the reference implementation provides. Finally, there's the fact that it takes time and effort to produce a proper specification, and this process usually reveals (to the author) complexities about the problem and edge cases that may not become apparent simply by providing a reference implementation.
  - solarexplorer 13y ago
    I suppose that Crockford is just tossing around this idea to test the waters. If he were serious, he would have to deliver a written spec of course!
  - kabdib 13y ago
    On the other hand, if you don't have a reference specification you shouldn't declare something standard. (re: all the web standards that had very wide "interpretation" by different browser efforts, leading to chaos and a whole industry based on fear an uncertainty)
marijn 13y ago
> The comment that object pointers can be stuffed into the coefficient field (usually called 'mantissa') is completely non-sequitur. Why? A similar thing is being used by some JavaScript and Lua implementations. It's called NaN boxing.
magicalist 13y ago
I would hate if this became the only numeric type available in JS (in fact, I don't want it at all), but it's dishonest to quote "specification" as you have and then dismiss it as such, as it doesn't claim to be one, the word doesn't appear a single time in it, and if you go through to the github repo, the readme explicitly refers to the page as a "descriptive web page". In fact, the only line of actual substance in your post is "For example, rounding modes and overflow behavior are not addressed", and it turns out that's only true for the descriptive web page, not the reference implementation. > 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. I'll just quote pg here: Yeah, we know that. But is that the most interesting thing one can say about this article? Is it not at least a source of ideas for things to investigate further? The problem with the middlebrow dismissal is that it's a magnet for upvotes. The "U R a fag"s get downvoted and end up at the bottom of the page where they cause little trouble. But this sort of comment rises to the top. Things have now gotten to the stage where I flinch slightly as I click on the "comments" link, bracing myself for the dismissive comment I know will be waiting for me at the top of the page.
- cornholio 13y ago
  This format is suicide from a numerical stability POV. It will lose 3 to 4 bits of precision for an operation with mixed exponents, whereas double will only lose one. Any kind of marginally stable problem, say eigenvalues with poorly conditioned data, will yield crap.
  - stcredzero 13y ago
    So the takeaway is that "one type to rule them all" in a scripting language won't really work until 128 bit machines are mainstream?
  - haberman 13y ago
    Can you explain this point in more detail? And maybe give an example? As someone who is not an expert in this I can't follow your argument.
barrkel 13y ago
This isn't a specification, and it's laughable that you think so. It's a polemic, designed to try and propagate an idea and change minds. It didn't change my mind much, but I found your comment more affecting - in the humorous!

norswap 13y ago

At the least, overflow is addressed: > nan is also the result of operations that produce results that are too large to be represented.

GyrosOfWar 13y ago
It's addressed, but in the wrong way. IEEE 754 has positive and negative infinity for a reason. Why do there have to be 255 zero values? Also, what about rounding modes? Floating point math is really, really hard and this specification makes it look too easy.
- kzrdude 13y ago
  They want to allow fast "addition with equal exponents" in a single cycle and that requires a zero value for each possible exponent.
  - GyrosOfWar 13y ago
    I see, that makes sense.

austinz 13y ago

> The BASIC language eliminated much of the complexity of FORTRAN by having a single number type. This simplified the programming model and avoided a class of errors caused by selection of the wrong type. The efficiencies that could have gained from having numerous number types proved to be insignificant. I don't agree with that, and I don't think BASIC has much (if anything) to offer in terms of good language design.

Someone 13y ago
I tried finding out whether that "having a single number type" actually were true (the microcomputer versions used a percentage sign suffix (I%, J%) to denote integers). From http://bitsavers.trailing-edge.com/pdf/dartmouth/BASIC_Oct64.pdf http://bitsavers.trailing-edge.com/pdf/dartmouth/BASIC_Oct64..., that appears to be the case. Off topic: in that PDF (page 4) the letter "Oh" is distinguished from the numeral "Zero" by having a diagonal slash through the"Oh". Yes, that program printed "NØ UNIQUE SØLUTIØN". That made me think of the periodic rants here on HN about the supposedly neigh insurmountable inconsistencies in mathematical notation.
- spc476 13y ago
  Not all microcomputer versions of BASIC used the percent sign to designate integers. The one I grew up using (Microsoft BASIC on the TRS-80 Color Computer) used only one representation for numbers, floating point (5 byte value, not IEEE 754 based).
- glurgh 13y ago
  Probably mean 'nigh'. Neigh is a sound horses make.
  - Someone 13y ago
    Yep, let's see whether I can blaim iOS autocorrect: nigh. No. Thanks for the feedback.
  - lttlrck 13y ago
    or nay...

dhimes 13y ago

Where's the spec? I can't find it. Certainly the linked web page isn't the spec...

ics 13y ago
Not a spec, but the reference implementation here: https://github.com/douglascrockford/DEC64 https://github.com/douglascrockford/DEC64
- dhimes 13y ago
  Thanks, I saw that. I thought maybe Ersatz was complaining about a spec I couldn't find. It seems he may be addressing the linked description instead.

solarexplorer 13y ago

> rounding modes and overflow behavior are not addressed He provides a reference implementation. That means this and many other details are defined by code. Quoting dec64.asm: "Rounding is to the nearest value. Ties are rounded away from zero. Integer division is floored." > Compare the level of thought and detail in this "specification" to ... [Goldberg] I don't think this comparison is fair. David Goldberg's text is an introduction to the topic. Douglas Crockford describes an idea and gives you a reference implementation.

chimeracoder 13y ago
> He provides a reference implementation. That means this and many other details are defined by code. I dream of a day when we stop thinking of "reference implementations" as proper specifications. The whole concept of a "reference implementation" leads to an entire class of nightmarish problems. What happens if there is an unintentional bug in the reference implementation that causes valid (but incorrect) output for certain inputs? What if feeding it certain input reliably produces a segfault? Does that mean that other implementations should mimic that behavior? What if a patch is issued to the reference implementation that changes the behavior of certain inputs? Is this the same as issuing an amendment to the specification? Does this mean that other implementations now need to change their behavior as well? Or, worse, what if there is certain behavior that should be explicitly left undefined in a proper specification? A reference implementation cannot express this concept - by definition, everything is defined based on the output that the reference implementation provides. Finally, there's the fact that it takes time and effort to produce a proper specification, and this process usually reveals (to the author) complexities about the problem and edge cases that may not become apparent simply by providing a reference implementation.
- solarexplorer 13y ago
  I suppose that Crockford is just tossing around this idea to test the waters. If he were serious, he would have to deliver a written spec of course!
- kabdib 13y ago
  On the other hand, if you don't have a reference specification you shouldn't declare something standard. (re: all the web standards that had very wide "interpretation" by different browser efforts, leading to chaos and a whole industry based on fear an uncertainty)

marijn 13y ago

> The comment that object pointers can be stuffed into the coefficient field (usually called 'mantissa') is completely non-sequitur. Why? A similar thing is being used by some JavaScript and Lua implementations. It's called NaN boxing.

magicalist 13y ago

I would hate if this became the only numeric type available in JS (in fact, I don't want it at all), but it's dishonest to quote "specification" as you have and then dismiss it as such, as it doesn't claim to be one, the word doesn't appear a single time in it, and if you go through to the github repo, the readme explicitly refers to the page as a "descriptive web page". In fact, the only line of actual substance in your post is "For example, rounding modes and overflow behavior are not addressed", and it turns out that's only true for the descriptive web page, not the reference implementation. > 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. I'll just quote pg here: Yeah, we know that. But is that the most interesting thing one can say about this article? Is it not at least a source of ideas for things to investigate further? The problem with the middlebrow dismissal is that it's a magnet for upvotes. The "U R a fag"s get downvoted and end up at the bottom of the page where they cause little trouble. But this sort of comment rises to the top. Things have now gotten to the stage where I flinch slightly as I click on the "comments" link, bracing myself for the dismissive comment I know will be waiting for me at the top of the page.

cornholio 13y ago
This format is suicide from a numerical stability POV. It will lose 3 to 4 bits of precision for an operation with mixed exponents, whereas double will only lose one. Any kind of marginally stable problem, say eigenvalues with poorly conditioned data, will yield crap.
- stcredzero 13y ago
  So the takeaway is that "one type to rule them all" in a scripting language won't really work until 128 bit machines are mainstream?
- haberman 13y ago
  Can you explain this point in more detail? And maybe give an example? As someone who is not an expert in this I can't follow your argument.

barrkel 13y ago

This isn't a specification, and it's laughable that you think so. It's a polemic, designed to try and propagate an idea and change minds. It didn't change my mind much, but I found your comment more affecting - in the humorous!