Michael
Michael

Reputation: 5897

integers or floating point in situations when either would do?

Moving a discussion on relative merits of integers and floats into a separate question. Here it is: what is your preference between an integer type or a floating point type in situations that are neither inherently integral nor inherently floating point? For example, when developing geometric engine for a well-conntrolled range of scales would you prefer integer coordinates in the smallest feasible units or float/double coordinates?

Upvotes: 0

Views: 198

Answers (2)

Eric Postpischil
Eric Postpischil

Reputation: 222362

Some reasons to prefer floating-point are:

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

Some reasons to prefer integers are:

  • Integer arithmetic may be faster or have greater throughput on particular hardware.
  • Integer arithmetic provides greater precision for the same number of bits.
  • Some support for integer arithmetic may be better in some language implementations. For example, default settings or low-quality software with high-precision settings may display floating-point values incorrectly, but software rarely prints integer values incorrectly.

I considered ways to list certain “features” of integer arithmetic as reasons to use it, but, upon examination, they are not actual features:

  • One might say that integer arithmetic is exact until it overflows. But this is false because integer arithmetic, or fixed-point arithmetic (integer arithmetic with a scale), is not exact. Calculating monthly interest given an annual rate is usually inexact. Converting between currencies is not exact. Physical calculations are not exact. Coordinate scaling is not exact.
  • To the extent that integer arithmetic is exact until it overflows, it is not a feature. Most machines allow integer arithmetic to overflow without warning. So, when integer arithmetic fails, it fails spectacularly. (With IEEE 754 floating-point, you can design exact arithmetic and request a trap or flag if inexactness occurs.)

Upvotes: 2

youdontneedtothankme
youdontneedtothankme

Reputation: 672

Here are some ideas to when NOT to use floats/doubles and stick to integers/fixedpoint

  • You need to compare for equality
  • You need predictable rounding errors or no rounding errors. (like when handling money)
  • Size of precision must be absolute, and not relative to the magnitude of value (Sometimes when handling dates or spatial coordinates. Time intervals or distances can normally use floats)

Upvotes: -1

Related Questions