Re: Use EXECUTE sparingly
Locked
 
|
I'd posted,
>>NUMERIC newdate (ADATE8). >>COMPUTE newdate=NUMBER(substr(date,2),ADATE8). At 03:28 PM 10/25/2006, Mark A Davenport MADAVENP wrote, off-list: >Well, I ran your solution and nothing populated the new_date cells >until after I added EXECUTE I reran the syntax. Right. That's the source of the common mis-perception: results of a transformation command don't show up right away >IN THE DATA EDITOR<. Indeed, a transformation command doesn't become effective until there's a pass through the data. (Makes sense: SPSS can't transform the data in a case, until it sees that case.) However, most of what you do in SPSS - run a procedure, save a file - takes a data pass anyway, and SPSS does the transformations then. A preceding EXECUTE is needless and, as I said, wasteful. (Sometimes, it's worth a data pass to see your results in the Data Editor. Then, EXECUTE in syntax (or, equivalently, menu Transform>Run Pending Transformations), will give you the data pass, and your results. But that doesn't mean you need the EXECUTE for a *procedure* to see the results.) For when EXECUTE is useful, see Levesque; or, among others, Ristow, Richard, "EXECUTE is sometimes useful", SPSSX-L Thu, 4 May 2006 12:10:14 -0400. Exercise: Copy the syntax below to a syntax window(*). Select and run, one step at a time, * Step I: Everything through the first FREQUENCIES You'll see the correct FREQUENCIES table in the output, and VBL_01 populated in the Data Editor. * Step II: The COMPUTE for VBL_02 You'll see VBL_02 created in the Data Editor, but not populated. That's what's bothering you. * Step III: The COMPUTE for VBL_03 Now VBL_03 is created and not populated. Looks still worse, right? It even needs the value of an unpopulated variable. BUT, now, * Step IV: The final FREQUENCIES Although FREQUENCIES runs on variables that were "not populated", it produces the correct frequency tables; and now, those variables are populated in the Data Editor. Explanation: FREQUENCIES needs the data, so it forces a data pass, during which the transformations are done. And no EXECUTE anywhere. -Cheers, and good luck, Richard * .................................. . * Step I: VBL_01 is created and populated . DATA LIST FREE /VBL_01 (F3). BEGIN DATA 1 1 3 3 5 5 7 7 END DATA. FREQUENCIES VBL_01. * Step II: VBL_02 is created, not populated . COMPUTE VBL_02 = VBL_01 + 1. * Step III: VBL_03 is created, not populated . * It depends on VBL_02. . COMPUTE VBL_03 = VBL_02 / 2. * Step IV: FREQUENCIES sees the new variables . * properly populated. . * They are then populated in the . * Data Editor. . * There is no EXECUTE in this syntax. . FREQUENCIES VBL_01 VBL_02 VBL_03. * .................................. . (*) Note to myself: This syntax not saved as a separate file |
|
One point to add to this discussion of Richard's favorite topic:
By default, dialog boxes that paste or run transformation syntax generate an EXECUTE command so that the Data Editor shows the effect of the transformation immediately (or when you run the pasted syntax). This is done so as not to confuse users who expect to see the result in the Data Editor when they Ok the dialog. But you can changed this behavior in Edit>Options>Data. The Transformation and Merge Options group offers the choices Calculate values immediately Calculate values before used The latter choice keeps the EXECUTE from being generated. Regards, Jon Peck -----Original Message----- From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Richard Ristow Sent: Thursday, October 26, 2006 9:30 AM To: [hidden email] Subject: Re: [SPSSX-L] Use EXECUTE sparingly I'd posted, >>NUMERIC newdate (ADATE8). >>COMPUTE newdate=NUMBER(substr(date,2),ADATE8). At 03:28 PM 10/25/2006, Mark A Davenport MADAVENP wrote, off-list: >Well, I ran your solution and nothing populated the new_date cells >until after I added EXECUTE I reran the syntax. Right. That's the source of the common mis-perception: results of a transformation command don't show up right away >IN THE DATA EDITOR<. Indeed, a transformation command doesn't become effective until there's a pass through the data. (Makes sense: SPSS can't transform the data in a case, until it sees that case.) However, most of what you do in SPSS - run a procedure, save a file - takes a data pass anyway, and SPSS does the transformations then. A preceding EXECUTE is needless and, as I said, wasteful. (Sometimes, it's worth a data pass to see your results in the Data Editor. Then, EXECUTE in syntax (or, equivalently, menu Transform>Run Pending Transformations), will give you the data pass, and your results. But that doesn't mean you need the EXECUTE for a *procedure* to see the results.) |
Re: Use EXECUTE sparingly
|
|
My point exactly. The reader would not have seen the result of this snip
of syntax (to know it had run properly or at all), without the EXECUTE. Richard's point is, strategically speaking, sound practice. *************************************************************************************************************************************************************** Mark A. Davenport Ph.D. Senior Research Analyst Office of Institutional Research The University of North Carolina at Greensboro 336.256.0395 [hidden email] 'An approximate answer to the right question is worth a good deal more than an exact answer to an approximate question.' --a paraphrase of J. W. Tukey (1962) "Peck, Jon" <[hidden email]> Sent by: "SPSSX(r) Discussion" <[hidden email]> 10/26/2006 11:38 AM Please respond to "Peck, Jon" <[hidden email]> To [hidden email] cc Subject Re: Use EXECUTE sparingly One point to add to this discussion of Richard's favorite topic: By default, dialog boxes that paste or run transformation syntax generate an EXECUTE command so that the Data Editor shows the effect of the transformation immediately (or when you run the pasted syntax). This is done so as not to confuse users who expect to see the result in the Data Editor when they Ok the dialog. But you can changed this behavior in Edit>Options>Data. The Transformation and Merge Options group offers the choices Calculate values immediately Calculate values before used The latter choice keeps the EXECUTE from being generated. Regards, Jon Peck -----Original Message----- From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Richard Ristow Sent: Thursday, October 26, 2006 9:30 AM To: [hidden email] Subject: Re: [SPSSX-L] Use EXECUTE sparingly I'd posted, >>NUMERIC newdate (ADATE8). >>COMPUTE newdate=NUMBER(substr(date,2),ADATE8). At 03:28 PM 10/25/2006, Mark A Davenport MADAVENP wrote, off-list: >Well, I ran your solution and nothing populated the new_date cells >until after I added EXECUTE I reran the syntax. Right. That's the source of the common mis-perception: results of a transformation command don't show up right away >IN THE DATA EDITOR<. Indeed, a transformation command doesn't become effective until there's a pass through the data. (Makes sense: SPSS can't transform the data in a case, until it sees that case.) However, most of what you do in SPSS - run a procedure, save a file - takes a data pass anyway, and SPSS does the transformations then. A preceding EXECUTE is needless and, as I said, wasteful. (Sometimes, it's worth a data pass to see your results in the Data Editor. Then, EXECUTE in syntax (or, equivalently, menu Transform>Run Pending Transformations), will give you the data pass, and your results. But that doesn't mean you need the EXECUTE for a *procedure* to see the results.) |
CTables pointers vis-a-vis General Tables
|
|
In reply to this post by Peck, Jon
Folks,
We all know that Custom Tables, if you build them yourself, can be much less complicated that those built by the POINT-CLICK-PASTE facility. Can Custom Tables be similarly simplified if I write the program statements myself? They appear to be even more needlessly complicated than General Tables when I use PASTE...even though I know there are more functions. Thanks for any advice you care to offer. Bonus question: Anyone know off hand what the variable limit is in Custom Tables? It's 100 (I think) with General Tables. I'm using SPSSS 15. King Douglas American Airlines Customer Research |
|
|
Assuming that you are talking about Ctables, there is no practical limit on the number of variables in a table.
It’s also true that you can write much simpler syntax by hand than is generated by the Ctables gui. In particular, you can use parentheses to factor out the statistics list. So, for example, the gui generates this: CTABLES /VLABELS VARIABLES=accel engine horse cylinder origin DISPLAY=DEFAULT /TABLE cylinder + origin BY accel [MEAN] + engine [MEAN] + horse [MEAN] /CATEGORIES VARIABLES=cylinder origin ORDER=A KEY=VALUE EMPTY=INCLUDE. but you can rewrite as this: CTABLES /VLABELS VARIABLES=accel engine horse cylinder origin DISPLAY=DEFAULT /TABLE cylinder + origin BY (accel + engine + horse) [MEAN] /CATEGORIES VARIABLES=cylinder origin ORDER=A KEY=VALUE EMPTY=INCLUDE. which produces the same output. The gui also generally pastes syntax that makes defaults explicit, so, for example, the entire /CATEGORIES and /VLABELS subcommands could be eliminated in this case, leaving just CTABLES /TABLE cylinder + origin BY (accel + engine + horse) [MEAN]. And since MEAN is the default statistic for scale variables, the whole command comes down to just CTABLES /TABLE cylinder + origin BY (accel + engine + horse). That is certainly shorter, but it is less explicit, so it’s your call whether this is simpler or not. ________________________________ From: King Douglas [mailto:[hidden email]] Sent: Thursday, October 26, 2006 11:28 AM To: Peck, Jon; [hidden email] Subject: CTables pointers vis-a-vis General Tables Folks, We all know that Custom Tables, if you build them yourself, can be much less complicated that those built by the POINT-CLICK-PASTE facility. Can Custom Tables be similarly simplified if I write the program statements myself? They appear to be even more needlessly complicated than General Tables when I use PASTE...even though I know there are more functions. Thanks for any advice you care to offer. Bonus question: Anyone know off hand what the variable limit is in Custom Tables? It's 100 (I think) with General Tables. I'm using SPSSS 15. King Douglas American Airlines Customer Research |
Re: CTables pointers vis-a-vis General Tables
|
|
Jon,
That's exactly what I was looking for. Thanks so much! King Douglas American Airlines Customer Research "Peck, Jon" <[hidden email]> wrote: Assuming that you are talking about Ctables, there is no practical limit on the number of variables in a table. Itâs also true that you can write much simpler syntax by hand than is generated by the Ctables gui. In particular, you can use parentheses to factor out the statistics list. So, for example, the gui generates this: CTABLES /VLABELS VARIABLES=accel engine horse cylinder origin DISPLAY=DEFAULT /TABLE cylinder + origin BY accel [MEAN] + engine [MEAN] + horse [MEAN] /CATEGORIES VARIABLES=cylinder origin ORDER=A KEY=VALUE EMPTY=INCLUDE. but you can rewrite as this: CTABLES /VLABELS VARIABLES=accel engine horse cylinder origin DISPLAY=DEFAULT /TABLE cylinder + origin BY (accel + engine + horse) [MEAN] /CATEGORIES VARIABLES=cylinder origin ORDER=A KEY=VALUE EMPTY=INCLUDE. which produces the same output. The gui also generally pastes syntax that makes defaults explicit, so, for example, the entire /CATEGORIES and /VLABELS subcommands could be eliminated in this case, leaving just CTABLES /TABLE cylinder + origin BY (accel + engine + horse) [MEAN]. And since MEAN is the default statistic for scale variables, the whole command comes down to just CTABLES /TABLE cylinder + origin BY (accel + engine + horse). That is certainly shorter, but it is less explicit, so itâs your call whether this is simpler or not. ________________________________ From: King Douglas [mailto:[hidden email]] Sent: Thursday, October 26, 2006 11:28 AM To: Peck, Jon; [hidden email] Subject: CTables pointers vis-a-vis General Tables Folks, We all know that Custom Tables, if you build them yourself, can be much less complicated that those built by the POINT-CLICK-PASTE facility. Can Custom Tables be similarly simplified if I write the program statements myself? They appear to be even more needlessly complicated than General Tables when I use PASTE...even though I know there are more functions. Thanks for any advice you care to offer. Bonus question: Anyone know off hand what the variable limit is in Custom Tables? It's 100 (I think) with General Tables. I'm using SPSSS 15. King Douglas American Airlines Customer Research |
«
Return to SPSSX Discussion
|
1 view|%1 views
| Free forum by Nabble | Edit this page |