Date: Thu, 29 Dec 2005 14:36:11 -0500
Reply-To: Ed Heaton <EdHeaton@WESTAT.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Ed Heaton <EdHeaton@WESTAT.COM>
Subject: Re: Numeric Precision Problem
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 <lpogodajr292185@COMCAST.NET>
wrote:
>"Ed Heaton" <EdHeaton@WESTAT.COM> 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.
| 
