Why does uint64([90​0719925474​0993]) results in 9007199254740992? What happens to the least significant bit?

In Matlab 2025a I came across an effect when large integer constants are interpreted differently if they are a part of an array.

For example, uint64(9007199254740993) result in 9007199254740993 (correct!)

uint64([9007199254740993]) result in 9007199254740992 (strange...)

The problem persists for other numbers larger than 2^53; I'm afraid it's a bug.

Or is this behaviour expected?

[Stephen23]

"I'm afraid it's a bug."

Not a bug: you concatenate a scalar double with nothing, and then convert the result to UINT64.

Doing so avoids the syntax which is documented to allow UINT64 to be defined at their full precision.

"Or is this behaviour expected?"

This behavior is very well documented here:

https://www.mathworks.com/help/matlab/ref/uint64.html

[Dyuman Joshi]

A similar thing has been discussed recently (passing a number as literal to uint64) - https://in.mathworks.com/matlabcentral/answers/2181378-integer-conversion-without-precision-loss-for-literal-function-inputs?s_tid=srchtitle

Answer 1

[Steven Lord]

MATLAB recognizes this:

x = uint64(9007199254740993)

x = uint64
9007199254740993

as a literal constant being used to construct a uint64 variable. It doesn't try to convert that constant to double then call uint64 on it, but directly interprets that string of digits as a uint64.

When you type:

y = uint64([9007199254740993])

y = uint64
9007199254740992

MATLAB applies the [] operator to the double precision value of that constant and then passes the result of that concatenation into the uint64 function. By the time the uint64 function is called the damage is already done; 9007199254740993 is not exactly representable as an IEEE 754 double precision value, but 9007199254740992 is and so that's the value that is used to create the variable y above.

d = double(y)

d = 9.0072e+15

You can see the exact value of d by calling the sym function with the 'f' flag, which does:

"When sym uses the floating-point to rational mode, it returns the symbolic form for all values in the form N*2^e or -N*2^e, where N >= 0 is a nonnegative integer and e is an integer. The returned symbolic number is a precise rational number that is equal to the floating-point value. For example, sym(1/10,"f") returns 3602879701896397/36028797018963968."

symbolicValue = sym(d, 'f')

symbolicValue = 

9007199254740992

Is 9007199254740993 representable in double? What's the distance from 9007199254740992 to the next representable number?

distanceToNextGreaterRepresentableDouble = eps(d)

distanceToNextGreaterRepresentableDouble = 2

See the "Convert Array of Large Integers Without Loss of Precision" example on the uint64 documentation page or the "Loss of Precision Due to Conversion" section on this documentation page.

Alternately, if you have that sequence of digits as a string, use sscanf or (if you have Symbolic Math Toolbox and want to operate on the value as a symbolic object) sym.

S = "9007199254740993"

S = "9007199254740993"

z = sscanf(S, "%lu")

z = uint64
9007199254740993

z2 = sym(S)

z2 = 

9007199254740993

So not a bug.

Answer 2

[Walter Roberson]

This result is expected.

uint64([9007199254740993]) is processed as

temp1 = double(9007199254740993);
temp2 = [temp1];
output = uint64(temp2);

That is, the code involves the operation [] applied to a double precision array, and then applies uint64 to the result of the [] operation.

output = uint64(9007199254740993)

on the other hand is syntax that directly tells the interpreter that 9007199254740993 is to be interpreted under uint64 rules.

Nearly any operation inside the () causes the number to be interpreted as double precision first and then uint64() applied to that. For example,

uint64(+9007199254740993)
uint64(9007199254740993.)
uint64(9007199254740993i)

all result in absolute value 9007199254740992

Side note: uint64(9007199254740993i) results in 0 + 9007199254740992i uint64, but it is not clear how to get 0 + 9007199254740993i . Once you have the 0 + 9007199254740992i then all complex arithmetic is prohibitted on the uint64 so you cannot do something like add 0+1i

Ah, just found it:

complex(0,uint64(9007199254740993))

gives 0 + 9007199254740993i