Hi, Thanks for the reply. The formatting code, such as it is, is below. It uses Martin Jansche's double.py (http://symptotic.com/mj/double/double.py) and then does some simple bit twiddling. I'm still hoping someone can help me find a way to use this format for arrays of float64s. Ken ================================ import double as _double def float_to_readable_string(f): ftype = _double.fpclassify(f) assert ftype == 'NORMAL' or ftype == 'ZERO' bits = _double.doubleToRawLongBits(f) exponent = (bits >> 52) & 0x7ff mantissa = bits & 0x000fFfffFfffFfffL sign = (bits >> 63) exponent -= 1023 pm = '+' if sign == 0 else '-' s = '%s(%+05d)0x%013x' % (pm, exponent, mantissa) return s def readable_string_to_float(s): assert len(s) == 23 pm = s[0] assert pm == '+' or pm == '-' sign = 1 if pm == '-' else 0 assert s[1] == '(' and s[7] == ')' e = s[2:7] exponent = int(e, 10) + 1023 assert 0 <= exponent < 0x7ff m = s[8:] assert m[:2] == '0x' mantissa = int(m, 16) bits = (sign << 63) + (exponent << 52) + mantissa return _double.longBitsToDouble(bits) Hans Meine wrote:
Am Dienstag, 08. April 2008 17:22:33 schrieb Ken Basye:
I've had this happen often enough that I found the first thing I did when an output difference arose was to print the FP in hex to see if the difference was "real" or just a formatting artifact.
Nice idea - is that code available somewhere / could you post it?
As a side note, there is a second big source of bug-like experiences with the x86 architecture: floating point values are represented with a higher precision inside the FPU (e.g. 80 bits instead of 64), but that probably only matters for compiled programs where the compiler may (or may not) optimize intermediate, truncating FPU->memory operations away (which leads to differing results and is one of the most often reported "bugs" of the GCC optimizer).