decimals cause huge problems for computers. How do you represent 0.6 as a floating point? In the long run, the correct solution is for everything to be binary.
Why? No matter what radix you pick, there's always going to be some rational-value you cannot accurately encode. Moving to binary just gives you a different distribution of "un-encodeable values". (I'd say a larger/worse set, but I'm not yet sure how to prove it.)
Making a self-reply here, I think I know how to show binary is "worse" when it comes to un-representable rational numbers. I'm not a math major, so this is probably some incredibly obvious textbook stuff to somebody else, but...
In base-N, you can accurately write any fraction of (1/y) provided that y can be expressed using the same prime-factors found in N.
For example, 10 has the prime factors of 2 and 5, leading to the requirement that y=(2^a × 5^b) .
This means base-10 can accurately represent (1/80), because 80 = (2^4 × 5^1). In base-2, you're limited to stuff in the form (2^a).
Finally, the, uh, infinity-of-integers that matches (2^a) is always going to be "smaller" than the infinity which can be matched by (2^a × 5^b), since the latter "contains" the former when b=0.
Your argument is intuitively correct, but formalizing it requires a very careful choice of "smaller than". In particular all of the infinities in question are countable, so in some sense they are the "same size".
But there are two approaches that we can use.
The first is to point out that in real life it is more common to encounter small numbers than big ones. So if you choose a probability distribution for what denominators you expect in practice, and sum up the values of all of the exactly represented numbers, you can get to a fixed probability of even division. And it won't be zero.
Unfortunately your choice of the relative probability of having a 2 in the denominator versus a 3 is extremely arbitrary. So while the approach makes sense, the numbers you get really will be made up. (Though no matter how you make them up, your general statement is guaranteed correct.)
The second approach is to just look at how the count of exactly representable numbers below N scales with both N and your set of primes. This has been studied. The exact counts are a mess, but if you have a set S of prime divisors of size k, then the count is (1+o(1)) * 1/k! * [product over p in S of (log(N)/log(p)].
The upshot is that for large N, more prime factors always wins. And for specific prime factors, you just look at the ratio of logs.
For instance with this approach we can say that log(3)/log(5) = 1.46497352071793... times as many denominators are exactly representable in base 12 as in base 10. (The log(2) factors cancel out.) Therefore base 12 is better.
Of course the second approach says that base 6 is as good as base 12, and it is smaller, so why not use it? Well, the reason why we keep on winding up with base 12 in practical situations is that divisibility by 4 comes up a lot. It isn't just exactly representable that matters, efficiency matters.
no. You can accurately represent anything which is k*2^n, where (k,n) are integers. Simple example: 3 is not 2^n but obviously expressing 3 as a floating point is not a problem. Similarly 1.5, etc.
In this fashion, primes p seem "better" as they increase, because for a given size limits on k and n, you get more 'numbers' per unit space on the real line. Composite numbers are 'even better', but there are a lot of pains in the ass with composite numbers, stemming from Z/nZ not being a field if n not prime.
Ultimately, though, your internal representation is binary, using anything not two produces other inefficiency. That's why IEEE 754 BCD is not base-10 but base-1000 (since 2^10 = 1024 which is the closest a power of two gets to a power of 10, for bit-wise representation efficiency). We don't have bi-quinary computers.
Once you know you can accurately represent (1/y) in a given base, you've established do not need an infinite number of digits to the right of the radix-point no matter how many times you multiply it by an integer.
In fact, I think it exemplifies the upper bound for the number of digits you'd need for "related fractions". For example, we know "one eighth" is expressible in decimal as 0.125. Even if you pick a really big N value, N * (1/8) should never need more than three digits to the right of the decimal point.
Perhaps I'm wrong, but I believe that nothing can stop the problem that some quantities cannot be finitely represented, but I don't see why rationals are a problem because computers can finitely represent them with no information loss if they treat these numbers symbolically. We only have 0.1 + 0.2 != 0.3 issues due to using an imprecise but fast number representation system.
It is easier for the computer to adapt to us, rather than vice versa. And over time things get easier and easier for the computer, while staying the same for us. Which is why over time we wind up interacting with computers in ways that are more and more adapted to us rather than them.
We already have acceptably good algorithms to convert to/from different representations, and roundoff errors are generally acceptable. (If they weren't, we wouldn't default to using floating point for most things.) Where precision matters, we have reasonably efficient implementations of exact integer arithmetic and exact fraction arithmetic. The performance hit from using these is less than the hit from using a high level language like Python versus a low-level language like C.
The main challenge is getting programmers to use the right representation for the purpose that they are using it for. Which is mostly challenging exactly because floating point works so well in practice that it is easy not to learn what its limitations are.
you can't use exact fraction arithmetic to take a square root, which comes up, you know, just a little bit, in physics. Of course this is a problem for binary representations, too, but you might as well not start out with an input that is already imprecise.
In physics it is uncommon to have exact measurements for much of anything except integers. In physics, measurement error is usually a bigger issue than roundoff errors from floating point, so the non-existence of an exact floating point representation of the stated measurement is a non-issue.
In the real world, most cases that I'm aware of where we need exact base 10 calculations have to do with dealing with money in a single currency. You would be amazed how often square roots don't come up in this context!
Fractions show up as soon as you start doing currency conversions. (In fact the Euclidean algorithm for finding the GCD is believed to have been first developed by merchants for exactly this problem.) They are easy to add to a programming language, but you'd only use them in contexts (like finance) where square roots make no sense.
If you want to go beyond fractions to add square roots and so on, you can do algebraic numbers. This is a fairly specialized mathematical need, but Mathematica has done it perfectly well for decades.
For arbitrary real numbers, we're sort of stuck. We can come up with representations that can cover any real number that we can talk about. But we can't take 2 arbitrary representations of a real number and in finite time decide whether or not they are actually the same number. That said, Mathematica again solves this problem "well enough" for most practical purposes. See http://mathworld.wolfram.com/Ferguson-ForcadeAlgorithm.html for more.
depends. If you're running a simulation in physics, e.g. n-body problem, you can choose your parameters to be exact to start off with, and rescale your units to be exact. Moreover, even if you start with measurement error, the error moves in generally a predictable fashion, so it tends to be O(1). A floating point roundoff error is a martingale, with O(sqrt(N)) - unless you "always round up" or "always round down" which is O(N). In the initial domain, the measurement error dominates, but over time fp roundoff gets bigger.
It still depends. Many simulations in physics are of chaotic systems where the initial measurement error grows exponentially over time and quickly exceeds fp roundoff. Other simulations (for example this comes up in fluid mechanics) can have discretization errors feed back on themselves in an unstable way resulting in artifacts that quickly overwhelm the simulation.
This is a complex topic, with ongoing research across multiple fields of study.
That said, floating point is a "good enough" default for a surprisingly wide variety of situations.
On the contrary, you might as well accept imprecision and work with the level of precision you need throughout - or, if you don't know or need to adjust it, work with a symbolic representation.
Decimals do not cause any problems for computers. Computers are just a bunch of switches of states. The meaning of these states is completely up to us. For example, 4 switches creates 2^4 states (16 states). That means we could have those states represent the numbers 1-16. As far as I'm aware, the only reason we use base 2 numbers in computing (floats) is because there are mathematical shortcuts you can take when doing so. There is nothing forcing a computer to interpret those 16 states as x * 2^y instead of x * 10^y. That is a software choice.
It's just that top to bottom very few people are willing to trade the loss of speed for the increase in accuracy (not that decimal is great either, you still run into plenty of repeating fractions)
Or bcd or fixed point. But it all depends what you want to represent. For financial data bcd or fixed point encoded in integers is generally preferred over floating point because it's easy to make it behave the way people expect it to.
