[
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
