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

TST, DOC: Added Broadcasting Tests in test_random.py #7082

Merged
merged 2 commits into from
Jan 24, 2016
Merged

TST, DOC: Added Broadcasting Tests in test_random.py #7082

merged 2 commits into from
Jan 24, 2016

Conversation

gfyoung
Copy link
Contributor

@gfyoung gfyoung commented Jan 21, 2016

Follow-up from #6997 in which I found that there was almost no testing for the broadcasting behavior of methods defined to broadcast in mtrand.pyx. Clarified documentation for these broadcastable functions with regards to output size depending on whether size is None and whether the inputs are all scalars.

@@ -3426,7 +3426,8 @@ cdef class RandomState:
Returns
-------
samples : ndarray or scalar
where the values are all integers in [0, n].
Samples from logistic distribution, shaped according to
`size`. Otherwise, a single value is returned.
Copy link
Member

Choose a reason for hiding this comment

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

is the "Otherwise..." really needed? I feel that given the explanation on the size parameter, this is more confusing than helpful. Also, size=None does not necessarily mean a single return if the other parameters are arrays, right? Again, I'd make that change in size, not here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, that is true. I think the documentation needs to be more standardized IMO, so I'll go through the doc strings for these broadcasting functions to make sure that that they properly explain how the size of the output varies depending on size and the size of the inputs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jaimefrio : Docs all updated.

@gfyoung
Copy link
Contributor Author

gfyoung commented Jan 22, 2016

Travis + Appveyor are happy, and the broadcasting + documentation (I think) have been hammered out pretty thoroughly now. Ready to merge.

Added a whole new suite of tests to ensure that
functions in mtrand.pyx which are broadcastable
actually broadcast their arguments properly.
single value is returned.
``m * n * k`` samples are drawn. If size is ``None`` (default),
a single value is returned if ``scale`` is a scalar. Otherwise,
``len(scale)`` samples are drawn.
Copy link
Member

Choose a reason for hiding this comment

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

This is not exactly correct: if scale is a 2D array, len(scale) is its number of rows, and this function returns scale.size items. If we wanted to write it in code, np.array(scale).size is probably the most accurate representation, but it may be better to come up with a description in prose, not sure...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. I prefer np.array(scale).size because it's more concise and should get the point across clear enough given the intended audience. I had tried to describe these size-related values in more prose when working on this PR, but I couldn't come up with anything clear enough.

Clarified the output size depending on whether
scalar or non-scalar inputs are passed to
functions in mtrand.pyx that can broadcast
their arguments.
jaimefrio added a commit that referenced this pull request Jan 24, 2016
TST, DOC: Added Broadcasting Tests in test_random.py
@jaimefrio jaimefrio merged commit 9849922 into numpy:master Jan 24, 2016
@jaimefrio
Copy link
Member

Thanks for your patience with my finding incremental nitpicks, in it goes!

@gfyoung
Copy link
Contributor Author

gfyoung commented Jan 24, 2016

No problem. It's easier to fix a PR before it's merged than after. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants