cd 0 Calibration 200 msec. 10 uvolt verpos.Note that cd must be lower case, and the cd and the 0 must be separated bay a space or a tab. It is permissible to indent entries in the bin descriptor files in order to improve their readability. This can be accomplished by using tabs or spaces in front of the entries. Even the ASCII descriptors can be indented, since any leading blanks or tabs will be ignored. Because the condition descriptions will be carried around in the header to the data, it is useful to make them meaningful. Up to 40 characters will be accepted after stripping off any preceding blanks or tabs. Following a condition code heading (as above) should be specifications for all the bins (averages) desired in that condition code. These are discussed next...
sd 39
high standards
.{3}
The .{3} specifies that event number 3 is averaged into bin 39; presumably
events with event numbers of 3 are high standards but this need not be
the case, since the descriptors are arbitrary. This is about as simple as
a bin specifier can be; any event numbered 3 in the appropriate condition
code is included in this bin (remember that the appropriate condition code
is determined by the position of the bin specifier in the bin descriptor
file). In general, the bin specifier is a sequence of symbols specifying
the conditions which must be satisfied to include an event in that bin.
No blanks, commas (,), or tabs can occur on the line of the bin specifier
proper, and there must be a period (.) somewhere. The period is referred
to as the time-lock point. There must also be what is called an item specifier
to the right of the time-lock point; this is referred to as the home item.
The home item is associated with the log entry currently being processed
and which is under consideration for assignment to the bin. It is always
the item corresponding to the EEG trial (the event which initiated post-sampling)
which will be added to the bin at averaging time; hence the terms home
item and time-lock point. Every bin specifier must have a time-lock point
and a home item; all tests involving time-relations or sequence are relative
to the home item. As can be seen from the simple example above, every item
specifier is composed of a sequence of characters enclosed by curly brackets
(set symbol signs, { and } ). A general bin specifier is a sequence of item
specifiers and the time-lock point thus:
{2}{3}.{3}
for example. Each of {2} , {3} , and {3} are item specifiers. Item specifiers
to the left of the time-lock point denote events which precede the home
item in time. For the bin specifier to be matched or fulfilled, all item
specifiers must be matched in the sequence they are written. In this example,
the home item of 3 will be included in the bin only if it is preceded by
a 2 and a 3 in that order. Likewise, item specifiers following the home
item must also be matched in the order specified for the bin specifier
to be fulfilled. These correspond to events occurring after the home item.
Note again that it is the home item that is being considered for inclusion;
any other item specifications entail only a test of their matching the
specifications, not an assignment to a bin (until they too come under consideration
as a home item). While the order of events must match that in the bin specifier
in order for the home item to be included in the bin, the actual sequence
in which the testing takes place is as follows. First, the home item is
tested. If it matches the log item, item specifiers preceding the home item
are compared sequentially to the log entries until a failure to match occurs
or the end of the bin specifier is encountered. Item specifiers closest
to the home item are processed first. In a similar manner, if the item specifiers
preceding the home item are matched (or there aren’t any), the item specifiers
following the home item are tested, starting with those closest to the
home item. This order of execution can become important in complex bin descriptor
files, as will be discussed later. To summarize these conventions, let’s
consider another example. Suppose in condition code 3 one wishes to average
events numbered 7 which are preceded by a 4 and followed by a 4 or a 5.
Somewhere in the list of bins under the condition code 3 header one might
have a bin specification including this line:
{4}.{7}{4;5}
Note the subtle way a smidgen of syntax was introduced. Item specifiers
can contain a list of events separated with ;’s to denote the inclusive
or of the events. That is, an item specifier containing event numbers separated
by ;’s is matched if any of the events in the list occur at the indicated
point.
event list meaning
{34} Matched by event # 34.
{2;7} Matched by event # 2 or 7.
{~9} Matched by anything but 9.
{*} Matched by any event.
{~*} Never matched.
{4;~5}
or
{~5;4}
since these are the same as {~5}. It might be useful, however, to be able
to express "not event 4 and not event 5", i.e. anything but a four or a five.
This is indeed the actual meaning of {~5;4}. A ~ (tilda) as the first character
of an item specifier negates the entire event list or time-conditioned
event list. That is, the item specifier is matched if the event list is
not matched; conversely, if the event list is matched, the item specifier
is not matched.
{t<200-1200>256}
This particular tcel is true if an event number 256 is found within 200
to 1200 milliseconds of the home item. Time sense is inverted if the tcel
appears before the time lock point. In this case log entries are examined
sequentially starting (in this example) 200 msec before the home item and
ending 1200 msec before the home item. Processing of a tcel stops on the
first match to the event list within the given time window.
{2}.{3}{1024:rt}
{2}.{3}{t<200-1200>1025:rt}
{2}.{3}{1024:rt}{t<200-1000>1025}
In these examples, each time an event is found to match the bin descriptor,
a line is output to the file specified by the -rt option to cdbl(1)
, that
details the event, the response, the reaction time, and the bin number.
Note that a reaction time is output only if the event completely matches
the bin descriptor; in the third example above, if the {t<200-1000>1025} disqualifies
the {1024} response to the {3} event, the reaction time is NOT output.
Also note that the :rt specifier must be declared with each event number
in a semicolon-separated event list in order for reaction times to be output
for every matching event, e.g.:
{2}.{3}{1024:rt;1025:rt}
otherwise, reaction times are only output for those events that match the
event number containing the :rt specifier, e.g.:
{2}.{3}{1024;1025:rt}
flag octal rep. 1 1 2 2 3 4 4 10 5 20 6 40 7 100 8 200A flag test operation is appended to an event using colon glue, thus:
256:f<200> or 256:~f<200>The first event in this example is matched if a 256 with flag 8 set is encountered in the log file; the second is matched if a 256 without flag 8 set is found. It is possible to test more than one flag at a time. In detail, the bits set in the octal number are anded with the flags in the log entry. If the result is nonzero, the flag test is true (unless preceded by the option negation tilda (~), in which case it’s false). In other words, the test f<203> is true if flag 8 or flag 1 or flag 2 (or any combination of these) is set. It is further possible to specify a situation such as "flag 1 set and flag 4 not set" by appending more than one flag test to the event number. This expression implies the "flag 1 and not flag 4" contingency when appended to and event number in an event list:
f<1>:~f<10>
Any number of flag tests can be concatenated in this manner. As usual, evaluation
stops at the first failure with implications for the set and clear flag
operations. One can further append a flag set or clear operation to a flag
test using more colon glue in the following manner:
256:~f<1>:s<1> 93:f<2>:c<2> 256:~f<0>:s<3>The first example indicates that if a 256 is found without flag 1 set, set flag 1. The second means that if a 93 is found with flag 2 set, clear it. The third example indicates how one can circumvent the necessity of having a flag test preceding a set or clear operation. Since ~f<0> is always true, 256:~f<0>:s<3> sets flags 1 and 2 on every event numbered 256, assuming all preceding contingencies were fulfilled. As with flag tests, flag set and clear operations can be strung together using "colon glue". Consider this mess:
256:f<3>:~f<70>:s<300>:c<10>
This particular specification is evaluated and executed as follows:
If the event number is 256 and___ either flag 1 or 2 (or both) is set and___ none of flags 4, 5, and 6 are set, Then set flags 7 and 8 and clear flag 4.Yikes!! An important consideration in the setting, clearing, and testing of flags is the order of operations and the point where the operation takes place. Flag setting or clearing occurs during tests applied to log entries when they match the event and flag conditions preceding them. This occurs whether they are home items or not. Since many operations in cdbl(1) are performed in a sequential self-terminating manner, the order of bin specifiers in a condition code as well as the order of events in an event list are very important.
cd 0
Calibration Pulses
sd 0
cals.
.{1;2;3;4}
cd 1
Attend 300Hz Tones
sd 1
300Hz Standards
.{1}
sd 2
700Hz Standards
.{3}
sd 3
700Hz Targets
.{4}
sd 4
300Hz Target Misses
.{2}{~t<200-800>256:~f<2>}
sd 5
300Hz Target Hits
.{2}{t<200-800>256:~f<2>:s<2>}
sd 6
Response Hits
.{256:f<2>}
sd 7
Response Misses
.{256:~f<2>}
cd 2
Attend 700Hz Tones
sd 8
300Hz Standards
.{1}
sd 9
300Hz Targets
.{2}
sd 10
700Hz Standards
.{3}
sd 11
700Hz Target Misses
.{4}{~t<200-800>256:~f<2>}
sd 12
700Hz Target Hits
.{4}{t<200-800>256:~f<2>:s<2>}
sd 13
Response Hits
.{256:f<2>}
sd 14
Response Misses
.{256:~f<2>}
Note how tabs have been used to indent the different major divisions to
enhance readability. This is perfectly O.K., and highly recommended. Perhaps
the most difficult part of this bin descriptor file to understand is the
usage of the flags. In this case flag 2 has been used to indicate that
a response event has been assigned to a stimulus target so that if two
targets occur very close together in time and are followed by only one
response which falls within the response windows of both targets, only
one target will be counted as a hit, while the other will be regarded as
a miss. It is also important to note the order of the statements which test,
set and clear flags. This is a consequence of the fact that binlist compares
log files events to the bin descriptor file statements in ascending order.
Thus, in the above bin descriptor file it would be an error to place the
bin specifier statement for target hits prior to the bin specifier statment
for target misses. The logic goes something like this. Suppose cdbl(1)
is
scanning condition code one (1)
of the log file and the event number of
the current item it is checking is 2. If the target hit and miss bin specifier
statements were reversed, binlist would first check the hit case. If it
found a response event (256) within 200 to 800 msec post stimulus it would
count the stimulus event as a hit and set flag 2 of the response event.
It would now go on to the next bin specifier statment which in this hypothetical
case is the miss specifier. It now checks to see that there is no response
event within 200 to 800 msec post stimulus which does not have flag 2 set.
Since the response event in the window has just had its flag 2 set in
the previous bin specifier statment, this condition is satisfied and the
stimulus event is now counted as a miss. Thus the same event has been counted
as both a hit and a miss which is a not desirable. The above bin descriptor
file deals only with events which occur after the time lock point. It is,
however, a simple matter to construct averages based on sequential events
by placing the approriate event lists before the time lock point. For example,
in condition code 1 of the above bin descriptor file if we wished to generate
an average of all 300 Hz standards immediately preceeded by two or more
300 Hz stimuli the bin specifier would look something like this:
sd n
Doubly Preceded 300Hz Standards
{1;2}{1;2}.{1}
Combinations of event lists and time conditional event lists are allowed
on either side of the time lock point. Remember that in order to accommodate
causality in the real world, cdbl(1)
evaluates events before the time lock
point before it evaluates events after the time lock point. Very complex
conditional averaging strategies are possible with prudent use of this
program. You must, however, pay very close attention to the order of statments
and the use of flags. It is foolish to attempt to use this program without
checking the binlist file which it produces for compliance with your intentions.