Bug with large HEX numbers

Bug with large HEX numbers like 'fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141', which is final number for private keys for Bitcoin network.

This code

Final = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

Hexadecimal literal has too many digits for specified or implied type suffix.

raises an error, which is a real bug!

[Stephen23]

"raises an error, which is a real bug!"

Not a bug.

The documentation on hexadecimal notation states that "By default, MATLAB stores the number as the smallest unsigned integer type that can accommodate it".

https://www.mathworks.com/help/matlab/matlab_prog/specify-hexadecimal-and-binary-numbers.html

The integer types are listed here:

https://www.mathworks.com/help/matlab/matlab_prog/integers.html

The largest representable integer value is

mxv = intmax('uint64')

mxv = uint64
18446744073709551615

which in hexadecimal is

sprintf('%lx',mxv)

ans = 'ffffffffffffffff'

and clearly a much much smaller number than fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141. So there is no possible way to store your large hexadecimal number using a standard numeric integer type, i.e. even if no error would be thrown then you would not get that value stored in memory.

You might be able to fit it into a double, but clearly only with loss of precision.

Answer 1

[John D'Errico]

H = 'fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141';
numel(H)

ans = 64

So 64 hex digits, which would yield an integer on the order of

16^64

ans = 1.1579e+77

The standard data type use 8 bytes to store all numbers. This far exceeds the largest integer which can be stored in either a double or uint64.

Note, that when you do this in MATLAB, it automatically stuffs the result into an integer form, of the smallest size that it will fit.

Final = 0xab

Final = uint8
171

Here, a uint8 will hold it. Add a few more digits, and it will use uint16, then iint32, then uint64. In each case, the result gets stuffed into an integer form.

Final = 0xab45

Final = uint16
43845

Final = 0xab45de2

Final = uint32
179592674

Final = 0xab45de2df

Final = uint64
45975724767

However, if you go too far, as you pushed things, it generates the error you saw.

% Final = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

That generates the error you saw, where you should recognize that MATLAB has no standard extended data type to store an arbitrarily large integer. To do that, you must work with it as a sym. (Or you could use some other big integer form, perhaps the Java.Math.BigInteger tools.)

Final = sym('0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141')

Final = 

115792089237316195423570985008687907852837564279074904382605163141518161494337

vpa(Final,100)

ans = 

115792089237316195423570985008687907852837564279074904382605163141518161494337.0

And of course, you can then convert back into hex form after you have done your work...

dec2hex(Final)

ans = 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141'

As such this this is NOT a bug in MATLAB! The only bug lies in your recognizance that you cannot stuff that large of an integer into the relatively small box provided by a UINT64.

[Steven Lord]

The standard data type use 8 bytes to store all numbers. This far exceeds the largest integer which can be stored in either a double or uint64.

John, I know you know what I'm about to write, but I wanted to call out for the original poster that there is some nuance to the second sentence. It is accurate that the number the poster wants to create is too large to store in a uint64, as it's greater than

M = intmax('uint64')

M = uint64
18446744073709551615

You can store numbers larger than this in MATLAB as double precision values, but one problem is that you can't store all integers on this order of magnitude in double.

x = 16^64

x = 1.1579e+77

y = x+1

y = 1.1579e+77

isequal(x, y) % true, and no this is NOT a bug!

ans = logical
   1

Every finite number greater than flintmax is an integer value, but not all integer values greater than flintmax can be stored as a double. See x and y above. So there's no guarantee that MATLAB could store exactly that number in double precision. In order to get to the next representable integer after x, you'd have to add:

spacing = eps(x)

spacing = 2.5711e+61

You can see this by looking at the hex representation of the double values x, y, and x+spacing. The last of those numbers differs from x by the last bit of the mantissa.

format hex
x

x = 
   4ff0000000000000

y

y = 
   4ff0000000000000

x+spacing

ans = 
   4ff0000000000001

John and Stephen23 are correct: this is not a bug. You could file it with Technical Support as an enhancement request for MATLAB to add a larger integer type, like int128 and uint128.

[John D'Errico]

Lol. Good catch by @Steven Lord. It ends up being almost a philosophical issue. If I store a number in a double, and because the large number is a double, it does not store the number exactly, have I actually stored the number? That is, if I stuff a number of that magnitude into a double, it can and will store something (as long as the number is no larger than realmax), but only an approximation to what you supplied. From that point of view, it is as if I take a picture of you. Is the picture truly you? Or only a representation of you?

I'd argue that it only stores the actual number, IF after storing the number, you can then extract the original number in hex form to full precision.

Anyway, yes, a double will fit that number. But not exactly, and since what matters here are essentially ALL of the digits, then you cannot use a double or a UINT64 to do so.

Could you fit it into a UINT128? (If such a datatype was provided?) No. 64 hex digits would require a uint1024 datatype to store them all, since 64 hex digits corresponds to 1024 binary bits, thus 16*64. And that means you would need a UINT1024 datatype. You COULD send in a feature request for that to happen, but I'm not sure it will happen in the near future. Of course, that does not stop you from writing it yourself. Or, you could use my VPI toolbox, or SYMs, or the Java.Math.BigInteger tools. Any of those three tools are essentially unlimited in the number of bits they can store. Of course, they are much slower to work with, but you can have it fast, or you can have the correct result. Your choice.