Hacker News Reader

Comment by wheybags | Hacker News Reader

Part of me wonders if binary floating point was a mistake. If we had invested the same effort into hardware optimising some kind of BCD based floating point format, where would we be now? The amount of confusion caused for new programmers by the way floats can't represent "simple" values like 0.1 perfectly is immense. Would also make round tripping through text formats like json "just work", as opposed to the mess we have now.

View on HN

Responses to this are IMHO unfair. In fact this isn't an inherently terrible or infeasible idea. Transistor costs for 4-bit BCD run just about at the ln(16)/ln(10) level you'd expect, and just a few gates of depth per digit are needed for the carry detect (something that can easily be folded into the carry lookahead optimizations all modern adders need anyway). Hardware multipliers would need more work, you can't make a Dadda/Wallace tree with anything but binary adders, but I'm sure there's a clever generalization.

The one thing you'd lose would be two's complement trickery. Addition and subtraction in BCD actually are fundamentally different algorithms, so that's something to worry about. But then signedness mismatches are themselves a historical footgun, so you could spin this away too, I think.

But... beyond that this could absolutely be done. And it's also true that a lot of traditional bugs with FPU/brain precision mismatch would be fixed in the process.

I don't know that it's an architecture I'd pick, but it's not something to reject out of hand either. It's worth discussing and not downvoting.

The confusion around 0.1 might be a good thing, it makes you learn early on that floats approximate a number to its significant digits and are not real numbers.

People are used to approximations, but they are used to decimal approximations. "I can't represent 1/3 as a decimal" is expected, "I can't represent 1/10 as a decimal" is surprising.

Making computers use more memory, use larger chips, and consume more power just to make one thing easier for novice programmers is a bad trade-off. Decimal floating-point types could be implemented in software for those who really want it.

By that reasoning we shouldn't be using higher level languages like Python and Java that use more memory, and consume more power for the same workload as code written in assembly. 6502 assembly FTW!

Well, they are real numbers, just not always the ones you want.

But we also have, e.g., fairly accurate weather models now, enabled by supercomputers running lots of floating point math.

Wouldn't we have the same if history tilted the way the grandparent post is asking about?

If only humans had 8 or 16 fingers instead of 10 ;)

This reminds me of this: https://news.ycombinator.com/item?id=12719273#12720638

> Fun fact: you can count to hexadecimal on the fingers of one hand.

> The way it works is that each of your four fingers has four well-defined places on them: the three joints, plus the tip. You use your thumb to point at one of these. The first finger represents 1-4, the second 5-8, the third 9-12, the fourth 13-16. You count up and down by moving your thumb.

(...)

> As a special bonus: if you point to the fleshy pads of the fingers instead of the joints, you can use the same system for base 12.

Tough call deciding between this and just using your fingers as a 5 bit binary counter. Incrementing is sure a lot faster with this method at the cost of a bit.

The difficulty with that is that your ring finger is not completely independent of your pinkie due to the way the tendons are connected.

Floats represent real numbers, not "values". (Whatever those are.)

Please teach new programmers the number type stack first.

How do they represent real numbers? If anything, they represent rational numbers.

Also I think your answer is unnecessarily nitpicky. Sentence 'floats can't represent "simple" values like 0.1 (...)' is perfectly clear to everyone on HN, I hope. In fact, I disagree that changing "values" here to a more precise mathematical term would improve anything.

> How do they represent real numbers? If anything, they represent rational numbers.

That's an interesting philosophical question. Does M_PI represent a rational number?

(M_PI isn't mentioned in my copy of the C spec, unless I just can't find it.)

does it not have to represent a rational approximation of Pi? Real numbers in the set theoretic sense are defined as limits of Cauchy sequences[0], and since we can't quite store an infinite sequence, it has to be a finite approximation due to the limitations of the real world.

[0]: https://en.wikipedia.org/wiki/Cauchy_sequence

It does after it's assigned to a variable, but maybe it doesn't before that.

Rationals are a subset of the reals.

No current computing architecture provides primitives for dealing for rational numbers. (Which is why you need to roll your own implementation in software, so nobody bothers.)

But we have great native support for approximating real numbers instead. (Because computing is designed first and foremost to make numerical methods efficient.)

Floats are designed to be computationally and mathematically efficient approximations of the real numbers.

The exist so that trigonometry and logarithms work properly in numerical methods. (A vastly more important problem than getting '0.1' to print pretty on the screen.)

There is no such thing as a 'value' in mathematics, and fixating on 0.1 in particular is pointless.

tldr - everyone should learn the math behind this first.

Reply on news.ycombinator.com