Date: Thu, 23 Apr 2009 11:11:08 -0400
Reply-To: Jack Clark <jclark@HILLTOP.UMBC.EDU>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jack Clark <jclark@HILLTOP.UMBC.EDU>
Subject: Re: Numeric Precision Issue with Summed Field from PROC SUMMARY?
In-Reply-To: A<16FD64291482A34F995D2AF14A5C932C07437C87@MAIL002.prod.ds.russell.com>
Content-Type: text/plain; charset="us-ascii"
Mark,
Thank you for the detailed information on precision. I really did learn
some things.
That being said, I'm still not "getting it" as to why this is an issue
when I started with values with 2 decimal places. Why do all the
additional decimal places come into play when summing values with a
maximum of 2 decimal places (or a maximum of 5 digits if we are to
ignore the decimal)?
Thank you,
Jack
Jack Clark
Senior Research Analyst
phone: 410-455-6256
fax: 410-455-6850
jclark@hilltop.umbc.edu
University of Maryland, Baltimore County
Sondheim Hall, 3rd Floor
1000 Hilltop Circle
Baltimore, MD 21250
Confidentiality Notice: This e-mail may contain information that is legally privileged and that is intended only for the use of the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying of this e-mail, distribution, or action taken in reliance on the contents of this e-mail and/or documents attributed to this e-mail is strictly prohibited. If you have received this information in error, please notify the sender immediately by phone and delete this entire e-mail. Thank you.-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
Terjeson, Mark
Sent: Wednesday, April 22, 2009 4:58 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Numeric Precision Issue with Summed Field from PROC
SUMMARY?
Hi All,
To expound on Jack's mention of typical 15th/16th
decimal place, most operating systems floating-point
number schemes store two kinds of information in
whatever format they end up with. The number value
as a common core value and also the location of the
decimal point. I make a point of these two pieces
because it helps to visualize in your head the next
statements which describe what you the user will see.
If you do thorough testing with SAS you will find
that in SAS you have 15 digits of precision regardless
of how many digits you print out. At this point in the
discussion you have to mentally ignore the decimal point.
That is key to understanding what you will see in your
results. When the comment above states that SAS has
15 digits of precision, it is similar to other products
and operating systems in floating-point limitations and
behaviors. Some systems will have 15 digits of precision,
some may have 13 digits on specific o/s and platforms.
But back to our discussion, ignore the decimal point
for a moment. The 15 digits of precision start at the
leftmost digit. Yes, this means you include BOTH the
integer portion to the left of the decimal point location
and include the mantissa to the right of the decimal point.
Using the alphabet as a ruler scale, the 15th digit is
found from letter A through letter P (as you ignore the
decimal point).
e.g.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
123456.7890123456789
What does that mean for positions Q thru Z? Well, you
must treat them as random garbage.
So as you can see, there are two misnomers that get in
the way of people understanding which digits are accurate.
Misnomer #1 - is that many people use the term "decimal" to
mean the mantissa (the digits to the right of the decimal)
because we humans so often talk about the "number of
decimal places", which is okay, but then we humans talk
about "the number of decimals in the precision", which
this phrase gets shortened to "the decimal precision",
and all of a sudden this becomes a very confusing context.
Misnomer #2 - More easily understood, it is not the number
of decimals in the precision, but the number of DIGITS in the
precision. This helps many folks understand the issue better.
The number of DIGITS in the precision, are the 15 digits
(ignoring the decimal point) which are represented by
letters A-F,H-P.
The number of digits in the mantissa (many people call
the decimal portion) is the 13 digits represented by
the letters H-T. But this has nothing to do with the
"precision". Note: the precision start at the far left
and accurate digits are just the first 15. So in this
example the decimal portion (mantissa) may be H-T, but
only digits H-P are accurate, and the remaining digits
from R-T are random garbage. Many times you can be
fooled because sometimes they look reasonable.
e.g.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
123456.7890123456789
12.34567890123456789
12345678901234.56789
12345678901234567.89
Therefore in all of the examples above, with 15 digits
of precision, the accurate digits are A-P regardless
of the decimal point. Even the last(4th) line there
are more than 15 digits to the left of the decimal point.
Again, starting at the far left, the first 15 are
accurate, and the remaining two "67" just to the left of
the decimal point must be assumed to be random garbage.
As mentioned early in this conversation, what is stored
in the floating-point information is the value and the
decimal point location. In simple terms, the floating
point routines and FPU processors in your computer deal
with the number value and you can picture that one of
the last steps is to apply the placement of the decimal
point. You can picture this as cosmetic, because the
limitations that limit the value precision has basically
already taken place. [For those interested in the why
there are limitations in precision during the floating-point
conversions, the logarithm tables supplied in each operating
system, is a separate investigation for you to research.]
So as Jack mentions (and others) the 15th or 16th digit,
it is the 15th position from the far left if there is not
a decimal point, and the 16th position (or character) if
there is a decimal point. This is where you here many folks
vacilate on the number 15 or 16.
There are many indepth discussions in the SAS-L archives
at http://listserv.uga.edu/archives/sas-l.html
Hope this is helpful.
Mark Terjeson
Senior Programmer Analyst
Investment Management & Research
Russell Investments
253-439-2367
Russell
Global Leaders in Multi-Manager Investing
