PXLab Manual

[Home]    [Content]    [Previous Chapter]    [Next Chapter]


Factorial Design

The abstract structure of an experiment is defined by its factors and conditions. An experimental design by PXLab tries to make the abstract structure as clearly visible as possible by explicitly defining the experimental conditions with explicitly defined factors and their operationalizations.

Factor Definitions

Experimental factors are defined in the Factors() section of a design file. It starts with the Factors() statement and contains a block of factor definitions. There are three different types of factors: independent factors, dependent factors and covariate factors. Each of these has its own type of factor statement:

The notions of independent and dependent factors are used here in their usual meaning. A covariate factor is a variable which describes some subject property which is collected at run time but only once and usually before the experiment starts. A typical case is age and sex of the subject. Covariate factors have only a single value per subject and session and are collected by directly asking the subject or the experimenter.

A factor statement has three aspects:

  1. it assigns a name to the factor and creates an experimental parameter of that name if the factor is not an experimental parameter by itself;
  2. it associates a factor with one or more experimental parameters;
  3. for independent and covariate factors it defines all possible factor levels.

Independent Factors and Factor Levels

Assigning a name to a factor and associating the factor with experimental parameters is done by the argument list of a factor statement. The first argument defines the factor's name and the following arguments are the name of experimental parameters which are associated with that factor. These parameters may be considered to be the factor's operationalization. Here is a simple example which also defines the factor levels:

There is one independent factor defined. Its name is "Luminance" and its experimental operationalization is the experimental parameter SimpleDisk.Color which is an experimental parameter which defines the color of a simple disk stimulus display. The block of a factor definitions contains the list of factor levels. Each factor level definition also contains the corresponding values of the experimental parameters which have been associated with the factor. Thus the independent factor "Luminance" of the above example has two levels which are called "8" and "90". The factor level "8" has an associated experimental parameter value [8.0, 0.330, 0.313] which defines the color coordinates of a dim gray light. The factor level "90" has an associated color parameter value of [90.0, 0.330, 0.313] which is a bright white light.

Thus the factor definition argument list contains the factor name and the names of the associated experimental parameters and the factor level definitions contain the corresponding factor level values and their associated parameter values. Internally factors are treated like experimental parameters. If a factor name is not the name of an experimental parameter then the respective parameter is created at runtime.

The number of experimental parameters associated with a factor is not limited. Here is a more complicated example from a Stroop experiment:

There are two experimental parameters necessary to define a factor level here: "Congruency" in a Stroop experiment means that the color word names the color of its letters. For incongruent conditions the color word must not name the color of its letters and in a neutral condition no words are used at all. Thus not a single experimental parameter defines the congruency factor but the combined value of two stimulus aspects constitute the factor level.

There may, however, exist also very simple cases where a factor already exists as a stimulus parameter. In this case the respective experimental parameter can be used as the only argument of the factor definition. The independent variable in a choice reaction time experiment for example might be the orientation of an arrow stimulus. The Display object Arrow which one would use in such an experiment already contains a parameter called 'Orientation'. Thus in this simple case the independent factor definition would be

Dependent and Covariate Factors

A similar syntax which has been explained for independent factor definitions is used for dependent factors and covariate factors. The main difference is that dependent factor definitions can only have a single argument and that it does not make sense to define factor levels for a dependent factor. Furthermore dependent factor names always have to be names of experimental parameters while covariate factor names may either be names of experimental parameters or may be previously undefined names.

Covariate factors have an additional aspect. Usually their values are not determined while the experiment is running. In general the values of covariate factors will be determined outside of the computer controlled experiment. Thus the values of covariate factors are not set from within the experiment like experimental parameters are but these are gathered by a dialog window which pops up before the experiment starts and asks for the values of all covariate factors. Covariate factors which have their factor levels defined in the design file offer the user a choice to select one of these admissible factor levels as a current value for the covariate. Here is an example for the use of covariate factors.

It defines two covariate factors "Sex" and "Age" with a restricted set of factor levels. When this experiment starts the user will see a dialog appear which asks for the covariate factor levels for the given subject. Every factor will have a choice field where the user can select one of the possible factor levels.

Covariate factors like SubjectGroup also may have operationalizing parameters. These may be used to select sessions for groups of subjects. This is described in the 'Experimental Procedure' chapter.

Experimental Conditions

The factor definitions in a design file are used to build an internal condition table. The conditon table is a list of factor level combinations and their associated experimental parameter values. The table contains an entry for every possible combination of factor levels of all independent factors. Every entry also contains the experimental parameter values associated with the respective factor levels. The association between factor levels and experimental parameters may in some cases be rather complicated such that it is not possible to build the condition table simply by combinatorial methods. For these cases the condition table may explicitly be defined in the design file.

Lets look at an example. Suppose we have a Stroop experiment with two factors: The first factor is "Congruency" as in our previous example. The second factor is "Color Associativity" of the distractor word. The highest degree of color associativity have words which themselves are color names, like "red". A medium level of color associativity is represented by words which are not color words but are associated with colors, like "blood" with red, or "grass" with green. We may thus have the following factor definitions:

There is, however, no way to associate experimental display parameters with any of the factors such that a combinatorial method may be used to create all combinations of factors since both of these factors have to be associated with the same experimental parameters and the difference is with respect to the content of the distractor word only. In order to create the experimental conditions we thus have to explicitly define the condition table.

The factor definitions and the condition table together completely define the operationalization of every independent experimental factor and its factor levels. For some experiments there may be a unique association between factors and experimental parameters. In this case automatic condition table creation can be used even if more than one experimental parameters are needed to operationalize a factor. If the condition table needs to be explicitly defined then the operationalization should only be done by condition statements. A condition table can be interpreted meaningfully only if all factors used in the table have factor definition statements. Otherwise it is impossible to decide which parameter names are factor names and which are operationalization parameters since experimental parameters may also be used as factors.

Where is the condition table used? The condition table is used for defining trials. Every trial is a realization of a single experimental condition. When a trial is defined one can simply use the factor levels to define the experimental condition which should be realized in this trial:

      Trial("Congruent", "medium", 2);

is enough to tell the system that the experimental condition

      Condition("Congruent", "medium", 2, Green, "GRASS");

should be presented in that trial. The experimental parameter values need not be specified. These parameters are implicitly localized for a trial as any other experimental parameters of the trial.

The condition table contains all possible experimental conditions. An automatically created condition table will be factorial complete. An explicitly defined condition table need only contain those conditions which are actually needed. In a certain sense the list of trials and the condition table contain the same information. The list of trials, however, implicitly contains more information: It groups conditions into procedural blocks and specifies the sequential properties within every block, and it defines how subjects are assigned to experimental conditions. Thus the list of trials defines whether a factor becomes a between factor or whether repeated measures are used. Every combination of these is possible.

[This file was last updated on July 15, 2010, 12:07:01.]

[Home]    [Content]    [Previous Chapter]    [Next Chapter]