Tom's (and Everybody's) Confusion

[From Bruce Abbott (9550123.2030 EST)]

Tom Bourbon [950123.1420]

[From Bill Powers (950121.2045 MST)]

Tom Bourbon, Rick Marken, Bruce Abbott (various) --

It's true that c = h + d under all conditions because that's how the
experiment is programmed. Therefore, d = c - h, exactly and at all
times. No way around that.

Good. I was beginning to wonder! :wink:

The confusion is arising here because of the definition of the
controlled variable.

I didn't think that was the problem. This thread began with the following:

Bruce Abbott (950116.1730 EST):

When the data set contains only cursor and handle
positions, (i.e., lacks the disturbance tables), the disturbance values
can be calculated exactly only if the reference values are known

Tom, here is the problem. Below is the code from Bill's THREECV1 program
that draws the cursor. The variable c is the cursor position, computed as c
= h + d. But note what happens when the cursor value is STORED:

procedure drawcursor(c,n,init: integer);
  . . .
  oldc[n] := c + maxx div 2;
  . . .

The "maxx div 2" is screen center, which also happens to be the position of
the three targets. The call to drawcursor, below, computes c as mousex +
dist^[k, i] (i.e., c = h + d):

drawcursor(mousex + dist^[k,i],k,0);
c^[k,i] := oldc[k];

As shown above, on return from drawcursor, oldc[k] is stored as c^[k,i].
Later, my added procedure saves this value to disk. Had I been more
familiar with Bill's program, I would have saved the original c values and
avoided this whole silly debate. The added constant has caused all the

No matter what relationship the person controls between cursor and target,
c - h = d. By definition, that's the state of affairs in the world.

This function is not a state of affairs in the world, but a convention you
guys use in your programs. It could be any function, even a nonlinear one.
This one just simplifies the analytic task.

The raw position of c on the screen probably is not the controlled variable,
but it might be. It makes no difference; given c and h, we can calculate d.

Not if c has been stored as c + maxx div 2. In that case you need to know
what maxx div 2 was. In this case it was the position of the targets, which
led me to believe that c was intended to be computed as h + d + t. And that
is the value on which Bill's PCTmodel analysis operates, so I needed to
include t in order to get it to work properly.