News for hackers. Stuff that matters.
Re:DEC64: Decimal Floating Point by olliej on Sunday March 04, 2018 @06:57PM (#16517620)
3. Correct there are not 255 possibilities, it’s closer to 50 - I have no paper to work it out on right now. This is because the desire to “not require normalization” is not a good idea.

4. To implement compare quickly you can probably short circuit by first checking that the values are normalized, and normalizing them if not. From a hardware point of view you just added two registers for compare, in addition to the logic for normalizing. For hardware it is probably cheaper to unconditionally normalize.

All math operations will also need to normalize inputs first because otherwise you throw away precision for no reason. For similar reasons all outputs will need to be normalized anyway. Again, given this why would you choose to not just have an implied leading bit?

5. Uh yeah what? If you’re making dedicated hardware you could randomize the bit ordering that’s what making hardware is all about ;)

Re:DEC64: Decimal Floating Point by Veedrac on Sunday March 04, 2018 @08:53PM (#16518122)
> Correct there are not 255 possibilities, it’s closer to 50

1 in 10 values have two representations, 1 in 100 have three, etc., since you can only change the exponent when the (normalized) value is 0 mod 10.

> For hardware it is probably cheaper to unconditionally normalize.

Given normalization is going to be infrequent (most values will either just be integers or have a single representation), and that arithmetic is more common than comparisons, I don't see why this would be. Normalizing a binary value is much easier, so you can't carry floating point intuitions over.

> All math operations will also need to normalize inputs first because otherwise you throw away precision for no reason.

No, you just conform the exponents and handle overflow.