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
Comments: To: pchoate <paulchoate61@GMAIL.COM>
In-Reply-To:  <417b2e65-7bd6-44c6-954e-6639aad7ce81@i3g2000hsf.googlegroups.com>
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>
said:
> 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;
>         -----
>         77
> ERROR: Invalid number '2E308'.
> ERROR 77-185: Invalid number conversion on 2E308.
> 1623  run;
>
>
>
> hth
>
> Paul
>
>
> 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.


--
Jack Hamilton
Sacramento, California
jfh@alumni.stanford.org