using scratch variables

[Anton Balabanov]

Dear listers,

here is the citation from SPSS Command Syntax Reference about scratch
variables: "SPSS does not reinitialize scratch variables when reading a new
case. Their values are always carried across cases. Therefore, a scratch
variable is a good choice for a looping index".

1. I interpret the first sentence as the scratch var at a given case will
have the same value for the previous and subsequent and all other cases at a
time. There is a support for such interpretation. Say, the syntax

IF $casenum=1 #temp=c.
COMPUTE d=c-#temp.

will write to the variable d the difference between each value of c and it’s
first value. I.e., #temp will not reinitialize while moving from case to
case. Can someone explain why then LAG function works quite well with
scratch variables? Let’s say,

COMPUTE #a=$casenum.
COMPUTE b=LAG(#a).

will write to the variable b lagged case numbers as it would be with
permanent variables. But following the logic expressed in CSR, LAG(#a)
should be equal to #a itself, isn't it? Does it mean that there is some
special treatment for scratch vars in LAG function (say, it works not only
in 'space', but also in 'time', i.e. remembers the past values of #-vars)?
Or, probably, SPSS holds previous values of scratch variable unchanged when
it gets a new value in the transformation course and updates values only for
subsequent cases?

2. Second question sounds simpler. Why the scratch variable is a good choice
for a looping index? Well, apart from the obvious advantage of disappearing
after use.

Would appreciate any ideas.
All the best,
Anton

[Raynald Levesque]

Hi Anton,

********* Re: your Q1:

"SPSS does not reinitialize scratch variables when reading a new case". This
means that if you assign (as you do in your first example) a value to a
scratch variable in case 1, then that value will remain the same for all
subsequent cases UNLESS YOU change it yourself by syntax. This is what you
do in your second example. The scratch variable is set to a new value by the
line COMPUTE #a=$casenum. The line COMPUTE b=LAG(#a) works as you describe
because SPSS uses the value that #a had in the prior case and that value is
(normally) different than that of the current case.

By contract to the above, if you run
IF $casenum=1 temp=c.
COMPUTE d=c-temp.

Then temp will be system missing for all cases but the first one. (It is
SPSS that reinitialize the variable temp to SYSMIS when reading a new case).


********** Re: your Q2:

That's an advantage, an other one is that scratch variables are not written
to disk while going through the file. This can make a difference when using
wide vectors for instances ( eg using VECTOR #vec(1000) instead of VECTOR
vec(1000) ).

Cheers!

Raynald Levesque [hidden email]
Visit my SPSS site: http://www.spsstools.net



-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of
Anton Balabanov
Sent: October 19, 2006 3:55 PM
To: [hidden email]
Subject: using scratch variables

Dear listers,

here is the citation from SPSS Command Syntax Reference about scratch
variables: "SPSS does not reinitialize scratch variables when reading a new
case. Their values are always carried across cases. Therefore, a scratch
variable is a good choice for a looping index".

1. I interpret the first sentence as the scratch var at a given case will
have the same value for the previous and subsequent and all other cases at a
time. There is a support for such interpretation. Say, the syntax

IF $casenum=1 #temp=c.
COMPUTE d=c-#temp.

will write to the variable d the difference between each value of c and it's
first value. I.e., #temp will not reinitialize while moving from case to
case. Can someone explain why then LAG function works quite well with
scratch variables? Let's say,

COMPUTE #a=$casenum.
COMPUTE b=LAG(#a).

will write to the variable b lagged case numbers as it would be with
permanent variables. But following the logic expressed in CSR, LAG(#a)
should be equal to #a itself, isn't it? Does it mean that there is some
special treatment for scratch vars in LAG function (say, it works not only
in 'space', but also in 'time', i.e. remembers the past values of #-vars)?
Or, probably, SPSS holds previous values of scratch variable unchanged when
it gets a new value in the transformation course and updates values only for
subsequent cases?

2. Second question sounds simpler. Why the scratch variable is a good choice
for a looping index? Well, apart from the obvious advantage of disappearing
after use.

Would appreciate any ideas.
All the best,
Anton

[Anton Balabanov]

Thank you very much, Raynald!

Regarding the Q2...
I just seized on the word "Therefore" from the citation: "SPSS does not
reinitialize scratch variables when reading a new
case. Their values are always carried across cases. Therefore, a scratch
variable is a good choice for a looping index".

The use of scratch vars is fast and clear way to do transformations, but, it
seems, they give no special advantage for looping defined immediately by the
absence of reinitialization?

Best,
Anton

> ********** Re: your Q2:
>
> That's an advantage, an other one is that scratch variables are not
written
> to disk while going through the file. This can make a difference when
using

> wide vectors for instances ( eg using VECTOR #vec(1000) instead of VECTOR
> vec(1000) ).
>
> Cheers!
>
> Raynald Levesque [hidden email]
> Visit my SPSS site: http://www.spsstools.net
>
>
>
> -----Original Message-----
> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of
> Anton Balabanov
> Sent: October 19, 2006 3:55 PM
> To: [hidden email]
> Subject: using scratch variables
>
> Dear listers,
>
> here is the citation from SPSS Command Syntax Reference about scratch
> variables: "SPSS does not reinitialize scratch variables when reading a

new
> case. Their values are always carried across cases. Therefore, a scratch
> variable is a good choice for a looping index".
>
> 2. Second question sounds simpler. Why the scratch variable is a good
choice
> for a looping index? Well, apart from the obvious advantage of
disappearing
> after use.
>
> Would appreciate any ideas.
> All the best,
> Anton

[Richard Ristow]

At 03:51 AM 10/21/2006, Anton Balabanov wrote:

>Regarding the Q2...
>I just seized on the word "Therefore" from the citation: "SPSS does
>not reinitialize scratch variables when reading a new case. Their
>values are always carried across cases. Therefore, a scratch variable
>is a good choice for a looping index".
>
>The use of scratch vars is fast and clear way to do transformations,
>but, it
>seems, they give no special advantage for looping defined immediately
>by the
>absence of reinitialization?

A good point. I think this is a stumble in SPSS's documentation. What
happens across cases is irrelevant for a LOOP, which can't operate
across cases.

[Richard Ristow]

At 02:55 PM 10/19/2006, Anton Balabanov wrote:

>Here is the citation from SPSS Command Syntax Reference about scratch
>variables: "SPSS does not reinitialize scratch variables when reading
>a new case. Their values are always carried across cases. Therefore, a
>scratch variable is a good choice for a looping index".

You ask two things:

>1. I interpret the first sentence as the scratch var at a given case
>will have the same value for the previous and subsequent and all other
>cases at a
>time. There is a support for such interpretation. Say, the syntax
>
>IF $casenum=1 #temp=c.
>COMPUTE d=c-#temp.
>
>will write to the variable d the difference between each value of c
>and it's
>first value.

Yes, exactly. So far, so good. I once posted almost exactly this code,
answering a question on SPSSX-L.

>Can someone explain why then LAG function works quite well with
>scratch variables? Let's say,
>
>COMPUTE #a=$casenum.
>COMPUTE b=LAG(#a).
>
>will write to the variable b lagged case numbers as it would be with
>permanent variables. But following the logic expressed in CSR, LAG(#a)
>should be equal to #a itself, isn't it?

I see two questions here:

a.) How does LAG works at all with scratch variables? I hadn't imagined
it it would, until you posted. That must have to do with how they
implemented LAG. From the SPSS 14 Command Syntax Reference p.60,

>LAG(arg,n) The value of the variable n cases before. The first
>argument is a variable. The second argument, if specified, is a
>constant and must be a positive integer; the default is 1.

Technically, that's no meaningful for scratch variables. They aren't in
the file at all, and so have no value "n cases before," or for any
other case. It sounds like the implementation is something like "the
value of the variable just before the Nth preceding re-initialization",
which is meaningful for scratch variables.


b.) "Following the logic expressed in CSR, LAG(#a) should be equal to
#a itself, shouldn't it?"

I don't think so. As you quote from the CSR,
>SPSS does not reinitialize scratch variables when reading a new case.
>Their values are always carried across cases.

As I read it, and as testing shows, that means that at the start of a
case, and until modified, a scratch variable has the value it had at
the end of the preceding case. So, in

.  IF $casenum=1 #temp=c.
.  COMPUTE d=c-#temp.

variable "#temp" has the value that "c" has in the first case, and
retains it throughout the file.

But scratch variables can be changed by transformation commands, as
you've shown yourself. In

.  COMPUTE #a=$casenum.
.  COMPUTE b=LAG(#a).

variable "#a", at the start of the case, has the value it had at the
end of the preceding case. But the COMPUTE statement changes the value,
in this case to the current value of $CASENUM, and that's the value of
#a at the end of this case, and the beginning of the next one. So,
LAG(#a) "writes to the variable b lagged case numbers," as you've seen.

>2. Why the scratch variable is a good choice for a looping index?
>Well, apart from the obvious advantage of disappearing after use.

I've been corresponding with Richard Oliver of SPSS, Inc., about this
point in the documentation. It's a little confusing, because it mixes
two points; they're both true, but quite different.

First, as you say, "disappearing after use" is an important advantage;
a looping index left in the file is useless, and often confusing. (I've
seen SAS programmers make the mistake of not getting rid of their loop
indices.)

Second, in transformation programs, this has nothing to do with scratch
variables' values being carried across cases. In a transformation
program, a LOOP acts entirely within each case.

Third, though, as Richard Oliver pointed out, having values carried
across cases DOES matter in loops in INPUT PROGRAMs. Loops in input
programs can act over multiple cases if they contain END CASE
statements; and that's often useful. In the example below (by Richard
Oliver), the first input program works as desired, and the second does
not. (Side issue: it looks like the loops in the second program
shouldn't work at all. For why they do, see thread "INPUT PROGRAM
paradox", 5/28/2006-6/01/2006.)

input program.
loop #i=1 to 5.
- loop #j=1 to 5.
-   compute x=#i+#j.
-   end case.
- end loop.
end loop.
end file.
end input program.
list.

input program.
loop i=1 to 5.
- loop j=1 to 5.
-   compute x=i+j.
-   end case.
- end loop.
end loop.
end file.
end input program.
list.

[Anton Balabanov]

Thank you for thorough explanation and pointing me out the example with
INPUT PROGRAM, as well as "INPUT PROGRAM paradox" discussion. Indeed,
LOOP within INPUT PROGRAM operates differently with scratch and
permanent variables!

But for the LAG function with scratch variables neither of your
explanations seems satisfactory, IMHO. Well, the question "why does it
work" in this case seems to be more theoretical, but, anyway, as you
wrote in INPUT PROGRAM paradox thread, it is, at least, interesting to
understand how the program thinks. :)

Look...
I saw 2 explanations in your posting:
1. "It sounds like the implementation is something like "the value of
the variable just before the Nth preceding re-initialization", which is
meaningful for scratch variables". That is, LAG operates "in space" with
permanent variable (i.e., in file sort order) and "in time" with scratch
variable (i.e. counts re-initializations). This would mean that the
following syntax

IF $casenum=1 #a=1.
IF RANGE($casenum,5,7) #a=$casenum.
COMPUTE b=LAG(#a,2).

for 10-case file would return

b
0
0
0
0
0
1
5
6
6
6

Zeros are because scratches are initialized to 0, not to SYSMIS. Zeros
up to the 6th case are because only at 6th case we have 2
re-initializations of #a.
Instead, we have

b
.
.
1
1
1
1
5
6
7
7

2. The second explanation "variable "#a", at the start of the case, has
the value it had at the end of the preceding case" is OK for LAG(#a) or
LAG(#a,1) (but, according to the CSR for SPSS13: "Note: In a series of
transformation commands without any intervening EXECUTE commands or
other commands that read the data, lag functions are calculated after
all other transformations, regardless of command order.", that is, #a in
the current case had been already re-initialized when LAG came in
force). Anyhow, it is not an explanation for LAG(#a,2) and higher order
lags.

The answer of Raynald Levesque for this topic "...if you assign ... a
value to a scratch variable in case 1, then that value will remain the
same for all subsequent cases UNLESS YOU change it yourself by syntax"
brought me to another understanding of the process how SPSS works with
scratch variables. The key word in the quotation above is "subsequent".
It seems, SPSS REMEMBERS past values of scratch variables for each case
just like it does with permanent variables, but it keeps the last
initialized value for every subsequent case, unless it will be
initialized via syntax next time. That is, scratch variable exists only
by the first EXECUTE and only in RAM of the computer, but it is not a
scalar, and it is not an array of serial re-initialized values. Instead,
it is a column vector just like the permanent variable, but with
different mode of re-initialization.

This 'hypothesis' explains why LAG works well with scratch variables
with any lag order. What do you think?

> -----Original Message-----
> From: Richard Ristow [mailto:[hidden email]]
> Sent: Tuesday, October 31, 2006 3:59 AM
> To: Anton Balabanov; [hidden email]
> Cc: Oliver, Richard
> Subject: Re: using scratch variables
>
>
> At 02:55 PM 10/19/2006, Anton Balabanov wrote:
>
> >Here is the citation from SPSS Command Syntax Reference about scratch
> >variables: "SPSS does not reinitialize scratch variables
> when reading
> >a new case. Their values are always carried across cases.
> Therefore, a
> >scratch variable is a good choice for a looping index".
>
> You ask two things:
>
> >1. I interpret the first sentence as the scratch var at a given case
> >will have the same value for the previous and subsequent and
> all other
> >cases at a
> >time. There is a support for such interpretation. Say, the syntax
> >
> >IF $casenum=1 #temp=c.
> >COMPUTE d=c-#temp.
> >
> >will write to the variable d the difference between each value of c
> >and it's
> >first value.
>
> Yes, exactly. So far, so good. I once posted almost exactly
> this code,
> answering a question on SPSSX-L.
>
> >Can someone explain why then LAG function works quite well with
> >scratch variables? Let's say,
> >
> >COMPUTE #a=$casenum.
> >COMPUTE b=LAG(#a).
> >
> >will write to the variable b lagged case numbers as it would be with
> >permanent variables. But following the logic expressed in
> CSR, LAG(#a)
> >should be equal to #a itself, isn't it?
>
> I see two questions here:
>
> a.) How does LAG works at all with scratch variables? I
> hadn't imagined
> it it would, until you posted. That must have to do with how they
> implemented LAG. From the SPSS 14 Command Syntax Reference p.60,
>
> >LAG(arg,n) The value of the variable n cases before. The first
> >argument is a variable. The second argument, if specified, is a
> >constant and must be a positive integer; the default is 1.
>
> Technically, that's no meaningful for scratch variables. They
> aren't in
> the file at all, and so have no value "n cases before," or for any
> other case. It sounds like the implementation is something like "the
> value of the variable just before the Nth preceding
> re-initialization",
> which is meaningful for scratch variables.
>
>
> b.) "Following the logic expressed in CSR, LAG(#a) should be equal to
> #a itself, shouldn't it?"
>
> I don't think so. As you quote from the CSR,
> >SPSS does not reinitialize scratch variables when reading a new case.
> >Their values are always carried across cases.
>
> As I read it, and as testing shows, that means that at the start of a
> case, and until modified, a scratch variable has the value it had at
> the end of the preceding case. So, in
>
> .  IF $casenum=1 #temp=c.
> .  COMPUTE d=c-#temp.
>
> variable "#temp" has the value that "c" has in the first case, and
> retains it throughout the file.
>
> But scratch variables can be changed by transformation commands, as
> you've shown yourself. In
>
> .  COMPUTE #a=$casenum.
> .  COMPUTE b=LAG(#a).
>
> variable "#a", at the start of the case, has the value it had at the
> end of the preceding case. But the COMPUTE statement changes
> the value,
> in this case to the current value of $CASENUM, and that's the
> value of
> #a at the end of this case, and the beginning of the next one. So,
> LAG(#a) "writes to the variable b lagged case numbers," as
> you've seen.
>
> >2. Why the scratch variable is a good choice for a looping index?
> >Well, apart from the obvious advantage of disappearing after use.
>
> I've been corresponding with Richard Oliver of SPSS, Inc., about this
> point in the documentation. It's a little confusing, because it mixes
> two points; they're both true, but quite different.
>
> First, as you say, "disappearing after use" is an important
> advantage;
> a looping index left in the file is useless, and often
> confusing. (I've
> seen SAS programmers make the mistake of not getting rid of
> their loop
> indices.)
>
> Second, in transformation programs, this has nothing to do
> with scratch
> variables' values being carried across cases. In a transformation
> program, a LOOP acts entirely within each case.
>
> Third, though, as Richard Oliver pointed out, having values carried
> across cases DOES matter in loops in INPUT PROGRAMs. Loops in input
> programs can act over multiple cases if they contain END CASE
> statements; and that's often useful. In the example below (by Richard
> Oliver), the first input program works as desired, and the
> second does
> not. (Side issue: it looks like the loops in the second program
> shouldn't work at all. For why they do, see thread "INPUT PROGRAM
> paradox", 5/28/2006-6/01/2006.)
>
> input program.
> loop #i=1 to 5.
> - loop #j=1 to 5.
> -   compute x=#i+#j.
> -   end case.
> - end loop.
> end loop.
> end file.
> end input program.
> list.
>
> input program.
> loop i=1 to 5.
> - loop j=1 to 5.
> -   compute x=i+j.
> -   end case.
> - end loop.
> end loop.
> end file.
> end input program.
> list.
>

[Richard Ristow]

At 10:56 AM 10/31/2006, Anton Balabanov wrote, following up concerning
scratch variables and LAG. Text from that posting is quoted where it is
pertinent in the following discussion.

Before I start, thank you, Anton. You've raised deep and interesting
questions in your earlier postings and here. I took several days to
post back because I took several days to work it out - as far as I did.

To readers in general: this is long and technical, though I've made it
as clear as I could manage. There are two sections:

Regarding LAG and scratch variables (Example I):
Regarding LAG, permanent, and scratch variables (Example II):


..............................................
Regarding LAG and scratch variables (Example I):

>I saw 2 explanations [of "LAG" for scratch variables] in your posting.
>But ... neither of your explanations seems satisfactory, IMHO.

See the following discussion. I think they're consistent, and accurate.
In the analysis below, I argue that they're consistent both with SPSS
documentation and with the behavior observed.

I think you fall into trouble when you think of re-initialization of
scratch variables. From both the documentation and observed behavior,
that re-initialization does not happen.

>1. "It sounds like the implementation is something like 'the value of
>the variable just before the Nth preceding [overall]
>re-initialization'".

Example I: The following SPSS draft output; discussion follows. In this
file, variable "b.1" and "b.2" are entered as data, from your posting.

*  ......   Example I:  Post from here on   .............  .
NUMERIC  #A               (F2).
NUMERIC @#A_BFR @#A_AFT B (F2).
COMPUTE @#A_BFR = #A.
*  "the following syntax for 10-case file would return     .
*  [b.1]; instead, we have [b.2]:"                         .
.     IF $casenum=1 #a=1.
.     IF RANGE($casenum,5,7) #a=$casenum.
.     COMPUTE b=LAG(#a,2).
COMPUTE @#A_AFT = #A.
LIST.
|-----------------------------|---------------------------|
|Output Created               |01-NOV-2006 15:03:52       |
|-----------------------------|---------------------------|
LINE_NUM b.1 b.2 @#A_BFR @#A_AFT  B

    01      0   .     0       1    .
    02      0   .     1       1    .
    03      0   1     1       1    1
    04      0   1     1       1    1
    05      0   1     1       5    1
    06      1   1     5       6    1
    07      5   5     6       7    5
    08      6   6     7       7    6
    09      6   7     7       7    7
    10      6   7     7       7    7

Number of cases read:  10    Number of cases listed:  10
*  ......   Example I:  End                 .............  .

In the above, B.1 is what you expected to see, and B.2 is what you saw.
B is what was calculated, and matches B.2.  Variables @#A_BFR and
@#A_AFT record the values of scratch variable #A at the beginning and
end of the transformation program, for that case.

Your reasoning:
>Zeros are [predicted] because scratches are initialized to 0, not to
>SYSMIS.

This doesn't apply for cases 01 and 02. You have
.     COMPUTE b=LAG(#a,2).
For cases 01 and 02, that's the value of #A from cases "-1" and "00",
neither of which exist; so the result is missing. #A is initialized to
0, but only when it comes into existence, i.e. in case 01.

>Zeros up to the 6th case are because only at 6th case we have 2
>re-initializations of #a.

#A is initialized to 0 at case 1; you then compute it as 1. As shown,
#A is 0 at the start of the input program for that case, and 1 at the
end.

But you don't have "2 re-initializations of #a": "SPSS does not
reinitialize scratch variables when reading a new case. Their values
are always carried across cases." (SPSS 14 Command Syntax Reference,
p.33).

In cases 02, 03, and 04 you don't change #A, so it keeps the value it
had had the end of case 01: namely, 1. (See @#A_BFR and @#A_AFT for
those cases.)

>Instead, we have [B.2, which matches variable B in the above listing].

Your code is
.     COMPUTE b=LAG(#a,2).
In the output,B.2, and B, are missing for the first two cases, as
discussed above. In later cases, they have the value of @#A_AFT from
two cases before: "the value of the variable [#A] just before the Nth
preceding [overall] re-initialization."

>2. The second explanation "variable "#a", at the start of the case,
>has the value it had at the end of the preceding case"

I believe that's correct. As you can see, above, @#A_BFR for cases 2
and following, matches @#A_AFT for the immediately preceding case. In
case 1, @#A_BFR is 0, which is the value of #A the ONLY time it is
initialized.

>[This] is OK for LAG(#a) or LAG(#a,1)

It doesn't, that I can see, have anything to do with LAG; notice that
it doesn't mention LAG. As noted above, b=LAG(#a,2) is what my
hypothesis about LAG predicts.

>According to the CSR for SPSS13: "In a series of transformation
>commands without any intervening EXECUTE commands or other commands
>that read the data, lag functions are calculated after all other
>transformations, regardless of command order.", that is, #a in the
>current case had been already re-initialized

That's the mistake.  As previously noted, #a is not re-initialized.

>Raynald Levesque [writes] "...if you assign ... a value to a scratch
>variable in case 1, then that value will remain the same for all
>subsequent cases UNLESS YOU change it yourself by syntax" brought me
>to another understanding of the process how SPSS works with scratch
>variables. The key word in the quotation above is "subsequent". It
>seems, SPSS REMEMBERS past values of scratch variables for each case.

Yes. You'll see that's exactly what is stated above.

>...just like it does with permanent variables,

Not quite; permanent variables are handled differently. Permanent
variables are "remembered" in that they're written to the working file;
scratch variables are "remembered" in that the values they had at the
end of one case's computations, are available at the beginning of the
next case's computation. (Permanent variables for which LEAVE is
specified are "remembered" in both senses.)

>SPSS keeps the last [calculated, not] initialized value for every
>subsequent case, unless it will be [calculated] via syntax next time.
>That is, scratch variable exists only [until] the first EXECUTE [or
>other procedure, or SAVE] and only in RAM of the computer.

I believe that is correct.

>But it is not a scalar, and it is not an array of serial
>re-initialized values. Instead, it is a column vector just like the
>permanent variable, but with different mode of re-initialization.

It's not possible to tell from the documentation or the observed
behavior, but I think scratch variables are probably scalars, i.e. not
written even temporarily as column vectors to the working file.
("Column vector" is not standard SPSS terminology, but it is accurate.)
That's OK for LAG, if it's implemented "in time" (your terminology),
i.e. "counts re-initializations." Which I think is accurate, except
that the re-initialization it the *global* re-initialization, from
which scratch variables, and permanent variables with LEAVE, are
exempt.

>This 'hypothesis' explains why LAG works well with scratch variables
>with any lag order. What do you think?

I think so. But I don't know whether "this 'hypothesis'," as I've
expounded it, should be considered consistent with yours, or not.

..............................................
Regarding LAG, permanent, and scratch variables (Example II):

>That is, LAG operates "in space" with permanent variable (i.e., in
>file sort order) and "in time" with scratch variable (i.e. counts
>re-initializations).

I would expect that both are implemented the same way, because it would
be very awkward to maintain two different implementations of LAG. If I
understand you, and interpret the following test correctly, both
implementations are "in time", as you put it. That is, LAG (VAR,N)
returns the value of variable 'VAR' from just before the Nth previous
global initialization, where a global initialization take place at the
close of the transformation program, just before a new case is begun.

To review: at a global initialization, numeric variables are generally
set to SYSMIS, and string variables to blank. However, this is not done
for scratch variables, or for permanent variables for which LEAVE has
been specified.

The following is SPSS draft output. Variables LINE_NUM and A have their
values at the start of this input program. All other computations are
shown.

*  ......   Example II:  Post from here on   ............  .
NUMERIC  #A     ##A       (F2).
NUMERIC @#A_BFR @#A_AFT   (F2).
NUMERIC B_PERM  B_SCRTCH  (F2).

COMPUTE @#A_BFR = #A.

*  "That is, LAG operates 'in space. with permanent        .
*  variable (i.e., in file sort order) and "in time" with  .
*  scratch variable (i.e. counts re-initializations)."     .
.  COMPUTE B_PERM   = LAG(A,2).
.  COMPUTE B_SCRTCH = LAG(#A,2).
.  COMPUTE #A       = A.

*  Drop cases 5 and 7 (original numbering)                 .
.  SELECT IF NOT ANY(LINE_NUM,5,7).

COMPUTE @#A_AFT = #A.
LIST.
|-----------------------------|---------------------------|
|Output Created               |01-NOV-2006 17:20:56       |
|-----------------------------|---------------------------|
LINE_NUM  A @#A_BFR @#A_AFT B_PERM B_SCRTCH

    01     1     0       1      .       .
    02     3     1       3      .       .
    03     5     3       5      1       1
    04     7     5       7      3       3
    06    11     9      11      5       5
    08    15    13      15      7       7
    09    17    15      17     11      11
    10    19    17      19     15      15

Number of cases read:  8    Number of cases listed:  8
*  ......   Example II:  End                 ............  .

. #A is computed as the value of A. Observe that the value of @#A_AFT
is the same as that of A, but the value of @#A_BFR is not.
. B_PERM is LAG(A,2). B_SCRTCH is LAG(#A,2), i.e. of a scratch
variable.
. Cases 05 and 07 (original numbering) are deleted.

Notice that B_PERM, lagging the permanent variable A, and B_SCRTCH,
lagging the scratch variable #A, are the same; and, in both cases, they
are the value of A (the same as #A), two cases before AFTER the
deletion.

With respect to lagging the scratch variable, this is consistent with
deletion "in time", i.e. saving values as they were before global
re-initialization, only of global re-initialization following a deleted
case, isn't counted. My guess is, that this is the case. In any case,
there's no evidence that logic for lagging A is different from that for
lagging #A.

My guess is that what you call "in time" logic is used for both. But
this test is certainly not definitive, and I can't think of one that
would be.

>Thank you for thorough explanation and pointing me out the example
>with INPUT PROGRAM, as well as "INPUT PROGRAM paradox" discussion.
>Indeed, LOOP within INPUT PROGRAM operates differently with scratch
>and permanent variables!

It does. However (not demonstrated) it operates the same for permanent
variables with LEAVE specified, as it does for scratch variables.

-With very best wishes,
  Richard