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).
_______________________________________________
Numpy-discussion mailing list
[email protected]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
