MSB after converting decimal values to binary

I've used this code for converting decimal values to binary. But I cannot understand how it's working. I need to find most significant bits. I mean which bits have more effect if error happened to them?

m = reshape(dec2bin(typecast(b(:),'uint8'),8).',1,[]);
b_recovered = reshape(typecast(uint8(bin2dec(reshape(m,8,[]).')),'double'),size(b));

b=-1.12;
m=1110110001010001101110000001111010000101111010111111000110111111;

Answer 1

[Walter Roberson]

The typecast() to uint8 is going to get you a sequence of byte values.

To interpret that sequence of byte values, you need to know whether your system is "Big Endian" or "Little Endian". Big Endian systems have the most significant byte first in memory; Little Endian systems have the most significant byte last in memory. All x86 and x64 architectures are Little Endian. (MATLAB is not presently supported on any Big Endian systems.)

You are almost certainly using a little endian system. So it is the last of the bytes that has the most significant byte. That will come out as the last chunk of 8 characters in m. Out of that chunk of 8, the first of them is the most significant bit of the byte. The most significant bit of the most significant byte would thus be at m(end-7)

[Guillaume]

However, Rihanna is looking at double. It's arguable which bit is the most significant. Bit 64 is just the sign bit. I'd argue that bit 63 (msb of exponent) or 52 (msb of fraction) are more critical, but to be honest, most of them are important.

[Walter Roberson]

True, good point.

Though in the context that I wrote the code Rihanna is using, the data is probably single rather than double, as it would be the result of waveread() with 'native'

[Rihanna Waterson]

Actually as I checked, I think bit 57 is sign bit. Maybe because we have little endian here.

[Guillaume]

No, the sign bit of a double on a little endian system (i.e. any system currently supported by matlab) is always the 64th bit (in base 1). For single, it's the 32nd. In any case, it's never going to be a bit in the middle. This is standardised by the IEE 754 standard which I linked in my answer.

You can see that straight away, if you use the code I also gave in my answer. flipping bit 64 is the only one that results in an answer of the opposite sign of the input.

[Walter Roberson]

Guillaume, if you typecast() a double to uint8 on a little endian system, then the byte order is 8 7 6 5 4 3 2 1 where 1 indicates the most significant byte. Within each byte, though, the order is 1 2 3 4 5 6 7 8 where 1 indicates the most significant bit. So you get

8 8 8 8 8 8 8 8 7 7 7 7 7 7 7 7 6 6 6 6 6 6 6 6 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

where the top row indicates the byte number and the bottom row indicates the bit number. The MSB is 1 1 in this notation, and it occurs in position 57.

[Guillaume]

Right, but you only get that view if you look at the memory layout as bytes. From the point of view of the processor, which is reading that memory as double (a block of 64 bits). That 57th position is bit 64 (where 64 is the MSB).

For me it's heresy to suggest that bit 57 of a double could be a sign bit. When talking about doubles, bit 57 is slap in the middle of the exponent.

[Walter Roberson]

Notice that the user did typecast to uint8 and is asking how to understand the result.

[Guillaume]

Yes, and I showed in my answer typecast to uint64 would make a lot more sense.

Yes, bit 64 of a double does end up at position 57 if you look at the layout as bytes. Nonetheless, it is still the 64th bit of the double. The processor will read it as one block of 64 bits, and when you ask maltab for the 64th bit, you'll get the sign bit.

[Walter Roberson]

In the original context that I wrote the typecast code for, that then got posted here, the size of the data was unknown until execution time... it comes from wavread() or audioread() with the 'native' parameter.

I suspect Rihanna is needing to do something like audio steganography.

[Guillaume]

Ok. I was missing the context.

However, if you just have a string of bytes, asking which bit is most significant is kind of meaningless, if you don't know what these bytes represent. So, at some point, the size and type of the data must be known.

Answer 2

[Guillaume]

As Walter explained, the code converts a double into its binary representation. Due to the way doubles are encoded there are a lot of important bits. Which "bits have more effect if error happened to them" is subjective to what the number represent. Changing bit 64 only changes the sign, the magnitude stays the same. Changing bit 63 to 53 will greatly change the magnitude of the number, while bits 52 to 1 will only affect the value of the number.

Here is a simple code that shows of effect of swapping each byte in turn:

%function to invert the bit of a double value:
bitnot = @(dval, bit) typecast(bitset(typecast(dval, 'uint64'), bit, ~bitget(typecast(dval, 'uint64'), bit)), 'double');

number = -1.12;   %number to test on
array2table([1:64; bitnot(number, 1:64)]', 'VariableNames', {'swapped_bit', 'result'})

[Rihanna Waterson]

Thanks. I ran your code. Here bit 64 is sign bit. But bit 57 is sign bit in my code. It's first bit in last byte. I'm not sure what's going on here.

[Walter Roberson]

The bit numbering used by bitset() is not the same as you get by typecast() to uint8 . The bit numbering for bitset() starts from 1 for the LSB and goes to 64 as the MSB .

From the outside, it is not really possible to say whether the processor re-arranges the bits when it reads them from memory, or if the processor is just wired to handle the bits in an order we would find strange. At the chip level it is all a bunch of gates and wires operating in parallel, probably in 3D, and numbering stops being meaningful unless you want to start checking which doped regions are closer to which doped regions.

[Guillaume]

As discussed in Walter's answer, this is because I look at the bits as one lump of 64 bits. Yes, if you look at how these bits are arranged in memory in a sequential way, that bit may end up at the 57th position but for the processor, this is still bit 64.

In any case, the code does show you which bit does what, using the standard bit numbering convention (using base 1) that is used in any article discussing IEE754 (such as the wikipedia page).

[ghibeche]

Hi

I want function like uint64 but generate 56 bit