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

Update FAQ with the actual, latest FAQs #2928

Merged
merged 3 commits into from Aug 15, 2018

Conversation

Projects
None yet
4 participants
@ahuang11
Copy link
Collaborator

ahuang11 commented Aug 5, 2018

Addresses #2906

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Aug 6, 2018

Thanks very much for this! If this is ready, I'll review and merge at which point we should do a doc build to make it live.

@ahuang11

This comment has been minimized.

Copy link
Collaborator Author

ahuang11 commented Aug 6, 2018

@jbednar
Copy link
Contributor

jbednar left a comment

Looks good, thanks!!

doc/FAQ.rst Outdated
renderer = hv.renderer(backend)
renderer.save(obj, 'name_of_file')
Just note that if have used Jupyter magic (%%opts) to customize your plot

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

if you have used

doc/FAQ.rst Outdated
renderer.save(obj, 'name_of_file')
Just note that if have used Jupyter magic (%%opts) to customize your plot
and you try to export it, the customizations will not be retained in the export.

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

I see; this must have been what you were referring to in the other PR. Here, it's not that customizations are not retained in the export, but that they are only applied to the object returned as the output of that cell. So in the example below, I think it should work if you put hv.renderer in the following cell, and end the preceding cell with curve; that way curve will be the output of that cell, and the IPython cell magics will apply to it.

backend = 'matplotlib'
hv_obj = hv.Curve(df, 'x_col', 'y_col')
hv_obj = hv_obj.options(final_hooks=[relabel])

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

Isn't there a third alternative that's more useful than the second one, i.e. to add the option to the style_opts for the corresponding plotting class? Seems like that alternative would be cleaner and also has more of a future, because then we could say "If this option seems likely to be important for other users, please open a PR to add that option to the style_opts list for the given Element's plotting class".

This comment has been minimized.

@ahuang11

ahuang11 Aug 7, 2018

Author Collaborator

I suppose the example here should not be a style option, but rather something more complicated like twin axis. (Also I'm unaware of the style_opts)

# for bokeh:
hv_obj = hv_obj.options(width=1000, height=500)

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

Maybe there's another FAQ missing here, i.e. "Q: Why are the sizing options so different between the Matplotlib and Bokeh backends?", with "A: The way plot sizes are computed is handled in radically different ways by these backends, with Matplotlib building plots 'inside out (from plot components with their own sizes)' and Bokeh building them 'outside in' (fitting plot components into a given overall size)" . @philippjfr could probably phrase that more accurately.

This comment has been minimized.

@ahuang11

ahuang11 Aug 7, 2018

Author Collaborator

I personally never thought of it like that; I just assumed different keyword arguments with each backend, but I did always wonder why HoloViews kwarg for matplotlib's backend is fig_size instead of matplotlib's figsize, and also why in matplotlib you could pass a tuple like plt.figure(figsize=(8, 6)) but here, it's like just a percentage of the original size?

doc/FAQ.rst Outdated
.. code:: python
x = [1, 2, 3]
y = [4, 5, 6]
curve = hv.Curve((x, y))

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

I don't think "extra level of parentheses" conveys much here. Maybe "A: HoloViews typically uses Pandas and XArray dataframes in its examples, but it can accept standard Python data structures as well. Whatever data type is used, it needs to be provided to the first argument of the Element as a single object, so if you are using a pair of lists, be sure to pass them as a tuple, not as two separate arguments:"

doc/FAQ.rst Outdated
**Q: How do I provide axes labels?**

**A:** Pass a tuple containing the column name and label.

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

"A: One convenient way is to pass a tuple"... (it's not the way, just one way).

doc/FAQ.rst Outdated
to .redim.label()
.. code:: python
curve = hv.Curve(df, 'x_col', 'y_col')
curve = curve.redim.label(x_col='X Label', **{'y_col': 'Label for Y'})

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

Is it important that it's an unpacked dictionary here? Wouldn't y_col='Label for Y' work?

This comment has been minimized.

@ahuang11

ahuang11 Aug 7, 2018

Author Collaborator

I'm just trying to demonstrate two separate methods. (I suppose I can note that).

doc/FAQ.rst Outdated
If your column names have spaces, you may predefine a dictionary
and unpack it in obj.redim.range(). This same method is applicable to
adjust the range of a color bar.

This comment has been minimized.

@jbednar

jbednar Aug 7, 2018

Contributor

Maybe "Q: How do I provide keyword arguments for items with spaces" should be a separate question (perhaps with this example), as this is a very general Python technique not specific to redim.range.

ahuang11 added some commits Aug 8, 2018

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Aug 14, 2018

@ahuang11 Given that you've been doing some great work in this PR (and others!) we have decided to add you as a collaborator so that you have write access. :-)

This means you can now make PRs off branches directly on this repo without having to use forks. We only request that you don't commit to master and continue making PRs the way you have been doing already!

@jbednar

This comment has been minimized.

Copy link
Contributor

jbednar commented Aug 14, 2018

continue making PRs the way you have been doing already!

Except that please make them as branches on the official repo, not on a separate fork, because that way we can more easily edit your PR to fix small problems before merging.

@ahuang11

This comment has been minimized.

Copy link
Collaborator Author

ahuang11 commented Aug 15, 2018

Great. Is there anything else I should revise for this PR?

@philippjfr

This comment has been minimized.

Copy link
Contributor

philippjfr commented Aug 15, 2018

Thanks again @ahuang11. I'll go ahead and merge, this is already a massive improvement, but we can continue thinking about other things to add/improve in the corresponding issue.

@philippjfr philippjfr merged commit 9a1d0f0 into pyviz:master Aug 15, 2018

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 83.076%
Details
s3-reference-data-cache Tests passing no test data changes required.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.