extract vars from files - syntax

[cristiano1974]

Dear listers,
I've tried to save into different file, some subset of vars of a dataset
using macro programming and DO statement.

I'd like to save in a .sav file just from:

 Var2 to Var6

then into another file :

just to var7 to var11 and so on, until Var111


After some attempts with macro and syntax, I'm not able to increment
correctly the index of the DO statement..

Any suggestions would be much appreciated, thanks!

[Bob Walker-2]

Hi Christiano,

Here's a macro example based on a sample data set with variables V2 to V16. The macro chops the file into blocks of three variables starting with V2, but you can change the increment to the value you need (since you have many more variables and files). In the macro language, true arithmetic looping using macro variables is not supported (unfortunately). You must improvise by using blanks (!BLANKS) or strings, and then measuring their changing length (e.g., using !CONCAT) to mimic a numeric counter.

SET MEXPAND ON / MPRINT ON / PRI ON.
DATA LIST LIST /V2 TO V16.
BEGIN DATA
0 1 0 1 1 0 1 0 1 1 0 1 0 1 1
1 1 1 1 1 1 1 0 1 1 0 1 0 1 1
0 1 0 1 1 0 1 0 1 1 0 1 0 1 1
1 0 1 1 0 1 0 1 1 0 1 0 1 1 0
0 1 0 1 1 0 0 0 0 0 0 1 0 1 1
1 1 0 1 0 1 1 0 1 0 1 1 1 1 1
0 1 0 1 1 0 1 0 1 1 0 1 0 1 1
END DATA.
DATASET NAME DS1 WINDOW=FRONT.
DATASET ACTIVATE DS1.

DEFINE !CRISTIANO()

!DO !A=2 !TO 16 !BY 3
!LET !B=!CONCAT(!BLANKS(!A),!BLANKS(2)) !LET !B=!LENGTH(!B)
SAVE OUT=!QUOTE(!CONCAT("C:\SAF\SPSS Listserv\V",!A,"-V",!B,".sav"))
  / KEEP !CONCAT("V",!A) !CONCAT(" TO V",!B).
!DOEND

!ENDDEFINE.
!CRISTIANO.

HTH,

Bob Walker
Surveys & Forecasts, LLC
www.safllc.com




----- Original Message -----
From: Cristiano
Date: Sunday, May 20, 2007 6:17 am
Subject: extract vars from files - syntax
To: [hidden email]

> Dear listers,
> I've tried to save into different file, some subset of vars of a
> datasetusing macro programming and DO statement.
>
> I'd like to save in a .sav file just from:
>
> Var2 to Var6
>
> then into another file :
>
> just to var7 to var11 and so on, until Var111
>
>
> After some attempts with macro and syntax, I'm not able to increment
> correctly the index of the DO statement..
>
> Any suggestions would be much appreciated, thanks!
>

 Bob Walker
Surveys & Forecasts, LLC
www.safllc.com

[Richard Ristow]

Bob, you ARE a good hand with a macro.

At 12:24 PM 5/21/2007, Bob Walker wrote:

>Here's a macro example based on a sample data set with variables V2 to
>V16. The macro chops the file into blocks of three variables starting
>with V2, but you can change the increment to the value you need.

Very nice work. A couple of comments:

. A matter of taste and style: MPRINT is great, but I think when a
macro isn't being expanded, MPRINT clutters the listing. Rather than

>SET MEXPAND ON / MPRINT ON / PRI ON.

I usually use (if necessary)

>SET MEXPAND ON / PRI ON.

and then run the macro with

PRESERVE.
SET MPRINT ON.
!CRISTIANO.
RESTORE.

. If the file's a big one, XSAVE may be significantly faster than SAVE,
since SAVE takes a complete pass through the data for each output file
written. Like this, using your test data and minimal change to your
macro. (The following EXECUTE is necessary.):

DATASET ACTIVATE DS1.
DEFINE !CRISTIANO()

