3 ms·
>“Because the chip it is running on doesn’t have native base-10 math”? Base 10 fixes exactly zero of the problems with floating point. Decimal floating point
by constantcrying 3y ago
>“Because the chip it is running on doesn’t have native base-10 math”?
Base 10 fixes exactly zero of the problems with floating point.
Decimal floating point exists as a standard already. It is even part of the upcomming C standard.
But again decimal arithmetic is just as weird as floating point arithmetic. The change of base s irrelevant, except for a few niche applications.
>The consequence of this is much heavier than any benefits of base 2 FP.
Totally false. Decimals don't fix floats. They are just as weird. Changing the base is irrelevant to the inherent properties of floats and using base 10 instead of base 2 just means that with a very high chance you get something even worse.
If you do not understand the basics of floating point arithmetic you should not be programming software. Tough world out there for people who refuse to learn, I know.
- PaulHoule 3y agoNo way. The problem with binary floating point is that it is input and output as decimal floating point. Every floating point number is really a fraction of the form M ------- b^E When you write x = 0.1 you are really asking for 1/10. If b=2, however, you can only get a denominator of 1/2, 1/4, 1/8 or something like that. 1/10 just doesn't exist in that number system, but there is a number A that you get when you ask for 0.1 that round-trips back to 0.1, and the same is true for 0.2 (B) and 0.3 (C). The trouble is those substitute numbers aren't the real numbers and A != B + C This has nothing to do with numeric precision, it's always going to be off a bit even if you are using 1024-bit floats or 1048576-bit floats. The problem punches above its weight because it is targeted right at two fault lines of the mind: (1) people flinch at inconsistencies, 0.1 + 0.2 = 0.3 is an identity and when basic identities are wrong people feel uncomfortable and don't want to proceed; if you are working with an accountant, for instance, and they see something that is not consistent in a way they've been trained has to be consistent, they will just stop until it is consistent. (2) A certain kind of laziness leads people to not get to the root of a problem like this and instead waste a huge amount of time and energy into non-solutions (rounding!) that are just like pushing a bubble around under a rug. Note that decimal floating point does not require that you use BCD. That is, the mantissa and the exponent of a floating point number are just integers, and unlike the floats, base 7 and base 192 integers are the same numbers. An obvious idea is to use base 2 for the mantissa and exponent, just have the exponent be base 10. One difficulty is the cost of sliding two numbers so they have the same exponent before you add them, for instance to add 43 723 --- 766 you have to express the 723 and 43 in the same base to add them (multiply/add by ten) and multiplication by powers of ten is a lot hard with base 2 math than with base 10 math. You also can represent decimal floating point numbers with a decimal mantissa and face the tradeoff of BCD numbers being wasteful of bits but the factors of 10 being easy to deal with. There is an efficiency gap between hardware binary floating point and hardware decimal floating point but it's not as bad as you might think.
- constantcrying 3y agoThe problems with floats are independent of the basis. >1/10 just doesn't exist in that number system And 1/3 doesn't exist for b=10. I really have no idea what you are on about. The number system you want does not exist, it is a mathematical theorem, floats are the best approximation of real numbers and choosing b=10 is dumb outside of specific applications. Decimal floating point fixes nothing it just moves around the issues where they less affect numbers in base 10. It is exactly as broken as base 2. You still violate basic identities in b=10, just different ones. Again, the number system you want doesn't exist and it can't. You can never approximate the real numbers with constant bits, division and arithmetic consistency.
- erik_seaberg 3y agoFloats are probably the best approximation of irrational numbers near zero. Rational numbers don’t need to be approximated, unless you’re doing something like tight SIMD loops where the hardware itself limits precision, or letting an end user dictate how much precision he wants to see at the moment. There are corners we don’t need to cut anymore, because a half century of Moore’s Law has already paid for better tools if only we would claim them.
- constantcrying 3y ago>Floats are probably the best approximation of irrational numbers near zero. Floats are generally better near zero, but better (although less useful) approximations exist. >Rational numbers don’t need to be approximated Nonsense. "rational" datatypes are far less useful than floats. Approximating rationals by floats is usually better. FYI rational datatypes can not support operations which result in irrational numbers, such as exp, sqrt. >where the hardware itself limits precision Hardware does not limit precision. It implements IEEE 754. > letting an end user dictate how much precision he wants to see at the moment. Those are arbirtrary precision numbers. >There are corners we don’t need to cut anymore, because a half century of Moore’s Law has already paid for better tools if only we would claim them. Total nonsense. Fast floats have never been more important than they are now.
- wruza 3y agoYour views are too extreme and elitist, exactly as mentioned before. I don’t think that this position may be considered an argument, as for this thread’s subject it is a lost cause.
- constantcrying 3y agoFloating point numbers are the most useful approximation to reals we have on a computer. That isn't an "elitist" view. I don't get what you are on about, seems ridicolous. People need to learn to use the systems they are working with any highschooler can understand what floating point numbers are and why they have flaws. It is really simple.