MATLAB: 64 bit binary number representation in matlab without rounding off

MATLAB

I have a 64 bits binary number having 1's and 0's and i need this number in all 64 bits for further processing. However, i am getting this number in exponential form after rounding i.e. 1.01010101010101e+41. Can anyone please tell me how to get full 64 bits without losing precision ? Thanks in advance.

Best Answer

If matlab shows the number is 1.01010101010101e+41 then you do not have a binary number. You have a decimal integer number consisting of just the digits 0 and 1. Additionally, that decimal number is stored as a 64-bit double.

Any integer number greater than flintmax (= 9007199254740992), so anything with 16 digits or more may not be stored exactly as a double. The greater the number, the less likely you can store it exactly. e.g 100000000000000010 (17 digits) is stored as 100000000000000016. There's nothing that can be done about that, that's the way double numbers work.

You could store your decimal representation as a 64-bit integer instead (uint64) to be able to store a few more digits but that won't get you far. The maximum decimal number consisting of 0s and 1s that you can store as uint64 is 11111111111111111111 (20 digits). Anything above that cannot be stored.

So, the first thing you need to realise is that you cannot store a number consisting of 64 0s and 1s as a decimal number, double or uint64 (unless you defer to the symbolic toolbox but that would be slow).

You could store it as a char vector, as suggested by Bruno.

In my opinion, the simplest way to store a 64-bit number is to store it in its decimal representation as a uint64 (i.e. store the binary 1111111111111111111111111111111111111111111111111111111111111111b as uint64(18446744073709551615)

Related Solutions

MATLAB: Swapbytes order problem with uint64

I suspect the problem is actually in hex2dec(). You are exceeding the flintmax limit described in the hex2dec documentation:

d = hex2dec('hex_value') converts hex_value to its floating-point integer representation. The argument hex_value is a hexadecimal integer stored as text. If the value of hex_value is greater than the hexadecimal equivalent of the value returned by flintmax, then hex2dec might not return an exact conversion.

MATLAB: Accuracy problems in uint64 numbers

It really depends on how you performed your computations. Let's take a somewhat large number, 3^40.

xDouble = 3^40;
xUint64 = uint64(3)^40;
areTheseTheSame = [uint64(xDouble); xUint64]

The answer to the implied question is no. The reason the two elements of areTheseTheSame are not the same is that 3^40 is greater than flintmax.

isGreaterThanFlintmax = xDouble > flintmax % true

The key statement in the flintmax documentation is "Above this value, double-precision format does not have integer precision, and not all integers can be represented exactly." The next largest representable number above flintmax is not flintmax+1 but flintmax+2.

>> F1 = flintmax;
>> F2 = flintmax + 1;
>> F1 == F2
ans =
  logical
   1
>> eps(flintmax)
ans =
     2
>> F3 = flintmax + 2;
>> F1 == F3
ans =
  logical
   0

However, 3^40 is less than the maximum value that you can store in a uint64 so it can be exactly represented in uint64.

isLessThanMaximumUint64 = xUint64 < intmax('uint64') % true

If your computations are likely to result in large (greater than flintmax) integer values, you should probably operate on values stored in an integer data type as much as you can, like I did when I computed xUint64 by computing mpower (the ^ operator) on a uint64 value.

Best Answer

Related Solutions

MATLAB: Swapbytes order problem with uint64

MATLAB: Accuracy problems in uint64 numbers

Related Question