!DO !A=2 !TO 16 !BY 3
!LET !B=!CONCAT(!BLANKS(!A),!BLANKS(2)) !LET !B=!LENGTH(!B)
XSAVE OUT=!QUOTE(!CONCAT("C:\Documents and Settings\Richard\My
Documents",
                           "\Temporary\SPSS\V",!A,"-V",!B,".sav"))
   / KEEP !CONCAT("V",!A) !CONCAT(" TO V",!B).
!DOEND

!ENDDEFINE.

PRESERVE.
SET MPRINT ON.
!CRISTIANO.
  141 M>
  142 M>  .
  143 M>  XSAVE OUT= 'C:\Documents and Settings\Richard\My
Documents\Temporary\SP
             SS\V2-V4.sav' / KEEP V2 TO V4.
  144 M>  XSAVE OUT= 'C:\Documents and Settings\Richard\My
Documents\Temporary\SP
             SS\V5-V7.sav' / KEEP V5 TO V7.
  145 M>  XSAVE OUT= 'C:\Documents and Settings\Richard\My
Documents\Temporary\SP
             SS\V8-V10.sav' / KEEP V8 TO V10.
  146 M>  XSAVE OUT= 'C:\Documents and Settings\Richard\My
Documents\Temporary\SP
             SS\V11-V13.sav' / KEEP V11 TO V13.
  147 M>  XSAVE OUT= 'C:\Documents and Settings\Richard\My
Documents\Temporary\SP
             SS\V14-V16.sav' / KEEP V14 TO V16.
  148 M>  .
RESTORE.
  149 M>  RESTORE.

EXECUTE.
....................
FOOTNOTE: You write,
>In the macro language, true arithmetic looping using macro variables
>is not supported (unfortunately). You must improvise by using blanks
>(!BLANKS) or strings, and then measuring their changing length (e.g.,
>using !CONCAT) to mimic a numeric counter.

"Unfortunately" is more than right. I've no idea why they didn't
include integer arithmetic in the macro language. It's hard to see how
it could have been difficult.

Anyway, to make sure it's clear (since this is a famous, and confusing,
kludge in macro-dom):

>!LET !B=!CONCAT(!BLANKS(!A),!BLANKS(2)) !LET !B=!LENGTH(!B)

!BLANKS(!A) <==> A string with the number of blanks = value of !A

(This is one context in which the macro language *will* recognize the
numeric value of a macro string value.)

!BLANKS(2)  <==> A string with 2 blanks

so,
!CONCAT(!BLANKS(!A),!BLANKS(2))
        <==> A string with 2 + (value of !A) blanks

So if that's the value of !B,
!LENGTH(!B) <==> The numeric value, 2 + (value of !A).

(You can also do subtraction, using !SUBSTR instead of !CONCAT; and
multiplication, using !BLANKS, !CONCAT and a macro loop. Ugly, but it
does work.)

[Bob Walker-2]

Richard,
 
Thanks... your suggestions and ideas are, as always, excellent. I really should avoid SET MPRINT ON, as it creates quite a mess until actually needed at macro expansion. I'll try to be more conscientious about that. XSAVE would probably save file processing time, as Christiano has 111 variables, so he'll end up with 37 files each with three variables. I have a fast machine and XSAVE makes a minor difference, but that may not be true for a slower machine.
 
For what it’s worth (and for anyone remotely interested), I'll add my 1.5 cents about the SPSS macro language based on my struggles with it. You know, when I first started writing macros, I was often completely baffled by the behavior of the interpreter. I had assumed that SPSS macros were much like macros in Excel or Word. Not! They are totally different in both concept and execution. The SPSS macro language does one thing and one thing only: it constructs SPSS syntax. When a macro runs, the syntax statements it was asked to create are then built or, in SPSS parlance, "expanded". If macro expansion occurs without an error (i.e., the statements that the macro was asked to create are syntactically correct), then and only then are the statements actually submitted to the processor for execution. Once a syntax user fully grasps this core concept, the mystery of SPSS macros lessens, and their ability to write very powerful code grows exponentially. You can do an incredible amount of heavy lifting with macros, including file manipulation of virtually any type and creating code that is adaptable and re-usable. I wish that the good folks at SPSS would spend just a little, tiny, eeny-weeny bit of time polishing up the macro language. But of course, I hear that Python is all the rage... yawn.
 
