I also use the syntax in the way, you described, Alan. Hence, it is an
argument in favour of implementing some important commands in the GUI.
This morning I liked to merge some files but because the command is not
implemented in the GUI and not easy to understand in the manual, I
stopped using PSPP and used R instead, because its "R Commander" has
some possibilities to merge files. This is the reason why I do not like
comments such as "learn syntax, please" as some other comments could be
understood. If we start to make such comments we could also say: "Use R
instead of PSPP, please".
Oliver Walter
Am 19.01.2017 um 21:40 schrieb Alan Mead:
That's a good question. When I learned the syntax, it was the only
way to do it. There are some good resources available online to
address specific questions. I usually google something like spss
syntax compute and that produces a lot of hits for most questions.
I should say that these days, I do use the GUI to generate the syntax
for virtually all analyses. What I do is to navigate to the dialog I
for the analysis that I want, add some random variables (for most
analyses, you have to find numeric variables), select the options I
want and then paste the syntax. I then edit it to include the
variables I want. If the analysis is just a variable or two and they
are easily found, then it's just as easy to simply pick that one. But
if there are many variables and especially if they are arranged in the
dataset contiguously, then it's far easier to edit the syntax to
change the randomly-selected variables to something like "X to Y"
(which includes all columns between variable X and variable Y in the
dataset, including X and Y).
I personally also use the GUI exclusively to generate syntax for
reading in raw data (reading SAV files with GET is pretty trivial) . I
try hard to analyze tab-delimited files with the variables names on
top and I've found that those are usually read very well into
PSPP/SPSS. I paste the syntax generated by the GUI so I can edit it
if needed. For example, sometimes it will guess wrong about a variable
type. Or I might want to manually change a variable name so it
matches another file.
So, I write syntax mainly for data manipulation (finding bad data,
scoring, creating new variables from input data, etc.) and that
includes a fairly small number of statements:
execute.
count
compute
recode
value label
variable label
temporary
select if
do if ... else ... end if.
sort cases
get
save
write
format
merge files
Maybe I'm digressing. And maybe these comments are mainly for people
who will be doing long, complex, or very important analyses. But I
highly recommend using syntax (whether generated by GUI or by hand)
for all analyses. For one thing, it's self-documenting (if you save
it)... You can go back later and see exactly what you did (e.g., what
variables were included in "INDEX"? How was that Likert scale scored?
What regions went into that market segment?) and if you find a
problem, you already have all the syntax you need to re-run the
analysis. In fact, PSPP produces readable output but with SPSS if you
don't have a copy of SPSS then you won't be able to read the output
file or the SAV file. So, the syntax is the only file that will be
readable (they're just text files; you can open them with your
favorite text editor or Notepad/Wordpad on Windows). If you did an
SPSS analysis and saved just the output and SAV data, you might not be
able to read either file years (or months) from now when you no longer
have SPSS.
I also think you should avoid ever modifying existing variables, so
that you can re-run your syntax to reproduce an analysis. (You could
also never over-write a SAV file, so that the modified variables
become part of a new SAV file, but this is fraught with peril and
tends to lead to a series of undocumented but indistinguishable
datasets, DATA1.SAV, DATA2.SAV, etc.... Far better to document your
analysis in syntax and avoid modifying existing variables by creating
new ones.)
Sometimes, you can also re-use old syntax (if you analyze similar
datasets frequently).
Also, I recommend that when feasible (and sometimes it simply isn't),
you should avoid using SAV files. Or only use them as temporary files,
not as permanent storage of data. Instead, your analysis should begin
by reading a "raw" data source and then do the whole analysis. The
reason is that you cannot tell what data transformation have been
applied to the dataset. Whereas if you read the data from a raw
source, you always know that that raw source data is in it's known
original state. This might not be an issue if your analyses do not
require data transformations; but I find that most of my analyses do
require a lot. In those cases, this isn't a trivial issue.
Once I had an NSF grant which entailed creating an ethics measure and
we used SPSS to score it. It would have been the work of centuries to
re-create the scoring (and verifying it) through a GUI for each
dataset. Instead, I copied a fairly complex chunk of syntax and
adapted it to the names of the variables in the current dataset. I
had a syntax error in one statement because the number of items had
changed. Because it didn't execute, my data were half scored (half
unscored) and I compounded the problem by not noticing the error and
using the score in a later analysis. If I'd written the syntax to
create new scored variables, it wouldn't be possible for my scored
variables to be "half scored" ... some of them wouldn't exist. And in
that case, the missing variables would have stopped the analysis,
instead of allowing erroneous results (from half-scored data) to be
produced.
This is definitely a problem is complex analyses or when manipulating
data, but I'd argue it's a potential source of error in any analysis
that involves any degree of data transformation. IIRC, PSPP
distributes a small example dataset with some kind of Likert data
(customer satisfaction ratings?) and in some version of that example
dataset, one of the items had been reversed (i.e., the Likert
responses had been swapped to 1->5, 2->4, 4->2, 5->1) and saved. You
cannot tell this from the SAV file (at all). In fact, I'm inferring
it from a data analysis, but it's the only possible way that one
Likert item could be so different. Garbage in, garbage out and you
often cannot verify that a SAV file is not "garbage" unless you've
just created it.
You should also be generous in adding comments to your syntax. A
comment is a note to the reader/analyst about the syntax and looks
like this:
* data cleaning code .
* removed item 12 on 17-jan-2017 because it had a poor ITC .
* this is the composite that worked best out of the four we tried.
it's R2 was 0.56.
* scoring for the customer satisfaction Likert responses.
I will admit that syntax requires adhering to the rules of PSPP/SPSS
syntax. You leave off a period at the end or a quote (or use the
wrong quote) and PSPP/SPSS gives you a cryptic error message. I think
this is one of the reasons novice PSPP/SPSS users avoid syntax, but I
think they are handicapping themselves as a result.
One final thing: one of the main advantages of PSPP is that it's free
(i.e., user-editable) software, which includes the manual. So if you
have modifications to make the manual clearer or to add examples, I'm
sure the developers will be delighted to see your changes/additions.
-Alan
On 1/19/2017 1:11 PM, Aj Hollenbach wrote:
Thanks Alan. What is the best approach, in your opinion, to learning
the syntax for these types of expressions? Again, I wholly relied
upon the GUI in SPSS. I did take a look at the PSPP manual, but did
not immediate see examples of the structure of the syntax.
Thanks,
Allen
On Thu, Jan 19, 2017 at 12:00 PM, <pspp-users-requ...@gnu.org
<mailto:pspp-users-requ...@gnu.org>> wrote:
Send Pspp-users mailing list submissions to
pspp-users@gnu.org <mailto:pspp-users@gnu.org>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/pspp-users
<https://lists.gnu.org/mailman/listinfo/pspp-users>
or, via email, send a message with subject or body 'help' to
pspp-users-requ...@gnu.org <mailto:pspp-users-requ...@gnu.org>
You can reach the person managing the list at
pspp-users-ow...@gnu.org <mailto:pspp-users-ow...@gnu.org>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pspp-users digest..."
Today's Topics:
1. Re: Selecting cases using the "IF" Function (Alan Mead)
---------- Forwarded message ----------
From: Alan Mead <ame...@alanmead.org <mailto:ame...@alanmead.org>>
To: pspp-users@gnu.org <mailto:pspp-users@gnu.org>
Cc:
Date: Wed, 18 Jan 2017 11:10:03 -0600
Subject: Re: Selecting cases using the "IF" Function
As Dr. Water says, syntax is a solution. The steps would be to
(1) paste the desired analysis and then (2) edit the syntax to
insert the "IF" statement above it.
You also need to decide if you want to "permanently" delete the
non-selected cases or not. If I have a long series of analyses,
I might select cases (say valid cases) and save them (or use a
filter). But Hollenbach describes analyzing subsets of the
dataset and in that case I often find the temporary command to be
helpful. The syntax for _each analysis_ would look like this:
temporary.
select if( region = 1 or (region=1 and id=3)).
freq ...
You would highlight all three statements and run them. The
"temporary" command causes the selection to be in effect only for
the next analysis. You repeat the "temporary" and "select if" for
each analysis (or, again, use a filter).
BTW, I honestly think just typing the syntax of the "select if"
is easier than using the GUI.
-Alan
On 1/18/2017 9:53 AM, Aj Hollenbach wrote:
Hi PSPP Users,
I am transitioning from SPSS to PSPP and am having some troubles
with case selection. Specifically, under SPSS, I used to be able
to select cases using a radio button in the Data / Select Cases
dialogue box that stated "Select if condition is satisfied...".
However, under PSPP, I have found that this option is not
available, and that you can only select cases based upon (1) a
random sample, (2) case range, or (3) a filter variable. In
other words, there is no option for using the IF function for
selection purposes. I am attaching screenshots from both programs.
I greatly appreciate any advice that others might have on how to
best make a selection of cases using a conditional IF statement.
In short, I am running analysis of household survey data, but
only want to use data from a handful of the administrative
jurisdictions (provinces) within the larger data set.
Regards,
Allen
PS: I am running GNU pspp 0.10.1-g1082b8
--
Alan D. Mead, Ph.D.
President, Talent Algorithms Inc.
science + technology = better workers
http://www.alanmead.org
_______________________________________________
Pspp-users mailing list
Pspp-users@gnu.org <mailto:Pspp-users@gnu.org>
https://lists.gnu.org/mailman/listinfo/pspp-users
<https://lists.gnu.org/mailman/listinfo/pspp-users>
_______________________________________________
Pspp-users mailing list
Pspp-users@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-users
--
Alan D. Mead, Ph.D.
President, Talent Algorithms Inc.
science + technology = better workers
http://www.alanmead.org
I've... seen things you people wouldn't believe...
functions on fire in a copy of Orion.
I watched C-Sharp glitter in the dark near a programmable gate.
All those moments will be lost in time, like Ruby... on... Rails... Time for Pi.
--"The Register" user Alister, applying the famous
"Blade Runner" speech to software development
_______________________________________________
Pspp-users mailing list
Pspp-users@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-users
_______________________________________________
Pspp-users mailing list
Pspp-users@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-users
