You don't have to restrict length shortening to just integers. If all your values are halves and quarters for instance, then you could shorten with no loss of accuracy. Consider the possibilities of length 6 below for this subset of integers divided by powers of 2:
213 data _null_;
214 /* Get the largest consecutive integer storable as floating point 6 bytes */
215 L6=constant('exactint',6);
216 put L6=comma22.0;
217
218 /* Now show the maximum consecutive value for power of 2 fractions: */
219 X=L6;
220 Length txt $22;
221 do denom = 2 by 0 while (denom<=256*256);
222 X=x/2;
223 TXT=right(put(x,comma22.0));
224 put '1/' denom @15 txt $char22.;
225 denom=2*denom;
226 end;
227 run;
L6=137,438,953,472
1/2 68,719,476,736
1/4 34,359,738,368
1/8 17,179,869,184
1/16 8,589,934,592
1/32 4,294,967,296
1/64 2,147,483,648
1/128 1,073,741,824
1/256 536,870,912
1/512 268,435,456
1/1024 134,217,728
1/2048 67,108,864
1/4096 33,554,432
1/8192 16,777,216
1/16384 8,388,608
1/32768 4,194,304
1/65536 2,097,152
I.e. every 1/4th up to 34,359,738,368 will suffer no loss of accuracy in a storage length of 6.
BTW, this was a real-world problem in the stock market. Markets used to report prices in dollars, half-dollar, quarters, eights (and I think down to sixteenths) up until 2001, when they switch to decimalization. Not only did the decimalization cut down of trader's commissions (granularity of prices went down to single pennies), but until that time we could accurately store daily closing prices with a length of less the 8 (I believe our supplier - CRSP - used a length of 6). Well, that little space savings disappeared quickly. More importantly, we get hundreds of millions of stock trades and quotes daily from us stock exchanges.
At 2 bytes per trade/quote space needs went up dramatically.
... View more
