[
https://issues.apache.org/jira/browse/SPARK-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph K. Bradley updated SPARK-7146:
-------------------------------------
Description:
Discussion: Should the Param traits in sharedParams.scala be public?
Pros:
* Sharing the Param traits helps to encourage standardized Param names and
documentation.
Cons:
* Users have to be careful since parameters can have different meanings for
different algorithms.
* If the shared Params are public, then implementations could test for the
traits. It is unclear if we want users to rely on these traits, which are
somewhat experimental.
Currently, the shared params are private.
Proposal: Either
(a) make the shared params private to encourage users to write specialized
documentation and value checks for parameters, or
(b) design a better way to encourage overriding documentation and parameter
value checks
was:
Discussion: Should the Param traits in sharedParams.scala be private?
Pros:
* Users have to be careful since parameters can have different meanings for
different algorithms.
Cons:
* Sharing the Param traits helps to encourage standardized Param names and
documentation.
* If the shared Params are public, then implementations could test for the
traits. We probably do not want users to do that.
Currently, the shared params are public but marked as DeveloperApi.
Proposal: Either
(a) make the shared params private to encourage users to write specialized
documentation and value checks for parameters, or
(b) design a better way to encourage overriding documentation and parameter
value checks
> Should ML sharedParams be a public API?
> ---------------------------------------
>
> Key: SPARK-7146
> URL: https://issues.apache.org/jira/browse/SPARK-7146
> Project: Spark
> Issue Type: Brainstorming
> Components: ML
> Reporter: Joseph K. Bradley
>
> Discussion: Should the Param traits in sharedParams.scala be public?
> Pros:
> * Sharing the Param traits helps to encourage standardized Param names and
> documentation.
> Cons:
> * Users have to be careful since parameters can have different meanings for
> different algorithms.
> * If the shared Params are public, then implementations could test for the
> traits. It is unclear if we want users to rely on these traits, which are
> somewhat experimental.
> Currently, the shared params are private.
> Proposal: Either
> (a) make the shared params private to encourage users to write specialized
> documentation and value checks for parameters, or
> (b) design a better way to encourage overriding documentation and parameter
> value checks
--
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
