[Numpy-discussion] Array printing and another question

[Ken Basye]

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).
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080411/9a354504/attachment.html>