I agree about adding analyses to PSPPIRE but I have to disagree about merging files (adding variables). I find it *far* easier to use syntax:
http://www.spss-tutorials.com/spss-match-files-command/ Just a few lines for most matches! The problem is that there are several choices (e.g., a table merge vs. a "normal" merge) and it makes the dialog too complex (i.e., I don't always get results I was expecting and I cannot tell what went wrong). I won't blame you if you learned the right way to do the merges you need to do in the dialog and now find that easy, but for a new dialog/GUI user it's not simple. The complexity of the underlying operations defy a trivially simple dialog interface. How many novice SPSS/PSPP users know what a "table match" is? And from the perspective of adding the functionality to PSPPIRE I think it would be a lot of work to support all the variations in merging. I added a tiny feature to PSPP and I didn't find the C impossible (although I needed help from John Darrington) but I have yet to figure out how to add things to PSPPIRE. So, anyway, merging two files to add variables is simple: match files file = 'c:\whatever\file1.sav' /file = 'c:\whatever\file2.sav' /by MyKeyVariable /map . file1.sav and file2.sav need to be sorted by MyKeyVariable (which, obviously, has to exist and be compatible in both files) so the whole syntax I use is just a little longer: get file = 'c:\whatever\file1.sav'. execute. sort cases by MyKeyVariable. compute dum1=1. execute. save /outfile = 'c:\whatever\file1.sav'. get file = 'c:\whatever\file.sav'. sort cases by MyKeyVariable. compute dum2=1. execute. save /outfile = 'c:\whatever\file2.sav'. match files file = 'c:\whatever\file1.sav' /file = 'c:\whatever\file2.sav' /by MyKeyVariable /map . recode dum1 dum2 (SYSMIS=0). execute. compute dum=dum1+dum2. freq / dum1 dum2 dum. temporary. select if( dum < 2). print / dum dum1 dum2 MyKeyVariable lname fname . execute. The business about DUM, DUM1 and DUM2 will help you identify mismatches. DUM1 will be 1 for all cases from file1, dum2 will be 1 for all cases from file 2. After recoding missing to zero and adding DUM1+DUM2, if DUM <> 2 then the case is the result of a mismatch. The PRINT statement will print these variables and the variables lname and fname to try to match up cases for all cases that are mismatched. I learned this method around 1993... I know there has since been added an in-built feature that's like dum (and MAP visually show in the output where variables came from). I'd be curious if there's a better way of doing this today. Of course, if you work with clean data that never have mismatches then you don't need to worry about this. I have never been so fortunate. -Alan On 1/19/2017 4:52 PM, Dr. Oliver Walter wrote: > > 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 > > -- 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
