Re: converting char-string (binary ieee representation) to double

In article <40ch0fF19sa3sU1@xxxxxxxxxxxxxx>, sebastian.held@xxxxxxxxxx wrote:

> Hello Mr. Lord,
>
> Steven Lord wrote:
>
> > Okay, so each of your 8 characters represents one of the 8 bytes, with a
> > value between 0 and 255. So you could use HEX2NUM if you could 'expand'
> > those characters into the 2 hex digits that represent the value.
>
> No I don't think so. The binary IEEE representation is like follows:
> SEEEEEEEEEEEMFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFL
> M is the most significant bit of the fractional part
> F is an intermediate fractional bit
> L is the least significant fractional bit
> S is the sign bit of the fractional part
> E is the exponent part
>
> M is always a one
> The Exponent is offset by 127
>
> That's why I don't think your solution would work, but I will try it
> nevertheless.
>
> br,
> Sebastian Held
--------------------------
Hello Sebastian Held,

I assume the format you describe is for the IEEE 754 standard for double
precision numbers. If so, there are a couple of errors present in your
description of it.

First, the bit you designate as 'M' is not the most significant bit of
the fractional part (the significand) for the usual normalized numbers,
and it is not necessarily a one - about half the time it will be a zero.
The most significant bit for normalized numbers is always, by definition,
a one and, because of that fact, is not explicitly present among the 64
bits. That would have been a waste of one bit. It is simply understood,
and is called the "hidden" bit. Its position, if it were to be present,
would be one bit left of your 'M'.

The second error is that the double precision exponent offset is 1023,
not 127. The latter is the offset used for 32-bit single precision
formats.

However, if the strings of eight full-range (0-255) characters you are
working with actually do adhere to the proper IEEE standard, then Steven
Lord's idea of expanding it to sixteen hex characters should work for
you. In theory, all MathWorks would have to do is translate those hex
characters to binary form, if they had direct access to a computer's
underlying 64-bit numbers. However, the function 'hex2num' apparently
does not have this kind of direct access to a computer's hardware
representation, so it converts a hex string to binary, separates the sign
bit, properly offsets the exponent, furnishes the hidden bit to the
significand, and rebuilds the number from these components using
arithmetic operations. I have studied the 'hex2num' script and it is done
correctly, even handling signed zeros, denormalized numbers, infinities,
and NaNs properly.

I would advise you to try Steven's idea. You can use matlab's 'format
hex' command to check out your results. Its sixteen hex characters,
expanded to binary form, give the exact binary form of the numbers you
will have created, and can be matched against those of your original
strings. The only cases where you will see a difference will be among the
NaNs which are not reproduced by 'hex2num' in their original form but use
Mathworks' NaN forms instead, but this difference will not affect any of
your numerical calculations.

(Remove "xyzzy" and ".invalid" to send me email.)
Roger Stafford
.

Relevant Pages