3

I'm reading data from a binary file. I have a document that lets me know how the information is stored. To be sure of this I use XVI32.

I was extracting information string and int data correctly, until I bumped with float data type.

According to this file:

00800000 = 0.0
7AFBDD35 = 0.061087
9BF7783C = -0.003491
00FBFCAD = 0.031416

I tried to solve this with:

struct.unpack('!f', my_float.decode('hex'))[0]

And other different ways....

I tested this information with some online tools like: http://babbage.cs.qc.cuny.edu/IEEE-754/index.xhtml and http://www.binaryconvert.com/result_float.html?decimal=048046048054049048056055, but all of these ways throws me a different value according the original results.

I'm starting to suspect that float information is encrypted or something like that but why string and int weren't encrypted?

Ry-
  • 218,210
  • 55
  • 464
  • 476
Hugo Medina
  • 351
  • 1
  • 2
  • 9
  • i can see no pattern in these numbers. what you tried (plus playing around with byte orders) is what i would have expected. the values you give don't seem to be arranged in any consistent way that i can see. are you sure they are right? – andrew cooke May 22 '12 at 00:46
  • 1
    Can you provide more examples? It's hard to see a pattern in the few you've shown. – Ignacio Vazquez-Abrams May 22 '12 at 00:54
  • 4
    Wait, the documentation really just gives you those four examples, and expects the pattern to be clear from that? It doesn't reference some other standard or anything? – Karl Knechtel May 22 '12 at 01:55
  • in `7AFBDD35`, `7A` is apparently the exponent without sign bit. but it doesn't work in other cases. Are you sure they are right? – Timothy May 22 '12 at 05:54
  • This is preliminary as my mind has changed several times since yesterday. It's big endian so library conversion routines on an x86 are not going to work. There appears to be a sign bit. The exponent I'm assuming to be 8 bits and does not appear to be offset yet how would one do positive exponents?. Curiously bit 9, from the big end, is always set. – starbolin May 22 '12 at 15:01
  • If the bytes are swapped in the word then have what looks like a 128 offset in the exponent and the sign bit in the mantissa. Either way I still can make heads or tails of the mantissa. – starbolin May 22 '12 at 15:06
  • The document of TMS320 float-point number is here: ti.com/lit/an/spra400/spra400.pdf , as I said in the comment to OP, the first 2 hex dights is the exponent. **BUT**, how can the exponent of 0.031416 be `00`? I have to ask it again: **are you sure they are right? are you playing us?** – Timothy May 22 '12 at 16:42

2 Answers2

2

Interesting puzzle. Working with the documentation I came up with this:

def byteswap(x):
    return ((x & 0x00ff00ff) << 8) | ((x & 0xff00ff00) >> 8)


def tms320_float(raw):
    s = (raw >> 23) & 1
    mantissa = (raw & 0x007fffff)
    exponent = raw >> 24
    if exponent >= 128:
        exponent -= 256
    if exponent == -128:
        return 0.0
    return (((-2) ** s) + float(mantissa) / float(1 << 23)) * (2.0 ** exponent)

>>> tms320_float(byteswap(0x00800000))
0.0
>>> tms320_float(byteswap(0x7AFBDD35))
0.06108652427792549
>>> tms320_float(byteswap(0x9BF7783C))
-0.003490658476948738
>>> tms320_float(byteswap(0x00FBFCAD))
0.031415924429893494
Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
1

my boss sent me the answer, The floating point data is not in IEEE format.

The data type is TMS320 floating point

for some reason, the real values from hex data are mixed each 2 bytes, I mean:

80000000 = 0.0
FB7A35DD = 0.061087
F79B3C78 = -0.003491
FB00ADFC = 0.031416

Thankyou for support me guys

Hugo Medina
  • 351
  • 1
  • 2
  • 9
  • The document of TMS320 float-point number is here: http://www.ti.com/lit/an/spra400/spra400.pdf , as I said in the comment to OP, the first 2 hex dights is the exponent. **BUT**, how can the exponent of 0.031416 be `00`? I have to ask it again: **are you sure they are right? are you playing us?** – Timothy May 22 '12 at 16:39
  • I'm still studing the information of the file, now that I have the function that converts an unsigned value which represents a TMS320 floating point format number to IEEE floating point format value, I'll understand if those values are right. I'll be sure why the results of these values. and I'm not playing with you, I'm being serious. – Hugo Medina May 22 '12 at 18:32
  • The real values from hex data are mixed each 2 bytes: 80000000 = 0.0 FB7A35DD = 0.061087 F79B3C78 = -0.003491 FB00ADFC = 0.031416K – Hugo Medina May 22 '12 at 19:01