1

This question is very simple. It is related to but definitely not a dupe of:

Most unpatched Tomcat webservers are vulnerable, who's at fault?

Seen the amazing amount of things that can go wrong with floating-point numbers (including, but not limited to, different results on different architectures, wrong results when used incorrectly, two denial of services crashes affecting two different languages, etc.) I'm wondering a very simple question:

Are floating-point numbers used without an epsilon always a code-smell or a spec-smell?

(that is: should floating-point number really only ever be used for scientific computation and all the rest should be done using a fixed number of bits of precision?)

Community
  • 1
  • 1
SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
  • Note that I've got a 250 KLOC codebase here doing a lot of very impressive things (including monetary computation, graphing, etc.) and there's exactly **zero** instance of floating-point numbers in my codebase. – SyntaxT3rr0r Feb 11 '11 at 00:13
  • you want an opinion or some definite resource? my opinion is yes... but i feel like you want more – Scott M. Feb 11 '11 at 00:18
  • @Scott M.: I want an answer like the one Jimmy gave. I'd really like to know if I can consider every single appearance of floating-point in non-scientific computation like something totally retarded or not. To me it's, as you think too, a code smell. However Jimmy gave a good example where it may be acceptable. But then physics in games is kinda "scientific computation". :-/ – SyntaxT3rr0r Feb 11 '11 at 00:22
  • In addition to that I wanted to reuse the *coolest-tag-ever-on-SO* that I created for the other question ;) – SyntaxT3rr0r Feb 11 '11 at 00:23
  • 5
    The existence of a JVM bug in floating point hardly makes all use of floating point suspect. If someone found an obscure JVM error with an 'int' value tomorrow, would you propose to stop using int? – bmargulies Feb 11 '11 at 01:13
  • 1) what do you mean "without an epsilon"? 2) floating point numbers have a fixed number of bits of precision -- 53 implicit for double. Do you mean keeping track of the precision after operations? – Artefacto Feb 11 '11 at 01:20
  • @Artefacto: yes, exactly. I mean keep track of the error. There's always an error when working with floating point numbers. And that error does propagate. – SyntaxT3rr0r Feb 11 '11 at 19:03

2 Answers2

5

No, they are absolutely not always a code smell.

In fact, in my line of work (low-level high-performance libraries), floating-point comparisons with a tolerance are a code smell: they indicate that the programmer either does not understand floating point, or does not fully understand the numerics of the algorithm that they are implementing, which sets off big warning bells that I should be reading over the rest of the code very, very closely.

That's not to say that they should never be used. There are lots of situations (maybe even most situations) where it's the right thing to do. It's only to say that all hard-and-fast rules are stupid, this one included.


To your clarified question: "should floating-point number really only ever be used for scientific computation and all the rest should be done using a fixed number of bits of precision?"

Of course not. That would be a monstrous engineering burden, and grossly inefficient to boot. It's just as easy for an inexperienced programmer to shoot himself in the foot with integer arithmetic (overflows, division-is-truncation, out-of-bounds array access, etc, etc) as it is with floating point. Floating-point is an enormous convenience for the vast majority of programmers; if it wasn't it wouldn't be used.

As with all things, take the time to learn about your tools, and use the right tool for the job.

Stephen Canon
  • 103,815
  • 19
  • 183
  • 269
  • 1
    how comes you can store numbers that are approximation and don't care about what the error is? I realize you obviously know your subject but an inquiring mind wants to know. What kind of operation do you do on these floating-point numbers and how comes you don't have to take care of the error propagation? – SyntaxT3rr0r Feb 11 '11 at 19:01
  • @SyntaxT3rr0r: this is the nut of the issue: "how comes you can store numbers that are *approximation*...". One **can** view floating-point numbers as approximations, but you don't need to. A floating-point number is *exactly* equal to some number, not a vague fuzzy interval (just like the integer 3 is really 3, and not an approximation of numbers between 3 and 4). – Stephen Canon Feb 11 '11 at 19:11
  • Rounding error propagation needs to be accounted for, of course, but in the libraries that I work on, we typically have known tight bounds on the rounding errors incurred, and software is carefully designed to control or eliminate the accumulation of rounding error. Much use of epsilon tolerances is to account for rounding error when it cannot be controlled or is unknown -- that's not he situation that I typically find myself in. – Stephen Canon Feb 11 '11 at 19:14
  • 1
    can I conclude that you're working on scientific applications? You obviously have knowledge on the issue and to me this seems *very* different than someone using some floating-point library to parse HTTP headers! Maybe this could be rephrased to: *"Are floating point numbers used in non-scientific application without an epsilon always a code smell?"* – SyntaxT3rr0r Feb 12 '11 at 17:38
  • @SyntaxT3rr0r: no, I don't work on scientific applications (though I am a scientist by training). I'm a system library writer, and my code gets called by developers of all sorts. – Stephen Canon Feb 13 '11 at 00:21
1

sometimes there's really no need for precision. Game engines use floating points for rendering all the time. Likewise, you wouldn't do monetary computation with floats, but it's not a problem writing a graphing system with floats.

The problem comes when you conflate two different sets of data (one non-precise, one precise (or more precise)) For example, game developers often wind up using the same coordinate system for their world-coordinates as they do for the rendering, and then when the world gets huge, their single-precision floats start showing major rounding errors. The tolerance for a full global-location coordinate isn't the same as the tolerance in a 2D-local-area-to-3D-screen-space coordinate system.

Jimmy
  • 89,068
  • 17
  • 119
  • 137