You are right to expect %d to print an integer as an integer, requiring no precision or field width specification, rather than in exponential notation (%e). There is a reason why sprintf fails to display this integer as an integer. Here's why (and more).
From the sprintf documentation, this is the output format that %d specifies:
Integer, signed; %d or %i;
Base 10
The keyword here is signed. This does specify an integer printed in decimal (base 10) notation, but the sign takes up one bit! The largest integer you (and %d) can represent with a 64-bit signed integer (i.e. int64) is 2^63-1 (check with intmax('int64')). And since (2^32 - 1) * (2^32 - 1) > 2^63-1, sprintf falls back to exponential notation (%e). But don't take my word for it:
>> sprintf('%d',uint64(2^63)-1)
ans =
9223372036854775807
>> sprintf('%d',uint64(2^63))
ans =
9.223372e+18
The solution is to use the unsigned integer format: %u.
>> sprintf('%u',uint64(2^63))
ans =
9223372036854775808
With (2^32 - 1) * (2^32 - 1), the issue is less subtle, but the solution is the same:
>> val = (2^32 - 1) * (2^32 - 1); % > 2^63-1
>> sprintf('%u',val)
ans =
18446744065119617024
This answers the question, but this is still wrong. This time it's not sprintf's fault. Double precision (64-bit) floating point numbers can only represent integers up to 2^53 without loss of precision1. Since the default data type in MATLAB is double, val is stored as a double. To ensure no loss of precision, use the uint64 type:
>> valUI = uint64(2^32 - 1) * uint64(2^32 - 1)
>> sprintf('%u',valUI)
ans =
18446744065119617025
Close. double almost got lucky.
1This value of 2^53 (or 9,007,199,254,740,992) can be verified by flintmax('double').