Re: execute

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: execute

Simon Phillip Freidin
If you're managing a massive database or writing thousands of lines of
transformation commands then excessive execute's will give poorer performance.

For everybody else ( = most of us) they are irrelevant, except where forced
execution is required, and there are lots of those:

1. more than one missing value statement for the same variables must be
separated by execute/procedure or the effect is as if only the last missing
value statement exists
2. prior to apply dictionary if the file has been opened but the data is
not yet loaded
3. prior to using the results of lag function on a string
4. after write command
5. after print command
6. before 'show n' if case selection will occur
7. when you are using transient system variables in subsequent code ie
compute caseno=$casenum.

Having just done a search, I find that I actually use at least one execute
in almost every program!  :-)

cheers
Simon



Research Database Manager and Analyst
Melbourne Institute of Applied Economic and Social Research
The University of Melbourne
Melbourne VIC 3010 Australia
New Tel: (03) 8344 2085 New Fax: (03) 8344 2111
http://www.melbourneinstitute.com/hilda/
Reply | Threaded
Open this post in threaded view
|

Re: execute

P. Scott Dixon
I agree with ViAnn.  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.

Scott

------------------------------

Date:    Wed, 12 Jul 2006 07:04:19 -0500
From:    "Beadle, ViAnn" <[hidden email]>
Subject: Re: reverse concat

OK, I'll take your bait.=20
=20
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 than the think time to =
step mentally through the process.=20
=20
What does that extra processing really cost you? It's not like the bad =
old days when every job submittal at $1.00 a pop ate up my account at =
the University of Chicago Comp Center.

________________________________
Reply | Threaded
Open this post in threaded view
|

Re: execute

Art Kendall
Of course if you debug your syntax using just a small set of cases, you
don't need to worry about how long it takes to do a data pass.
either create a small data set or use
n of cases 100.

Art

P. Scott Dixon wrote:

>I agree with ViAnn.  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.
>
>Scott
>
>------------------------------
>
>Date:    Wed, 12 Jul 2006 07:04:19 -0500
>From:    "Beadle, ViAnn" <[hidden email]>
>Subject: Re: reverse concat
>
>OK, I'll take your bait.=20
>=20
>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 than the think time to =
>step mentally through the process.=20
>=20
>What does that extra processing really cost you? It's not like the bad =
>old days when every job submittal at $1.00 a pop ate up my account at =
>the University of Chicago Comp Center.
>
>________________________________
>
>
>
>
Art Kendall
Social Research Consultants
Reply | Threaded
Open this post in threaded view
|

Re: execute

Richard Ristow
In reply to this post by P. Scott Dixon
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" <[hidden email]>
>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
>than the think time to step mentally through the process.