Skip to content

← machine_learning package

QuadraticDiscriminantAnalysis

Classify data instances using Quadratic Discriminant Analysis (QDA).

The QDA method is a relatively simple statistical method that learns a quadratic mapping (i.e., a basic non-linear mapping) from input data to discrete category labels. QDA assumes that the data are Gaussian-distributed, that is, have no or very few major statistical outliers. To the extent that these assumptions are violated, this method will likely underperform. To ameliorate the outlier issue, the raw data can be cleaned of artifacts with various artifact removal methods. This implementation uses shrinkage regularization by default, which allows it to handle large numbers of features quite gracefully, compared to the unregularized variant, which will overfit or fail on more than a few dozen features. This method relies on a regularization parameter that is tuned using an internal cross-validation on the data. If there are very few trials, or some extensive stretches of the data exhibit only one class, this cross-validation can fail with an error that there were too few or no trials of a given class present. By default, this method will return not the most likely class label for each trial it is given, but instead the probabilies for each class (=category of labels), that the trial is actually of that class. Like all machine learning methods, this method needs to be calibrated ("trained") before it can make any predictions on data. For this, the method requires training instances and associated training labels. The typical way to get such labels associated with time-series data is to make sure that a marker stream is included in the data, which is usually imported together with the data using one of the Import nodes, or received over the network alongside with the data, e.g., using the LSL Input node (with a non-empty marker query). These markers are then annotated with target labels using the Assign Targets node. To generate instances of training data for each of the training markers, one usually uses the Segmentation node to extract segments from the continuous time series around each marker. Since this machine learning method is not capable of being trained incrementally on streaming data, the method requires a data packet that contains the entire training data; this training data packet can either be accumulated online and then released in one shot using the Accumulate Calibration Data node, or it can be imported from a separate calibration recording and then spliced into the processing pipeline using the Inject Calibration Data, where it passes through the same nodes as the regular data until it reaches the machine learning node, where it is used for calibration. Once this node is calibrated, the trainable state of this node can be saved to a model file and later loaded for continued use. More Info... Version 1.0.1

Ports/Properties

data

Data to process.

  • verbose name: Data
  • default value: None
  • port type: DataPort
  • value type: Packet (can be None)
  • data direction: INOUT

shrinkage

Regularization strength. Given as a list of numbers between 0 and 1 where 0 is no regularization and 1 is maximal regularization. The best parameter is searched, which can be slow. The details of the parameter search can be controlled via the search metric and number of folds parameters.

  • verbose name: Regularization Strength
  • default value: [0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.8]
  • port type: ListPort
  • value type: list (can be None)

search_metric

Parameter search metric. This method will run a cross-validation for each possible shrinkage parameter value and use this metric to score how well the method performs in each case, in order to select the best parameter. Therefore, the running time of the method is proportional to the number of parameter values times the number of folds in the cross-validation, which can be slow. While 'accuracy' is usually a good default, some other metrics can be useful under special circumstances, e.g., roc_auc for highly imbalanced ratios of trials from different classes.

  • verbose name: Scoring Metric For Parameter Search
  • default value: accuracy
  • port type: EnumPort
  • value type: str (can be None)

num_folds

Number of cross-validation folds for parameter search. Cross-validation proceeds by splitting up the data into this many blocks of trials, and then tests the method on each block. For each fold, the method is re-trained on all the other blocks, excluding the test block. This is not a randomized cross-validation, but a blockwise cross-validation, which is usually the correct choice if the data stem from a time series. If there are few trials in the data, one can use a higher number here (e.g., 10) to ensure that more data is available for training

  • verbose name: Number Of Cross-Validation Folds
  • default value: 5
  • port type: IntPort
  • value type: int (can be None)

cv_group_field

Optionally a field indicating the group from which each trial is sourced. If given, then data will be split such that test sets contain unseen groups. Examples groups are SubjectID, SessionID, etc.

  • verbose name: Grouping Field (Cross-Validation)
  • default value:
  • port type: StringPort
  • value type: str (can be None)

cv_stratified

Optionally perform stratified cross-validation. This means that all the folds have the same relative percentage of trials in each class.

  • verbose name: Stratified Cross-Validation
  • default value: False
  • port type: BoolPort
  • value type: bool (can be None)

probabilistic

Use probabilistic outputs. If enabled, the node will output for each class the probability that a given trial is of that class; otherwise it will output the most likely class label.

  • verbose name: Output Probabilities
  • default value: True
  • port type: BoolPort
  • value type: bool (can be None)

class_weights

Per-class weights. Optionally this is a mapping from class label to weight. The weights represent the a priori ("prior") probability of encountering a specific class that the model shall assume. The weights will be renormalized so that they add up to one. Example syntax: {'0': 0.5, '1': 0.5} (note the quotes before the colons).

  • verbose name: Per-Class Weight
  • default value: None
  • port type: Port
  • value type: object (can be None)

initialize_once

Calibrate the model only once. If set to False, then this node will recalibrate itself whenever a non-streaming data chunk is received that has both training labels and associated training instances.

  • verbose name: Calibrate Only Once
  • default value: True
  • port type: BoolPort
  • value type: bool (can be None)

verbosity

Verbosity level. Higher numbers will produce more extensive diagnostic output.

  • verbose name: Verbosity Level
  • default value: 0
  • port type: IntPort
  • value type: int (can be None)

dont_reset_model

Do not reset the model when the preceding graph is changed. Normally, when certain parameters of preceding nodes are being changed, the model will be reset. If this is enabled, the model will persist, but there is a chance that the model is incompatible when input data format to this node has changed.

  • verbose name: Do Not Reset Model
  • default value: False
  • port type: BoolPort
  • value type: bool (can be None)

set_breakpoint

Set a breakpoint on this node. If this is enabled, your debugger (if one is attached) will trigger a breakpoint.

  • verbose name: Set Breakpoint (Debug Only)
  • default value: False
  • port type: BoolPort
  • value type: bool (can be None)

metadata

User-definable meta-data associated with the node. Usually reserved for technical purposes.

  • verbose name: Metadata
  • default value: {}
  • port type: DictPort
  • value type: dict (can be None)