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 (July 2006)Back to main SPSSX-L pageJoin or leave SPSSX-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
=========================================================================
Date:         Thu, 20 Jul 2006 22:00:59 -0400
Reply-To:     Richard Ristow <wrristow@mindspring.com>
Sender:       "SPSSX(r) Discussion" <SPSSX-L@LISTSERV.UGA.EDU>
From:         Richard Ristow <wrristow@mindspring.com>
Subject:      Re: execute
Comments: To: "P. Scott Dixon" <psdixon@pdx.edu>
In-Reply-To:  <1152804678.44b667465fdc5@webmail.pdx.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed;
              x-avg-checked=avg-ok-6D6C57DA

At 11:31 AM 7/13/2006, P. Scott Dixon wrote:

>I agree with ViAnn [Beadle, in posting included]. With all respect to >the SPSS wunderkinds(*), I think the use of executes is useful to find >flaws in my code at the point they occur, and the cost in processor >time is negligible with small to mid size samples. It is a strong >tool in my, admittedly, less-than-perfect code.

(*) wunderkinder (Richard now ducks quickly out of the way)

Sure. We all put test code in, and test pieces of our programs; or, at least, we do if we've any experience, and know anything about reliability in programming.

In my postings, you'll see a good many LIST commands for this purpose -

LIST or . /**/ LIST. or . /*-- LIST.

Using LIST, instead of executing through that point and using the Data Editor, isn't wunderkindlich; it's from having learned programming when there were no interactive data tools, and if you wanted to learn what was in a file, you printed it. (It's also from SPSS having no 'stop' statement, or 'stop' option on EXECUTE, which will halt execution when that point is reached. I guess I don't like selecting part of the code and running it - though, in fact, I do it fairly often.)

Test code, LIST or EXECUTE or whatever, is just fine. It's just fine even if it slows processing. (As noted, that's negligible in many, many cases.) If you do put in EXECUTEs for testing, I recommend . /**/ EXECUTE. That flags it as test code (the convention is my own, modified following Jan Spousta's practice). It can be inactivated easily, without taking it out, by changing it to . /*-- EXECUTE.

My biggest worry, and warning, is about the perception - which, from inquiries on the List, seems to be fairly common - that an EXECUTE is needed after transformation statements, perhaps ALL transformation statements, for them to take effect.

By the way, as I've written, any statement that forces a data pass, including EXECUTE and LIST, changes the logic flow. That's often of no consequence. But it means that using either EXECUTE or LIST for debugging risks Heisenbugs: bugs that disappear, or possibly appear, because they're being looked for.

From ViAnn Beadle: ------------------------------ >Date: Wed, 12 Jul 2006 07:04:19 -0500 >From: "Beadle, ViAnn" <viann@spss.com> >Subject: Re: reverse concat > >I don't actually use EXECUTE in syntax but when I'm work out gnarly >transformation problems I frequently Run Pending Transformations >(which generates your dreaded EXECUTE) from the data editor and see >the effects of my transformations immediately. My strategy is to work >through the problem a "executable" unit at a time and check out the >unit by running the pending transformations. Unless your dealing with >wide (more than 200 or so variables) or long (more than 10,000) or >more cases the time to actually do the transformation is much less


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