@mkeintz: Yes, I agree that the wording ("largest integer") which is often used in this context can be misleading. (However, the statement that "negative values require more storage ..." contradicts the fact that the "sign bit" is always included in the internal representation. I guess you copied this sentence from this recent post, not from official SAS documentation.)
Just to add the explanation (for readers who are curious) why numeric variables of any length can store certain larger integers than those supposedly "largest" ones without losing precision, in particular powers of 2 (up to 2**1023=8.988...E307 -- displaying such values is a different issue): The internal floating-point representation of numeric values uses separate sets of bits for the exponent (containing a number's "order of magnitude") and the mantissa (relevant for the "precision"). For both parts of the number it uses the binary system.
This means: If a number can be stored exactly, such as an integer with an absolute value below the upper bounds 8192 etc. mentioned in @mkeintz's post, then one can multiply this number by any power of 2, i.e. 2**k with a positive or negative integer k, and the result, be it an integer or not, can still be stored exactly -- except in the extreme cases where its absolute value exceeds CONSTANT('BIG') or falls below CONSTANT('SMALL'). This is because that multiplication will only change the exponent, but not the mantissa. It's analogous to scientific notation in the decimal system, e.g. 6.022E23, where a multiplication by any power of the base 10 affects only the exponent (23), but leaves the mantissa digits (6022) unchanged and in particular doesn't require more of them.
For example, a numeric variable of length 3 (bytes) on a Windows or Unix system will happily store exact numbers like 4321*2**44=76015835897921536 or 123*2**-17=0.00093841552734375, but will miserably lose precision when being assigned values such as 8765 or 0.1 (!), for which 12 mantissa bits (3*8 bits due to length 3, minus 1 bit for the sign minus 11 bits for the exponent) are insufficient:
data test;
length a1-a4 3; /* mathematical binary representation, mantissa bits blue: */
a1=4321*2**44; /* 100001110000100000000000000000000000000000000000000000000 */
a2=123*2**-17; /* 0.00000000001111011000000 */
a3=8765; /* 10001000111101 */
a4=0.1; /* 0.000110011001100110011001... (infinitely repeating "0011") */
run;
proc print data=test;
format a1 best32. a2 e20.;
run;
Results (under Windows):
a1 a2 a3 a4
76015835897921536 9.3841552734375E-04 8764 0.099991
More details can be found in Numerical Accuracy in SAS Software.
[Edit: Corrected minor typo in the text and improved wording in one place.]
Edit 2: Just noticed: I think your calculations underestimate the number of integers with an exact representation in a 3-byte variable: Each of the ranges [8192, 16384), [16384, 32768), ..., [2**1023, 2**1024) -- these are 1023-13+1=1011 ranges -- contributes 2**12=4096 integers. (In fact, there are 4096, not 2048, integers divisible by 4 in the range (16384, 32768] or [16384, 32768) for that matter, again 4096 divisible by 8 in [32768, 65536) and so on. Both the length of the range and the divisor are doubled in each step.) These correspond to the 2**12 different combinations that can be formed with the 12 mantissa bits and each range corresponds to one combination of the exponent bits. The pertinent values of the exponent (which is shifted by 1023 ["bias"]) are 1036, 1037, ..., 2046. So, together with the 8191 integers 1, 2, 3, ..., 8191 (whose exponents range from 1023 to 1035 while only 1+2+4+8+...+4096=8191 mantissas yield integers) I end up with n=1011*4096+8191=4,149,247 positive integers and hence a total of 2*n+1=8,298,495 integers including zero and negative integers.
