-
Notifications
You must be signed in to change notification settings - Fork 218
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
Wrap histogram #1072
Wrap histogram #1072
Conversation
I'm not sure how to use the virtualfile to import a table. I'm trying: But I get I'm not sure how to fix this, as it seems like I'm passing the correct input in (but clearly not).Any ideas @GenericMappingTools/python ? |
I would suggest you only focus on the plotting part in this PR, and implement the inquire (-I) feature in a separate PR (after some discussions as in #896). |
Co-authored-by: Dongdong Tian <[email protected]>
… into wrap-histogram
Just on this point (and as I've mentioned to Jiayuan at #1145 (review)), I'd recommend wrapping as few aliases as you can get away with in this PR. We can open up separate PRs to wrap any complicated parameter like To be clear, that means you just have to alias the required arguments (https://docs.generic-mapping-tools.org/dev/histogram.html#required-arguments), and the common aliases (-R, -J, -c, -p, -t, etc) to pass. Maybe add one minimal unit test to hit the code coverage target. I see you've done a few aliases already (and you can leave them in if you want), but don't feel like you have to complete all of them. Example workflow would be to do: Minimal PR (this one) -> Gallery Example PR -> Complete documentation/aliases PR -> Full Tutorial PR P.S. Yes, we should document this 'policy' about wrapping modules chunk by chunk somewhere, but thought I'd mention it to you first. |
I'm on board with with suggested workflow. I think it keeps the pull request more manageable by not including everything under one review, |
Co-authored-by: Wei Ji <[email protected]>
@weiji14 Updated the baseline image with my new GMT 6.2.0rc1 environment (took much longer than I'm proud to admit to find out to use the current working branch of PyGMT in your conda environment; PR coming soon to add that to contributing/install guidelines). |
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.
Alright, glad you managed to update to GMT 6.2.0rc1, I agree that the upgrade process could be a lot less painful (but that's for a separate issue). Anyways, time for the final review call!
Co-authored-by: Wei Ji <[email protected]>
""" | ||
Returns a list of integers to be used in the histogram. | ||
""" | ||
return [1, 1, 1, 1, 1, 1, 2, 2, 2, 3, 4, 5, 6, 7, 8, 8, 8, 8, 8, 8] |
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.
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.
@seisman I just tried it on both GMT 6.1.1 and 6.2.0rc1, with the figure coming out the same way. Any idea what might be causing the miscount for 8?
Also, changing the projection to X3c/10c
to give it a larger vertical scale; does that work?
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.
It looks like an upstream bug.
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'll try and recreate it in GMT and open an upstream issue
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.
GMT automatically determines the x range from input data. In this example, xmin=1, xmax=8, but the vertical bar for x=8 is outside of the [1, 8] range, so it's not plotted.
You should be able to see the x=8 bar, if you manually set region=[0, 9, 0, 6]
. I think we can do it temporarily so that this PR can be merged, and report it to upstream and wait for feedback and potential fix.
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.
Also, changing the projection to
X3c/10c
to give it a larger vertical scale; does that work?
BTW, the large vertical scale makes the image difficult to read, why not just use "X10c/10c" for a square basemap?
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.
@seisman I made your suggested changes
The "Style Checks" fail but is unrelated to changes in this PR:
|
Co-authored-by: Dongdong Tian <[email protected]> Co-authored-by: Wei Ji <[email protected]>
Wrapping the histogram module
Preview at https://pygmt-git-wrap-histogram-gmt.vercel.app/api/generated/pygmt.Figure.histogram.html
Fixes #563
Reminders
make format
andmake check
to make sure the code follows the style guide.doc/api/index.rst
.Slash Commands
You can write slash commands (
/command
) in the first line of a comment to performspecific operations. Supported slash commands are:
/format
: automatically format and lint the code/test-gmt-dev
: run full tests on the latest GMT development version