35

While investigating the accuracy of floating point numbers, I've seen in a few places a statement similar to

"float and double are (designed for/used often in) engineering and scientific calculation"

From my understanding, the strength of floats and doubles are the amount of memory they use for their (good, but not perfect) precision.

I feel like I'm almost getting an understanding from this answer

"floating point numbers let you model continuous quantities"

I still am not convinced I understand. Engineering and Science both sound like fields where you would want precise results from your calculations, which, from my understanding, floating points do not give. I'm also not sure I follow what a "continuous quantity" is, exactly.

Can somebody expand on this explanation and perhaps give an example?

Community
  • 1
DoubleDouble
  • 603
  • 1
  • 5
  • 11
  • 2
    See http://floating-point-gui.de/ – Basile Starynkevitch Oct 21 '14 at 18:42
  • @BasileStarynkevitch I'm aware of how floating points work, I'm just confused on how that makes it good for "modeling continuous quantites", when floating point errors would add up over time. How can this be good over a more precise data type? – DoubleDouble Oct 21 '14 at 18:49
  • 47
    `Engineering and Science both sound like fields where you would want precise results from your calculations, which, from my understanding, floating points do not give.` In both Science and Engineering you only care about precision up to a certain point. Using infinite precision for every calculation is often unnecessarily expensive. What sets floating point apart from fixed point is that you don't have to commit to a certain number of decimal places - you can have really small quantities with a lot of decimal places or really large quantities with limited precision. – Doval Oct 21 '14 at 18:50
  • 1
    Related: http://programmers.stackexchange.com/questions/131107/handling-extremely-large-numbers-in-a-language-which-cant And see the answers in: http://programmers.stackexchange.com/questions/202843/solutions-for-floating-point-rounding-errors –  Oct 21 '14 at 18:51
  • I completely agree with @Doval. Most "Engineering" and numeric methods formulas come with a second set of formulas that give the applicable situations and precision boundaries. Our physical constants are also known *to a certain precision*, and only a part of that precision is used in software (one of the reasons being that those "constants" are being updated with more and more precise experiments) – Ordous Oct 21 '14 at 18:59
  • 24
    To add to the points made above, not only do you not care about precision beyond a certain point, you *can't* get arbitrarily precise results because many of your inputs are measured quantities that have some inherent error. –  Oct 21 '14 at 19:24
  • 2
    It's also wroth pointing out that it's not a given that the rounding errors will continue to accumulate either. It depends on what you're doing and how you're doing it; there's [an entire field](http://en.wikipedia.org/wiki/Numerical_analysis) dedicated to that. – Doval Oct 21 '14 at 19:52
  • http://meta.programmers.stackexchange.com/questions/6483/why-was-my-question-closed-or-down-voted/6490#6490 – gnat Oct 21 '14 at 20:36
  • 1
    @gnat I disagree that the question is overly broad. It's actually very easily answered, and the fact that all the answers and comments are in agreement (and indeed somewhat repetitive) is evidence that it is not simply a matter of opinion. – Charles E. Grant Oct 21 '14 at 21:11
  • 1
    @CharlesE.Grant maybe. Maybe it's more of **[Discuss this ${blog}](http://meta.programmers.stackexchange.com/a/6418/31260)** kind – gnat Oct 21 '14 at 21:16
  • @gnat Is there an improvement I could make to make it a better question for future viewers? – DoubleDouble Oct 21 '14 at 21:17
  • 1
    hard to tell, none comes to mind right now. You can ask for advice in [chat] (Whiteboard room) or at [meta] – gnat Oct 21 '14 at 21:19
  • 10
    Floating point isn't "random precision", the errors for various operations are predictable and well-known, and the errors for an algorithm can be worked out. If they're low enough (and in particular if your backwards errors are smaller than the uncertanties in your input variables) then you can be certain that your results are good (or at least that any problems with them aren't caused by floating-point error). – hobbs Oct 21 '14 at 22:13
  • You've never heard the expression "engineering accuracy"??? – Daniel R Hicks Oct 22 '14 at 02:06
  • 1
    Voting to close as "too broad." The answers provided and associated commentary are not covering any new territory that hasn't been covered by different questions on the site. It's becoming evident that a "good answer" would be too long for what can be reasonably expected from the site. –  Oct 22 '14 at 02:33
  • 1
    Mathematic real numbers are generally not computable (proof with a cardinality argument, related to [Cantor diagonalization](https://en.wikipedia.org/wiki/Cantor%27s_diagonal_argument)). – Basile Starynkevitch Oct 22 '14 at 08:51
  • Please see IEEE 754 : https://en.wikipedia.org/wiki/IEEE_floating_point defining the common technical standard for floating-point. The idea is that using this standard, one can eliminate part of the rounding errors so that they will be negligible compared to the measurement errors of the data you're computing with. – Florian Castellane Oct 22 '14 at 09:46
  • A lot of the time it's down to programmers being silly. – Lightness Races in Orbit Oct 22 '14 at 17:32
  • @LightnessRacesinOrbit: I'd say more down to compiler and framework vendors being silly. If floating-point hardware provides a means of storing values at whatever precision it uses internally (any decent hardware does), it should be easy for a compiler or framework to offer a datatype whose precision would be specified as being "whatever the hardware uses"; such a datatype would make it easy for programmers to write programs with consistent semantics. The lack of such a type forces programmers that want consistent results to jump through hoops to make their code run needlessly slow. – supercat Oct 22 '14 at 18:39
  • @supercat: Fixed point isn't hard. – Lightness Races in Orbit Oct 22 '14 at 19:03
  • @supercat -- That makes no sense. First off, if every computer used a different precision then designing portable code with reproducible results would be much more challenging. (In fact, we had that situation 40 years ago, with a dozen different FP standards, and it sucked.) Secondly, IEEE float is implemented by every major general computing platform, and is so standardized that implementing it is quite cheap and efficient. On most platforms doing FP multiplies/divides is faster than fixed point. Nothing about it forces programmers to write code that is "needlessly slow". – Daniel R Hicks Oct 22 '14 at 19:28
  • @DanielRHicks: Given 64-bit `double` values a, b, and c of arbitrary sign, write a method which will compute their sum accurate to +/- 1 ulp if the largest and smallest value are within three orders of magnitude. On my 1980s Pascal compiler, it's easy. `Result := a+b+c;` Can you offer any approach that's as fast on a platform which doesn't expose the underlying hardware type? – supercat Oct 22 '14 at 20:45
  • @DanielRHicks: By my understanding, one of the worst problems historically had been exactly what I'm complaining about now: calculations were performed using types which are not exposed to the programmer with deterministic semantics. On the x87 architecture, the fastest way to perform computations is generally to promote all operands to 80 bits, operate on them, and then store any results in whatever form is required. Rounding intermediate results to lower precision slows things down, and also often requires that code use additional calculations which wouldn't otherwise have been necessary. – supercat Oct 22 '14 at 20:51
  • 1
    @Doval's comment, although popular is misleading. Whether your floating point numbers express very large or very small quantities, the number of decimals of precision is still the same. – Octopus Oct 22 '14 at 23:06
  • 1
    @Octopus: The relative precision is constant within a factor of two; the absolute precision differs drastically. Which is more relevant depends upon the application. When multiplying two numbers, relative precision matters; when adding two numbers, absolute precision matters. – supercat Oct 23 '14 at 01:34
  • @Octopus It's difficult to explain the issue precisely in few enough words to fit in a comment. I know the mantissa has a fixed size, but for large enough exponents the difference between floating point numbers will be bigger than 1. That makes a difference when you're simulating, say, a large world - at some point you can only move in large increments. – Doval Oct 23 '14 at 12:03
  • The integers and the rationals are countable infinite (aleph-0) and the Reals are uncountable infinite (aleph-1) because of irrational numbers (pi, e). We cannot represent all of the integers or rationals on a computer (finite memory), much less the Reals :-) So we compromise on precision, and range. Floating point is a good compromise. – ChuckCottrill Oct 23 '14 at 23:54

9 Answers9

79

Computation in science and engineering requires tradeoffs in precision, range, and speed. Fixed point arithmetic provides precision, and decent speed, but it sacrifices range. BigNum, arbitrary precision libraries, win on range and precision, but lose on speed.

The crux of the matter is that most scientific and engineering calculations need high speed, and huge range, but have relatively modest needs for precision. The most well determined physical constant is only known to about 13 digits, and many values are known with far less certainty. Having more than 13 digits of precision on the computer isn't going to help that. The fly in the ointment is that sequences of floating point operations can gradually lose precision. The bread and butter of numerical analysis is figuring out which problems are particularly susceptible to this, and figuring out clever ways of rearranging the sequence of operations to reduce the problem.

An exception to this is number theory in mathematics which needs to perform arithmetic operations on numbers with millions of digits but with absolute precision. Numerical number theorists often use BigNum libraries, and they put up with their calculations taking a long time.

Charles E. Grant
  • 16,612
  • 1
  • 46
  • 73
  • 3
    Good answer. While the underlying functions may be perfectly continuous, which would require perfect precision to exactly model, the reality is that everything in science and engineering is an approximation. We'd rather have decent, useful approximations and accomplish something than infinite precision, for which we'd wait forever for many operations to complete. – Jonathan Eunice Oct 21 '14 at 19:55
  • 4
    @JonathanEunice You cannot exactly model the reality. The input for the model comes from measurements and you will probably never able to measure things so precisely that a native real number in modern computer/software (at the time) would limit it. In other words, you can have perfect model, software or mathematical, it doesn't matter. E.g. Calculate a volume of a box. `a*b*c` easy stuff, however you need to measure the dimensions which you cannot do with absolute certainty, thus you don't really need infinite precision of calculation anyways, just enough to be bound by measurement error. – luk32 Oct 21 '14 at 22:23
  • 2
    @luk32 We violently agree about most of those points. One can model some thing exactly (volume of a sphere, e.g.), but can never measure exactly. And reality never perfectly fits a perfect model. Better to get slightly imprecise, useful values/models than wait for perfect measurements or computations--something that will always be one step away. – Jonathan Eunice Oct 21 '14 at 23:32
  • 2
    “The crux of the matter is that most scientific and engineering calculations need high speed, and huge range” If I give you long time, you still cannot compute exactly because algorithms to compute exactly are widely unknown. And first of all, we cannot even represent numbers exactly. This is just a problem we do not know how to solve, neither quickly nor slowly. – Michaël Le Barbier Oct 22 '14 at 08:47
  • @MichaelGrünewald, we can't represent real numbers exactly, but we are able to solve problems to a close enough approximation that we can build structures a couple thousand feet high, identify genes in DNA, and rendezvous a satellite with a comet after two years in space. To paraphrase Randy Newman, that may not be exact, but it is all right. In fact we can represent rationals exactly using arbitrary precision libraries (subject to limitations of memory). – Charles E. Grant Oct 22 '14 at 16:07
  • That's a very big limitation to be subject to. If one were to choose a rational number drawn from the set of all rational numbers with equal probability, the chance of the selected number being representable in any arbitrary finite quantity of memory is essentially zero. Unless a process includes some kind of bias towards simple numbers, we simply cannot model it exactly. – Jules Oct 22 '14 at 16:40
  • @Jules You made a type - you mean real, not rational, number. As rationals are enumerable you can do it by storing their number in a series (though easier way is through 2 bignums AKA arbitrary precision arithmetic). – Maciej Piechotka Oct 22 '14 at 16:46
  • No, I really did mean rational... arbitrary precision arithmetic only works as long as you have enough memory to store the numerator and divisor. This means you can only work on a finite subset of rationals. In any arbitrarily chosen range of rationals there are infinitely many that you cannot represent exactly on any real computer system, and only a finite number that you can. Hence, for a randomly chosen rational in that range, the probability of it being representable is zero. – Jules Oct 22 '14 at 16:58
  • @CharlesE.Grant I am well aware of all that. The important point for the OP is that we do not use computations with perfect precision just because the corresponding computation methods do not exist. Of course, floating point arithmetic is faster than non-existant arithmetic. – Michaël Le Barbier Oct 22 '14 at 18:54
  • It should probably be noted that in science / engineering you have measurements that you take to start calculations. Those measurements very rarely have more than 6 digits of precision. – Martin Thoma Oct 27 '14 at 17:57
  • @CharlesE.Grant - We can represent many real numbers exactly, using continued fractions and lazy algorithms that can deliver any desired degree of precision. See Gosper's algorithm for arithmetic using continued fractions. Numbers like Pi, e, sqrt(2), etc. can be manipulated exactly. Results of functions like log and tangent as well. – Paul Chernoch Apr 24 '15 at 17:45
  • @PaulChernoch, sure, but there is a performance cost to that. Nobody is going to re-write their finite element modeling package or their machine learning library to use a continued fraction representation or even arbitrary precision rationals because they can't afford the performance penalty. As I said in my answer, scientific computing is a trade-off among precision, range, and speed. – Charles E. Grant Apr 24 '15 at 17:57
  • @MichaelGrünewald, What you say is certainly true, but I think primarily of interest to mathematicians and their fellow travelers. The subtext of the original question is that many work-a-day programmers find floating point arithmetic baffling. I suspect this is because they mostly work with computations that *can* be made with perfect precision using integers from a finite range (think bookkeeping and inventory). Floating point arithmetic is confusing for them because they don't appreciate that they've entered a problem domain where perfect precision is impossible. – Charles E. Grant Apr 24 '15 at 18:25
  • @CharlesE.Grant Well I think this refers quite to the plain text of the question, which mentions *scientific computing*. In scientific computing, one will not go anywhere without the exponential function, and so, rational numbers or any countable class of numbers will not allow us to compute exactly. You are definitely right in your explanation why floating point arithmetic is confusing for “them”. Few people realise that most numbers cannot be computed and how much mathematics is about reasoning on quantities despite them not being computable! – Michaël Le Barbier Apr 24 '15 at 23:41
30

What alternative do you propose?

Continuous quantities are represented using real numbers in mathematics. There is no data type that can encode every possible real number (because reals are uncountable), so that means we can only pick a subset of those real numbers that we're most interested in.

  • You can pick all computable reals, which is similar to what computer algebra systems (CAS) do. The problem is that it becomes rapidly unfeasible as your expression tree grows larger and larger. It's also very slow: try solving a huge system of differential equations in Mathematica symbolically and compare against some other floating-point based implementation and you'll see a dramatic difference in speed. Additionally, as Jörg W Mittag and kasperd have pointed out: you don't even have decidable equality/comparison operations.

  • You could use exact rational numbers, but that doesn't really work for many applications because you need to calculate square roots or cosines or logarithms etc. Furthermore, there is also a tendency for rationals to become increasingly complex and thus requiring more space to store and time to process as you perform more and more calculations on them.

  • You could also use arbitrary-precision decimals, but then even something as simple as division won't work because you get infinitely repeating digits. You can also run into the issue of increasing complexity as you perform more similar to rational numbers, though to a lesser extent.

So you'd be forced to use approximations at some point, in which case that's exactly where floating-point numbers do best. Floating-point numbers are also of fixed width (unlike all the other 3 data types mentioned earlier), which prevents the complexity increase as you perform more and more calculations on them.

Rufflewind
  • 2,217
  • 1
  • 15
  • 19
  • 1
    One of the best answers, I overlooked it before writing mine. – Michaël Le Barbier Oct 22 '14 at 08:56
  • 8
    Plus, there is the slightly inconvenient fact that you cannot even tell if two computable reals are equal. – Jörg W Mittag Oct 22 '14 at 09:32
  • 1
    Wouldn't using all computable reals run into a problem with comparisons? I'm pretty sure you can't compare arbitrary computable reals without solving the halting problem. – kasperd Oct 22 '14 at 16:45
  • @kasperd: I think that would depend in some measure upon what operations one was allowed to use in the computation, though I'm not sure how rich a set of computation types one could have and still guarantee that any two arbitrary results that could be produced in a finite number of operations could be compared in bounded time. Algebraic types would almost certainly meet that criterion, but I don't know if ln(x) and exp(x) functions could be added and still meet it. – supercat Oct 22 '14 at 21:48
  • You can support arbitrary precision arithmetic (add, multiply, subtract, divide), irrationals (like √2), well known transcendentals (like Pi and e), trig functions, etc. using continued fractions. See Gosper's algorithm in HAKMEM. When finished, you can perform lazy evaluation to get a floating point approximation to the desired precision. – Paul Chernoch Apr 24 '15 at 17:52
14

Your proposition about science is wrong, Engineering and Science other then Math don't work with exact precise results. They work with a precision factor which is built into how many digits you show.

The key term you need to understand here is: significant figures. The significant figures of a number are those digits that carry meaning contributing to its precision.

Which basically means if I state that something is 12 centimeters longs, it can actually be somewhere between 11,5 and 12,5 centimeters long. If however I state that something is 12,00 centimeters long it can be somewhere between 11,995 and 12,005 centimeters long.

Just as an illustration, if you take a measurement tape and measure your living room. Even though you may find that it 6 meters 25 centimeters wide, you know that your tape measurement wasn't accurate enough to tell anything about the millimeter-accuracy or nano-meter-accuracy.

Pieter B
  • 12,867
  • 1
  • 40
  • 65
  • @leftaroundabout what do you mean math (as in mathematics) isn't science? In my book it is. – Pieter B Oct 22 '14 at 10:50
  • 2
    @PieterB: Maths isn't Science. It's Philosophy. Science it the act of forming an understanding of our physical world. Philosophy is the act of understanding how ideas work in an ideal world. – slebetman Oct 22 '14 at 12:07
  • I think science usually prefer to work with explicit confidence ranges rather than significant figure. – Taemyr Oct 22 '14 at 12:10
  • @slebetman Besides that it has nothing to do with my point in my post, if math is a science or not I can't help to drop a quote : Nature is innately mathematical, and she speaks to us in mathematics. We only have to listen. Because nature is mathematical, any science that intends to describe nature is completely dependent on mathematics. It is impossible to overemphasize this point, and it is why Carl Friedrich Gauss called mathematics "the queen of the sciences." – Pieter B Oct 22 '14 at 12:17
  • That quote being [from here](http://arachnoid.com/is_math_a_science/index.html). A good read and plenty to discuss about, but not here since indeed it has nothing to do with your post or this question. – leftaroundabout Oct 22 '14 at 14:32
  • @slebetman You appear to say "science = natural science", which is not the consensus to say the least. Mathematics and philosophy share a foundation in logic, and philosophy has a sub-discipline concerning the discussion and interpretation of mathematical study and results, but the two are nevertheless quite distinct fields of study. Mathematics does not use the scientific method though, since it's not empirical and doesn't even begin to attempt to make statements about the observable universe (I hope I've phrased this in a way that includes Platonists). –  Oct 22 '14 at 17:29
7

Note that floating point numbers are basically the same as scientific and engineering notation, the standard way for humans to write numbers in math and science. In these fields, there's not a great need for extreme precision, but there's often a huge range.

To pick a random example from my physics homework, I recently had to work with the mass of an electron, which is roughly 9.11 * 10^-31 kg. I don't care a lot about the precision; it could easily be 9.12 for all I care. But I care about the exponent and don't want to have to write out 0.0000...911 kg, so I use scientific notation.

Similar reasoning applies in scientific and engineering computing: there's a huge range, but we don't want to have to store and work with very large numbers, so we store a normalized value and an exponent, which is smaller and faster to work with.

raptortech97
  • 448
  • 1
  • 4
  • 9
6

Floating-point numbers also have several properties that lend themselves well to computing certain types of scientific results. Most notably, precision is inversely proportional to magnitude, just like in scientific notation, so you can represent both small differences close to zero and larger differences much farther away.

Goldberg's paper is probably the most famous analysis of the properties of floating-point numbers (and should be required reading if you care about this sort of thing), but Kahan's papers I think do a better job of explaining the rationale behind many of the subtle design issues.

In particular, Kahan's diatribe about Java's implementation of floating point, while quite inflammatory, makes several good points about why IEEE-754 semantics are useful, and Much Ado About Nothing's Sign Bit explores the rationale for signed zero in considerable depth.

Daniel Pryden
  • 3,268
  • 1
  • 21
  • 21
  • I've not read Kahan's entire paper yet, but he seems more polite than I would be. Java could have had numerics which were more useful and performed faster than what it actually has if it had added a `real` type which would take three stack entries to store, and would represent the machine's natural computational precision; the value could be stored as an 80-bit float + 16 bits padding a 64-bit float + 32 bits padding, or 64 bit mantissa, 16 bit exponent, and 16 bits for sign and flags [for non-FPU implementations]. – supercat Oct 21 '14 at 23:17
  • Specify that `float` and `double` are storage formats, and `real` is the computational format. In many systems with no FPU, working with a mantissa, exponent, and flags that are on word and half-word boundaries would be faster than having to unpack and repack doubles with every operation. – supercat Oct 21 '14 at 23:19
2

TL;DR We do not know how to compute most functions with perfect precision, there is therefore no point representing numbers with perfect precision.

All of the answers so far miss the most important point: we cannot compute exact values of most numbers. As an important special case, we cannot compute exact values of the exponential function — to cite only the most important irrational function.

Naive answer to the naive question

It seems your question is rather “there is exact arithmetic libraries, why don't we use them in place of floating point arithmetic?” The answer is that exact arithmetic works on rational numbers and that:

  • Archimede's number — the pedantic name of π — is not rational.
  • Many other important constants are not rational.
  • Many other important constants are not even known to be rational or not.
  • For any non-zero rational number x the number exp(x) is irrational.
  • Similar statements hold for radicals, logarithms, and a wealth of functions important to scientists (Gauss's distribution, its CDF, Bessel functions, Euler functions, …).

The rational number is a lucky accident. Most numbers are not rational (see Baire's theorem) so computing on numbers will always bring us out of the rational world.

What is computing and representing a number?

We may react by saying “OK, the problem is that rational numbers were not such a great choice to represent real numbers.” Then we roll up our sleaves fork Debian and devise a new representation system for real numbers.

If we want to compute numbers we have to pick a representation system for real numbers and describe important operations on them — i.e. define what computing means. Since we are interested in scientific computing, we want to represent accurately all decimal numbers (our measures), their quotients (rational numbers), values of the exponential functions and some funny constants, like Archimede's number.

The problem is that the only way to perfectly represent numbers in such a system is to use symbolic form, that is, not to compute anything at all and work with algebraic expressions. This is a rather crippled representation of real numbers, because we cannot reliably compare two numbers (which one is greater)? We cannot even easily answer the question “Is the given number equal to 0?”.

If you look for more precise mathematical definitions and problems, look for rational numbers, transcendental numbers, best approximations, and Baire's theorem, for instance.

Michaël Le Barbier
  • 2,025
  • 14
  • 25
  • I think this is a great answer, just not to this question, insofar I am not confident that the asker will understand the points you are making. That and you are being quite glib with the inexact representation of \Real or \Complex numbers by a finite digital representation (regardless of dynamic or static bit width). That is all entirely true, but beside the point. Kudos for *not* robotic-ally citing Goldberg. :) And Baire's theorem is not part of the usual rhetoric found on Programmers or StackOverflow. – mctylr Oct 22 '14 at 21:49
0

Because

1) The authors make the assumptions that "engineering and scientific calculation" measure real-world physical quantities

2) Physical quantities are continuous, and exactly as you state "floating point numbers let you model continuous quantities"

.. and the rest of my answer is summed up nicely by Rufflewind, so I'm not going to repeat that here.

Community
  • 1
Jan Doggen
  • 1,140
  • 4
  • 16
  • 22
0

Floating point numbers provide relative accuracy: they can represent numbers that are at most a small percentage (if you want to call something like 0.0000000000001% a percentage) away from any accurate number over a wide range of numbers. They share this trait with a slide rule, though the latter does not get better than something like 3 digits of accuracy. Still, it was quite sufficient for working out the static and dynamic forces of large structures before digital computers became commonplace for that, and that's because the material constants also show some variation, and picking constructs that are reasonably benign against material and construction differences will tend to make the maximum loads and weak points reasonably identifiable.

Now "accuracy" is a useful feature for many numbers representing measurements and/or magnitudes of physical properties.

Not everything in science/engineering belongs in that category. For example, if you are using number theoretic transforms for multiplying large numbers or Galois fields for manipulating error correction polynomials, there is no such thing as a small error: any single bit error during processing will lead to results that are quite indistinguishable from completely random noise.

Even in those areas one can work with floating point numbers (like using complex FFTs for doing convolution) if one keeps track of the accumulation of errors and makes sure that the floating point errors do not accumulate enough magnitude to possibly even flip a single bit in the actual entities that they are an approximations of. For such approximations, fixed point processing would likely be more appropriate but floating point units in the field tend to provide faster operation and a larger number of usable bits.

Also programming languages like C or Fortran make it surprisingly hard to access basic operations like mixed precision multiplication and division or a carry bit for addition/subtraction, and those are basic building blocks for going beyond limited precision integers.

So if you can map operations to floating point numbers, you tend to have reasonably powerful hardware at your disposal these days and you can reasonably well specify your algorithms in one of today's general purpose programming languages.

user153796
  • 1
0

I think this can be answered by addressing what application float/double data types are not suitable for.

When you need to make sure that you can represent a number accurately with a specific number of digits, then floating point numbers are inappropriate, because they represent the numbers as powers of 2, instead of powers of 10, as is how we represent numbers in the real world.

So one domain where floating point data types should not be used is that of finance*. For the core system of e.g. a bank, it would be completely unacceptable if an amount that should have been $100000.01 suddenly becomes $100000.00 or $100000.02.

Such a problem could easily occur when using floats, especially if the number was the result of one or more calculations, e.g. calculating the sum of all transactions in an account.

Engineering and scientific calculation are domains where these relatively small rounding errors are acceptable. Users are normally aware that all numbers have a limited precision, and they often work with a number of significant digits. But most importantly they have a well defined relative precision, i.e. they have provide the same number of significant digits, both for very large numbers, and for very small numbers.

* I did once work on a financial application where floats had been used to represent values, and as a consequence, rounding errors were introduced. Fortunately, this specific bug wasn't critical at all, the users did complain about calculation errors in the program. And this led to a different, far worse, effect: the users started loosing faith in the system.

Pete
  • 8,916
  • 3
  • 41
  • 53