ENH: Add support for ipython latex printing to polynomial by eric-wieser · Pull Request #11528 · numpy/numpy

eric-wieser · 2018-07-08T12:00:41Z

Choices made, and the alternatives rejected (for no particularly strong reason):

Show terms in ascending order, to match their internal representation
- alternative: descending, to match convention
Shows 0 terms in gray
- alternative: omit entirely
- alternative: show normally to aid comparison
Write each term as `basis(ax + b)
- alternative: write as basis(u) ... where u = ax + b
- alternative: show the normalized polynomial

In future it would perhaps make sense to expose these options to the end user

eric-wieser

Shown with some mathjax renderings

eric-wieser · 2018-07-08T12:04:31Z

numpy/polynomial/tests/test_classes.py

eric-wieser · 2018-07-08T12:05:02Z

numpy/polynomial/tests/test_classes.py

eric-wieser · 2018-07-08T12:07:36Z

numpy/polynomial/tests/test_classes.py

charris · 2018-07-09T01:37:17Z

I think we may want to revisit 3., especially as the terms extend to higher powers and the mapping ax + b has full precision coefficients, which is likely to happen when doing fits to data scattered along the x axis. Using u = a x + b explicitly is also how one would want to evaluate the polynomial or publish it. We will probably want to add some options for the order also. I think the domain is also needed, especially for fitting, where it is the domain in which the polynomial is valid. For high order fits the polynomial will try to run off to inf almost immediately outside the domain.

That said, this PR looks like a good starting point that will generate useful feedback.

eric-wieser · 2018-07-09T04:40:42Z

I think we may want to revisit 3

Yes, I agree - that was the choice I was least sure of. Shall I do 0, 1, or both of the following?

Change it to \text{ where } u = ...
Add a np.polynomial.set_latex_printoptions(substitute=False) to tweak this at runtime

that will generate useful feedback

Do you think we should gain most of the feedback before or after merging?

It's not clear to me how best to run jupyter notebook with runtests.py.

eric-wieser · 2018-07-09T04:43:28Z

numpy/polynomial/_polybase.py

Unfortunately '{}'.format(some_float) doesn't generate valid latex for coefficients using scientific notation. I'm not sure what the best thing to do here is - do we show the coefficients as monospaced and keep the e, to make it easy to copy/paste them?

do we show the coefficients as monospaced and keep the e, to make it easy to copy/paste them?

Makes sense, at least in the near term. This might be one of the things that garners feedback. We should probably decide how to set various options for the display, but that can wait.

Do you think we should gain most of the feedback before or after merging?

I was thinking after merge. I don't think it matters much if we change things later, and we won't know what people want in practice until we have people using it :) Maybe mark it as experimental in the release notes. Can make it a highlight just so folks see it.

Yes, this part of latex formatting is annoying; we have a specific method that does it for units/quantities

mattip · 2018-07-09T17:06:31Z

For those following along and wondering what this does, ipython front-ends can call "rich display" methods to display a class object.

ev-br · 2018-07-15T08:58:51Z

A big +1 for this from the peanut gallery.

charris · 2018-08-12T14:17:57Z

Needs a release note.

Choices made, and the alternatives rejected (for no particularly strong reason): 1. Show terms in ascending order, to match their internal representation * alternative: descending, to match convention 2. Shows 0 terms in gray * alternative: omit entirely * alternative: show normally to aid comparison 3. Write each term as `basis(ax + b) * alternative: write as `basis(u) ... where u = ax + b` * alternative: show the normalized polynomial In future it would perhaps make sense to expose these options to the end user

codecov-io · 2018-08-12T23:05:15Z

Codecov Report

Merging #11528 into master will decrease coverage by 0.63%.
The diff coverage is 91.46%.

@@            Coverage Diff             @@
##           master   #11528      +/-   ##
==========================================
- Coverage   86.58%   85.95%   -0.64%     
==========================================
  Files         315      326      +11     
  Lines       81307    81990     +683     
==========================================
+ Hits        70401    70474      +73     
- Misses      10906    11516     +610

