In the end of the day, it all comes down to the very simple question of how much precision is needed. If the difference between the "technically correct" and the "easy to implement" is less than a thousandth of a cent, one has to wonder if it's really worth the trouble. Of course, for some purposes, it really matters, but for the majority, it really doesn't. 'nuff said by now, I think…

No it doesn't. Then again I've primarily worked at large banks and insurance companies for the past 24 years. We never used floating point in financial calculations, we use fixed point decimals. The banking and insurance industry legacy goes back to Amdahl/Unisys/Honeywell/Burroughs/IBM computers, where either packed decimal, zoned decimal, binary-coded decimal, fixed point decimal were part of the architectures because frankly the business demanded it and knew floating point was not appropriate for financial calculations. So Unix and C/C++ never played much of a role in any of the financial shops I worked at, even though IBM C has been around and included decimals.

The only shops I've been in where floating point was widely used was a testing company where Fortran, SAS and SPSS were the main languages because all types of statistical data not finance was the business product. I did encounter a commercial inventory system that used floating points, but it gave the auditors fits because they could NEVER balance it. We had to write a parallel system to produce proper ledgers.

Today most of these shops are heavily into Java and they are still not using FP, they use BigDecimals.

There's a difference between back-office book-keeping and then the vast majority of things you would do when running models, making projections, risk management, and so forth. Keeping the books is a relatively small portion of what one does when trying to make money. It's unsurprising that at a bank (as opposed to an investment bank) the important task is exactitude of book-keeping. But the financial world is quite a bit bigger than just book-keeping…

Forecasting and modeling ain't keeping track of people's money, which is of course the context of the earlier quote.
And yet even our actuarial systems use fixed point decimal.

I'm not entirely sure why "dealing with money" (the context of the previous quote) "of course" excludes forecasting and modeling financial, or dare I say monetary, decisions.

Likewise the generalization "working in finance" doesn't exclude that virtually every industry deals in forecasting and modeling.

Since you agreed that floats work for forecasting and modeling, aren't you supporting the claim that floats are appropriate in many places? :wink:

I didn't say that either. There's a whole host of modeling, forecasting and other problems that floating point doesn't handle well.
http://www.cs.princeton.edu/introcs/91fl...

Getting back to muds, here's a mud float problem for you.
Check out this "robust" implementation of an R-TREE:
http://research.att.com/~marioh/spatiali...

Now I thought I'd implement a cool space game and I thought I might use this.
Then I noticed this implementation used floting point coordinates, and this naughty bit for collision detection:

for (size_t i = 0; i < m_dimension; i++)
	{
		if (
			m_pCoords[i] < p.m_pCoords[i] - std::numeric_limits<double>::epsilon() ||
			m_pCoords[i] > p.m_pCoords[i] + std::numeric_limits<double>::epsilon())  return false;
	}

	return true;

The region code employs the same comparison on rectangular vertices. This is a fundamental wierdness of floating point leading to erroneous and pointless comparisons. The epsilon is difference of the next integral value that can be represented greater than 1. The epsilon changes with the magnitude, in both directions from 1.0 (to max and down to 0). Only at < 2.0 is the above not a waste of time.

Furthermore the number of integral values that can be represented decreases with magnitude, that is there are far less integrals between 101 and 102 than between 1 and 2. Which makes floating point probably a poor coordinate system for a space game because the further from origin a ship is the greater the chance of a ships fixed range/propulsion systems (region comparison) falling into the gaps between integrals (epsilon).

"Many places" can encompass "many real word applications" and "many mathematical problems". If by "many places" you mean "many mathematical problems" then fine, but I would challenge you to provide "many places" more numerous and more relevant to many programmers than book keeping.

I thought the point of these forums was to help people with mud programming issues, not to try to defend irrelevant and possibly arbitrary use of a flawed numerical system?

Giving practical solutions and examples of why and when to use floats and when not to in mud contexts (as Tyche has done) is far more useful. Trying to prove you are not wrong* is pointless.

[EDIT: * which you are not (entirely), but you seem to be trying to prove that you are not]

Well flumpy, you tell me, since you started us down this road of how floats are so terrible for anything involving money. And no, I'm not talking about abstract "mathematical problems", I'm talking about very real-world, multi-billion dollar industries (where individual companies manage billions just to themselves). I'm a little tired of defending the idea that floats work just fine for many purposes in finance, when literally decades of empirical evidence supports it, as does plain common sense when you actually look at or understand the problems being solved. So, well, that's that for this.

(edit to fix typo)

That was on another thread, and I said "Be Careful". I never said "they are terrible".



I fail to see any evidence that you have provided, in this thread or the last one, empirical or otherwise, that demonstrates where it is actually ok to use floating points with financial calculations. I and others have demonstrated the problems that can occur, by providing coding problems, hard links to papers and books and anecdotes.

Perhaps you could give us the benefit of your emperically based experience and provide a real example of where it is ok, and some good techniques that can be used to prevent problems (apart from epsilon equalility, which has already been demonstrated to be flawed)?



Well you gave in on this more easily than I thought you would :D

Are you asking a serious question here? Let's try to not waste any more time, especially not on infantile jibes.

