XSAVE vs SAVE

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

XSAVE vs SAVE

Eugenio Grant
Hi.



What's the difference between XSAVE and SAVE???



Also I need to drop variables from my Database, I'm using the SAVE OUTFILE
command and then Drop, how can I tell SPSS that I want to keep the same file
name without having to write it every time.



Intead of doing. SAVE OTUFILE = 'LONG LONG LONG LONG LONG LONG NAME' then
Drop



Been able to say SAVE OTUFILE = 'Same name' then Drop



Any ideas???



Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: XSAVE vs SAVE

Brian Pickerill
On Dec 7, 2006, at 12:57 PM, Eugenio Grant wrote:

> Hi.
>
>
>
> What's the difference between XSAVE and SAVE???

The way I look at it, the biggest difference is that XSAVE doesn't
force a pass on the data.   Nothing is actually saved until you get
to a procedure or force a pass on the data with EXECUTE.    As
someone pointed out, you can also use XSAVE in some places (inside do
if/end if loops for instance) where you can't use a SAVE.   XSAVE was
probably originally implemented to save processor time on multiuser
systems, but within a loop, it can't really save all the data until
the loop is completed as the logic is still pending, so XSAVE works
(a deferred save is how I look at it) where an actual save would
not.  In other words, the XSAVE is like a placeholder, wether you are
just planning to save (in that state of the active system file) or
when you are still building logic.

>
> Also I need to drop variables from my Database, I'm using the SAVE
> OUTFILE
> command and then Drop, how can I tell SPSS that I want to keep the
> same file
> name without having to write it every time.
>
> Intead of doing. SAVE OTUFILE = 'LONG LONG LONG LONG LONG LONG
> NAME' then
> Drop
>
> Been able to say SAVE OTUFILE = 'Same name' then Drop
>
> Any ideas??

Not sure I completely understand the question, but one additional
idea is to use FILE HANDLE.

e.g.

File handle myfile /name='My incredibly long file name.SAV'.

Then, you should subsequently be able to refer to the file as simply
myfile, if that helps any.   I find it easier to cut and paste, most
of the time.    Macros, as has been pointed out already, are far more
flexible (and difficult to code) allowing you to change the name
slightly, based, for instance, on a loop variable value, etc...

--Brian
Reply | Threaded
Open this post in threaded view
|

Re: XSAVE vs SAVE

Richard Ristow
At 11:15 AM 12/8/2006, Brian Pickerill wrote:

>>What's the difference between XSAVE and SAVE???
>
>The way I look at it, the biggest difference is that XSAVE doesn't
>force a pass on the data.   Nothing is actually saved until you get to
>a procedure or force a pass on the data with EXECUTE.

Yes. So the file you're XSAVEing to is not available to the immediately
following procedure. However, after the next procedure, or EXECUTE, the
file is available exactly like a SAVEd file.

>You can also use XSAVE in some places (inside do if/end if
>[constructs], and LOOPS) where you can't use a SAVE.

Yes; giving you much greater control over the output. Among other
things, this makes it valuable for writing several output cases from
one input case (although VARSTOCASES now covers most of the instances
when you want to do that).

>XSAVE was probably originally implemented to save processor time on
>multiuser systems

I remember its being introduced in mainframe SPSS in the 1970s. On
those systems, I/O was expensive, so data passes were especially
expensive.

<transformations>
XSAVE <output file>.
<procedure>.

only read the input file once, and could be considerably cheaper than

<transformations>
SAVE <output file>.
<procedure>.

That's still true, although now it matters mainly to keep from
re-reading an input file that is slow because it's much bigger than you
are using, or because it's being read from a slow external source.

<Input and transformations>
XSAVE <output file>.
<procedure>.
GET FILE <output file>

is approximately equivalent to

<Input and transformations>
XSAVE <output file>.
<procedure>.
GET FILE <output file>.

Using XSAVE lets you bypass CACHE restrictions, including that ".. A
cache file will not be written during a procedure that uses temporary
variables." (SPSS 14 Command Syntax Reference p. 177).

The other tricks you can do with XSAVE, like writing multiple cases
from one, only became possible when DO IF and LOOP were introduced, in
SPSSX. (Like Mac OS-X, that was a conscious word-play on 'release 10'.)
You wouldn't *believe* how much less SPSS could do, before that.

>Within a loop, it can't really save all the data until the loop is
>completed as the logic is still pending, so XSAVE works (a deferred
>save is how I look at it) where an actual save would not.

I wouldn't put it quite that way; the meaning of 'loop' could be
confusing.

There are loops within transformation programs, created with
(surprise!) LOOP/END LOOP constructs.

In addition, more important and more subtle, reading the data is a
loop, one record at a time until the file is finished. The entire
transformation program is inside that loop, and the whole program is
executed for every case - XSAVEs and all.

>[XSAVE] can't really save all the data until the loop is completed as
>the logic is still pending

In fact, the logic is complete when the first case is read, and XSAVE
saves right then; but it doesn't save "all the data." It saves, or
writes, whatever record or records it builds from *that case*; and
leaves its output file open for the record it saves with data from
later cases.

>In other words, the XSAVE is like a placeholder, whether you are just
>planning to save (in that state of the active system file) or when you
>are still building logic.

No, it's quite a bit more than a placeholder; it's an executable
transformation-language statement. That's why you can put an XSAVE in a
DO IF, to write data from only some of the input records; or within a
LOOP, to write multiple records from one input record. (You can't put
it in a DO REPEAT, but that's another story.)

The perspective, is to be vividly aware that the transformation program
is the interior of a loop, XSAVEs and all.

To complete the story: SAVE, and procedures, are *not* within a loop.
They have, each, a loop within them, to accept and process records in
sequence, as they come from the transformation program. That's why a
single SAVE or FREQUENCIES or whatever, can accept an entire file.

-Cheers, and onward,
  Richard
Reply | Threaded
Open this post in threaded view
|

Re: XSAVE vs SAVE

Richard Ristow
Correction, to an inadequately edited posting: At 03:50 PM 12/9/2006, I
wrote:


><Input and transformations>
>XSAVE <output file>.
><procedure>.
>GET FILE <output file>
>
>is approximately equivalent to
>
><Input and transformations>
>XSAVE <output file>.
><procedure>.
>GET FILE <output file>.

Since they're identical, they OUGHT to be equivalent. The first example
was supposed to use CACHE, like this:


<Input and transformations>
CACHE.
<procedure>.

is approximately equivalent to

<Input and transformations>
XSAVE <output file>.
<procedure>.
GET FILE <output file>.

It is correct, as I stated, that

>Using XSAVE lets you bypass CACHE restrictions, including that ".. A
>cache file will not be written during a procedure that uses temporary
>variables." (SPSS 14 Command Syntax Reference p. 177).

-Embarrassed,
  Richard