RESOLUTION:

Post #73,049 by admin 1/6/03 7:34:23 PM Reply	RESOLUTION: I heart CrisR ;-) The FPU does indeed run in 80 bits; this is the default. One can set the FPU precision using <fpu_control.h> like so: \n unsigned int cw;\n _FPU_GETCW(cw);\n cw &= (~_FPU_EXTENDED);\n _FPU_SETCW(cw \| _FPU_DOUBLE);\n Basically, turn off extended precision, turn on double precision. I made the mistake of not turning off extended at first. time_spent += 15 minutes :-P The alternative is to use temporary variables (declared volatile) for intermediaries to force a conversion. This is a known issue for Motorol 68X chips, Intel, and AMD CPUs... the fact that 2.95.x and VC++ don't bug is incidental to their assembler code construction. Thanks for all the help, everyone! Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
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..."
Post #73,064 by deSitter 1/6/03 9:03:59 PM Reply	Re: RESOLUTION: Stupid me - I assumed it was well known that Intel floating point was fairly standardized on 80 bits - long double. The Intel FPU is very standard. The 80 bit BCD format is IEEE. It's commonplace to expect accuracy to 16 digits in basic things such as special functions. The 80 bit format gives added range for error accumulation. You should not have to worry about something for which there is no compiler warning. This is a real problem if that is the actual resolution. -drl
Post #73,085 by ChrisR 1/6/03 9:53:48 PM Reply	Historically speaking... ...you'd choose the precision of the floating point operations for the compiler, and the compiler would attempt to enforce that precision. In a lot of old embedded apps, you'd choose to run everything as single precision (32 bits) so that everything could fit into a 4 byte space. When the FPU's came out, they leapfrogged the double precision (64 bits) and went for double long precision (80 bits). Now, 80 bits can fit in 10 bytes, but most modern processors like even 4 byte boundaries, so most of the access for 80 bits is usually 12 bytes in length (with 16 spare unused bits). I know on the MC6888x, one can move things in and out of the FPU in whatever resolution is desired. So you can have extended precision throughout the compiler enforced if the compiler writer so desires. Of course, this does eat processor cycles and memory since you've increased the access by 1/3. One thing I couldn't find was the correlary in the intel x87 instruction set to allow you to FLD (load) and FST (store) in extended precision (i.e. 12 bytes). The default is 8 bytes, unless otherwise specified. I'd be surprised if the later versions of the FPU didn't provide that facility, I just couldn't find it. With that said, the extended precision real (12 bytes, 80 bits) format was not a standard in the K&R or ANSI C specifications. The C'99 spec does have the format as a base type, but I'm not sure that the C++ standard has adopted it yet. From a pure C perspective, the standard is very much influenced by C since the C++ compilers are compiling a lot of C code.
Post #73,087 by deSitter 1/6/03 10:04:39 PM Reply	Re: Historically speaking... The whole point of 80 bits is to have a cushion against error accumulation so that you can have double precision with confidence. The fp stack are all 80 bit. Here's the reference: [link\|http://212.247.200.167/asm/asm_deformed_us/documentation/masm/mmr61/Chap_05.htm\|big link] FLD/FILD/FBLD Load Pushes the specified operand onto the stack. All memory operands are automatically converted to temporary-real numbers before being loaded. Memory operands can be 32-, 64-, or 80-bit real numbers or 16-, 32-, or 64-bit integers. -drl

Welcome to IWETHEY!