Bob Walker
Surveys & Forecasts, LLC
www.safllc.com


----- Original Message -----
From: Richard Ristow
Date: Monday, May 21, 2007 3:28 pm
Subject: Re: extract vars from files - syntax
To: [hidden email]

> Bob, you ARE a good hand with a macro.
>
> At 12:24 PM 5/21/2007, Bob Walker wrote:
>
> >Here's a macro example based on a sample data set with
> variables V2 to
> >V16. The macro chops the file into blocks of three variables starting
> >with V2, but you can change the increment to the value you need.
>
> Very nice work. A couple of comments:
>
> . A matter of taste and style: MPRINT is great, but I think when a
> macro isn't being expanded, MPRINT clutters the listing. Rather than
>
> >SET MEXPAND ON / MPRINT ON / PRI ON.
>
> I usually use (if necessary)
>
> >SET MEXPAND ON / PRI ON.
>
> and then run the macro with
>
> PRESERVE.
> SET MPRINT ON.
> !CRISTIANO.
> RESTORE.
>
> . If the file's a big one, XSAVE may be significantly faster
> than SAVE,
> since SAVE takes a complete pass through the data for each
> output file
> written. Like this, using your test data and minimal change to your
> macro. (The following EXECUTE is necessary.):
>
> DATASET ACTIVATE DS1.
> DEFINE !CRISTIANO()
>
> !DO !A=2 !TO 16 !BY 3
> !LET !B=!CONCAT(!BLANKS(!A),!BLANKS(2)) !LET !B=!LENGTH(!B)
> XSAVE OUT=!QUOTE(!CONCAT("C:\Documents and Settings\Richard\My
> Documents",
> "\Temporary\SPSS\V",!A,"-V",!B,".sav"))
> / KEEP !CONCAT("V",!A) !CONCAT(" TO V",!B).
> !DOEND
>
> !ENDDEFINE.
>
> PRESERVE.
> SET MPRINT ON.
> !CRISTIANO.
> 141 M>
> 142 M> .
> 143 M> XSAVE OUT= 'C:\Documents and Settings\Richard\My
> Documents\Temporary\SP
> SS\V2-V4.sav' / KEEP V2 TO V4.
> 144 M> XSAVE OUT= 'C:\Documents and Settings\Richard\My
> Documents\Temporary\SP
> SS\V5-V7.sav' / KEEP V5 TO V7.
> 145 M> XSAVE OUT= 'C:\Documents and Settings\Richard\My
> Documents\Temporary\SP
> SS\V8-V10.sav' / KEEP V8 TO V10.
> 146 M> XSAVE OUT= 'C:\Documents and Settings\Richard\My
> Documents\Temporary\SP
> SS\V11-V13.sav' / KEEP V11 TO V13.
> 147 M> XSAVE OUT= 'C:\Documents and Settings\Richard\My
> Documents\Temporary\SP
> SS\V14-V16.sav' / KEEP V14 TO V16.
> 148 M> .
> RESTORE.
> 149 M> RESTORE.
>
> EXECUTE.
> ....................
> FOOTNOTE: You write,
> >In the macro language, true arithmetic looping using macro variables
> >is not supported (unfortunately). You must improvise by using blanks
> >(!BLANKS) or strings, and then measuring their changing length (e.g.,
> >using !CONCAT) to mimic a numeric counter.
>
> "Unfortunately" is more than right. I've no idea why they didn't
> include integer arithmetic in the macro language. It's hard to
> see how
> it could have been difficult.
>
> Anyway, to make sure it's clear (since this is a famous, and
> confusing,kludge in macro-dom):
>
> >!LET !B=!CONCAT(!BLANKS(!A),!BLANKS(2)) !LET !B=!LENGTH(!B)
>
> !BLANKS(!A) <==> A string with the number of blanks = value of !A
>
> (This is one context in which the macro language *will*
> recognize the
> numeric value of a macro string value.)
>
> !BLANKS(2) <==> A string with 2 blanks
>
> so,
> !CONCAT(!BLANKS(!A),!BLANKS(2))
> <==> A string with 2 + (value of !A) blanks
>
> So if that's the value of !B,
> !LENGTH(!B) <==> The numeric value, 2 + (value of !A).
>
> (You can also do subtraction, using !SUBSTR instead of !CONCAT; and
> multiplication, using !BLANKS, !CONCAT and a macro loop. Ugly,
> but it
> does work.)
>

 Bob Walker