Why would asking you to provide relevant, real examples of where floats can be used and techniques that can be used be considered an infantile jibe??

That's just a little insulting.

Fine, consider this topic over.

I was referring to your last comment. As to your question, I already gave examples, such as forecasting and modeling. And yes, epsilon equality works just fine any time I've ever needed to use it.

And we have seen people on these forums that adamantly insist that parsing the results from a single read() call for ANSI sequences or TELNET commands "works for them" yet we know they're wrong. :)

Tyche explained it very well in one of his later posts. floats do not have infinite precision, and their fractional precision decreases with their magnitude. For small numeric ranges, they very well can have adequate precision for loose calculations, like most 3D rendering or general math. When you need exact values, though, floats fail to provide adequate guarantees. Even for relatively "small" numbers (for the financial world) you can easily start to get off-by-one-tenth errors in results that are totally unacceptable, and with larger numbers you start getting errors far more frequently and eventually get them in the digits left of the decimal!

You might think that being a few pennies off in a mid-size business' forecasting report is totally acceptable, but the financial types aren't going to agree. They see a report that is off from what their other tool said or what their hand-done calculations said and then they freak the hell out. Trying to explain that being slightly inaccurate in a "non-precision-critical" codepath saved you a little time and effort will NOT fly. You might, though – right out the door. If you really know the potential inaccuracy is acceptable and you know the range of values you're working with is suitable small, floats work fine even for money/ Those two conditions are very, very rarely true, though, especially when you have to take a financial officers' definition of "acceptable inaccuracy" and not just an engineer's.

I really don't think it's appropriate for you to tell me what the financial types in my firm are or aren't going to like, especially when empirically you are completely incorrect in your claim. It's especially strange that you are making noise about people being fired for using floats. This is all rather mystifying to me, frankly. I'm not sure what point you're trying to make. Mine is very simple: in the decades of existence of hedge funds, floats have worked just fine for very many purposes.

If your company made that decision, fine. Do NOT expect that to fly everywhere just because your firm didn't mind corners being cut. I play it safe and feel it to be far more constructive for others to instruct them to play it safe too – it takes very little extra effort to "do it right" (especially with modern C++ libraries and the _Decimal extension to C, or with other languages that have had built-in decimal number support for ages). While some firms might be willing to accept the precision of floating point math, ALL firms are willing to accept the precision of proper decimal math. :)

That's the thing – it's not just my firm. I've spoken to developers at several hedge funds, and they all say the same thing. When you're dealing with quantities in the millions or billions, a few cents here and there – assuming you even see the imprecision (and frankly I've only very rarely noticed any kind of problem, and usually it's to the 10^-6 level of precision) – just isn't important unless you're actually keeping the books, which is another ballgame entirely.

I have no objection to telling people not to use floats if they actually need high precision. It's something to be aware of and know about depending on what you're doing. But people are starting to shift away from the simple (and rather generally agreeable) "be aware of it" and to the more contentious "always avoid floats", which is simply not a correct statement – it depends on what exactly one is doing.

And FWIW, it's not just a simple, one-language environment. There are systems in C++, Java, Tcl, Python, Perl, and shell scripts. Having an easy common denominator that is completely acceptable isn't just a simple cop-out. It would be an utter waste of time to "fix" this problem we don't actually have.

Well, this sounds like you've changed your tune. Allow me to post cross-comment from another thread since you seemed to believe it's ok before:



This, to me, seems like a complete turn around. You were quite ready to blast me out of the water for even suggesting that using floats was a bad idea sometimes, when NOW you claim floats are a bad idea when book keeping. If you had pointed that out (using your vast empirical knowledge of the subject) I would have been more understanding, corrected my position on the subject, and possibly learned something new.



No one has said "always avoid floats"… who said that? Elanthis said that "his company prefers decimals" but nobody said what you are claiming.

So… apart from belittling my comments, claiming false victories and indeed being insulting by calling me juvanile, have you actually finished now because:

a) it sounds like you have climbed down from your "skeptical" position

b) all the comments you are now posting are still "I'm right", have no substance, and do not seem relevant to the topic

c) nothing you have said is actually helpful to anyone who is running a mud

.. or do you just like the text equivalent of the sound of your own voice?

And btw my last "infantile jibe" comment was actually supposed to be more of an encouragement. You never normally give up that easily.

Flumpy, what are you trying to achieve? I don't understand what you are "encouraging" me to do here. Are you trying to start/continue/encourage an argument? I wasn't giving up, I was doing what I should have done a while ago and am doing now, namely stopping this nonsense. It is true that I moved past my initial skepticism of your claim, as I have concluded that I was correct to doubt its general scope. I feel like my skepticism was met with extreme positions, and then my position was interpreted as the other extreme (namely that everybody should always use floating point calculations). I am not sure what kind of substance you are looking for as I have given many examples (perhaps you just don't understand what I'm talking about, in which case it would help if you asked me to clarify), and yes, I still feel that I am correct that floating point arithmetic is completely appropriate for very many purposes, as demonstrated by empirical experience. So really, is there anything else, or can we stop wasting time please? :thinking: