Date: Tue, 16 Nov 2010 02:53:15 0500
ReplyTo: Gerhard Hellriegel <gerhard.hellriegel@TONLINE.DE>
Sender: "SAS(r) Discussion" <SASL@LISTSERV.UGA.EDU>
From: Gerhard Hellriegel <gerhard.hellriegel@TONLINE.DE>
Subject: Re: length of numeric variables
If you are sure, ok. My customer, a big german bankhouse, was sure also.
They had keys of length 8 digits. Question was to make the keys char or
better num. nums had the advantage that it was very easy to add 1 to
generate a new unique key. The second idea was to save diskspace, so a
num with length 8 would have no advantage over a char(8) and they decided
to use length 6 (as far as I remember). Nobody had any idea, that the
application should run on AIX. That did not work any more. The searching
and changing of all programs with that problem was kind of expensive,
surely more than "wasting" that 2 bytes of diskspace.
Gerhard
On Mon, 15 Nov 2010 20:13:23 0800, Jack Hamilton <jfh@STANFORDALUMNI.ORG>
wrote:
>Not at all. If you have an input field that you know will always be
small, there's no reason to use 8 bytes (other than bugs in SAS). For
example, I use a field that is displayed and entered as 4 digits in
literally thousands of different programs. It's not going to become 5
digits  it would simply be too expensive to make the changes. So I don't
have a problem defining it with length 4.
>
>I don't, however, use lengths below 4.
>
>
>
>Jack Hamilton
>jfh@alumni.stanford.org
>Caelum non animum mutant qui trans mare currunt.
>
>
>
>
>On Nov 15, 2010, at 12:05 , bbser2009 wrote:
>
>> Thanks for sharing this. I guess SAS should ban the length statement for
>> numeric variables at lease with mainframes.
>>
>> Max
>>
>> Original Message
>> From: Gerhard Hellriegel [mailto:gerhard.hellriegel@TONLINE.DE]
>> Sent: November1510 12:13 PM
>> Subject: Re: length of numeric variables
>>
>> By the way: the length does not influence the length of the variables in
>> PDV. Only the storage in the dataset. So everything what you are doing
in
>> a datastep will work with length 8 and only the results are truncated.
>>
>> I've found it very dangerous to "minimize" storage on mainframes by
>> reducing the length of nums. I once saw that with numeric keys. Ok, the
>> amount of data was very big and preserving disk space WAS a challenge.
>> One day, big management decided to go to ORACLE on UNIX and some keys
were
>> NOT unique any more! Not good for primary keys!
>>
>> Gerhard
>>
>>
>>
>>
>>
>> On Sun, 14 Nov 2010 22:08:57 0600, Joe Matise <snoopy369@GMAIL.COM>
wrote:
>>
>>> Sure, but if you read in a value of 256, it could be 256 or 257, right?
>>> Unless I am missing something? In which case 256 is not usefully
>> stored...
>>>
>>> Joe
>>>
>>> On Sun, Nov 14, 2010 at 9:39 PM, Keintz, H. Mark
>>> <mkeintz@wharton.upenn.edu>wrote:
>>>
>>>> True, but what happens when you assign the value 256 and then store as
>>>> length 2? SAS has to truncate (or round maybe) the mantissa to fit
one
>>>> byte, and simultaneously make a commpensating adjustment to the
exponent
>>>> (these are stored as floating point value after all).
>>>> Now since the mantissa would be hexadecimal 0100 if you had a length
of
>> 3
>>>> bytes instead of 2, then truncating the trailng zeroes creates no
>> problem as
>>>> the exponent is increased. After all, when reading back stored
values
>> with
>>>> length <8, SAS always appends zeroes, which in this case yields the
>> original
>>>> values (256).
>>>>
>>>> IIRC, the real representation "normalizes" the mantissa to start with
an
>>>> implied decimal point. So 256 is really hexademical '.80'X (i.e. one
>> half)
>>>> times 2 to the 9th (i.e. an exponent of 9).
>>>>
>>>> For that reason, I believe if you run this test on a mainframe, that
the
>>>> first (Y=255) and second (256) obs will have X=Y in dataset TEST, but
>> not
>>>> the third obs (257).
>>>>
>>>> data have;
>>>> Length x 2 y 8;
>>>> Do y=255 to 257;
>>>> X=y;
>>>> output;
>>>> End;
>>>> Run;
>>>> Data test;
>>>> Set have;
>>>> If x=y then equal='Y'; else equal='N';
>>>> Put x= y= equal=;
>>>> Run;
>>>>
>>>> More generally I think any integer whose real representation has a
>> mantissa
>>>> with nonzeroes only in the first and second significant digits will
>> lose no
>>>> precision when stored in SAS length 2 on a Z/OS system. 256 is such
an
>>>> integer. In fact, as per my argument above, I expect X=Y for every
even
>>>> number 256 to 512, every 4th number from 512 to 1024, etc.
>>>>
>>>> In short, I believe the SAS document for Z/OS is correct for each
>> length 2
>>>> through 8.
>>>>
>>>> Regards,
>>>> Mark
>>>>
>>>>
>>>>> Original Message
>>>>> From: Mark Miller [mailto:mdhmiller@gmail.com]
>>>>> Sent: Sunday, November 14, 2010 5:31 PM
>>>>> To: Keintz, H. Mark
>>>>> Cc: SASL@LISTSERV.UGA.EDU
>>>>> Subject: Re: length of numeric variables
>>>>>
>>>>> Mark,
>>>>>
>>>>> RANGE is 0..255 (i.e. range is 256 values)
>>>>> Maximum MUST be odd since it is composed of
>>>>> 2**7 + 2**6 + 2**5 +2**4 +2**3 + 2**2 + 2**1 + 2**0
>>>>> 128 64 32 16 8 4 2
>>>>> 1
>>>>>
>>>>>
>>>>>
>>>>> ... Mark Miller
>>>>>
>>>>> On 11/14/2010 5:24 PM, Keintz, H. Mark wrote:
>>>>>> Barry,
>>>>>>
>>>>>> Isn't the maximum consecutive integer actually 256, not 255? It's
>>>>> 257 that will be the smallest integer unstorable in LENGTH 2.
>>>>>>
>>>>>> Just like the maximum consecutive decimal integer realizable with 2
>>>>> digits in psuedofloating notation is 10, as per here:
>>>>>>
>>>>>>
>>>>>> Integer Mantissa Power of 10
>>>>>> 99 = .99 * 2 99=.99*10**2
>>>>>> 100 = .10 * 3 10**3 100=.10*10**3
>>>>>> 101 = can't be expressed with twodigit mantissa and 1 digit
>>>>> exponent
>>>>>>
>>>>>>
>>>>>> Back to binary computers: In hexadecimal, 256 would be accurately
>>>>> stored as
>>>>>> Mantissa Exponent (in powers of 2)
>>>>>> .FF (1 byte) * 8 =.FF*(2**8) =
>>>>> FF*(2**0) = 256
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>> Original Message
>>>>>>> From: SAS(r) Discussion [mailto:SASL@LISTSERV.UGA.EDU] On Behalf
>> Of
>>>>>>> Schwarz, Barry A
>>>>>>> Sent: Sunday, November 14, 2010 4:32 PM
>>>>>>> To: SASL@LISTSERV.UGA.EDU
>>>>>>> Subject: Re: length of numeric variables
>>>>>>>
>>>>>>> Unfortunately, the z/OS reference below is incorrect. Every value
>>>>> is
>>>>>>> off by one. For example, when length is 2, the max value is 255,
>>>>> not
>>>>>>> 256.
>>>>>>>
>>>>>>> Furthermore, there is a typo for length 7. The correct value is
>>>>>>> 281,474,976,710,655. (The reference has a 4 in the tenmillion
>>>>> digit.)
>>>>>>>
>>>>>>> Original Message
>>>>>>> From: SAS(r) Discussion [mailto:SASL@LISTSERV.UGA.EDU] On Behalf
>> Of
>>>>>>> Michael Raithel
>>>>>>> Sent: Sunday, November 14, 2010 8:31 AM
>>>>>>> To: SASL@LISTSERV.UGA.EDU
>>>>>>> Subject: Re: length of numeric variables
>>>>>>>
>>>>>>> snip
>>>>>>>
>>>>>>> Max, I see that you have already had a plethora of helpful answers.
>>>>> If
>>>>>>> you _DO_ want to change the length of your numeric variables, here
>>>>> are
>>>>>>> some helpful links describing how the length of a numeric variable
>>>>>>> affects its precision on the various popular computing platforms:
>>>>>>>
>>>>>>> For SAS under Windows:
>>>>>>>
>>>>>
>> http://support.sas.com/documentation/cdl/en/hostwin/61924/HTML/default/
>>>>>>> numvar.htm
>>>>>>>
>>>>>>> For SAS under UNIX:
>>>>>>>
>>>>>
>> http://support.sas.com/documentation/cdl/en/hostunx/61879/HTML/default/
>>>>>>> a000344718.htm
>>>>>>>
>>>>>>> For SAS under z/OS:
>>>>>>>
>>>>>
>> http://support.sas.com/documentation/cdl/en/hosto390/61886/HTML/default
>>>>>>> /mvslengthlength.htm
>>>>