Surveys & Forecasts, LLC
www.safllc.com

[Bob Walker-2]

Hi Jon,
 
In the context of what Richard and I were chatting about, I was referring to 'simple' situations like looping. For example, having to remember that counters are really strings (i.e., 10 follows 1, 20 follows 2, and so on), or that one must use things like !BLANKS( ) to increment counters, can really make one crazy. Since the macro language is so deeply emedded, I guess I'm stuck.
 
I confess that I have picked up several books on Python, but haven't really stuck with it. I have found it a rather daunting task for a non-programmer, and other priorities usually pull me away. I can usually get a macro to behave properly, so I've become lazy about learning something totally new. But I suppose if were writing SPSS-specific applications I would be more motivated. And I am probably a bit of a retro grouch! But too often I often find that the latest new thing rarely lives up to the hyperbole. Maybe I'll have to dust off that Python book again.

Bob Walker
Surveys & Forecasts, LLC
www.safllc.com

----- Original Message -----
From: "Peck, Jon"
Date: Tuesday, May 22, 2007 10:47 am
Subject: RE: Re: [SPSSX-L] extract vars from files - syntax
To: [hidden email]

> Bob,
>
> You are exactly right about the macro language: it is a static
> textual substitution mechanism similar to what languages like C
> have. The SaxBasic scripting language is much more like Excel
> macros. In fact, Microsoft VBA and SaxBasic are essentially the
> same language, and you can control SPSS from Excel using VBA or
> control Excel from SPSS using SaxBasic. In both cases you use
> Windows OLE automation.
>
> I'm curious what your polishing of the macro language means, but
> I can promise you that tiny, eeny-weeny bit of time and macro
> don't go in the same sentence. The macro language is embedded
> in the most complex part of SPSS, and every little change made
> there has subtle ramifications for syntax parsing. When we fix
> bugs or make small changes in the system in this area, somebody
> always complains that we broke something, even it was
> undocumented behavior. So we are extremely hesitant to change
> anything in macro.
>
> Besides which, despite your Python yawn, we think that Python is
> vastly superior to the macro language, and it is more powerful
> and at the same time easier to learn. And, of course, it is
> dynamic like SaxBasic (only better). So I'm curious why you see
> this as a big yawn.
>
> Anyway, thanks for all your good posting on the list.
>
> Regards,
> Jon Peck
> SPSS
>
> -----Original Message-----
> From: SPSSX(r) Discussion [mailto:[hidden email]] On
> Behalf Of Bob Walker
> Sent: Monday, May 21, 2007 6:48 PM
> To: [hidden email]
> Subject: Re: [SPSSX-L] extract vars from files - syntax
>
> Richard,
>
> [>>>Peck, Jon] [snip]
> For what it’s worth (and for anyone remotely interested), I'll
> add my 1.5 cents about the SPSS macro language based on my
> struggles with it. You know, when I first started writing
> macros, I was often completely baffled by the behavior of the
> interpreter. I had assumed that SPSS macros were much like
> macros in Excel or Word. Not! They are totally different in both
> concept and execution. The SPSS macro language does one thing
> and one thing only: it constructs SPSS syntax. When a macro
> runs, the syntax statements it was asked to create are then
> built or, in SPSS parlance, "expanded". If macro expansion
> occurs without an error (i.e., the statements that the macro was
> asked to create are syntactically correct), then and only then
> are the statements actually submitted to the processor for
> execution. Once a syntax user fully grasps this core concept,
> the mystery of SPSS macros lessens, and their ability to write
> very powerful code grows exponentially. You can do an incredible
> amount of heavy
> lifting with macros, including file manipulation of virtually
> any type and creating code that is adaptable and re-usable. I
> wish that the good folks at SPSS would spend just a little,
> tiny, eeny-weeny bit of time polishing up the macro language.
> But of course, I hear that Python is all the rage... yawn.
>
> Bob Walker
> Surveys & Forecasts, LLC
> www.safllc.com
>

 Bob Walker
