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

Turn off latex rendering in jupyter notebooks #654

Closed
nbren12 opened this issue Jul 19, 2018 · 6 comments · Fixed by #1133
Closed

Turn off latex rendering in jupyter notebooks #654

nbren12 opened this issue Jul 19, 2018 · 6 comments · Fixed by #1133

Comments

@nbren12
Copy link

nbren12 commented Jul 19, 2018

I have been wrapping some pretty large numpy arrays with pint lately. Unfortunately, viewing these arrays with mathjax rendering ends up crashing my web browser. I searched the docs for a way to turn off the default rendering, but I could not find anything. Is there an easy way to do this?

@hgrecco
Copy link
Owner

hgrecco commented Jul 19, 2018

No but we should add it. Please propose an API so we can discuss it an implement it.

@nbren12
Copy link
Author

nbren12 commented Jul 19, 2018

I am not sure what would fit best with pint at the moment. Maybe something like pint.set_jupyter_output_style('string')?

@hgrecco
Copy link
Owner

hgrecco commented Jul 19, 2018

Right now all jupyter formatting (HTML/Latex/pretty) is done here

Maybe we can start adding simply a boolean flag there to disconnect all of them? If needed we can the make it fine grained.

@nbren12
Copy link
Author

nbren12 commented Jul 20, 2018 via email

@jondoesntgit
Copy link
Contributor

I know that matplotlib has an rc params setting. Perhaps we can implement something like that. Pint could also read from a config file on load...

@hgrecco
Copy link
Owner

hgrecco commented Dec 3, 2019

Moving the discussion to #765

@hgrecco hgrecco closed this as completed Dec 3, 2019
bors bot added a commit that referenced this issue Aug 17, 2020
1133: Change HTML repr away from LaTeX to a Sparse/Dask-like repr r=hgrecco a=jthielen

While I've never been a big fan of Pint's LaTeX repr in JupyterLab/Jupyter Notebook due to working with large arrays that would crash the renderer, I've recently been working a lot with various wrapping combinations of xarray, Pint, Dask, and Sparse, in which Pint's LaTeX repr performs particularly poorly. Even if Pint's repr were elided (#765), it would still poorly nest with the other HTML reprs.

This motivated me to implement an alternative HTML repr for Pint using a simple HTML table similar to what both Dask and Sparse use. As shown in [this demonstration notebook](https://nbviewer.jupyter.org/urls/dl.dropbox.com/s/jlgqm6s92kzvagi/pint_html_repr_demo.ipynb), this allows much better nesting of HTML reprs. A quick example image is below:

![](https://www.meteor.iastate.edu/~jthielen/Screenshot%20from%202020-07-14%2017-07-51.png)

This doesn't quite take care of [xarray's unit repr discussions](pydata/xarray#2773) (since this only shows up when expanding the data in a dataset), but I still think it is a worthwhile improvement for the expanded view. @keewis do you have any thoughts on this particular interaction?

Marking as a WIP/draft for now to see if this is a welcome format for the HTML repr first before I dig too much into optimizing the implementation and writing tests for it.

- [x] Closes #654 (even though it was already closed in favor of #765, I think the are related but separate issues)
- [x] Executed ``black -t py36 . && isort -rc . && flake8`` with no errors
- [x] The change is fully covered by automated unit tests
- [x] Documented in docs/ as appropriate
- [x] Added an entry to the CHANGES file

Tagging @nbren12, @hgrecco, @jondoesntgit, @natezb, @ipcoder, @keewis, and @TomNicholas for input based on past issues (#654, #765, and xarray-contrib/pint-xarray#6).


Co-authored-by: Jon Thielen <[email protected]>
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 a pull request may close this issue.

3 participants