4 ms·

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 i

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. Also, it's worth mentioning http://speleotrove.com/decimal/ http://speleotrove.com/decimal/ as a great repository of decimal float info. I hope it will be updated with some discussion of this proposed format.

eliteraspberrie 13y ago
One difference is with non-numbers. IEEE 754 defines several infinities (positive, negative) and several NaN values. DEC64 seems to simplify things to a single NaN value. That seems more practical for the average use case.
- fhars 13y ago
  But it complicates things by having 255 different zeros which are all equal, and by defining 1 / 0 == 0 / 0 == (-1) / 0 == MAX_DEC64 + X == (-MAX_DEC64) - X (X being the some number large enough to cause overflow) I'd qualify the proposal as a midbrow dismissial of all the real thought that went into the IEEE float standards (I mean, there is no actual substance to his criticism, except "uh, look, it's so bad nobody uses it," which isn't even true, it is in IBM Power7, IBM zSeries, Fujitsu SPARC64, SAP ABAP and gcc). Floating point on a finite precision computer is hard, you can't gloss over the details and assume you have solved everything by that.
  - Karellen 13y ago
    Holy crap. I was about to comment that NANs are not equal to each other, as is the case in every other floating-point representation on the planet[0]. I wasn't actually expecting the page to say either way, but I decided to have a quick look in the vague hope of finding a quote to support that, and instead discovered: "nan is equal to itself." That strikes me as being very odd, and will likely catch a lot of programmers out who are expecting the "normal" behaviour there. I predict many bugs, and much wailing and gnashing of teeth, as a result. [0] Maybe. Edit: I see Stormbrew made the point before me, lower down the thread.
- caf 13y ago
  If you're shooting for universal applicability, then you can't really cater only to the average use case.

eliteraspberrie 13y ago

One difference is with non-numbers. IEEE 754 defines several infinities (positive, negative) and several NaN values. DEC64 seems to simplify things to a single NaN value. That seems more practical for the average use case.

fhars 13y ago
But it complicates things by having 255 different zeros which are all equal, and by defining 1 / 0 == 0 / 0 == (-1) / 0 == MAX_DEC64 + X == (-MAX_DEC64) - X (X being the some number large enough to cause overflow) I'd qualify the proposal as a midbrow dismissial of all the real thought that went into the IEEE float standards (I mean, there is no actual substance to his criticism, except "uh, look, it's so bad nobody uses it," which isn't even true, it is in IBM Power7, IBM zSeries, Fujitsu SPARC64, SAP ABAP and gcc). Floating point on a finite precision computer is hard, you can't gloss over the details and assume you have solved everything by that.
- Karellen 13y ago
  Holy crap. I was about to comment that NANs are not equal to each other, as is the case in every other floating-point representation on the planet[0]. I wasn't actually expecting the page to say either way, but I decided to have a quick look in the vague hope of finding a quote to support that, and instead discovered: "nan is equal to itself." That strikes me as being very odd, and will likely catch a lot of programmers out who are expecting the "normal" behaviour there. I predict many bugs, and much wailing and gnashing of teeth, as a result. [0] Maybe. Edit: I see Stormbrew made the point before me, lower down the thread.
caf 13y ago
If you're shooting for universal applicability, then you can't really cater only to the average use case.