Surveys & Forecasts, LLC
www.safllc.com

[Richard Ristow]

At 07:47 PM 5/21/2007, Bob Walker wrote, under subject "Re: extract
vars from files - syntax":

>For what it's worth, I'll add my 1.5 cents about the SPSS macro
>language based on my struggles with it.
>
>When I first started writing macros, I was often completely baffled by
>the behavior of the interpreter. I had assumed that SPSS macros were
>much like macros in Excel or Word. Not! They are totally different in
>both concept and execution. The SPSS macro language does one thing and
>one thing only: it constructs SPSS syntax. When a macro runs, the
>syntax statements it was asked to create are then built or, in SPSS
>parlance, "expanded". If macro expansion occurs without an error
>(i.e., the statements that the macro was asked to create are
>syntactically correct), then and only then are the statements actually
>submitted to the processor for execution.

Right. In this sense, the SPSS has a 'true' or 'pure' macro facility;
that is, a pure string processor that generates code for its
programming system. (The term and the idea were originally used to
generate the sequences of instructions that occur frequently in
assembly-language code.)

I think it's even more basic than you state. "If macro expansion occurs
without an error" applies only to errors in the macro language itself;
if none of those occur, the statements are submitted to the SPSS
processor. Only in the SPSS processor are they checked for SPSS syntax
errors, and that is done exactly as if they came from open code.

Since a pure macro language generates textual code, it's only
meaningful if the system runs textual code. The Excel and Word are not
driven by textual code; their user interfaces are GUI-driven
special-purpose editors. So VBA 'macros' for these applications issue
calls to 'methods' (OOP parlance) of various objects that the
applications make available to VBA for that purpose. That's one
difference from SPSS macros.

And Excel and Word macros are not invoked as part of a
code-interpreting system; Excel and Word, in their essence, don't run
code. Excel and Word macros, like macros for all editors, are invoked
by user action, though the result may be to run a sizable program. So
that's a second difference.

And, like most 'macro' languages for editors, Excel and Word macros are
really what's commonly called 'scripting' languages: the macros do not
merely generate commands, but execute them as they do so; and they have
access to the resulting state of the system, and can modify subsequent
actions based on that state.

Pure macro languages are natural for systems driven by code that's only
meaningful executed as units or large blocks: SPSS, SAS, C, PL/I
(remember that?), assembly languages. Similarly, it's natural to
implement scripting languages for systems driven by commands that
execute individually: editors, operating-system user interfaces.
(MS-DOS .BAT files are really scripts, though very primitive ones: they
have access to little system information except environmental variables
and return codes from DOS commands.)

