Date:         Wed, 9 Sep 1992 14:00:00 PDT
Reply-To:     Melvin Klassen <KLASSEN@UVVM.BITNET>
Comments:     Warning -- original Sender: tag was NETNEWS@UVVM.UVIC.CA
From:         Melvin Klassen <KLASSEN@UVVM.BITNET>
Subject:      Re: numbers in SAS

Andy Norton <76350.1604@COMPUSERVE.COM> writes:
>NO NO NO!  NEVER USE A LENGTH LESS THAN 8 FOR A NON-INTEGER NUMERIC VALUE!
>(excuse me for getting overexcited)

You're excused, but that doesn't make you right!

>The problem is not how much precision you need.  The problem is that
>you want *comparisons* to be done with exactly the same precision.

You really do *not* want that either -- you should abandon hope
of getting the computer to test "equality" of two non-integer values,
and instead program it to test for "approximately-equal".

>If a decimal value is stored with less than 8 bytes, it may not match.

If a decimal value is stored with even 16 or 32 or 64 bytes,
the stored binary-value may *still* not match the external decimal-value!

>Remember there are also hidden comparisons which can occur in procedures,
>such as determining whether observations are in the same BY-group or not.

This is the only good point in your answer!
Woe on anybody who chooses to use non-integer-valued variables
in BY-group processing!

I suppose that the extreme argument is that any statistical package
should never hand the user a loaded gun, in order to prevent the user
from shooting his/her own foot.  Balderdash!

Since round-off-errors are a fact-of-life when using non-integer numbers
within computers, one should really disable the floating-point hardware,
or at least remove SAS's capability of using floating-point values.   :-))))
(A classic presentation given at most SHARE meetings is titled
"The answers are almost right"; it's a tutorial on the dangers
of finite-precision binary-arithmetic by a decimal-oriented programmer.
Look for a copy of it in the Proceedings of the SHARE.)

A side-point: remember all the discussion on SAS-L a few years ago,
when Version 6 was first released?  Users complained that the conversion
routines (newly written in the C programming language) did not produce
identical results as the "old" (written in the PL/I programming language)
conversion routines?  A similar wave of complaints arose when users upgraded
from the "classic" transcendental-function routines in VS FORTRAN Version 1
to the "new" routines in the VS FORTRAN Version 2 library -- the "new" results
are always accurate to one ULP (unit in the last place), but the users
preferred the old, inaccurate routines!  My point is that external-format to
internal-format conversion has always been a problem for computer-programmers,
whether they write in C, PL/I, FORTRAN, or SAS.

Only a naive user of computers should expect a line of code like:
     IF A EQ .1 THEN ...
to actually perform what the user intended!
(I exclude symbolic-manipulation packages like MAPLE and REXX,
which store all numbers as indefinite-precision strings,
rather than as finite-precision values.)

A user who codes the above will soon learn that this should be coded as:
    IF  (A-0.1) < 1.0E-5  THEN PUT 'Close enough for jazz!'
and that the statement:
    DO X=0.0 to 100.0 by 0.01
can produce "interesting" results. :-)

SAS provides all the tools for the user to properly code a comparison
between two numeric variables, e.g., the FUZZ function (page 550 in
"SAS(r) Language, Reference, Version 6, First Edition"),
and a tool (the LENGTH statement) to allow the knowledgeable user
to *choose* to produce SAS datasets which economize on the disk-space
required for their storage.  Since "end-user computing" seems here to stay,
the onus is on the user to understand the tools they choose to use.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU