Skip to content

Conversation

@sujithjay
Copy link

…k ml vectors to mllib vectors

What changes were proposed in this pull request?

Currently, ml.StandardScaler converts Spark ml vectors to mllib vectors during transform operation. This PR makes changes to skip this step.

How was this patch tested?

Existing tests in StandardScalerSuite

@holdensmagicalunicorn
Copy link

@sujithjay, thanks! I am a bot who has found some folks who might be able to help with the review:@mengxr, @jkbradley and @MLnick

@sujithjay
Copy link
Author

@holdenk Could you also please take a look at this PR?

Copy link
Contributor

@hhbyyh hhbyyh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it's a good thing that we move the implementation from MLlib to ML. Yet I do see one concern about test coverage. Most of the unit tests are still in MLlib and ML does not provide equivalent converge, which makes it difficult to verify code changes.

One solution is to move all the unit tests to ML too, though this will double the unit test time.

* for the column with zero std.
*/
@Since("2.3.0")
def transform(vector: Vector): Vector = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private[spark]?

Change access modifier of `transform` method from public to
private[spark]. Also, remove `@Since` annotation from the method.
@sujithjay
Copy link
Author

@hhbyyh I, personally, like the idea of moving the unit tests to ML. However, are you suggesting I move some of them as part of this PR? Or were you suggesting that it is a task we need to take up separately?

@hhbyyh
Copy link
Contributor

hhbyyh commented Aug 3, 2018

I think it's better to move the code and unit test in one PR. But since it's not a trivial change, I suggest you to wait for committers' opinion.

@sujithjay
Copy link
Author

Hi @mengxr, @jkbradley, @MLnick and @holdenk , could you please review this PR ? Thank you.

@sujithjay
Copy link
Author

Hi @mengxr, @jkbradley, @MLnick, @holdenk, @viirya , could you please review this PR ?

@holdenk
Copy link
Contributor

holdenk commented Sep 7, 2018

Sorry I've been slow to respond, I'll take a look today.

Copy link
Contributor

@holdenk holdenk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working to get us off of MLlib :) I'm +1 on the need to move the tests over, it will temporarily increase our total test time but that's better than not having coverage. If you wouldn't mind a quick micro-benchmark showing that it's not a performance regression over the old code-path would be great as well.

* `lazy val` so it will be evaluated in that branch. Note that we don't
* want to create this array multiple times in `transform` function.
*/
private lazy val shift: Array[Double] = mean.toArray
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this interplay with serialization? Would it make sense to evaluate this before we serialize the UDF so it isn't done on each worker or?

}
}
Vectors.dense(values)
} else if ($(withStd)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe leave a comment withStd and not mean since when tracing the code by hand the nested if/else if can get a bit confusing flow wise.

@mgaido91
Copy link
Contributor

@sujithjay are you still active on this PR? Or shall someone take this over?

Copy link
Member

@srowen srowen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zhengruifeng are you working on something similar or would you care to review?

@zhengruifeng
Copy link
Contributor

@srowen After the crrently merged pr Make the transform natively in ml framework to avoid extra conversion, StandardScaler can now skip the conversion .ml.vector => .mllib.vector

And in RobustScaler, I am to make the transformation more common, so that RobustScaler can reuse the function.

@srowen srowen closed this Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants