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 (September 2005)Back to main SPSSX-L pageJoin or leave SPSSX-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Thu, 22 Sep 2005 14:49:08 -0400
Reply-To:     Michael Wexler <mwexler@E-DIALOG.COM>
Sender:       "SPSSX(r) Discussion" <SPSSX-L@LISTSERV.UGA.EDU>
From:         Michael Wexler <mwexler@E-DIALOG.COM>
Subject:      Re: 2nd Attempt: Grouping Zip Codes
Content-Type: text/plain; charset="us-ascii"

Yet another reason to hope for an allegory to "proc sql" in SAS in some future version of SPSS...

-----Original Message----- From: SPSSX(r) Discussion [mailto:SPSSX-L@LISTSERV.UGA.EDU] On Behalf Of Richard Ristow Sent: Wednesday, September 21, 2005 1:53 PM To: SPSSX-L@LISTSERV.UGA.EDU Subject: Re: 2nd Attempt: Grouping Zip Codes

At 09:40 AM 9/21/2005, Spousta Jan wrote:

>Only a few thoughts: <<remarks on the inherent difficulty of the problem>>

>3) The question is then, whether SPSS is just the best tool to create >such algorithm - another possibility is to use a general programming >language. It can be better suited to go through the data in logically >complicated ways. (SPSS and similar tools use the top-to-bottom way >automatically - they just read/write all cases in one step...)

For an appropriate tool, I'd consider a relational DBMS that supports SQL. It has syntax and semantics for many-to-many merges, and this problem tends to need them. What do you think, Jan?

As Jan wrote, the problem is difficult. No tool can solve the conceptual problems. The computational problems could manifest themselves in SQL as straightforward, logically correct, solutions needing storage and computation utterly beyond what's attainable.


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