Impacted Files	Coverage Δ
numpy/polynomial/chebyshev.py	`92.98% <100%> (+0.01%)`	⬆️
numpy/polynomial/legendre.py	`95.67% <100%> (+0.01%)`	⬆️
numpy/polynomial/hermite_e.py	`95.46% <100%> (+0.01%)`	⬆️
numpy/polynomial/hermite.py	`95.49% <100%> (+0.01%)`	⬆️
numpy/polynomial/polynomial.py	`95.46% <100%> (+0.11%)`	⬆️
numpy/polynomial/laguerre.py	`95.58% <100%> (+0.01%)`	⬆️
numpy/polynomial/tests/test_classes.py	`99.34% <100%> (+0.03%)`	⬆️
numpy/polynomial/_polybase.py	`78.75% <84.44%> (+0.68%)`	⬆️
numpy/lib/setup.py	`0% <0%> (ø)`
numpy/compat/setup.py	`0% <0%> (ø)`
... and 9 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b007246...e6e60c0. Read the comment docs.

charris · 2018-08-12T23:58:00Z

Seems users can toggle pretty printing with %pprint, which will hopefully disable this if big polynomials get out of hand. I think the only way we will get useful feedback is to put it out there and see what happens. If it goes wrong there is always the 1.16.1 release :) Thanks Eric.

eric-wieser · 2018-08-13T04:52:03Z

The sad reality might be that almost no one uses np.polynomial anyway, and people are stuck on np.poly1d and friends...

mhvk · 2018-08-13T08:51:40Z

I do use it...

This variable is never used, and shows signs of being leftover from a previous implementation. Introduced in gh-11528. Closes gh-11842

eric-wieser commented Jul 8, 2018

View reviewed changes

eric-wieser added 01 - Enhancement component: numpy.polynomial labels Jul 8, 2018

eric-wieser mentioned this pull request Jul 8, 2018

ENH: Formatting Polynomials #8893

Closed

eric-wieser commented Jul 9, 2018

View reviewed changes

mattip added the 56 - Needs Release Note. Needs an entry in doc/release/upcoming_changes label Jul 9, 2018

eric-wieser self-assigned this Jul 23, 2018

eric-wieser force-pushed the polynomial-ipython-latex branch from 36ca790 to 1457b53 Compare August 12, 2018 18:56

eric-wieser force-pushed the polynomial-ipython-latex branch from 1457b53 to e6e60c0 Compare August 12, 2018 21:34

charris merged commit a524915 into numpy:master Aug 12, 2018

eric-wieser mentioned this pull request Aug 31, 2018

ENH: implement _polynomial baseclass' _repr_latex_scalar method #11844

Closed

eric-wieser pushed a commit that referenced this pull request Sep 4, 2018

MAINT: remove surviving, unused, list comprehension (#11843)

fe3412f

This variable is never used, and shows signs of being leftover from a previous implementation. Introduced in gh-11528. Closes gh-11842

mattip mentioned this pull request Mar 19, 2020

ENH: Improved __str__ for polynomials #15666

Merged

milliams mentioned this pull request Mar 31, 2022

ENH: Add support for IPython pretty printers to ndarray #21273

Open

Uh oh!

Conversation

eric-wieser commented Jul 8, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eric-wieser left a comment

Choose a reason for hiding this comment

Uh oh!

eric-wieser Jul 8, 2018

Choose a reason for hiding this comment

Uh oh!

eric-wieser Jul 8, 2018

Choose a reason for hiding this comment

Uh oh!

eric-wieser Jul 8, 2018

Choose a reason for hiding this comment

Uh oh!

charris commented Jul 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eric-wieser commented Jul 9, 2018

Uh oh!

eric-wieser Jul 9, 2018

Choose a reason for hiding this comment

Uh oh!

charris Jul 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhvk Jul 23, 2018

Choose a reason for hiding this comment

Uh oh!

mattip commented Jul 9, 2018

Uh oh!

ev-br commented Jul 15, 2018

Uh oh!

charris commented Aug 12, 2018

Uh oh!

codecov-io commented Aug 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

charris commented Aug 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eric-wieser commented Aug 13, 2018

Uh oh!

mhvk commented Aug 13, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

eric-wieser commented Jul 8, 2018 •

edited

Loading

charris commented Jul 9, 2018 •

edited

Loading

charris Jul 9, 2018 •

edited

Loading

codecov-io commented Aug 12, 2018 •

edited

Loading

charris commented Aug 12, 2018 •

edited

Loading