Add memory to the KP domain

[iamaya2]

• [ ] Define way to incorporate historical data within the feature calculation of the instance
• [ ] Create features with one-step memory
• [ ] Test feasibilty of memory-based approach
  • [ ] Determine if more steps are required
  • [ ] Compare against memory-less approach

[iamaya2]

• [ ] Define way to incorporate historical data within the feature calculation of the instance

Constants

• Use a naming convention with high feature IDs for differentiating memory-based features from those without memory. For example, feature 101 would be a memory of feature 1. A second memory step could be associated with ID 201, and so on. This is possible since we have a dictionary for the features.

Alternatives

• Add one 'new' feature to the dictionary, with an additional parameter for a given HH (it already stores historical data with feature values). Requires one extra feature per memory step but the instance structure would remain intact (the only change would be in the getFeatureVector method). Possible to implement since we have a dictionary of feature handles and because the getFeatureVector method already incorporates varargin as input. May be more difficult to implement/debug since it would have to access the HH and its historical data.
• Add a memory property to the instance that stores the previous set of feature values. This makes the instance more complex and would have to be manually updated within the getFeatureVector method, so that it automatically updates previous values. Susceptible to having out-of-sync data since values will be moved to memory each time getFeatureVector is called, which may not happen once per solution step. Requires one extra feature per memory step but it will be straightforward to implement (simply access the corresponding location in the memory property.

[iamaya2]

• Add a memory property to the instance that stores the previous set of feature values. This makes the instance more complex and would have to be manually updated within the getFeatureVector method, so that it automatically updates previous values. Susceptible to having out-of-sync data since values will be moved to memory each time getFeatureVector is called, which may not happen once per solution step. Requires one extra feature per memory step but it will be straightforward to implement (simply access the corresponding location in the memory property.

Selected this one for implementation

[iamaya2]

• Add a memory property to the instance that stores the previous set of feature values. This makes the instance more complex and would have to be manually updated within the getFeatureVector method, so that it automatically updates previous values. Susceptible to having out-of-sync data since values will be moved to memory each time getFeatureVector is called, which may not happen once per solution step. Requires one extra feature per memory step but it will be straightforward to implement (simply access the corresponding location in the memory property.

Selected this one for implementation

Implemented memory storage capability. Pending: Relate it to feature IDs