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 (April 2009, week 4)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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?
Comments: To: "Terjeson, Mark" <Mterjeson@RUSSELL.COM>
In-Reply-To:  A<>
Content-Type: text/plain; charset="us-ascii"


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 Clark Senior Research Analyst phone: 410-455-6256 fax: 410-455-6850

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

Hope this is helpful.

Mark Terjeson Senior Programmer Analyst Investment Management & Research Russell Investments 253-439-2367

Russell Global Leaders in Multi-Manager Investing

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