(I'm talking, here, about the front-end interface to Excel and Word,
the GUI-oriented special-purpose editors. An Excel spreadsheet, itself,
contains and runs a good deal of code, as cell formulas and the like;
and a Word document does a good deal of processing, to format its text
for output. But both are separate from editing. With respect to that
back-end processing, the macros are pure text generators; at least, I
don't think an Excel macro has access to the values produced by cell
formulas, in the spreadsheet it's working on.)

Back to SPSS:

>Once a user fully grasps [that SPSS macros are 'pure' macros,] their
>mystery lessens, and their ability to write very powerful code grows
>exponentially.

Exactly. Pure macros are very useful indeed, no matter the various
things they can't do.

>But of course, I hear that Python is all the rage... yawn.

And here's a next step. "Pure macro languages are natural [and
scripting languages aren't] for systems driven by code that's only
meaningful executed as units". But for systems like SPSS and SAS, where
code is executed in blocks that leave the system in defined states,
scripting is meaningful, so long as the script only tries to read the
system state at such a place. The SAS macro system is really such a
scripting system; notoriously, it is both powerful and confusing, for
that reason.

In SPSS, it's long been practice to get 'scripting' effects by
generating code in a transformation program, writing it to a file, and
INCLUDEing or INSERTing the file. (That works because of an illogical
but useful SPSS quirk: INCLUDEd or INSERTed files are not read until
execution reaches the INCLUDE or INSERT statements.)

One thing (not the only thing) that Python 'programmability' gives is
'scripting' in this sense: Python can emit SPSS code as a macro
facility (using spss.Submit), and it has access to the data dictionary
and some other information, on which it can base the code it generates
and emits. That's only part of the new story, but it's a big part.

(And yes, I put 'programmability' in quotes. That's not because
Python/SPSS isn't programmable; of course it is. But SPSS has been
programmable all along, in the transformation language and the
procedure statements. It would be more accurate to say that Python adds
'scripting ability', though through direct access to the data as a
Python/SPSS 'cursor' object, the Python interface goes beyond
scripting.)

Novus ordo seclorum.

-Regards to all,
  Richard

[Bob Walker-2]

Thanks for this very thoughtful posting... Regards,

Bob Walker
Surveys & Forecasts, LLC
www.safllc.com

----- Original Message -----
From: Richard Ristow
Date: Tuesday, May 22, 2007 8:12 pm
Subject: The nature of SPSS macros, with context
To: [hidden email], [hidden email]

> At 07:47 PM 5/21/2007, Bob Walker wrote, under subject "Re:
> extract
> vars from files - syntax":
>
> >For what it's worth, I'll add my 1.5 cents about the SPSS macro
> >language based on my struggles with it.
> >
> >When I first started writing macros, I was often completely
> baffled by
> >the behavior of the interpreter. I had assumed that SPSS macros
> were
> >much like macros in Excel or Word. Not! They are totally
> different in
> >both concept and execution. The SPSS macro language does one
> thing and
> >one thing only: it constructs SPSS syntax. When a macro runs,
> the
> >syntax statements it was asked to create are then built or, in
> SPSS
> >parlance, "expanded". If macro expansion occurs without an
> error
> >(i.e., the statements that the macro was asked to create are
> >syntactically correct), then and only then are the statements
> actually
> >submitted to the processor for execution.
>
> Right. In this sense, the SPSS has a 'true' or 'pure' macro
> facility;
> that is, a pure string processor that generates code for its
> programming system. (The term and the idea were originally used
> to
> generate the sequences of instructions that occur frequently in
> assembly-language code.)
>
> I think it's even more basic than you state. "If macro expansion
> occurs
> without an error" applies only to errors in the macro language
> itself;
> if none of those occur, the statements are submitted to the SPSS
> processor. Only in the SPSS processor are they checked for SPSS
> syntax
> errors, and that is done exactly as if they came from open code.
>
> Since a pure macro language generates textual code, it's only
> meaningful if the system runs textual code. The Excel and Word
> are not
> driven by textual code; their user interfaces are GUI-driven
> special-purpose editors. So VBA 'macros' for these applications
> issue
> calls to 'methods' (OOP parlance) of various objects that the
> applications make available to VBA for that purpose. That's one
> difference from SPSS macros.
>
> And Excel and Word macros are not invoked as part of a
> code-interpreting system; Excel and Word, in their essence,
> don't run
> code. Excel and Word macros, like macros for all editors, are
> invoked
> by user action, though the result may be to run a sizable
> program. So
> that's a second difference.
>
> And, like most 'macro' languages for editors, Excel and Word
> macros are
> really what's commonly called 'scripting' languages: the macros
> do not
> merely generate commands, but execute them as they do so; and
> they have
> access to the resulting state of the system, and can modify
> subsequent
> actions based on that state.
>
> Pure macro languages are natural for systems driven by code
> that's only
> meaningful executed as units or large blocks: SPSS, SAS, C, PL/I
> (remember that?), assembly languages. Similarly, it's natural to
> implement scripting languages for systems driven by commands
> that
> execute individually: editors, operating-system user interfaces.
> (MS-DOS .BAT files are really scripts, though very primitive
> ones: they
> have access to little system information except environmental
> variables
> and return codes from DOS commands.)
>
> (I'm talking, here, about the front-end interface to Excel and
> Word,
> the GUI-oriented special-purpose editors. An Excel spreadsheet,
> itself,
> contains and runs a good deal of code, as cell formulas and the
> like;
> and a Word document does a good deal of processing, to format
> its text
> for output. But both are separate from editing. With respect to
> that
> back-end processing, the macros are pure text generators; at
> least, I
> don't think an Excel macro has access to the values produced by
> cell
> formulas, in the spreadsheet it's working on.)
>
> Back to SPSS:
>
> >Once a user fully grasps [that SPSS macros are 'pure' macros,]
> their
> >mystery lessens, and their ability to write very powerful code
> grows
> >exponentially.
>
> Exactly. Pure macros are very useful indeed, no matter the
> various
> things they can't do.
>
> >But of course, I hear that Python is all the rage... yawn.
>
> And here's a next step. "Pure macro languages are natural [and
> scripting languages aren't] for systems driven by code that's
> only
> meaningful executed as units". But for systems like SPSS and
> SAS, where
> code is executed in blocks that leave the system in defined
> states,
> scripting is meaningful, so long as the script only tries to
> read the
> system state at such a place. The SAS macro system is really
> such a
> scripting system; notoriously, it is both powerful and
> confusing, for
> that reason.
>
> In SPSS, it's long been practice to get 'scripting' effects by
> generating code in a transformation program, writing it to a
> file, and
> INCLUDEing or INSERTing the file. (That works because of an
> illogical
> but useful SPSS quirk: INCLUDEd or INSERTed files are not read
> until
> execution reaches the INCLUDE or INSERT statements.)
>
> One thing (not the only thing) that Python 'programmability'
> gives is
> 'scripting' in this sense: Python can emit SPSS code as a macro
> facility (using spss.Submit), and it has access to the data
> dictionary
> and some other information, on which it can base the code it
> generates
> and emits. That's only part of the new story, but it's a big part.
>
> (And yes, I put 'programmability' in quotes. That's not because
> Python/SPSS isn't programmable; of course it is. But SPSS has
> been
> programmable all along, in the transformation language and the
> procedure statements. It would be more accurate to say that
> Python adds
> 'scripting ability', though through direct access to the data as
> a
> Python/SPSS 'cursor' object, the Python interface goes beyond
> scripting.)
>
> Novus ordo seclorum.
>
> -Regards to all,
> Richard
>
>

 Bob Walker
Surveys & Forecasts, LLC
www.safllc.com

[cristiano1974]

Thanks for all suggestions and example, they are really useful!

Cris

On 5/23/07, Bob Walker <[hidden email]> wrote:

>
> Hi Jon,
>
> In the context of what Richard and I were chatting about, I was referring
> to 'simple' situations like looping. For example, having to remember that
> counters are really strings (i.e., 10 follows 1, 20 follows 2, and so on),
> or that one must use things like !BLANKS( ) to increment counters, can
> really make one crazy. Since the macro language is so deeply emedded, I
> guess I'm stuck.
>
> I confess that I have picked up several books on Python, but haven't
> really stuck with it. I have found it a rather daunting task for a
> non-programmer, and other priorities usually pull me away. I can usually get
> a macro to behave properly, so I've become lazy about learning something
> totally new. But I suppose if were writing SPSS-specific applications I
> would be more motivated. And I am probably a bit of a retro grouch! But too
> often I often find that the latest new thing rarely lives up to the
> hyperbole. Maybe I'll have to dust off that Python book again.
>
> Bob Walker
> Surveys & Forecasts, LLC
> www.safllc.com
>
> ----- Original Message -----
> From: "Peck, Jon"
> Date: Tuesday, May 22, 2007 10:47 am
> Subject: RE: Re: [SPSSX-L] extract vars from files - syntax
> To: [hidden email]
>
> > Bob,
> >
> > You are exactly right about the macro language: it is a static
> > textual substitution mechanism similar to what languages like C
> > have. The SaxBasic scripting language is much more like Excel
> > macros. In fact, Microsoft VBA and SaxBasic are essentially the
> > same language, and you can control SPSS from Excel using VBA or
> > control Excel from SPSS using SaxBasic. In both cases you use
> > Windows OLE automation.
> >
> > I'm curious what your polishing of the macro language means, but
> > I can promise you that tiny, eeny-weeny bit of time and macro
> > don't go in the same sentence. The macro language is embedded
> > in the most complex part of SPSS, and every little change made
> > there has subtle ramifications for syntax parsing. When we fix
> > bugs or make small changes in the system in this area, somebody
> > always complains that we broke something, even it was
> > undocumented behavior. So we are extremely hesitant to change
> > anything in macro.
> >
> > Besides which, despite your Python yawn, we think that Python is
> > vastly superior to the macro language, and it is more powerful
> > and at the same time easier to learn. And, of course, it is
> > dynamic like SaxBasic (only better). So I'm curious why you see
> > this as a big yawn.
> >
> > Anyway, thanks for all your good posting on the list.
> >
> > Regards,
> > Jon Peck
> > SPSS
> >
> > -----Original Message-----
> > From: SPSSX(r) Discussion [mailto:[hidden email]] On
> > Behalf Of Bob Walker
> > Sent: Monday, May 21, 2007 6:48 PM
> > To: [hidden email]
> > Subject: Re: [SPSSX-L] extract vars from files - syntax
> >
> > Richard,
> >
> > [>>>Peck, Jon] [snip]
> > For what it's worth (and for anyone remotely interested), I'll
> > add my 1.5 cents about the SPSS macro language based on my
> > struggles with it. You know, when I first started writing
> > macros, I was often completely baffled by the behavior of the
> > interpreter. I had assumed that SPSS macros were much like
> > macros in Excel or Word. Not! They are totally different in both
> > concept and execution. The SPSS macro language does one thing
> > and one thing only: it constructs SPSS syntax. When a macro
> > runs, the syntax statements it was asked to create are then
> > built or, in SPSS parlance, "expanded". If macro expansion
> > occurs without an error (i.e., the statements that the macro was
> > asked to create are syntactically correct), then and only then
> > are the statements actually submitted to the processor for
> > execution. Once a syntax user fully grasps this core concept,
> > the mystery of SPSS macros lessens, and their ability to write
> > very powerful code grows exponentially. You can do an incredible
> > amount of heavy
> > lifting with macros, including file manipulation of virtually
> > any type and creating code that is adaptable and re-usable. I
> > wish that the good folks at SPSS would spend just a little,
> > tiny, eeny-weeny bit of time polishing up the macro language.
> > But of course, I hear that Python is all the rage... yawn.
> >
> > Bob Walker
> > Surveys & Forecasts, LLC
> > www.safllc.com
> >
>
> Bob Walker
> Surveys & Forecasts, LLC
> www.safllc.com
>