Timeline for Why are floating point numbers used often in Science/Engineering?
Current License: CC BY-SA 3.0
41 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Oct 28, 2014 at 11:01 | history | tweeted | twitter.com/#!/StackProgrammer/status/527052534095937536 | ||
| Oct 23, 2014 at 23:54 | comment | added | ChuckCottrill | 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. | |
| Oct 23, 2014 at 14:58 | answer | added | Pete | timeline score: 0 | |
| Oct 23, 2014 at 12:03 | comment | added | Doval | @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. | |
| Oct 23, 2014 at 1:34 | comment | added | supercat | @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. | |
| Oct 22, 2014 at 23:06 | comment | added | Octopus | @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. | |
| Oct 22, 2014 at 20:51 | comment | added | supercat | @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. | |
| Oct 22, 2014 at 20:45 | comment | added | supercat |
@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?
|
|
| Oct 22, 2014 at 19:28 | comment | added | Daniel R Hicks | @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". | |
| Oct 22, 2014 at 19:03 | comment | added | Lightness Races in Orbit | @supercat: Fixed point isn't hard. | |
| Oct 22, 2014 at 18:39 | comment | added | supercat | @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. | |
| Oct 22, 2014 at 17:32 | comment | added | Lightness Races in Orbit | A lot of the time it's down to programmers being silly. | |
| Oct 22, 2014 at 16:34 | answer | added | user153796 | timeline score: 0 | |
| Oct 22, 2014 at 15:26 | vote | accept | DoubleDouble | ||
| Oct 22, 2014 at 9:46 | comment | added | Florian Castellane | Please see IEEE 754 : 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. | |
| Oct 22, 2014 at 8:51 | comment | added | Basile Starynkevitch | Mathematic real numbers are generally not computable (proof with a cardinality argument, related to Cantor diagonalization). | |
| Oct 22, 2014 at 8:40 | answer | added | Michaël Le Barbier | timeline score: 2 | |
| Oct 22, 2014 at 7:36 | answer | added | Jan Doggen | timeline score: 0 | |
| Oct 22, 2014 at 2:54 | answer | added | Rufflewind | timeline score: 32 | |
| Oct 22, 2014 at 2:33 | comment | added | user53019 | 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, 2014 at 2:06 | comment | added | Daniel R Hicks | You've never heard the expression "engineering accuracy"??? | |
| Oct 21, 2014 at 22:44 | answer | added | Pieter B | timeline score: 15 | |
| Oct 21, 2014 at 22:29 | answer | added | Daniel Pryden | timeline score: 6 | |
| Oct 21, 2014 at 22:13 | comment | added | hobbs | 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). | |
| Oct 21, 2014 at 21:19 | comment | added | gnat | hard to tell, none comes to mind right now. You can ask for advice in Software Engineering Chat (Whiteboard room) or at Software Engineering Meta | |
| Oct 21, 2014 at 21:17 | comment | added | DoubleDouble | @gnat Is there an improvement I could make to make it a better question for future viewers? | |
| Oct 21, 2014 at 21:16 | comment | added | gnat | @CharlesE.Grant maybe. Maybe it's more of Discuss this ${blog} kind | |
| Oct 21, 2014 at 21:11 | comment | added | Charles E. Grant | @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. | |
| Oct 21, 2014 at 20:36 | comment | added | gnat | meta.programmers.stackexchange.com/questions/6483/… | |
| Oct 21, 2014 at 19:52 | comment | added | Doval | 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 dedicated to that. | |
| Oct 21, 2014 at 19:47 | answer | added | raptortech97 | timeline score: 7 | |
| Oct 21, 2014 at 19:24 | comment | added | user7043 | 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, 2014 at 19:12 | answer | added | Charles E. Grant | timeline score: 81 | |
| Oct 21, 2014 at 19:08 | review | Close votes | |||
| Oct 27, 2014 at 10:57 | |||||
| Oct 21, 2014 at 18:59 | comment | added | Ordous | 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) | |
| Oct 21, 2014 at 18:51 | comment | added | user53019 | Related: programmers.stackexchange.com/questions/131107/… And see the answers in: programmers.stackexchange.com/questions/202843/… | |
| Oct 21, 2014 at 18:50 | comment | added | Doval |
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.
|
|
| Oct 21, 2014 at 18:49 | comment | added | DoubleDouble | @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? | |
| Oct 21, 2014 at 18:42 | comment | added | Basile Starynkevitch | See floating-point-gui.de | |
| Oct 21, 2014 at 18:40 | history | asked | DoubleDouble | CC BY-SA 3.0 |