Date: Wed, 16 Jan 2008 13:51:57 -0800
Reply-To: Jack Hamilton <jfh@STANFORDALUMNI.ORG>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jack Hamilton <jfh@STANFORDALUMNI.ORG>
Subject: Re: numeric precision
Content-Type: text/plain; charset="ISO-8859-1"
Perhaps David Cassell will jump in to point out that Perl can handle
numbers of whatever precision you want. So can REXX. Of course,
rewriting PROC GLM as a Perl script might slow down your project.
On Wed, 16 Jan 2008 13:47:38 -0800, "pchoate" <paulchoate61@GMAIL.COM>
> Hi Marc -
> To throw in a couple more cents worth - the problem is handled with
> the FUZZ function or ROUND (as well as CEIL, CEILZ, FLOOR, FLOORZ,
> INT, INTZ, ROUNDE, and ROUNDZ). These functions make different
> choices regarding the problem, be sure to read the fine print. The
> only place _you do not have to worry_ about numeric representation is
> in integer values 0 through 9,007,199,254,740,992, as well as rational
> numbers that are sums of powers of 1/2 out to a certain accuracy. The
> CONSTANT function can report more to you about your platform. I don't
> believe there are any system options, but functions, call routines,
> and procedures may have fuzz= options or presets. If you choose to
> shorten your numeric variable lengths remember that this affects only
> how they are stored after they are processed. The datastep processes
> all numeric values with 8 byte precision.
> That said, if you stick with integers below 9e15 then your arithmetic
> will be precise, for example as Jack suggests work with pennies rather
> than dollars with two place decimals - up to 90 trillion dollars this
> works with perfect precision. Otherwise don't make direct comparisons
> of calculated values that haven't been rounded.
> One more point - SAS allows strings of much greater length than
> numbers, using character representation of numeric values allows you
> to play with up to 32K digits. Since the largest number _allowed_ in
> SAS is below 1.7E308, strings allow you to represent much larger
> values than floating point numbers.
> 1620 data;
> 1621 x=1E308;
> 1622 x=2E308;
> ERROR: Invalid number '2E308'.
> ERROR 77-185: Invalid number conversion on 2E308.
> 1623 run;
> On Jan 14, 10:48 am, marc.s...@RBC.COM ("Marc S.") wrote:
> > We've all encountered problems due to the way SAS stores numeric
> > variables. Specifically a series of calculations (should) lead to a zero
> > value but results in a wonky looking approximation of zero. (eg. 1.3878E-
> > 17) Statements that compare to zero fail as a result.
> > Although this can be coded around, it represents a lot of work to update
> > all sources that *may* encounter this problem.
> > Is there a system option that will cause automatic rounding to avoid this
> > issue? Perhaps another approach would work?
> > Marc.