Hacker News Reader

Comment by haberman | Hacker News Reader

So is this primarily a performance vs. convenience thing?

If both base2 and base10 floating point are implemented in hardware, what makes base10 inherently less efficient?

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.

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.

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).

So the "holes" are different, so-to-speak. How would this affect accuracy of complicated expressions?

View on HN

Decimal floating point would hardly affect accuracy compared to binary floating point -- with the exception of domains where the inputs and output are strictly human-readable and human-precise constructs (e.g. banking... is there a better term for this?).

Binary floating point can accurately represent fractions of the form 1/(2^n). Decimal floating point can accurately represent fractions of the form 1/((2^n)*(5^m)). Either can only approximate fractions with other prime factors in the denominator (1/3, 1/7, 1/11, ...).

In terms of a programmer having to be concerned with accumulated errors due to approximations in the representation, I'd assert that decimal floating point in no way changes the scope of concerns or approach to numeric programming compared to binary floating point. I'd guess even in a domain with a very precise need of fractional decimals, a programmer would still need to reason about and account for numeric representation errors in decimal floating point such as overflow and underflow.

> Decimal floating point would hardly affect accuracy compared to binary floating point

The larger the radix, the more of the mantissa is wasted. Given fixed storage, base 2 floats will have higher precision over their range than higher bases, like 10 and 16.

The difference is easy to illustrate with base 16 and base 2, since we can convert between the two easily. Converting a base 16 float to base 2 will result in leading zeroes some of the time, which could have been used for storing data. The same is true with base 10, but you have to do more math to demonstrate it.

You could just expand the mantissa to account for the base providing more range, though I do agree using a small base is better in general.

> I'd assert that decimal floating point in no way changes the scope of concerns or approach to numeric programming compared to binary floating point.

Agree. What problem does this solve? That I can now represent 1/5 precisely?

All the other problems of representing floating point numbers and numbers generally are maintained.

The thing that remains most compelling about decimal encodings is in the types of errors seen and how human-comprehensible they are.

For example, arithmetic operations in binary floating point are notorious for producing mystery meat error quantities, because the actual error quantity is in binary and only later represented as a decimal amount. And when coding it is most natural to account for floating point errors in decimal terms, even though this is a false representation.

So the main thrust of any decimal float proposal comes from "this is more in tune with the way humans think" and not the specific performance and precision constraints.That said, I have no special insights into Crockford's proposal.

Decimal floating point would almost definitely be slower than IEEE754 if implemented in hardware.

But why? That is the question I was looking to understand. Why is it inherently slower?

I imagine it's because binary exponents correspond very well to binary arithmetics, while decimal exponents don't.

Imagine you have a floating point format which has 8-bit mantissa (i.e. 8 bits to store the digits, without the floating point). You're trying to calculate 200 + 200. In binary, that's

    0b11001000 + 0b11001000 = 0b110010000

However, to represent the result you would need 9 bits, which you don't have, so you instead represent it as 400 = 200 * 2 = 0b11001000 * 2 ^ 1. Notice how the resulting mantissa is just the result (0b110010000) shifted one bit.

If your exponent is decimal exponent, you would instead have to represent 400 as 400 = 40 * 10 = 0b101000 * 10 ^ 1. In this case, the resulting mantissa has to be calculated separately (using more expensive operations), as it has no connection to the mathematical result of the operation.

Because division/multiplication by powers of two is a simple bitshift and can be implemented very easily on silicon. Division/multiplication by ten is complicated and needs many more gates and more time.

division/multiplication by powers of 2 is not the only thing people do with binary floating point numbers.

Yeah, but you need that to do anything with binary floating point numbers, like a simple addition.

It's not inherently slower, however you have to add extra logic to correctly handle overflows and the like. However given the size of modern floating point units I doubt it's a massive overhead. Basically they would need to convert back and forth between the native zeros and ones of hardware and the decimal representation. And extra logic might mean slower hardware in certain circumstances.

Basically try to implement a BCD counter in verilog and you'll see where the overhead appears compared to a "dumb" binary counter.

In practice it would be slow because not a whole lot of CPU architectures natively handle BCD. If this "standard" goes mainstream maybe the vendors will adapt and make special purpose "DEC64 FPU" hardware.

I'm not really sure what's the point of using this floating point format outside of banking and probably a few other niche applications. For general purpose computing I see absolutely no benefits.

Because it's easy to do things in base 2 with binary signals (like the kind used in computers). It's unnatural to use base 10 for anything in this domain.

It would be extremely unintuitive if math could be done faster in any base except for 2 (or a power thereof) when running on a modern CPU.

It's not inherently slower. It's a question of economics. How much are people willing to spend to get a CPU to make it be fast? With IEEE 754 math, there's a lot of monetary incentive because a lot of code uses 754. With a new decimal class, there is much less inventive.

Aligning the decimal point can be done in a single cycle with a barrel shifter in base 2.

That's what he said, and he's asking why.

Reply on news.ycombinator.com