Floating point formats: Java/C/C++, PPC and Intel platforms

The 32 bit float formats are just byte order reversed on the two Macintosh platforms. Your just need to change the byte order as your go from Intel to PowerPC.

See the header file MacTypes.h. In it, you will find:

Base floating point types

Float32 32 bit IEEE float: 1 sign bit, 8 exponent bits, 23 fraction bits
Float64 64 bit IEEE float: 1 sign bit, 11 exponent bits, 52 fraction bits
Float80 80 bit MacOS float: 1 sign bit, 15 exponent bits, 1 integer bit, 63 fraction bits
Float96 96 bit 68881 float: 1 sign bit, 15 exponent bits, 16 pad bits, 1 integer bit, 63 fraction bits

Yes,

It is IEEE format. I move binary files back and forth between PPC, Intel, SUN, SGI, IBM, COMPAQ platforms and run in all those places with C, C++ and fortran with no problems - after correctly rotating the bytes. I have not tested it with Java, but my Java programs run as fast as you would expect and that would be impossible in an emulation mode - the bit pattern must be the same. The only machines that I know of that do not use IEEE are some of the CRAY machines.

I've been writing a program in XCodes implementation of GNU C++ and judging by the accuracies of the results and stepping through the variables when it's running, it looks like all floats, doubles and long doubles are rounded to 6 digits before calculations, no matter what sizeof() the type has. With this low precision, the program I'm writing is worthless. I'd tried to #include MacTypes.h and it gave me Float96, but then gave me weird compile errors like disabling the "<<" operator for cout! Rather than hassle more with it, can you recommend where I can get a [set of] header[s] that will give me either working long doubles or, better, Float64, Float80 or Float96? Thanks and mahalos.

Blue & White G3 Mac OS X (10.4.6) Developing for 10.2.8 - 10.4.6

I think you might be confusing the precision of the variables with the precision of whatever is displaying them.

What are you writing that you think needs 96 bit float?

This is compiler-dependent, not platform-dependent.

¡¡¡ Belay this all, and my apologies

I was making an error so stupid and obvious that I didn't even pick it up in more than a dozen passes:

I used the wrong value for a global constant that screwed up all the results of all my calculations. After I put in the correct value, everything calculated with beautifully accuracy. "double" and "long double" are quite sufficient for what I want.

Sorry... sometimes it takes going out on a stage in front of an audience to realize that your shirt is on backwards 😉


PS The precision of the output was never a question. I knew that to be an artifact of cout.

Blue & White G3 Mac OS X (10.4.6) Sometimes run on 10.2.8

I am not sure that Rosetta floating point works the same as PPC floating point. I was using RealBasic (a PPC basic compiler) and moved one of the my compiled applications to a MacBook Pro and floating point comparisons that had been exact on the PPC stopped working under Rosetta. I changed the code to do an approximate comparison (i.e. abs(a -b) < tolerance) and this fixed things.

I reported the problem to the RealBasic people and thought nothing more of it until I fired up Adobe's InDesign and not being used to working with picas, changed the units of measurement to inches. The default letter paper size was suddenly 8.5000500050005 inches instead of the more usual 8.5! This was not a big problem, but it appears that all of InDesign's page math is running into some kind of rounding errors.

The floating point format is almost certainly IEEE, and I cannot imagine Rosetta doing anything other than using native hardware Intel floating point. On the other hand, there is a subtle difference in behavior.

I am posting this here as a follow up, but I am also going to post this as a proper question in the forum. If you have to delete one or the other of these duplicate posts, please zap the reply, not the question.