Github user sethah commented on the issue:
https://github.com/apache/spark/pull/11119
@jkbradley Thanks for your thoughts. I agree it's a good idea to change the
KMeans prediction function to not use the entire model in its closure, but that
we need a more thorough solution when we generalize this to predictors.
Would you mind pointing me to an example of an algorithm which only copies
some, but not all, of the estimator params?
> Users can identify the initialization method of the model by looking at
Model.parent.initialModel.
Sure, but will they? How will they know that `kMeansModel.getInitialModel`
is invalid, and that they should instead call
`kMeansModel.parent.getInitialModel`? Also, there is some coupling between
`initMode` and `initialModel`. It's misleading to have:
````scala
val km = new KMeans().setInitialModel(...)
km.getInitMode
> "k-means||"
````
It's especially misleading to have a model that says `initialModel` is
unset (or that it doesn't even have an initialModel param), when it really was,
AND that the init mode is some value as well. Maybe we should automatically set
`initMode` to something like "initialModel" in the `setInitialModel` method.
That would give the following behavior:
````scala
val km = new KMeans().setInitialModel(...)
km.getInitMode
> "initialModel"
val model = km.fit(df)
model.getInitMode
> "initialModel"
````
That solves the problem of users having to know to access the
initialization modes via its parent, and having conflicting `initMode` and
`initialModel`. This makes sense since setting an initial model is really just
another option for `initMode`.
---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
