Newsgroups: bit.listserv.sas-l
Date:         Tue, 7 Apr 1992 15:31:29 ECT
Reply-To:     Lary Jones <LJONES@BINGVMB.BITNET>
From:         Lary Jones <LJONES@BINGVMB.BITNET>
Subject:      Re: SAS vs. SPSS Summary - Final Chapter.
              7 Apr 1992 12:07:00 EDT from <bdperrm1%budget@ALBNYDH2>

On Tue, 7 Apr 1992 12:07:00 EDT <bdperrm1%budget@ALBNYDH2> said:
>David Alderton recently sent me some additional comments regarding the
>differences between SPSS and SAS.

>=========================================================================
>>Reply-To: alderton@nprdc.navy.mil
>
>      1.  Database management: just try merging 3 files in SPSS!  This, the
>simplist of database techniques requires 2 runs in SPSS; a third if you
>want flat file output.  And this is just the beginning.  Fundamentally,
>SPSS is a data analysis package and little more.

Like David Alderton, I was raised on SPSS, and now a use SAS _a lot_.
However, my job requires me to use both packages/languages.  I wonder
if he has had the opportunity to stay current with each.

Maybe I am missing something, but I do multiple merges in both
packages all the time. In both cases the input to the MERGE (SAS) or
MATCH FILES (SPSS) statement must be a product dataset file. The SPSS
command is a Proc.  In SAS, MERGE is a Data step command. However, the
syntax of the two commands is very similar.

   SPSS                                   SAS
   ----                                   ---
MATCH FILES                           MERGE ONE TWO THREE;
   FILE= ONE /                        BY ID;
   FILE= TWO /
   FILE= THREE /
   BY= ID

Both offer marker (IN=) variables.  SPSS has a TABLE= spec for aggregated or
summary files whose cases should be merged with multiple records of another
file.  SAS handles this via implication in MERGE statement.  The capabilities
seem pretty similar to me :-)

>      2.  Flexibility: while the number of options available under SAS
>procs (data steps also, but I'm thinking mostly about procs) is somethings
>overwhelming, SPSS allows very little flexibility;

The SAS Data Step language is more extensive and flexible.  But,
difference between the two packages is elastic.  They watch each other
carefully, and make changes to approximate capabilities in the other.
SAS is usually ahead in its data manipulation language, and in the
presence of some specialized procs and advanced statistical techniques
and procedures.  The difference may be more apparent on IBM systems,
where SAS traditionally has provided utility routines unavailable on
other systems.

>worse yet, many decisions
>and assumptions are not only hardwired, but in fact, are unspecified.

I do not believe this is still true.  In fact, to the contrary, two years
ago there was an inquiry on SAS-L asking why SPSS MANOVA output matched a
text book example, and SAS GLM did not (different choices in the type of
SS used by default).  The response said RTFM for each package.  There was
a clear specification of the default in both cases.

>(I have forgotten which one, but for years, one of the SPSS ANOVA routines
>assumed equal n's in its analysis, and although it was not stated, all
>computations were based on this assumption so often the sums of squares
>were all wrong -- a whole generation of social scientists reported errant
>results!)

I am sorry Dave, but this kind of historical slur doesn't help.  Even
though basically true (SPSS wasn't using the favored approach to
unequal N), this is a critique of SPSS before it even went to the "X"
version (9-10 years ago). Comparisons of packages should be based on
the present commercial versions.

>       3.  Interaction between procs/data steps/database:  One really slick
>thing about SAS is its ability to utilize its own output; something SPSS
>can rarely do.

Again we have to be careful that we are not comparing SAS 6.07 with
SPSS-X release 1. SAS does provide more output functions, but SPSS has
added a bunch itself. SAS definitely does a better job here.  This is
a good distinction.  Especially, SAS's ability to output parameters
(OUTEST=) for later use is a real plus.

  --- Much ommitted --

I've got to get back to my real work ;-)  I hope what I have added is
productive and not fanning *flames*.  Perhaps, if this is a hot topic,
we should move (or copy it) to STAT-L, and include comparisons with
other major packages/languages.

Regards to all,
__________________________________________________________________
Lary Jones...Computing Services...Binghamton Univ...(607) 777-2879
School of Management Research Support ...... LJones@BingVMB.Bitnet
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU