-
Notifications
You must be signed in to change notification settings - Fork 28.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-18318][ML] ML, Graph 2.1 QA: API: New Scala APIs, docs #16009
Changes from 4 commits
8cfc859
ac72c05
8c36940
f494a47
0b1cced
eae0d2c
019e5af
27b07ef
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -70,17 +70,16 @@ private[feature] trait QuantileDiscretizerBase extends Params | |
* invalid values), error (throw an error), or keep (keep invalid values in a special additional | ||
* bucket). | ||
* Default: "error" | ||
* TODO: Reuse handleInvalid in HasHandleInvalid. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this just a note to add "HasHandleInvalid" as a shared param? I was a bit confused by it at first. Maybe we can reference a jira number for it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, updated. |
||
* @group param | ||
*/ | ||
@Since("2.1.0") | ||
val handleInvalid: Param[String] = new Param[String](this, "handleInvalid", "how to handle" + | ||
"invalid entries. Options are skip (filter out rows with invalid values), " + | ||
"error (throw an error), or keep (keep invalid values in a special additional bucket).", | ||
ParamValidators.inArray(Bucketizer.supportedHandleInvalid)) | ||
ParamValidators.inArray(Bucketizer.supportedHandleInvalids)) | ||
setDefault(handleInvalid, Bucketizer.ERROR_INVALID) | ||
|
||
/** @group getParam */ | ||
@Since("2.1.0") | ||
def getHandleInvalid: String = $(handleInvalid) | ||
|
||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are the
@since
removed, btw?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually we don't add
since
tag to variables and functions in traits, since they may be inherited by new child classes later on and the tag is incorrect for them.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This happens in several other places though, are we going to remove them all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, theoretically we should do that, but I'm not very confidence whether this change is appropriate. If we meet an agreement on how to deal with this issue, we can address other places in this PR or follow-up work. cc @jkbradley
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, I think it's OK to have Since annotations in the trait since it is private and should never be used beyond ChiSqSelector and ChiSqSelectorModel. That seems pretty safe to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's safe for this case. However, I found lots of other traits which is also safe enough to add since tag but did not add. I reverted this part of change in this PR to make it catch another RC of 2.1, and I think we should unify them in a separate work. Thanks.