[ https://issues.apache.org/jira/browse/SPARK-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Justin Yip updated SPARK-8298: ------------------------------ Description: CrossValidator only supports k-folds. It cannot prevent the validation data from look-ahead bias. I would like to contribute a sliding-window based CrossValidator. The sliding window guarantees a clear cutoff time between the training and validation data, to prevent look-ahead bias. Three parameters are used to govern the generation process. 1. numFold - Int 2. firstCutoffIndex - Long, the cutoff index of the training data for the first (training, validation) data pair 3. validationWindowSize - Long, index range of the validation data set duration. Need to decide: Whether to make the current CrossValidator more generic or implement a new SlidingWindowCrossValidator. - Most of the logic are identical between CrossValidator and SlidingWindowValidator, except for the part where the training-validation data pairs is generated. More, if we introduce other kinds of data splitting methods, there will be lots of code redundancy if we use multiple classes. - However, I also foresee that things will get messy to support too many splitting methods with one CrossValidator class. was: CrossValidator only supports k-folds. It cannot prevent the validation data from look-ahead bias. I would like to contribute a sliding-window based CrossValidator. The sliding window guarantees a clear cutoff time between the training and validation data, to prevent look-ahead bias. Three parameters are used to govern the generation process. 1. numFold - Int 2. firstCutoffTime - Timestamp, the cutoff time of the training data for the first (training, validation) data pair 3. validationWindowSize - Long, millis of the validation data set duration. Need to decide: Whether to make the current CrossValidator more generic or implement a new SlidingWindowCrossValidator. - Most of the logic are identical between CrossValidator and SlidingWindowValidator, except for the part where the training-validation data pairs is generated. More, if we introduce other kinds of data splitting methods, there will be lots of code redundancy if we use multiple classes. - However, I also foresee that things will get messy to support too many splitting methods with one CrossValidator class. > Sliding Window CrossValidator > ----------------------------- > > Key: SPARK-8298 > URL: https://issues.apache.org/jira/browse/SPARK-8298 > Project: Spark > Issue Type: Improvement > Components: ML > Reporter: Justin Yip > > CrossValidator only supports k-folds. It cannot prevent the validation data > from look-ahead bias. I would like to contribute a sliding-window based > CrossValidator. The sliding window guarantees a clear cutoff time between the > training and validation data, to prevent look-ahead bias. > Three parameters are used to govern the generation process. > 1. numFold - Int > 2. firstCutoffIndex - Long, the cutoff index of the training data for the > first (training, validation) data pair > 3. validationWindowSize - Long, index range of the validation data set > duration. > Need to decide: > Whether to make the current CrossValidator more generic or implement a new > SlidingWindowCrossValidator. > - Most of the logic are identical between CrossValidator and > SlidingWindowValidator, except for the part where the training-validation > data pairs is generated. More, if we introduce other kinds of data splitting > methods, there will be lots of code redundancy if we use multiple classes. > - However, I also foresee that things will get messy to support too many > splitting methods with one CrossValidator class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org