I hang out in the MSDN forums on a regular basis, to see if there’re any questions that need answering. Usualy this is pretty unexciting, but every now and again, the asker really needs a reality check.
This thread came up some time ago, and it refuses to die.
The first thing that stands out is the title itself : ‘A very serious bug in MS Visual C++’. Sensationalist headlines like this almost always indicate a serious misunderstanding on the part of the author. It also indicates someone who is very, very sure of himself, because it excludes any possibility that he himself might be wrong.
The initial message itself was the classical example of ‘newbie discovers floating point numbers, it’s the end of the world as we know it’
If you haven’t bothered following the link, this is his gripe:
// and you will receive
//instead => a=111.567, b=111, c=0.567;
Yawn… another programmer who discovers that the floating point format does not guarantee fixed decimal correctness. The results are correct within the required precision of the floating point format, so all is well.
A is no 111.567 because it is a floating point number, and not a fixed point number. In any case, googling for ‘what every computer programmer should know about floating point’ will get you a paper that explains this issue in detail.
The original poster also explains that he has tested with every compiler from VC6 to VC2008, and they are all wrong. That in itself should have been a clue to think twice before using such a preposterous title.
Various people tried to explain the problem, but to no avail. Here are a handful of quotes from the OP (who is building an ERP system…) in the course of the discussion:
· Industry standard ??? I am not agreeing with you. There are laws of mathematics which must be respected by all. I can not agree that 111,567 is equal to 111.56699999999999 because of simple reason that it is not equal.
- You cover me with theory. Thank you. But things are much simpler.
- I think that something fundamental such as a declaration of fractional numbers and their actions should not be in so surrounded way. I think that the variables with floating point (‘double’) are unusable at this time, because they do not always give accurate results. And I would like experts from Microsoft, which deal with these issues, in some way to offer basic solution to this problem.
- All indicate the standard IEEE as a dogma. I am not familiar with the IEEE simply because I do not have time. But once the standard makes it impossible to use a certain type of fundamental variables and actions with them, maybe it is better to consider changes in the standard
But it gets even better! A second poster enters the discussion with the claim
‘I am absolutely astounded by two things here:
1. That this math bug is still floating around (I remember when it was a CPU issue)
2. That people here claim that it is not a bug in c++ in VS2003 or later’
Someone then explains that his SUN stations give the same results, just to indicate that this problem has nothing to do with compiler errors (or CPU dependency) whatsoever.
But it wasn’t meant to be. What did the second poster reply?
‘Thanks for testing it for me on the SPARC system.
Perhaps it is some bizarre feature of hardware-based floating point present in modern CPUs? This may account for why similar code compiled on older compilers (VS6) (who don’t have modern FCPU knowledge) yields expected results.
It’s a bit amusing when the system can’t even handle a result with one decimal place!’
If people are misguided, you can do your best to make them see. But if they want nothing to do with ‘reality’, then you can’t force them to understand.
After all, the powers of reason are futile in face of the powers of persuasion that allow someone to think every CPU, compiler and engineer / programmer / scientist in existence is wrong.