Github user srowen commented on a diff in the pull request:
https://github.com/apache/spark/pull/14597#discussion_r75366634
--- Diff:
mllib/src/main/scala/org/apache/spark/mllib/feature/ChiSqSelector.scala ---
@@ -189,11 +228,35 @@ class ChiSqSelector @Since("1.3.0") (
*/
@Since("1.3.0")
def fit(data: RDD[LabeledPoint]): ChiSqSelectorModel = {
- val indices = Statistics.chiSqTest(data)
- .zipWithIndex.sortBy { case (res, _) => -res.statistic }
- .take(numTopFeatures)
- .map { case (_, indices) => indices }
- .sorted
+ chiSqTestResult = Statistics.chiSqTest(data)
+ selectorType match {
+ case ChiSqSelectorType.KBest => selectKBest(numTopFeatures)
+ case ChiSqSelectorType.Percentile => selectPercentile(percentile)
+ case ChiSqSelectorType.Fpr => selectFpr(alpha)
+ case _ => throw new Exception("Unknown ChiSqSelector Type")
+ }
+ }
+
+ @Since("2.1.0")
+ def selectKBest(value: Int): ChiSqSelectorModel = {
--- End diff --
The chi squared test result should be the same no matter which type of
selection you do, yes. I agree it's desirable to avoid computing it many times
if one wanted to perform many variations on chi squared selection, but is that
a common use case?
Still, I can also imagine going back to the idea of only finding the
chi-squared values in the selector, and letting the model instance be
parameterized. So its behavior as a transformer would be modified by setting
parameters on it. I'm OK with that, I just thought you were saying this wasn't
consistent with other model classes. Maybe I misunderstood that.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
