LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (November 2010, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 16 Nov 2010 02:53:15 -0500
Reply-To:     Gerhard Hellriegel <gerhard.hellriegel@T-ONLINE.DE>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Gerhard Hellriegel <gerhard.hellriegel@T-ONLINE.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 disk-space, 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@T-ONLINE.DE] >> Sent: November-15-10 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 non-zeroes 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: SAS-L@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 psuedo-floating 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 two-digit 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:SAS-L@LISTSERV.UGA.EDU] On Behalf >> Of >>>>>>> Schwarz, Barry A >>>>>>> Sent: Sunday, November 14, 2010 4:32 PM >>>>>>> To: SAS-L@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 ten-million >>>>> digit.) >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf >> Of >>>>>>> Michael Raithel >>>>>>> Sent: Sunday, November 14, 2010 8:31 AM >>>>>>> To: SAS-L@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 >>>>>>> /mvs-length-length.htm >>>>


Back to: Top of message | Previous page | Main SAS-L page