[norswap]

I'd like an explanation also.

From my own understanding, an operation will lose precision iff () the result cannot be represented with 52 significant coefficient bits. Logically, the same happens in IEEE754, the difference is that the loss of precision in DEC64 is always a multiple 3.5 bits, whereas IEEE754 can lose precision in decrements of one bit.

() Maybe excluding over/underflow scenarios.

To clarify, what you say sounds like (I'm pretty sure that's not what you meant) every operation with mixed exponent will lead to loss of precision. From my understanding, that is not the case. It also sounds like every IEEE754 operation with mixed exponents only leads to one bit precision loss while it could lead to much more (in fact to (<total number of fraction bits between the two IEEE754 doubles> - 52).

[jejones3141]

OK. It looks like the proposed representation represents numbers as a signed 56 bit integer times ten to a signed 8-bit number. That does avoid fiddling with BCD, but it's VERY different from usual floating point. Look at the neighborhood of zero. As with usual floating point there's a gap between zero and the smallest nonzero number... but unlike floating point numbers, the next larger nonzero number is twice the smallest nonzero number. The behavior of numerical methods in DEC64 will, I suspect, be quite different from that of floating point. It would be very interesting to know what the difference is, and I'd hope that proponents of it as "the only number type in the next generation of application programming languages" would exercise due diligence in that and other regards.