Sdtest3 analysis considerations

CSGnet Archive CSG1995
1

[From Samuel Saunders (950314:1415 EST)]

[Bill Powers (950313.0915 MST)]

The data on Luis is interesting, but it would be more so without some of
the side-issues like color blindness! Why not go into the program and
change the cursor colors to two colors he can easily distinguish?

I may have been unclear earlier. I had been worried about how well he
could distinguish the colors, so I asked him after his 10 runs. He said
he could distinguish them "ok". He said "remember it is green and brown I
can't tell apart, not green and red". On some of the early runs, when he
called out the color at each change, he was accurate in his naming. I
assume he could distinguish the colors, although I can't say if there was
something about his color vision which made him slower to do so. Without a
lot of testing, I am not sure how to select other colors which would be
"better" under these circumstances. It will be interesting to see what
happens with more practice on his part.

The low k-factors and the high RMS error suggest that Luis isn't
tracking very accurately. It might help if the score incremented about 5
times as fast on the average, and at a rate inversely proportional to
the error instead of just count/don't-count. If Luis gets the idea that
you get more credit for tracking closely, he might not allow so many big
errors.

I think a higher rate for points might help. I suspect he may have been
experimenting to see just what was producing the points, and the low rate
made it more difficult to determine. These may be more acquisition
effects.

When he tried the DEMO 1 and 2 tasks last fall, his basic tracking was
similar to mine, so I suspect that something about this task is either
keeping his tracking less accurate, or causing it to improve more slowly.
More testing should tell.

It would be nice to disguise this experiment as some sort of game for
kids. Tracking for tracking's sake isn't very interesting except to
wierd PCT experimenters. Got any ideas?

This task seems to be more attractive than the tracking tasks in the DEMOs,
and I think it is from being more game-like. Luis said he wished the runs
were longer and that he could get more points ("at least 100 points"). It
might help to have a screen with a list of the points from the current run
and the last 2 or three, or a 'high point list', or some such after each
run to give a more game-like impression.

ยทยทยท

_________________________________________________________________

I had thought off and on for that last several months about getting a
joy stick or such as an improvement on the mouse for tracking. It would
probably be a good idea to agree on a standard device.

I definitely have some mouse acceleration in SDtest3 in a DOS box under
OS/2. How about the rest of you?

I just noticed that the spell checker offers 'cutest' as an alternative for
SDtest3.

//----------------------------------------------------------------------------
//Samuel Spence Saunders,Ph.D.

2

[From Bruce Abbott (950315.1030 EST)]

Samuel Saunders (950314:1415 EST) --

[Bill Powers (950313.0915 MST)]

The low k-factors and the high RMS error suggest that Luis isn't
tracking very accurately. It might help if the score incremented about 5
times as fast on the average, and at a rate inversely proportional to
the error instead of just count/don't-count. If Luis gets the idea that
you get more credit for tracking closely, he might not allow so many big
errors.

I think a higher rate for points might help. I suspect he may have been
experimenting to see just what was producing the points, and the low rate
made it more difficult to determine. These may be more acquisition
effects.

There would be no difficulty increasing the point rate, and I like Bill's
idea of making the point rate inversely proportional to error. However, I
set up SDTEST3 the way I did in order to approximate fairly closely the task
faced by pigeons in a two-key discriminated operant problem. The two target
positions are equivalent to the two keys; keeping the cursor within some
fixed distance of the targets is analogous to pecking the keys, and the
point increments are loosely analogous to grain reinforcement on a variable
interval schedule. The reason point increments occur at random times and at
a fairly low rate was to make it fairly difficult to discriminate the switch
of active target based solely on the change in reinforcement rate. Making
the point rate too high while tracking on the active target would
reintroduce that problem.

This task seems to be more attractive than the tracking tasks in the DEMOs,
and I think it is from being more game-like. Luis said he wished the runs
were longer and that he could get more points ("at least 100 points"). It
might help to have a screen with a list of the points from the current run
and the last 2 or three, or a 'high point list', or some such after each
run to give a more game-like impression.

We could increment the points by 2 or 5 instead of 1. (Like basketball,
football, etc.). I like the idea of displaying the points earned on the
last several runs and keeping a high point list, as are employed in many
video games. This would require only a small addition to the program to
read and update a file.

I had thought off and on for that last several months about getting a
joy stick or such as an improvement on the mouse for tracking. It would
probably be a good idea to agree on a standard device.

As I mentioned in another post, there are quite a few commercial models
available now, designed for the video game market. Some have "pistol grip"
handles; I've even seen one designed as a steering wheel.

Awhile back I did some playing around with the joystick ports on an IBM
PCjr, which I believe to be identical (except for the connector) to the
standard IBM PC ports. Each joystick provides two 100K potentiometers that
provide variable resistances to an R/C network. The capacitor is fixed, so
the discharge rate of the capacitor is inversely proportional to the
resistance. To take a reading, the computer fires off two one-shots, one
for each joystick axis, whose durations are set by the above-mentioned R/C
networks. It then counts the clock cycles to time the duration of the
one-shots' pulses. These times are then represented as 8-bit numbers in the
joystick port registers. Theoretically this could provide a resolution of
256 values for a full excursion of the joystick along a given axis, or 0.39
percent of excursion. However, as I recall, the PCjr's joysticks actually
delivered a range of around 3 to just over 100, or about 1 percent. I found
that I could get higher values from the port by using a higher resistance
pot, all the way up to 255. I don't recall the nature of the function
(whether linear or not).

One "defect" of the joystick port is that the time required to return a
value is proportional to the input resistance. This can create a problem if
your program uses counter variables to time events in a loop, because loop
execution time becomes variable. In our case we have been syncronizing the
loop with the video retrace signal; as long as the program loop remains less
than the 1/60th second retrace interval, variable joystick read times should
not be a problem.

I definitely have some mouse acceleration in SDtest3 in a DOS box under
OS/2. How about the rest of you?

I'm running Windows 3.2, which includes a program to adjust mouse
parameters. I tried running SDTEST3 in a DOS box with mouse acceleration
set to maximum and with mouse acceleration turned off; it didn't seem to
make any difference.

Samuel Saunders (950310.1145 EST)

I should warn the list participants that "stimulus control" is central to
most of my backgound and work, so I am likely to slip into EAB speak from
time to time and would appreciate reminders when I do.

That's O.K. with me--I speak fluent Skinnerian. I'm glad to hear you have a
strong background in stimulus control; you are probably more familiar with
some of the procedures and findings than I am. It will be helpful to have
your personal experience to draw on.

Regards,

Bruce