-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-16961][CORE] Fixed off-by-one error that biased randomizeInPlace #14551
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
Closed
Closed
Changes from 1 commit
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
4218c5e
Fixed off-by-one error that biased randomizeInPlace against keeping e…
nicklavers e33741c
style changes
nicklavers 4bb0afe
changed seeds to pass tests
nicklavers 42e750f
changed expected output for show() method
nicklavers 4382f8e
Merge remote-tracking branch 'origin/master' into SPARK-16961-randomi…
nicklavers 4848f42
merged in master and changed Rspark mllib test expectations
nicklavers 76efd0b
finer adjustment of SparkR mllib test expectaion
nicklavers 17d28a5
added tolerance to lambda test
nicklavers File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
style changes
- Loading branch information
commit e33741cf15e47c64a7cb83383e83db88531e2539
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I think this ends up being a little hard to grok. Just do two nested loops
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.
I'm not sure if it's just me but I find this even harder to understand.
?
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.
@srowen IMHO, @nicklavers's original
forcomprehension follows a common and well-known Scala idiom. In my mind, it's simpler and easier to understand than a nested loop.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.
OK, I'm not against it, esp. if nobody else speaks up otherwise.
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.
Hm, but perhaps your original version was easier to read than this chained form of nested loops though, on second thought here.
I've actually never seen this type of expression even in Scala. I'm not sure I'd call this well-known. I'm having trouble getting into the nested assignment mixed in with loop indices... aren't you technically generating a tuple at each iteration of each loop this way? when the 'product' of each loop is just 0-1 values, conceptually. I desugared it to see and that seems true. And everything but the body is in braces.
Digression: the version I suggested is certainly more like Java/C++/C#, and it's great that it's possible in Scala too. That has some limited value to readers. Lots of stuff is possible in Scala and some is obviously more compact, and therefore readable and less error-prone, and should be used. I think this is just difference from a standard expression for its own sake, to use syntax because it's merely possible in Scala. Lots of things can be written in a complicated way in Scala.
It's also not consistent with how the Spark code base is written.
I know it's a minor digression but sometimes worthwhile. I'd favor some kind of "compromise" solution like your original version, which felt a little more like the rest of the code base. I'd prefer a conventional loop construct like the rest of the code, but don't feel strongly about that.