A caveat from Borland:

Post #73,052 by a6l6e6x 1/6/03 8:14:49 PM Reply	A caveat from Borland: [link\|http://community.borland.com/article/0,1410,17139,00.html\|Link.] When searching through real world data, we can't expect to always find exact matches. This is particularly true with floating point data, where the need to convert the numbers to a form the computer can store in binary leads to minor precision or round-off deviations. One solution is to consider the numbers equal if the difference between absolute values of the two numbers is less than some threshold amount. Simply put, direct comparisons of floating point data is not a good idea. Alex "No man's life, liberty, or property are safe while the legislature is in session."\t-- Mark Twain
Post #73,053 by admin 1/6/03 8:17:18 PM Reply	This was slightly different. Comparing floating point, I understand. If you are careful to stick to IEEE and are aware of the pitfalls, you should be ok. Non-deterministic behaviour, where putting the same calculation on each side of the == operation gives you a false... well, that's a little odd. Anyway, cause identified and fixed, and I've raised the flag that our MS stuff may or may not be correct. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #73,065 by deSitter 1/6/03 9:11:32 PM Reply	Re: This was slightly different. You can't just wave your hand like that! This is a real problem! APL compares numbers flawlessly since 1968 or so - float or not. You should NOT have to restrict the compiler to this or that assumption about the data UNLESS the compiler says "implicit conversion of double to float" or whatever if you don't. -drl
Post #73,075 by deSitter 1/6/03 9:36:04 PM Reply	Oh - to discover a real compiler problem ..is real cool! Once I had to write a big string processing program in FORTRAN (!!) so I stumbled across a problem with the IBM VS FORTRAN compiler regarding character data - man those guys hopped to it! A tape with the fixed compiler on it was in the lab the next day. It was a real "code red" for the compiler people - I was stoked about that :) -drl
Post #73,093 by admin 1/6/03 10:18:20 PM Reply	This is not considered a compiler problem by the GCC folks. Basically, it is this: IEEE designates that doubles should be held as 64-bits in memory. The Intel FPU, however, has 80 bits available for calculations. So it comes down to 1) being aware of the platform on which you are running, and 2) using a programming strategy that ensures the FPU is used as you need it to be used. For many applications, the extra 16 bits of precision is a good thing. For some applications, such as mine, a much greater control over rounding and precision is needed, and means are provided for making use of what you need to use. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #73,100 by Simon_Jester 1/6/03 10:34:21 PM Reply	Scott, that's a bug worthy of catching Damn. (Okay, so technically speaking it's probably not a bug...but still....)
Post #73,101 by admin 1/6/03 10:37:27 PM Reply	Fun to track down, at least. Since I learned a truckload about the subject matter. But again, the key piece was Chris' analysis of the ASM output. Reading through the FAQs and newsgroups (now that I know what to look for) it's also quite commonly reported as a bug. :-P Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!