```Date: Thu, 29 Dec 2005 14:36:11 -0500 Reply-To: Ed Heaton Sender: "SAS(r) Discussion" From: Ed Heaton Subject: Re: Numeric Precision Problem Comments: To: Gerhard Hellriegel Content-Type: text/plain; charset="us-ascii" A little birdie confirmed that ability of SAS numbers to precisely represent decimal digits differs depending on which side of the decimal point the numbers lie. That birdie suggested that a discussion of the problem is in the documentation for the ROUND function in SAS8.2 and later releases. Ed Edward Heaton, SAS Senior Systems Analyst, Westat (An Employee-Owned Research Corporation), 1600 Research Boulevard, RW-4541, Rockville, MD 20850-3195 Voice: (301) 610-4818 Fax: (301) 294-3879 mailto:EdHeaton@Westat.com http://www.Westat.com -----Original Message----- From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-l@listserv.uga.edu] On Behalf Of Gerhard Hellriegel Sent: Wednesday, December 28, 2005 5:00 AM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Numeric Precision Problem its not a question of right or left of the decimal point! In SAS we have a floating point representation of nums, so you have 8 byte for the whole number, 1 byte for the exponent, 7 bytes for the sequence of digits including the sign. For the precision of the number you'll have 7*8 = 56 binary-"switches" to represent the sequence of decimal numbers. If you transform that in decimal you'll get 2**56 = 72057594037927936, what should allow something around 16 significant decimal positions, no matter if left or right of the decimal delimiter. now one problem is, that 1/3 is not representable in binary coding, nor in decimal coding, the other is, that even numbers which are not endless decimal fractions might be endless in binary representation! The second problem is resolved by some programming systems with bcd-arithmetics (binary coded decimals), the nums are also called "packed decimals". That means, that every decimal digit has a half-byte memory, which is a bit too much for a decimal digit cause you could hold up to 16 different numbers in a half-byte where you need only 10. It's a very memory intensive kind of numeric representation, but very precise. That's often used for commercial purposes where it is important to have the best possible control about precision. SAS came from the statistical corner, where it is not so important to have that control, if you have enough room to be NEARLY precise. In most cases, the 8-byte floating point representation is ok. But a warning: be very careful of reducing the 8 to any other! It means NOT, that you have 8 significant decimals, also e.g. 4 means NOT, you have 4! 4 means, that you have 3*8=24, so the decimal max number is 16777216... On Tue, 27 Dec 2005 20:17:46 -0500, Lou wrote: >"Ed Heaton" wrote in message >news:403593359CA56C4CAE1F8F4F00DCFE7D0267A0E6@MAILBE2.westat.com... >> Mark, >> >> SAS (on Windows) can render 15 good digits on the LEFT side of the >> decimal point. It can't on the RIGHT side of the decimal point. In >> fact, it might not be able to render one digit accurately. >> >> Don't believe me? Run the following code. >> >> Data _null_ ; >> x = 0.1 ; >> y = x + x + x ; >> If ( y eq 0.3 ) >> then put "One decimal digit rendered okay." ; >> Else put "One decimal digit not accurate!" ; >> Run ; > >It RENDERS the digit accurately, but internally the value isn't >precisely three tenths. One-tenth is an infinitely repeating "bimal" >in the same way that one-third is an infinitely repeating decimal. So >"y" doesn't equal "0.3" in the guts of the machine. ```

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