Skip to content
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-17173][SPARKR] R MLlib refactor, cleanup, reformat, fix deprecation in test #14735

Closed
wants to merge 6 commits into from

Conversation

felixcheung
Copy link
Member

What changes were proposed in this pull request?

refactor, cleanup, reformat, fix deprecation in test

How was this patch tested?

unit tests, manual tests

@felixcheung
Copy link
Member Author

@SparkQA
Copy link

SparkQA commented Aug 20, 2016

Test build #64150 has finished for PR 14735 at commit d73a2c0.

  • This patch fails SparkR unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Aug 20, 2016

Test build #64151 has finished for PR 14735 at commit 3ea30bb.

  • This patch fails SparkR unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Aug 20, 2016

Test build #64154 has finished for PR 14735 at commit 1ef18d6.

  • This patch fails SparkR unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@shivaram
Copy link
Contributor

This seems a big enough change that it might be good to have a JIRA for this ?

@felixcheung felixcheung changed the title [MINOR][SPARKR] R MLlib refactor, cleanup, reformat, fix deprecation in test [SPARK-17173][SPARKR] R MLlib refactor, cleanup, reformat, fix deprecation in test Aug 20, 2016
@felixcheung
Copy link
Member Author

felixcheung commented Aug 20, 2016

This also tighten the signature for mllib by removing the previously unused ...:

# new in 2.0.0
"summary", signature(object = "GeneralizedLinearRegressionModel")
print.summary.GeneralizedLinearRegressionModel
"summary", signature(object = "NaiveBayesModel")
"fitted", signature(object = "KMeansModel")
"summary", signature(object = "KMeansModel")

# new in 2.1.0 only
"summary", signature(object = "IsotonicRegressionModel")
"spark.naiveBayes", signature(data = "SparkDataFrame", formula = "formula"
"summary", signature(object = "GaussianMixtureModel")

spark.survreg was updated in SPARK-16508

@SparkQA
Copy link

SparkQA commented Aug 20, 2016

Test build #64157 has finished for PR 14735 at commit 30815e0.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

* checking S3 generic/method consistency ... WARNING
print:
  function(x, ...)
print.summary.GeneralizedLinearRegressionModel:
  function(x)

print:
  function(x, ...)
print.summary.GeneralizedLinearRegressionModel:
  function(x)
@SparkQA
Copy link

SparkQA commented Aug 21, 2016

Test build #64161 has finished for PR 14735 at commit b42e10c.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@mengxr
Copy link
Contributor

mengxr commented Aug 21, 2016

@junyangq Could you help review this PR?

return(list(coefficients = coefficients, size = size,
cluster = cluster, is.loaded = is.loaded))
list(coefficients = coefficients, size = size,
cluster = cluster, is.loaded = is.loaded)
Copy link
Contributor

Choose a reason for hiding this comment

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

align list arguments?

@SparkQA
Copy link

SparkQA commented Aug 22, 2016

Test build #64198 has finished for PR 14735 at commit d727093.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@felixcheung
Copy link
Member Author

any more thought? I'd like to merge to facilitate more R mllib work.

@junyangq
Copy link
Contributor

LGTM

@shivaram
Copy link
Contributor

@felixcheung I didn't look at the code very closely, but will this change be required in branch-2.0 as well ? If so the merge might be hard to

@felixcheung
Copy link
Member Author

I don't think they should be required for branch 2.0 - some part of the signature change with ... is likely good to have for consistency but those might also be "breaking" for a *.0.1 release

If we think we should - since we did make some changes like that in 2.0.0 branch - I could open a PR for the branch separately.

@shivaram
Copy link
Contributor

Leaving it out of branch-2.0 sounds good to me.

@asfgit asfgit closed this in 0583ecd Aug 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants