Why is floating point preferred over long for precise tasks?

Question

Why is float preferred for precision? Couldn't very large integers to represent the precision that float give and be deterministic across all machines? For example, an object moving 0.48124 meters in floating point could instead be represented by an object moving 48124 micrometers in int or long.

Answer 1

Actually, in some applications integers are preferred for a number of reasons. In particular, integers, unlike floating point, are translation-invariant:

x1 - x2 == (x1 - displacement) - (x2 - displacement)

This is very important in some geometric engines. For example, if you are computing a large grid of identical shapes determined by some parameter then you compute sets of identical parameters and for each set compute what happens in one of its representative and copy the results over to other shapes with the same parameters. Translation invariance ensures that such optimization is faithful.

Floating point, on the other hand, is NOT translation-invariant:

0.0002 - 0.0001 != (0.0002 - 1000000) - (0.0002 - 1000000) // this example in single precision

This causes sometimes very nasty surprises that are difficult to debug.

Answer 2

Although many kinds of code could use some kind of fixed values more efficiently than floating-point, different kinds of code and different situations have different requirements. Some situations require storing numbers from zero to a million accurate to one part per thousand; others require storing numbers from zero to a one accurate to one part per billion. A fixed-point format which is barely adequate for some purposes will be vastly overkill for others. If a language can efficiently support working with a numbers stored in a wide variety of different formats, fixed-point math can have some pretty huge advantages. On the other hand, it's generally easier for a language to support one to three floating-point formats than to support the many fixed-point formats that would otherwise be necessary. Further, unless a language makes it possible for a single routine to work with a variety of fixed-point formats, use of general-purpose math routines is apt to be difficult. Perhaps compiler technology has advanced to enough that using a wide variety of fixed-point types might be practical, but hardware floating-point technology has advanced enough to largely obviate the need for such a thing.

Answer 3

The degree of deterministic behavior is independent of the data representation. It just takes a longer specification to precisely define floating point math than integer math and is more confounding to implement.

IEEE floating point strives to make floating point deterministic across all machines.

Integers could be 1's or 2's compliment and various widths and thus not deterministic for certain calculations. So integer math, unto itself, can troubles.

Yes, big integers could, and have been used as OP suggests. But the F-P benefits, as @Eric Postpischil points out, are numerous. Big ints are used in select situations including cryptography.

Watch for upcoming decimal floating point standards to deal with issues like banking.

Answer 4

Floating-point is preferred over integers for some calculations because:

• When you multiply in a fixed-point format, the product has a new scale, so it must be adjusted or the code must be written to account for the changed scale. For example, if you adopt a format scaled by 100, so that .3 is represented with 30 and .4 is represented with 40, then multiplying 30 by 40 produces 1200, but correct answer at the same scale should be 12 (representing .12). Division needs similar adjustment.
• When the integer format overflows, many machines and programming languages do not have good support for getting the most significant portion of the result. Floating-point automatically produces the most significant portion of the result and rounds the discarded bits.
• Integer arithmetic usually truncates fractions, but floating-point rounds them (unless requested otherwise).
• Some calculations involve a large range of numbers, including both numbers that are very large and very small. A fixed-point format has a small range, but a floating-point format has a large range. You could manually track the scale with a fixed-point format, but then you are merely implementing your own floating-point using integers.
• Many machines and/or programming languages ignore integer overflow, but floating-point can handle these gracefully and/or provide notifications when they occur.
• Floating-point arithmetic is well defined and generally well implemented; bugs in it have been reduced (sometimes by painful experience). Building new do-it-yourself arithmetic is prone to bugs.
• For some functions, it is difficult to predict the scale of the result in advance, so it is awkward to use a fixed-point format. For example, consider sine. Whenever the input is near a multiple of π, sine is near zero. Because π is irrational (and transcendental), the pattern of which integers or fixed-point numbers are near multiples of π is very irregular. Some fixed-point numbers are not near multiples of π, and their sines are around .1, .5, .9, et cetera. Some fixed-point numbers are very near multiples of π, and their sines are close to zero. A few are very close to multiples of π, and their sines are tiny. Because of this, there is no fixed-point format of reasonable precision that can always return the result of sine without either underflowing or overflowing.

You asking about floating-point versus long. A 64-bit integer might have advantages over a 32-bit floating-point format in some situations, but often the proper comparison is for comparable sizes, such as 32-bit integer to 32-bit floating-point and 64-bit integer to 64-bit floating-point. In these cases, the question is whether the benefits of a dynamic scale outweigh the loss of a few bits of precision.

Answer 5

It'd be 481.24 millimeters, which is part of where the problem shows up. Using integers (or long ints), you're very likely to run into a situation where you'll encounter some sort of rounding off. Maybe your program would guarantee that the smallest units you care about are millimeters, but it still leads to a somewhat ugly standard of writing units. It's not hard to figure out that 100000 millimeters == 100 meters, but it's not instantly obvious in the way that 100.000 is, and in an application where you might deal with mostly meters or kilometers, but you still want precision, is a lot more annoying to read than 3463.823.

In addition, there are plenty of situations where you do care about sizes beyond the inconveniently small, and while with floats you can trim the number of digits you display, the data is still there, so 3.141592653 (and so on up to whatever the floating point precision is) trimmed to 3.14 meters is a lot easier to deal with than 3141592653 nanometers