Sage: Ticket #5448: [with patch, positive review] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib
https://trac.sagemath.org/ticket/5448
<p>
This makes the axes and gridline code in Sage obsolete and upgrades the matplotlib spkg.
</p>
<p>
This patch depends on the following spkgs.
</p>
<p>
<a class="ext-link" href="http://sage.math.washington.edu/home/jason/matplotlib-0.99.0.spkg"><span class="icon"></span>http://sage.math.washington.edu/home/jason/matplotlib-0.99.0.spkg</a> (for all of the good stuff for this patch)
</p>
<p>
<a class="ext-link" href="http://sage.math.washington.edu/home/jason/networkx-0.99.p1-fake_really-0.36.p1.spkg"><span class="icon"></span>http://sage.math.washington.edu/home/jason/networkx-0.99.p1-fake_really-0.36.p1.spkg</a> (to get rid of lots of deprecation warnings from the upgraded matplotlib).
</p>
<p>
Last patch applies to 4.1.2.alpha0, or 4.1.1 with <a class="closed ticket" href="https://trac.sagemath.org/ticket/6685" title="enhancement: [with patch, positive review] include pictures in the reference manual ... (closed: fixed)">#6685</a>.
</p>
<p>
Doctests in plot/*.py pass. -docbuild reference html passes.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/5448
Trac 1.1.6mhansenFri, 06 Mar 2009 03:39:15 GMTattachment set
https://trac.sagemath.org/ticket/5448
https://trac.sagemath.org/ticket/5448
<ul>
<li><strong>attachment</strong>
set to <em>plot.patch</em>
</li>
</ul>
TicketjasonFri, 06 Mar 2009 21:29:34 GMTcc set
https://trac.sagemath.org/ticket/5448#comment:1
https://trac.sagemath.org/ticket/5448#comment:1
<ul>
<li><strong>cc</strong>
<em>jason</em> added
</li>
</ul>
TicketjasonFri, 06 Mar 2009 21:31:18 GMT
https://trac.sagemath.org/ticket/5448#comment:2
https://trac.sagemath.org/ticket/5448#comment:2
<p>
mhansen: are you still working on this, or are you posting it in hopes that someone else will work on it?
</p>
TicketmhansenSat, 07 Mar 2009 19:21:15 GMTowner, status changed
https://trac.sagemath.org/ticket/5448#comment:3
https://trac.sagemath.org/ticket/5448#comment:3
<ul>
<li><strong>owner</strong>
changed from <em>was</em> to <em>mhansen</em>
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>assigned</em>
</li>
</ul>
<p>
I was planning on finishing this up in the near future. I posted it because I wanted to see what all I had left to do and possibly to get feedback from others.
</p>
TicketjasonFri, 27 Mar 2009 04:17:14 GMT
https://trac.sagemath.org/ticket/5448#comment:4
https://trac.sagemath.org/ticket/5448#comment:4
<p>
Here's another project that provides nice axes functionality for matplotlib, for reference:
</p>
<p>
<a class="ext-link" href="http://sourceforge.net/mailarchive/forum.php?thread_name=6e8d907b0903252232u66427cd5obbd78867424e2651%40mail.gmail.com&forum_name=matplotlib-devel"><span class="icon"></span>http://sourceforge.net/mailarchive/forum.php?thread_name=6e8d907b0903252232u66427cd5obbd78867424e2651%40mail.gmail.com&forum_name=matplotlib-devel</a>
</p>
TicketschymansFri, 26 Jun 2009 13:29:02 GMT
https://trac.sagemath.org/ticket/5448#comment:5
https://trac.sagemath.org/ticket/5448#comment:5
<p>
Just a very naive question: It seems like a lot of work to include Matplotlib's functionality in plot(). Wouldn't it be easier to just transfer the list of values generated by plot() to Matplotlib? Then, the rest could be done with the conventional Matplotlib commands. So far, I have been able to do everything I wanted using Matplotlib, the only impasse being the generation of points to plot, which I believe is solved in plot() a lot more elegantly than just evaluating a number of equidistant points. I apologise in advance for my ignorance.
</p>
TicketjasonWed, 19 Aug 2009 07:20:39 GMTsummary changed
https://trac.sagemath.org/ticket/5448#comment:6
https://trac.sagemath.org/ticket/5448#comment:6
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, not ready for review] rework save/show in plot, use Matplotlib's axes code</em> to <em>[with patch, needs work] rework save/show in plot, use Matplotlib's axes code</em>
</li>
</ul>
<p>
PLEASE KEEP MIKE'S PATCH ATTACHED TO THIS TICKET FOR NOW
</p>
<p>
(I think he might have some more elegant ways of doing things than I did, which I'd like to copy to my patch).
The trac-5448-matplotlib-axes-gridlines.patch requires the new matplotlib spkg at <a class="ext-link" href="http://sage.math.washington.edu/home/jason/matplotlib-0.99.0.spkg"><span class="icon"></span>http://sage.math.washington.edu/home/jason/matplotlib-0.99.0.spkg</a>
</p>
<p>
Please give feedback!
</p>
TicketjasonWed, 19 Aug 2009 07:23:40 GMTcc, description, summary changed
https://trac.sagemath.org/ticket/5448#comment:7
https://trac.sagemath.org/ticket/5448#comment:7
<ul>
<li><strong>cc</strong>
<em>wcauchois</em> <em>kcrisman</em> added; <em>jason</em> removed
</li>
<li><strong>description</strong>
modified (<a href="/ticket/5448?action=diff&version=7">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>[with patch, needs work] rework save/show in plot, use Matplotlib's axes code</em> to <em>[with patch, needs work] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em>
</li>
</ul>
<p>
Here is the old description (applicable to Mike's patch, and some of which may be applicable to my patch):
</p>
<p>
This removes the axes.py code from Sage and switches to Matplotlib's code. This allows for things like log scales as well as more flexibility in controlling how the ticks are labeled formatted. It also fixes a number of existing bugs (like 2754). After this change, it will be trivial to add a viewer='flot' option to Graphics.
</p>
<p>
The patch still needs some work a.k.a. doctests. There are also a few things that don't work yet (like tick color and tick fontsize), and matrix_plot needs a matplotlib Locater and Formatter. Also, <a class="missing wiki">GraphicsArray?</a> needs to be updated and should get lots of doctests for it added.
</p>
TicketkcrismanThu, 20 Aug 2009 16:50:27 GMT
https://trac.sagemath.org/ticket/5448#comment:8
https://trac.sagemath.org/ticket/5448#comment:8
<p>
Just a question to Jason - will this break any currently existing code that has rgbcolor instead of color in use? I assume not but thought I would ask - ditto for any other options for plot or show that would be deprecated?
</p>
TicketjasonThu, 20 Aug 2009 17:01:16 GMT
https://trac.sagemath.org/ticket/5448#comment:9
https://trac.sagemath.org/ticket/5448#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:8" title="Comment 8">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Just a question to Jason - will this break any currently existing code that has rgbcolor instead of color in use? I assume not but thought I would ask - ditto for any other options for plot or show that would be deprecated?
</p>
</blockquote>
<p>
I think the only code it might break is the use of rgbcolor in gridline styles, which according to the docs, should not have been allowed anyway (matplotlib lines do not have an rgbcolor option). For everything else, I've been careful to doctest everything in plot.py, and all tests pass.
</p>
TicketkcrismanWed, 26 Aug 2009 02:06:16 GMT
https://trac.sagemath.org/ticket/5448#comment:10
https://trac.sagemath.org/ticket/5448#comment:10
<p>
Okay, first off patch needs work if only because it does not apply to 4.1.1! Fix is to correct all spellings of "apect" in the patch to "aspect" and to replace one instance of "png's" at the end to "PNG's". Also, eventually presumably axes.py should go to dev/null, right? I also get a bunch of deprecation warnings, but presumably that is known.
</p>
<p>
As to the stuff itself:
</p>
<ol><li>When using pointsize, matplotlib axes (or the way in which they are used) has some whitespace cutting off points, for example when pointsize is large (20 worked for me, but unfortunately I can't cut and paste and example here).
</li></ol><ol start="2"><li>I'm not sure I like the non-intersecting axes on regular plots. That is weird, especially in graphs like the plot of x squared type things. plot(x<strong>2,0,1) looks great; plot(x</strong>2,-1,1) looks... interesting.
</li></ol><ol start="3"><li>For some reasons, showing some plots yields the <a class="closed ticket" href="https://trac.sagemath.org/ticket/5956" title="defect: image dimensions for show() are in inches (closed: fixed)">#5956</a> <a class="missing wiki">ValueError?</a> of "<a class="missing wiki">ValueError?</a>: width and height must each be below 32768" which apparently comes from matplotlib/backends/backend_agg.py, the <a class="missing wiki">RendererAgg?</a> (whatever that is). I should point out these are plots which worked before. Apparently it has something to do with adding axes_labels, because without them, this problem does not appear. Did something get a LOT bigger on the axis labels?
</li></ol><ol start="4"><li>The two zeros where axes intersect is distracting. I'm not sure what else to say about that, other than that it's true. This is especially true when the graph gets close to the origin. Of course, the reason for labeling it has been discussed elsewhere - it just may have to get "smart". Maybe when the origin IS the intersection point of the axes (as one might expect), this could be tacitly omitted?
</li></ol><ol start="5"><li>For some reason William's example in some talk where he does a little eye candy with image manipulation (e.g., "compressed using x eigenvalues") doesn't work right; only the second matrix_plot works properly, the other one does not. So something with the new axes and frame isn't working right.
</li></ol><ol start="6"><li>Ironically, switching slope fields to normal (not frame) axes is worse, because it's hard to see the numbers with any reasonably density of the points for the slopes.
</li></ol><ol start="7"><li>This is just a question: is it possible to get custom labeling for axis numbering now in matrix plots? E.g., (!) if I am taking just the 4th-6th powers of some numbers and plotting them in a grid, can I label those columns as 4-6? I don't know if mpl has this; the axes_grid thing on the website looked conceivably related, maybe even good for matrix_plot or multiple graphics.
</li></ol><p>
But great work notwithstanding! Looking forward to whatever comes out of this ticket, and the mpl upgrade seems nice.
</p>
TicketjasonWed, 26 Aug 2009 03:18:05 GMT
https://trac.sagemath.org/ticket/5448#comment:11
https://trac.sagemath.org/ticket/5448#comment:11
<p>
Thanks for looking at this! I haven't had time to come back to it yet (our semester started...)
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:10" title="Comment 10">kcrisman</a>:
</p>
<blockquote class="citation">
<ol><li>When using pointsize, matplotlib axes (or the way in which they are used) has some whitespace cutting off points, for example when pointsize is large (20 worked for me, but unfortunately I can't cut and paste and example here).
</li></ol></blockquote>
<p>
On the one hand, I can turn off clipping. However, that tends to make really ugly plots when you have frame axes (since then the dots go outside of the frames). On the other hand, we can automatically enlarge the plot axes (so that if you request -3..3, it might actually cover -3.5..3.5). This could be frustrating, but is sort of what happens now. I guess you have to make a choice between things extending beyond your plot (no clipping) or extending your plot. For right now, I was hoping that people would just make their ranges a bit bigger by hand.
</p>
<blockquote class="citation">
<ol start="2"><li>I'm not sure I like the non-intersecting axes on regular plots. That is weird, especially in graphs like the plot of x squared type things. plot(x<strong>2,0,1) looks great; plot(x</strong>2,-1,1) looks... interesting.
</li></ol></blockquote>
<p>
Yeah, it's a bit different, but after playing with it for a while, I liked it. At a glance, it oriented me to what I was looking at and how it was compared to the infinite plane. This is definitely something that should go up for a vote.
</p>
<p>
Also, I'd like to add an option for a custom crossing point. That would be another 5 lines of code, maybe.
</p>
<blockquote class="citation">
<ol start="3"><li>For some reasons, showing some plots yields the <a class="closed ticket" href="https://trac.sagemath.org/ticket/5956" title="defect: image dimensions for show() are in inches (closed: fixed)">#5956</a> <a class="missing wiki">ValueError?</a> of "<a class="missing wiki">ValueError?</a>: width and height must each be below 32768" which apparently comes from matplotlib/backends/backend_agg.py, the <a class="missing wiki">RendererAgg?</a> (whatever that is). I should point out these are plots which worked before. Apparently it has something to do with adding axes_labels, because without them, this problem does not appear. Did something get a LOT bigger on the axis labels?
</li></ol></blockquote>
<p>
For right now, I automatically expand things to not clip axes labels. There might be a bug in that. Can you post an example?
</p>
<blockquote class="citation">
<ol start="4"><li>The two zeros where axes intersect is distracting. I'm not sure what else to say about that, other than that it's true. This is especially true when the graph gets close to the origin. Of course, the reason for labeling it has been discussed elsewhere - it just may have to get "smart". Maybe when the origin IS the intersection point of the axes (as one might expect), this could be tacitly omitted?
</li></ol></blockquote>
<p>
It would be easy to omit one or both of these zeros in these cases.
</p>
<blockquote class="citation">
<ol start="5"><li>For some reason William's example in some talk where he does a little eye candy with image manipulation (e.g., "compressed using x eigenvalues") doesn't work right; only the second matrix_plot works properly, the other one does not. So something with the new axes and frame isn't working right.
</li></ol></blockquote>
<p>
Okay, I'll try to look at this.
</p>
<blockquote class="citation">
<ol start="6"><li>Ironically, switching slope fields to normal (not frame) axes is worse, because it's hard to see the numbers with any reasonably density of the points for the slopes.
</li></ol></blockquote>
<p>
and your proposed fix is...?
</p>
<blockquote class="citation">
<ol start="7"><li>This is just a question: is it possible to get custom labeling for axis numbering now in matrix plots? E.g., (!) if I am taking just the 4th-6th powers of some numbers and plotting them in a grid, can I label those columns as 4-6? I don't know if mpl has this; the axes_grid thing on the website looked conceivably related, maybe even good for matrix_plot or multiple graphics.
</li></ol></blockquote>
<p>
Totally easy. You have the full power of matplotlib at your command. You just do something like:
</p>
<p>
p=plot(m).matplotlib()
# p is now a matplotlib figure object
</p>
<p>
Now just do custom axes locators for axes in p, like in <a class="ext-link" href="http://matplotlib.sourceforge.net/examples/pylab_examples/custom_ticker1.html"><span class="icon"></span>http://matplotlib.sourceforge.net/examples/pylab_examples/custom_ticker1.html</a>
</p>
<p>
When you are done, just do:
</p>
<p>
p.save_fig('test.png') # or something like this
</p>
<p>
or (with another change that should be coming soon, now that I understand matplotlib a lot better):
</p>
<p>
Graphics(p) # This is now a sage Graphics object...
</p>
TicketkcrismanWed, 26 Aug 2009 12:13:59 GMT
https://trac.sagemath.org/ticket/5448#comment:12
https://trac.sagemath.org/ticket/5448#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:11" title="Comment 11">jason</a>:
</p>
<blockquote class="citation">
<p>
Thanks for looking at this! I haven't had time to come back to it yet (our semester started...)
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:10" title="Comment 10">kcrisman</a>:
</p>
<blockquote class="citation">
<ol><li>When using pointsize, matplotlib axes (or the way in which they are used) has some whitespace cutting off points, for example when pointsize is large (20 worked for me, but unfortunately I can't cut and paste and example here).
</li></ol></blockquote>
<p>
On the one hand, I can turn off clipping. However, that tends to make really ugly plots when you have frame axes (since then the dots go outside of the frames). On the other hand, we can automatically enlarge the plot axes (so that if you request -3..3, it might actually cover -3.5..3.5). This could be frustrating, but is sort of what happens now. I guess you have to make a choice between things extending beyond your plot (no clipping) or extending your plot. For right now, I was hoping that people would just make their ranges a bit bigger by hand.
</p>
</blockquote>
<p>
Definitely should be automatic, I think, if it's already-existing behavior.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ol start="2"><li>I'm not sure I like the non-intersecting axes on regular plots. That is weird, especially in graphs like the plot of x squared type things. plot(x<strong>2,0,1) looks great; plot(x</strong>2,-1,1) looks... interesting.
</li></ol></blockquote>
<p>
Yeah, it's a bit different, but after playing with it for a while, I liked it. At a glance, it oriented me to what I was looking at and how it was compared to the infinite plane. This is definitely something that should go up for a vote.
</p>
</blockquote>
<p>
I'm not sure what you are looking at. The axes do not actually cross! That is bad, imho.
</p>
<blockquote class="citation">
<p>
Also, I'd like to add an option for a custom crossing point. That would be another 5 lines of code, maybe.
</p>
</blockquote>
<p>
Yeah, that would be good, though hopefully not often needed.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ol start="4"><li>The two zeros where axes intersect is distracting. I'm not sure what else to say about that, other than that it's true. This is especially true when the graph gets close to the origin. Of course, the reason for labeling it has been discussed elsewhere - it just may have to get "smart". Maybe when the origin IS the intersection point of the axes (as one might expect), this could be tacitly omitted?
</li></ol></blockquote>
<p>
It would be easy to omit one or both of these zeros in these cases.
</p>
</blockquote>
<p>
Something to think about. Presumably the other labels would make it clear it's a zero.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ol start="6"><li>Ironically, switching slope fields to normal (not frame) axes is worse, because it's hard to see the numbers with any reasonably density of the points for the slopes.
</li></ol></blockquote>
<p>
and your proposed fix is...?
</p>
</blockquote>
<p>
Using frames again for slope fields (the previous behavior).
</p>
TicketkcrismanWed, 26 Aug 2009 13:02:21 GMT
https://trac.sagemath.org/ticket/5448#comment:13
https://trac.sagemath.org/ticket/5448#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:11" title="Comment 11">jason</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<ol start="3"><li>For some reasons, showing some plots yields the <a class="closed ticket" href="https://trac.sagemath.org/ticket/5956" title="defect: image dimensions for show() are in inches (closed: fixed)">#5956</a> <a class="missing wiki">ValueError?</a> of "<a class="missing wiki">ValueError?</a>: width and height must each be below 32768" which apparently comes from matplotlib/backends/backend_agg.py, the <a class="missing wiki">RendererAgg?</a> (whatever that is). I should point out these are plots which worked before. Apparently it has something to do with adding axes_labels, because without them, this problem does not appear. Did something get a LOT bigger on the axis labels?
</li></ol></blockquote>
<p>
For right now, I automatically expand things to not clip axes labels. There might be a bug in that. Can you post an example?
</p>
</blockquote>
<p>
It appears to have something to do with where the labels are located.
</p>
<pre class="wiki">sage: plot(x**2,0,1,axes_labels=['x','y'])
</pre><p>
is fine, but
</p>
<pre class="wiki">sage: plot(x**2,99,100,axes_labels=['x','y'])
</pre><p>
yields the problem. This also happens with point sets:
</p>
<pre class="wiki">sage: data=[(1990,1611),(1991,1586)]
sage: plot1=point(data)
sage: show(plot1,axes_labels=['x','y'])
</pre><p>
Back to the other issues, note that while the following does plot
</p>
<pre class="wiki">sage: show(plot1)
</pre><p>
it also is not ideal, as the axes don't even come close to touching. By the way, the pointsize is irrelevant - even with no pointsize given, the points are still cut off. Also, there is a mysterious cut-off thing at the bottom which look like +1.00e3, but it's cut off so I can't tell for sure. Any ideas on that?
</p>
TicketjasonWed, 26 Aug 2009 14:02:30 GMT
https://trac.sagemath.org/ticket/5448#comment:14
https://trac.sagemath.org/ticket/5448#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:12" title="Comment 12">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:11" title="Comment 11">jason</a>:
</p>
<blockquote class="citation">
<p>
Thanks for looking at this! I haven't had time to come back to it yet (our semester started...)
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:10" title="Comment 10">kcrisman</a>:
</p>
<blockquote class="citation">
<ol><li>When using pointsize, matplotlib axes (or the way in which they are used) has some whitespace cutting off points, for example when pointsize is large (20 worked for me, but unfortunately I can't cut and paste and example here).
</li></ol></blockquote>
<p>
On the one hand, I can turn off clipping. However, that tends to make really ugly plots when you have frame axes (since then the dots go outside of the frames). On the other hand, we can automatically enlarge the plot axes (so that if you request -3..3, it might actually cover -3.5..3.5). This could be frustrating, but is sort of what happens now. I guess you have to make a choice between things extending beyond your plot (no clipping) or extending your plot. For right now, I was hoping that people would just make their ranges a bit bigger by hand.
</p>
</blockquote>
<p>
Definitely should be automatic, I think, if it's already-existing behavior.
</p>
</blockquote>
<p>
Okay, I think I have an idea that will do this (find the bounding box of the scatter plots, convert those coordinates to axes coordinates, and then enlarge the axes to include those bounding boxes)
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ol start="2"><li>I'm not sure I like the non-intersecting axes on regular plots. That is weird, especially in graphs like the plot of x squared type things. plot(x<strong>2,0,1) looks great; plot(x</strong>2,-1,1) looks... interesting.
</li></ol></blockquote>
<p>
Yeah, it's a bit different, but after playing with it for a while, I liked it. At a glance, it oriented me to what I was looking at and how it was compared to the infinite plane. This is definitely something that should go up for a vote.
</p>
</blockquote>
<p>
I'm not sure what you are looking at. The axes do not actually cross! That is bad, imho.
</p>
</blockquote>
<p>
And, after I played with it for a bit, I thought it was great! The axes only ever cross at the origin. That is wonderfully refreshing and consistent, and leads to being able to immediately orient yourself in the graph without having to examine and think about the axes tick labels. If there is some space, then that means you are way above the axis (and the side the axis is on tells you where the axis really is). I think of it sort of like a small zigzag break in the axes. Maybe if we put that in an explicit small zigzag symbol, would that help you?
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ol start="6"><li>Ironically, switching slope fields to normal (not frame) axes is worse, because it's hard to see the numbers with any reasonably density of the points for the slopes.
</li></ol></blockquote>
<p>
and your proposed fix is...?
</p>
</blockquote>
<p>
Using frames again for slope fields (the previous behavior).
</p>
</blockquote>
<p>
Ah, I thought I did this. I did it for contour plots; doing it for vector fields is about a one-line change (just add frame=True to the @options decorator before the vector field plotting function)
</p>
TicketkcrismanWed, 26 Aug 2009 14:13:08 GMT
https://trac.sagemath.org/ticket/5448#comment:15
https://trac.sagemath.org/ticket/5448#comment:15
<p>
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ol start="2"><li>I'm not sure I like the non-intersecting axes on regular plots. That is weird, especially in graphs like the plot of x squared type things. plot(x<strong>2,0,1) looks great; plot(x</strong>2,-1,1) looks... interesting.
</li></ol></blockquote>
<p>
Yeah, it's a bit different, but after playing with it for a while, I liked it. At a glance, it oriented me to what I was looking at and how it was compared to the infinite plane. This is definitely something that should go up for a vote.
</p>
</blockquote>
<p>
I'm not sure what you are looking at. The axes do not actually cross! That is bad, imho.
</p>
</blockquote>
<p>
And, after I played with it for a bit, I thought it was great! The axes only ever cross at the origin. That is wonderfully refreshing and consistent, and leads to being able to immediately orient yourself in the graph without having to examine and think about the axes tick labels. If there is some space, then that means you are way above the axis (and the side the axis is on tells you where the axis really is). I think of it sort of like a small zigzag break in the axes. Maybe if we put that in an explicit small zigzag symbol, would that help you?
</p>
</blockquote>
<p>
I see. The problem is that this is just as non-standard as the previous behavior, which people also complained about. For sure it shouldn't happen with
</p>
<pre class="wiki">sage: plot(x**2,-1,1)
</pre><p>
I do agree that it is more consistent, if you can get it to be consistent - and if it is REALLY well documented, i.e. right up at the top of the plot docs and in the tutorial. If you think the rest of the stuff is ready for prime time, you should definitely put the various versions in screenshots up for a vote on sage-devel, since improved axes would really be great to have.
</p>
TicketjasonSun, 30 Aug 2009 04:17:49 GMT
https://trac.sagemath.org/ticket/5448#comment:16
https://trac.sagemath.org/ticket/5448#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:13" title="Comment 13">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:11" title="Comment 11">jason</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<ol start="3"><li>For some reasons, showing some plots yields the <a class="closed ticket" href="https://trac.sagemath.org/ticket/5956" title="defect: image dimensions for show() are in inches (closed: fixed)">#5956</a> <a class="missing wiki">ValueError?</a> of "<a class="missing wiki">ValueError?</a>: width and height must each be below 32768" which apparently comes from matplotlib/backends/backend_agg.py, the <a class="missing wiki">RendererAgg?</a> (whatever that is). I should point out these are plots which worked before. Apparently it has something to do with adding axes_labels, because without them, this problem does not appear. Did something get a LOT bigger on the axis labels?
</li></ol></blockquote>
<p>
For right now, I automatically expand things to not clip axes labels. There might be a bug in that. Can you post an example?
</p>
</blockquote>
<p>
It appears to have something to do with where the labels are located.
</p>
<pre class="wiki">sage: plot(x**2,0,1,axes_labels=['x','y'])
</pre><p>
is fine, but
</p>
<pre class="wiki">sage: plot(x**2,99,100,axes_labels=['x','y'])
</pre><p>
yields the problem. This also happens with point sets:
</p>
<pre class="wiki">sage: data=[(1990,1611),(1991,1586)]
sage: plot1=point(data)
sage: show(plot1,axes_labels=['x','y'])
</pre></blockquote>
<p>
I figured out what the problem was. I'm setting the x-axis label y-coordinate to y=0, which is obviously wrong if y=0 is not in the picture. I'm doing a similar thing with the y-axis label. I've emailed the matplotlib list for help on getting the right matplotlib transform to get the label to be offset from the actual axis in the picture.
</p>
TicketjasonSun, 30 Aug 2009 05:21:48 GMT
https://trac.sagemath.org/ticket/5448#comment:17
https://trac.sagemath.org/ticket/5448#comment:17
<p>
The new patch:
</p>
<ul><li>is rebased against 4.1.1
</li><li>omits the tick labels for the origin when the axes cross inside of the picture
</li><li>puts the axis labels where they go by default in matplotlib, instead of trying to make them like mathematica. This is temporary until I hear back from the matplotlib mailing list about the best way to make it so that the labels are at the end of the axes.
</li><li>changes vector field and slope field plots to have frame=True by default
</li></ul>
TicketmpatelSun, 30 Aug 2009 11:45:27 GMT
https://trac.sagemath.org/ticket/5448#comment:18
https://trac.sagemath.org/ticket/5448#comment:18
<p>
A minor question about <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/260" title="enhancement: Background color and opacity of graphics output (needs_work)">#260</a>: When I rebase its patch, should I change this part:
</p>
<pre class="wiki"># Set the degree of transparency. Since the matplotlib axes
# are hidden, we omit subplot.patch.set_alpha(transparency).
if transparency is not None:
figure.patch.set_alpha(transparency)
</pre><p>
?
</p>
TicketschymansMon, 31 Aug 2009 06:42:37 GMT
https://trac.sagemath.org/ticket/5448#comment:19
https://trac.sagemath.org/ticket/5448#comment:19
<p>
Sorry about the dumb question, but how do I apply this patch?
</p>
<p>
Following the instructions at <a href="http://www.sagemath.org/doc/developer/producing_patches.html">http://www.sagemath.org/doc/developer/producing_patches.html</a>, I did:
hg_sage.patch('trac-5448-matplotlib-axes-gridlines.patch')
</p>
<p>
However, this launched me straight into editing the patch, which I was not really up to. Exiting the editors led to the following message:
</p>
<p>
<a class="missing wiki">RuntimeError?</a>: Refusing to do operation since you still have unrecorded changes. You must check in all changes in your working repository first.
</p>
<p>
Thanks for your help!
</p>
<p>
Stan
</p>
TicketjasonMon, 31 Aug 2009 13:13:01 GMT
https://trac.sagemath.org/ticket/5448#comment:20
https://trac.sagemath.org/ticket/5448#comment:20
<p>
Try this from the command line:
</p>
<pre class="wiki">$ sage -sh
$ cd $SAGE_ROOT/devel/sage/sage/
$ hg qimport http://trac.sagemath.org/sage_trac/raw-attachment/ticket/5448/trac-5448-matplotlib-axes-gridlines.patch
$ hg qpush
</pre><p>
(there is a way to do this inside of Sage too, like you tried above, but I never use that and don't know exactly what to type).
</p>
<p>
The error message above says that you were modifying files, though. To see what has been changed, do:
</p>
<pre class="wiki">$ sage -sh
$ cd $SAGE_ROOT/devel/sage/sage/
$ hg diff
</pre><p>
If you don't want to save any of your changes, you can do the following. WARNING: this will delete all changes you've made to Sage files that you haven't checked into the repository.
</p>
<pre class="wiki">hg revert --all
</pre><p>
and then do the above hg qimport commands.
</p>
TicketjasonMon, 31 Aug 2009 13:38:10 GMT
https://trac.sagemath.org/ticket/5448#comment:21
https://trac.sagemath.org/ticket/5448#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:18" title="Comment 18">mpatel</a>:
</p>
<blockquote class="citation">
<p>
A minor question about <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/260" title="enhancement: Background color and opacity of graphics output (needs_work)">#260</a>: When I rebase its patch, should I change this part:
</p>
<pre class="wiki"># Set the degree of transparency. Since the matplotlib axes
# are hidden, we omit subplot.patch.set_alpha(transparency).
if transparency is not None:
figure.patch.set_alpha(transparency)
</pre><p>
?
</p>
</blockquote>
<p>
I've posted up some comments on <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/260" title="enhancement: Background color and opacity of graphics output (needs_work)">#260</a>. Either that patch or this patch will need to be updated.
</p>
TicketschymansMon, 31 Aug 2009 14:44:22 GMT
https://trac.sagemath.org/ticket/5448#comment:22
https://trac.sagemath.org/ticket/5448#comment:22
<p>
Thanks for your help, Jason. Unfortunately, I get the following error:
$ hg qimport <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/5448/trac-5448-matplotlib-axes-gridlines.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/5448/trac-5448-matplotlib-axes-gridlines.patch</a>
</p>
<p>
hg: unknown command 'qimport'
</p>
<p>
Maybe there is something wrong with my installation of sage? I'm on OSX 10.4.
</p>
<p>
The hg revert --all took me a few steps further using hg_sage.patch from within sage, until:
</p>
<p>
patching file sage/plot/matrix_plot.py
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/1" title="defect: SAGE Notebook leaves dead processes on OS X (closed: fixed)">#1</a> FAILED at 155
1 out of 1 hunks FAILED -- saving rejects to file sage/plot/matrix_plot.py.rej
patching file sage/plot/plot.py
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/6" title="defect: PowerSeriesRing(QQ, 10) raises unhelpful exception (closed: fixed)">#6</a> FAILED at 1222
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/10" title="enhancement: [with spkg, positive review] update M2 to the 1.1 release (closed: fixed)">#10</a> FAILED at 1770
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/11" title="defect: doctest failure in functions/special.py (closed: fixed)">#11</a> FAILED at 1812
3 out of 14 hunks FAILED -- saving rejects to file sage/plot/plot.py.rej
abort: patch failed to apply
</p>
<p>
:-(
</p>
<p>
Not sure if this is the right place for this kind of support. Should I post about it to the support mailing list?
</p>
<p>
Cheers,
Stan
</p>
TicketjasonMon, 31 Aug 2009 16:53:27 GMT
https://trac.sagemath.org/ticket/5448#comment:23
https://trac.sagemath.org/ticket/5448#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:22" title="Comment 22">schymans</a>:
</p>
<blockquote class="citation">
<p>
Thanks for your help, Jason. Unfortunately, I get the following error:
$ hg qimport <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/5448/trac-5448-matplotlib-axes-gridlines.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/5448/trac-5448-matplotlib-axes-gridlines.patch</a>
</p>
<p>
hg: unknown command 'qimport'
</p>
<p>
Maybe there is something wrong with my installation of sage? I'm on OSX 10.4.
</p>
<p>
The hg revert --all took me a few steps further using hg_sage.patch from within sage, until:
</p>
<p>
patching file sage/plot/matrix_plot.py
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/1" title="defect: SAGE Notebook leaves dead processes on OS X (closed: fixed)">#1</a> FAILED at 155
1 out of 1 hunks FAILED -- saving rejects to file sage/plot/matrix_plot.py.rej
patching file sage/plot/plot.py
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/6" title="defect: PowerSeriesRing(QQ, 10) raises unhelpful exception (closed: fixed)">#6</a> FAILED at 1222
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/10" title="enhancement: [with spkg, positive review] update M2 to the 1.1 release (closed: fixed)">#10</a> FAILED at 1770
Hunk <a class="closed ticket" href="https://trac.sagemath.org/ticket/11" title="defect: doctest failure in functions/special.py (closed: fixed)">#11</a> FAILED at 1812
3 out of 14 hunks FAILED -- saving rejects to file sage/plot/plot.py.rej
abort: patch failed to apply
</p>
<p>
:-(
</p>
<p>
Not sure if this is the right place for this kind of support. Should I post about it to the support mailing list?
</p>
</blockquote>
<ol><li>Are you applying this to 4.1.1? Have you made any changes or applied any other patches before this one?
</li></ol><ol start="2"><li>Did you download the latest version of the patch? I updated it Saturday to work with 4.1.1.
</li></ol>
TicketkcrismanMon, 31 Aug 2009 20:06:40 GMT
https://trac.sagemath.org/ticket/5448#comment:24
https://trac.sagemath.org/ticket/5448#comment:24
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:22" title="Comment 22">schymans</a>:
</p>
<blockquote class="citation">
<p>
Thanks for your help, Jason. Unfortunately, I get the following error:
$ hg qimport <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/5448/trac-5448-matplotlib-axes-gridlines.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/5448/trac-5448-matplotlib-axes-gridlines.patch</a>
</p>
<p>
hg: unknown command 'qimport'
</p>
</blockquote>
<p>
You have to have the Mercurial queues to do this (I don't, either). Your previous command should work, as long as you do NOT have any (uncommitted) changes to your code in the branch you attach it to.
</p>
<p>
That said, this sort of thing probably does belong on support next time, because others will likely have the same problem and it's not specific to this patch. Good luck!
</p>
TicketschymansTue, 01 Sep 2009 00:45:00 GMT
https://trac.sagemath.org/ticket/5448#comment:25
https://trac.sagemath.org/ticket/5448#comment:25
<p>
Thanks for your help, guys! I keep getting messages about uncommitted changes, probably from previous unsuccessful attempts to apply the patch. I'll move the discussion to sage-devel.
</p>
<p>
Cheers,
Stan
</p>
TicketkcrismanTue, 01 Sep 2009 02:01:24 GMT
https://trac.sagemath.org/ticket/5448#comment:26
https://trac.sagemath.org/ticket/5448#comment:26
<p>
Comments on the latest iteration:
</p>
<p>
I like the new look of vector/slope fields, actually - clear, because there are internal axes now!
</p>
<p>
Here are some small technical details I do not like, which cause it to still "need work".
</p>
<ol><li>plot(x<strong>2,-1,1) is unacceptable. No one will believe that even though the origin is in the graph, the axes don't cross! Instead they will assume that the origin is not in the graph. Presumably there is a way to have the algorithm do this, though, on an adhoc basis.
</strong></li></ol><ol start="2"><li>plot(x<strong>3,-1,1,axes_labels=['x','y']) shows that we should wait with this patch until there is a good way to move the axes - this is too confusing. Try replacing 'y' with 'zany' and it's just silly. Matplotlib style axis labels only work with frames.
</strong></li></ol><ol start="3"><li>there needs to be a slightly better algorithm for deciding what direction the ticks face. E.g. look at plot(x<strong>3,-1,0).
</strong></li></ol><ol start="4"><li>compare plot(x<strong>4,-1,54) and plot(x</strong>4,-1,55). Notice how once the scientific notation comes into play, matplotlib doesn't label correctly.
</li></ol><p>
That's all I found for now :) But it's nice to have some time to try to get this good. Assuming we actually want to do so, that is - is it more effort than its worth? Maybe the matplotlib upgrade could be a separate ticket, because that is certainly worthwhile and presumably doesn't cause any problems.
</p>
TicketjasonTue, 01 Sep 2009 15:41:05 GMT
https://trac.sagemath.org/ticket/5448#comment:27
https://trac.sagemath.org/ticket/5448#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:26" title="Comment 26">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Comments on the latest iteration:
</p>
<p>
I like the new look of vector/slope fields, actually - clear, because there are internal axes now!
</p>
<p>
Here are some small technical details I do not like, which cause it to still "need work".
</p>
<ol><li>plot(x<strong>2,-1,1) is unacceptable. No one will believe that even though the origin is in the graph, the axes don't cross! Instead they will assume that the origin is not in the graph. Presumably there is a way to have the algorithm do this, though, on an adhoc basis.
</strong></li></ol></blockquote>
<p>
Yes, it seems that numerical error is our enemy here:
</p>
<pre class="wiki">sage: ax=plot(x**2,-1,1).matplotlib().axes[0]
sage: ax.get_ylim()
(2.2226365446612245e-06, 1.0)
</pre><p>
I modified the code so that if 0 is within 1% of the range, but not included in the range, then we enlarge the range to include 0. We could change this 1% parameter, or make it user-settable.
</p>
<p>
This is fixed in the patch I'm posting up in a second.
</p>
<blockquote class="citation">
<ol start="2"><li>plot(x<strong>3,-1,1,axes_labels=['x','y']) shows that we should wait with this patch until there is a good way to move the axes - this is too confusing. Try replacing 'y' with 'zany' and it's just silly. Matplotlib style axis labels only work with frames.
</strong></li></ol></blockquote>
<p>
I've fixed this---well, except for one exceptional case. I'm waiting to hear back on the matplotlib mailing list (it might be a bug in matplotlib). I'll post up a patch in a second.
</p>
<blockquote class="citation">
<ol start="3"><li>there needs to be a slightly better algorithm for deciding what direction the ticks face. E.g. look at plot(x<strong>3,-1,0).
</strong></li></ol></blockquote>
<p>
Agreed. Do you have a suggestion? Maybe if the axis is in the middle of the picture, put ticks on both sides, and if it is on the side of the picture, put ticks facing inwards?
</p>
<blockquote class="citation">
<ol start="4"><li>compare plot(x<strong>4,-1,54) and plot(x</strong>4,-1,55). Notice how once the scientific notation comes into play, matplotlib doesn't label correctly.
</li></ol></blockquote>
<p>
As in the top is cut off? Is that what you are talking about?
</p>
<p>
We can change how the labels are printed pretty easily. What do you suggest?
</p>
<blockquote class="citation">
<p>
That's all I found for now :) But it's nice to have some time to try to get this good. Assuming we actually want to do so, that is - is it more effort than its worth? Maybe the matplotlib upgrade could be a separate ticket, because that is certainly worthwhile and presumably doesn't cause any problems.
</p>
</blockquote>
<p>
This is great. I think we are close enough to being done with this (or at least, close enough to a sage-devel discussion) that it's not worth trying to package 0.99.0 separately. Most of the reason why 0.99.0 is worth it is for these changes, I think.
</p>
TicketjasonTue, 01 Sep 2009 15:56:11 GMT
https://trac.sagemath.org/ticket/5448#comment:28
https://trac.sagemath.org/ticket/5448#comment:28
<p>
I updated the patch to:
</p>
<ol><li>if zero is within 1% of the range, but is not included in the range, then extend the range to include zero.
</li></ol><ol start="2"><li>fix axes labels for cases where the axes are not on the top or the right. A full solution is waiting for a response on the matplotlib mailing list---there might be a bug in how matplotlib handles things.
</li></ol><ol start="3"><li>Introduced a simple "transparent" option to show, which saves the image with transparent background. This is a subset of the functionality implemented at <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/260" title="enhancement: Background color and opacity of graphics output (needs_work)">#260</a>. I think <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/260" title="enhancement: Background color and opacity of graphics output (needs_work)">#260</a> ought to go ahead and implement its functionality in full generality (i.e., let the user specify the background color and opacity of a plot), but my change in this patch lets the user easily generate a transparent background using the function already provided by matplotlib.
</li></ol>
TicketkcrismanTue, 01 Sep 2009 17:24:05 GMT
https://trac.sagemath.org/ticket/5448#comment:29
https://trac.sagemath.org/ticket/5448#comment:29
<blockquote class="citation">
<blockquote class="citation">
<ol start="3"><li>there needs to be a slightly better algorithm for deciding what direction the ticks face. E.g. look at plot(x<strong>3,-1,0).
</strong></li></ol></blockquote>
<p>
Agreed. Do you have a suggestion? Maybe if the axis is in the middle of the picture, put ticks on both sides, and if it is on the side of the picture, put ticks facing inwards?
</p>
</blockquote>
<p>
I thought that was already the convention, but it was screwed up in this plot. I think that in general ticks on the right/top are okay, except where the axis is beyond the entire plot. Probably that isn't the case for this plot, but it still looks weird.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ol start="4"><li>compare plot(x<strong>4,-1,54) and plot(x</strong>4,-1,55). Notice how once the scientific notation comes into play, matplotlib doesn't label correctly.
</li></ol></blockquote>
<p>
As in the top is cut off? Is that what you are talking about?
</p>
<p>
We can change how the labels are printed pretty easily. What do you suggest?
</p>
</blockquote>
<p>
No, I mean that the labels are WRONG. The scientific notation only shows up at the very top e.g. 2e8 or something, and the rest are just 1, 1.5, etc; certainly the fourth power function does not stay around 1, 1.5 very long. Having 2e8 or 1.5e8 is okay, of course.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
That's all I found for now :) But it's nice to have some time to try to get this good. Assuming we actually want to do so, that is - is it more effort than its worth? Maybe the matplotlib upgrade could be a separate ticket, because that is certainly worthwhile and presumably doesn't cause any problems.
</p>
</blockquote>
<p>
This is great. I think we are close enough to being done with this (or at least, close enough to a sage-devel discussion) that it's not worth trying to package 0.99.0 separately. Most of the reason why 0.99.0 is worth it is for these changes, I think.
</p>
</blockquote>
<p>
Okay.
</p>
TicketjasonTue, 01 Sep 2009 17:34:24 GMT
https://trac.sagemath.org/ticket/5448#comment:30
https://trac.sagemath.org/ticket/5448#comment:30
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:29" title="Comment 29">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ol start="3"><li>there needs to be a slightly better algorithm for deciding what direction the ticks face. E.g. look at plot(x<strong>3,-1,0).
</strong></li></ol></blockquote>
<p>
Agreed. Do you have a suggestion? Maybe if the axis is in the middle of the picture, put ticks on both sides, and if it is on the side of the picture, put ticks facing inwards?
</p>
</blockquote>
<p>
I thought that was already the convention, but it was screwed up in this plot. I think that in general ticks on the right/top are okay, except where the axis is beyond the entire plot. Probably that isn't the case for this plot, but it still looks weird.
</p>
</blockquote>
<p>
Right now the convention was to put left-facing ticks unless the axis was beyond the plot on the right. Then put right-facing ticks. In your example, the axes were still considered to be inside the plot.
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ol start="4"><li>compare plot(x<strong>4,-1,54) and plot(x</strong>4,-1,55). Notice how once the scientific notation comes into play, matplotlib doesn't label correctly.
</li></ol></blockquote>
<p>
As in the top is cut off? Is that what you are talking about?
</p>
<p>
We can change how the labels are printed pretty easily. What do you suggest?
</p>
</blockquote>
<p>
No, I mean that the labels are WRONG. The scientific notation only shows up at the very top e.g. 2e8 or something, and the rest are just 1, 1.5, etc; certainly the fourth power function does not stay around 1, 1.5 very long. Having 2e8 or 1.5e8 is okay, of course.
</p>
</blockquote>
<p>
I think they mean that the number at the top of the axis shows the units of the labels. You would rather have labels in units of 1 always, I presume?
</p>
TicketkcrismanTue, 01 Sep 2009 17:56:25 GMT
https://trac.sagemath.org/ticket/5448#comment:31
https://trac.sagemath.org/ticket/5448#comment:31
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:30" title="Comment 30">jason</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/5448#comment:29" title="Comment 29">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ol start="3"><li>there needs to be a slightly better algorithm for deciding what direction the ticks face. E.g. look at plot(x<strong>3,-1,0).
</strong></li></ol></blockquote>
<p>
Agreed. Do you have a suggestion? Maybe if the axis is in the middle of the picture, put ticks on both sides, and if it is on the side of the picture, put ticks facing inwards?
</p>
</blockquote>
<p>
I thought that was already the convention, but it was screwed up in this plot. I think that in general ticks on the right/top are okay, except where the axis is beyond the entire plot. Probably that isn't the case for this plot, but it still looks weird.
</p>
</blockquote>
<p>
Right now the convention was to put left-facing ticks unless the axis was beyond the plot on the right. Then put right-facing ticks. In your example, the axes were still considered to be inside the plot.
</p>
</blockquote>
<p>
Because x=0 was in it... hmm, maybe that should be axis <= plot, instead of axis < plot? If that makes sense. This is obviously painting the shed, of course.
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ol start="4"><li>compare plot(x<strong>4,-1,54) and plot(x</strong>4,-1,55). Notice how once the scientific notation comes into play, matplotlib doesn't label correctly.
</li></ol></blockquote>
<p>
As in the top is cut off? Is that what you are talking about?
</p>
<p>
We can change how the labels are printed pretty easily. What do you suggest?
</p>
</blockquote>
<p>
No, I mean that the labels are WRONG. The scientific notation only shows up at the very top e.g. 2e8 or something, and the rest are just 1, 1.5, etc; certainly the fourth power function does not stay around 1, 1.5 very long. Having 2e8 or 1.5e8 is okay, of course.
</p>
</blockquote>
<p>
I think they mean that the number at the top of the axis shows the units of the labels. You would rather have labels in units of 1 always, I presume?
</p>
</blockquote>
<p>
Well, since the number at the top of the axis was getting cut off, that was a problem. I still think it could be confusing, though 1e200000 is probably not an ideal label if you got numbers that large (if they were even plottable). I like what happened before with
</p>
<pre class="wiki">sage: plot(x^4,-1,2000)
</pre><p>
better, though it was also sometimes inconsistent and things got cut off, for instance
</p>
<pre class="wiki">sage: plot(x^4,-1,1500)
</pre><p>
So it seems that explicit and longer is better than implicit and shorter, in this case.
</p>
<p>
Maybe it's time to start declaring this reviewed and make new tickets for the other things...
</p>
TicketjasonTue, 01 Sep 2009 18:12:44 GMT
https://trac.sagemath.org/ticket/5448#comment:32
https://trac.sagemath.org/ticket/5448#comment:32
<p>
Matplotlib has very nice pluggable formatting framework for ticks. The standard formatter is this one: <a class="ext-link" href="http://matplotlib.sourceforge.net/api/ticker_api.html#matplotlib.ticker.ScalarFormatter"><span class="icon"></span>http://matplotlib.sourceforge.net/api/ticker_api.html#matplotlib.ticker.ScalarFormatter</a> We can set it not to use scientific notation, or set the cutoff, or write our own. Or we could use the <a class="missing wiki">FuncFormatter?</a> with our own (user-overridable) function. Or we could just let the user pass a printf-style format string and use another matplotlib pluggable formatter. Some examples are:
</p>
<p>
<a class="ext-link" href="http://matplotlib.sourceforge.net/examples/pylab_examples/newscalarformatter_demo.html"><span class="icon"></span>http://matplotlib.sourceforge.net/examples/pylab_examples/newscalarformatter_demo.html</a>
</p>
<p>
<a class="ext-link" href="http://matplotlib.sourceforge.net/examples/pylab_examples/custom_ticker1.html"><span class="icon"></span>http://matplotlib.sourceforge.net/examples/pylab_examples/custom_ticker1.html</a>
</p>
<p>
I think that once the matplotlib people get back to me about fixing the bug or my misunderstanding where axis labels aren't correct for top or right axes, we can post some images to sage-devel and move this forward on a vote.
</p>
TicketkcrismanTue, 01 Sep 2009 18:53:42 GMT
https://trac.sagemath.org/ticket/5448#comment:33
https://trac.sagemath.org/ticket/5448#comment:33
<p>
Incidentally, there are a HUGE slew of error messages, largely in sage/combinat, when doing sage -t, which all look like this:
</p>
<pre class="wiki"> doctest:18: DeprecationWarning:
**********************************************************
matplotlib.numerix and all its subpackages are deprecated.
They will be removed soon. Please use numpy instead.
**********************************************************
<BLANKLINE>
</pre><p>
I'm not interested in doing that patch! But it should only be tedious, not hard... unless someone removes sage/combinat's dependence on numerix. But that's for another ticket.
</p>
TicketkcrismanTue, 01 Sep 2009 19:02:24 GMT
https://trac.sagemath.org/ticket/5448#comment:34
https://trac.sagemath.org/ticket/5448#comment:34
<p>
See also <a class="ext-link" href="https://networkx.lanl.gov/trac/ticket/258"><span class="icon"></span>https://networkx.lanl.gov/trac/ticket/258</a>, where the networkx folks fix this (the new mpl leads to lots of test failures in sage/graphs, too, unfortunately...)
</p>
TicketjasonTue, 01 Sep 2009 19:08:24 GMT
https://trac.sagemath.org/ticket/5448#comment:35
https://trac.sagemath.org/ticket/5448#comment:35
<p>
Ugh. For now, I say we disable the deprecation warning. I'm not looking forward to upgrading networkx at the moment---that's a bigger job.
</p>
TicketjasonTue, 01 Sep 2009 19:13:52 GMT
https://trac.sagemath.org/ticket/5448#comment:36
https://trac.sagemath.org/ticket/5448#comment:36
<p>
Actually, my guess is that all of these errors come from networkx. We could apply the networkx patch changeset you point out above to our networkx spkg and it seems like all would be well.
</p>
TicketjasonTue, 01 Sep 2009 19:24:40 GMT
https://trac.sagemath.org/ticket/5448#comment:37
https://trac.sagemath.org/ticket/5448#comment:37
<p>
Okay, I updated the networkx spkg. Please install:
</p>
<p>
<a class="ext-link" href="http://sage.math.washington.edu/home/jason/networkx-0.99.p1-fake_really-0.36.p1.spkg"><span class="icon"></span>http://sage.math.washington.edu/home/jason/networkx-0.99.p1-fake_really-0.36.p1.spkg</a>
</p>
TicketjasonTue, 01 Sep 2009 22:35:40 GMTattachment set
https://trac.sagemath.org/ticket/5448
https://trac.sagemath.org/ticket/5448
<ul>
<li><strong>attachment</strong>
set to <em>trac-5448-matplotlib-axes-gridlines.patch</em>
</li>
</ul>
<p>
apply instead of previous patch.
</p>
TicketjasonTue, 01 Sep 2009 23:41:22 GMTauthor set
https://trac.sagemath.org/ticket/5448#comment:38
https://trac.sagemath.org/ticket/5448#comment:38
<ul>
<li><strong>author</strong>
set to <em>Jason Grout</em>
</li>
</ul>
<p>
I posted a long post to sage-devel calling for comment and a vote on this axes placement strategy. The post is here: <a class="ext-link" href="http://groups.google.com/group/sage-devel/browse_thread/thread/5ad2b32d68bf8b87"><span class="icon"></span>http://groups.google.com/group/sage-devel/browse_thread/thread/5ad2b32d68bf8b87</a>
</p>
TicketkcrismanWed, 02 Sep 2009 14:08:26 GMTsummary changed
https://trac.sagemath.org/ticket/5448#comment:39
https://trac.sagemath.org/ticket/5448#comment:39
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, needs work] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em> to <em>[with patch, positive review] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em>
</li>
</ul>
<p>
I can't figure out how to make transparent=True work (some pics would be nice for you to post). But it doesn't break anything, so based on the devel discussion, let's get this in - everything works more or less as well as I can help right now.
</p>
<p>
Things to think about: Note there are some mpl warnings about numerix and other deprecated things (e.g., legend.handlelen) when you start up the notebook. Make sure that <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/260" title="enhancement: Background color and opacity of graphics output (needs_work)">#260</a> works off this patch, as mpatel has indicated willingness to do.
</p>
<p>
Note to release manager: needs both new matplotlib AND new networkx spkgs in order to avoid many, many deprecation warnings.
</p>
TicketschymansWed, 02 Sep 2009 15:22:14 GMT
https://trac.sagemath.org/ticket/5448#comment:40
https://trac.sagemath.org/ticket/5448#comment:40
<p>
It seems that the problem of cutting off axes labels of large numbers is just a matter of when the axis switches to scientific notation. Consider this:
</p>
<p>
<code>sage: plot(2^(20*x),(x,1,2.))</code>
</p>
<p>
Only numbers > 1.e+11 are converted to scientific notation, while the smaller ones get cut off. This could be fixed by changing to scientific notation at much smaller numbers. Actually, the change from decimal to scientific notation half way across the axis is something that bothered me in MMA already. Could you either let the user decide which notation to use or make it the same for the whole axis, depending on whether the largest (or smallest) number requires it?
</p>
<p>
Just a few ideas for when you get to fixing the matplotlib tick stuff.
</p>
<p>
Cheers
Stan
</p>
TicketjasonWed, 02 Sep 2009 16:34:05 GMT
https://trac.sagemath.org/ticket/5448#comment:41
https://trac.sagemath.org/ticket/5448#comment:41
<p>
Both of you, please make sure you are using the most recent version of the patch (from around the time I posted to sage-devel). Sorry for the rapid iteration---your feedback has very helpful.
</p>
<ol><li>Transparency: this should just be an option to show now, so this should work:
</li></ol><pre class="wiki">sage: plot(x^2, (x, 0, 1), transparent=True)
</pre><p>
Of course, in a web browser, you will "see" a white background through the image. If you save the image, you can "see" the transparent background. Your viewer may not be showing you the transparency easily.
</p>
<ol start="2"><li>Deprecations: Just delete (or update) your .sage/matplotlibrc file. If you haven't touched that file, then deleting it is fine.
</li></ol><ol start="3"><li>scientific notation: I switched to using the "old" matplotlib tick formatter in the most recent patch. I'm not on a computer that has 4.1.1, so I can't test what you are seeing at the moment. In any case, it will be really easy to do whatever you want with formatting ticks once this patch goes in.
</li></ol>
TicketjasonWed, 02 Sep 2009 16:35:29 GMTsummary changed
https://trac.sagemath.org/ticket/5448#comment:42
https://trac.sagemath.org/ticket/5448#comment:42
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, positive review] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em> to <em>[with patch, needs work] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em>
</li>
</ul>
<p>
Oh, based on the problems I mentioned in the sage-devel thread, I'm not quite comfortable with this going in yet, unless there's an understanding that there is a fix-up patch before the next release. So I'm changing this back to "needs work" for now. I hope that by the weekend, the issues will be resolved.
</p>
TicketjasonWed, 02 Sep 2009 16:51:27 GMT
https://trac.sagemath.org/ticket/5448#comment:43
https://trac.sagemath.org/ticket/5448#comment:43
<p>
And one more thing needs to be done: documentation! (for the new functions added, and check the documentation for functions that were changed).
</p>
TicketjasonSat, 05 Sep 2009 03:39:28 GMTdescription changed
https://trac.sagemath.org/ticket/5448#comment:44
https://trac.sagemath.org/ticket/5448#comment:44
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/5448?action=diff&version=44">diff</a>)
</li>
</ul>
TicketjasonSat, 05 Sep 2009 03:54:34 GMTattachment set
https://trac.sagemath.org/ticket/5448
https://trac.sagemath.org/ticket/5448
<ul>
<li><strong>attachment</strong>
set to <em>trac-5448-matplotlib-axes-gridlines.2.patch</em>
</li>
</ul>
<p>
apply instead of previous patches
</p>
TicketjasonSat, 05 Sep 2009 04:12:35 GMTattachment set
https://trac.sagemath.org/ticket/5448
https://trac.sagemath.org/ticket/5448
<ul>
<li><strong>attachment</strong>
set to <em>trac-5448-matplotlib-axes-gridlines.3.patch</em>
</li>
</ul>
TicketjasonSat, 05 Sep 2009 05:15:53 GMT
https://trac.sagemath.org/ticket/5448#comment:45
https://trac.sagemath.org/ticket/5448#comment:45
<p>
I am deleting the following code from the patch because it is not used right now. If in the future we want to have more control over the size of the figure, but still want to automatically shrink the plot to fit everything (labels, etc.) inside of the figure without clipping them, then the following code will prove useful. I'm pasting the code here so that it is some sort of permanent record.
</p>
<p>
This is an extension of an idea in the matplotlib FAQ.
</p>
<pre class="wiki"># Put the following somewhere in your routine that saves the file, after you've created the FigureCanvas object, but before you've actually saved the canvas.
#canvas.mpl_connect('draw_event', on_draw)
def on_draw(event):
"""
TODO: write documentation
"""
import matplotlib.transforms as mtransforms
figure=event.canvas.figure
bboxes = []
for ax in figure.axes:
bbox = ax.xaxis.get_label().get_window_extent()
# the figure transform goes from relative coords->pixels and we
# want the inverse of that
bboxi = bbox.inverse_transformed(figure.transFigure)
bboxes.append(bboxi)
bbox = ax.yaxis.get_label().get_window_extent()
bboxi = bbox.inverse_transformed(figure.transFigure)
bboxes.append(bboxi)
for label in (ax.get_xticklabels()+ax.get_yticklabels() \
+ ax.get_xticklabels(minor=True) \
+ax.get_yticklabels(minor=True)):
bbox = label.get_window_extent()
bboxi = bbox.inverse_transformed(figure.transFigure)
bboxes.append(bboxi)
# this is the bbox that bounds all the bboxes, again in relative
# figure coords
bbox = mtransforms.Bbox.union(bboxes)
adjusted=adjust_figure_to_contain_bbox(figure,bbox)
if adjusted:
figure.canvas.draw()
return False
def adjust_figure_to_contain_bbox(fig, bbox):
"""
TODO: write documentation
"""
adjusted=False
if bbox.xmin<0:
fig.subplots_adjust(left=fig.subplotpars.left-bbox.xmin)
adjusted=True
if bbox.ymin<0:
fig.subplots_adjust(bottom=fig.subplotpars.bottom-bbox.ymin)
adjusted=True
if bbox.xmax>1:
fig.subplots_adjust(right=fig.subplotpars.right-(bbox.xmax-1))
adjusted=True
if bbox.ymax>1:
fig.subplots_adjust(top=fig.subplotpars.top-(bbox.ymax-1))
adjusted=True
return adjusted
</pre>
TicketjasonSat, 05 Sep 2009 09:01:40 GMTattachment set
https://trac.sagemath.org/ticket/5448
https://trac.sagemath.org/ticket/5448
<ul>
<li><strong>attachment</strong>
set to <em>trac-5448-matplotlib-axes-gridlines.4.patch</em>
</li>
</ul>
<p>
apply instead of previous patches
</p>
TicketjasonSat, 05 Sep 2009 09:04:08 GMTdescription, summary changed
https://trac.sagemath.org/ticket/5448#comment:46
https://trac.sagemath.org/ticket/5448#comment:46
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/5448?action=diff&version=46">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>[with patch, needs work] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em> to <em>[with patch, needs review] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em>
</li>
</ul>
<p>
I believe I've taken care of all outstanding issues, so this patch is ready to be (re-)reviewed.
</p>
TicketjasonSat, 05 Sep 2009 09:10:05 GMT
https://trac.sagemath.org/ticket/5448#comment:47
https://trac.sagemath.org/ticket/5448#comment:47
<p>
I've moved Mike's plot.patch to <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/6893" title="enhancement: [with patch, needs work] Plotting code improvements (needs_work)">#6893</a>, so that patch can be deleted from this ticket. In fact, all patches except for trac-5448-matplotlib-axes-gridlines.4.patch can be deleted from this ticket.
</p>
TicketkcrismanSun, 06 Sep 2009 02:37:37 GMTsummary changed
https://trac.sagemath.org/ticket/5448#comment:48
https://trac.sagemath.org/ticket/5448#comment:48
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, needs review] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em> to <em>[with patch, positive review] rework save/show in plot, use Matplotlib's axes code, upgrade matplotlib</em>
</li>
</ul>
<p>
Positive review - behaves as advertised after actually viewing many, many of the plots in the sage/plot/ directory, and testing on a few others which had given trouble before.
</p>
<p>
I look forward to doing custom axes soon; perhaps that should be wrapped, and then a few other tickets could be closed. These might include (not just axes-related, and not necessarily, but worth checking into) <a class="closed ticket" href="https://trac.sagemath.org/ticket/6548" title="enhancement: Improve tasteful ticks documentation (closed: fixed)">#6548</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/5645" title="defect: error in axis plotting with large values (closed: fixed)">#5645</a>, <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/5128" title="enhancement: [with patch, needs work] matplotlib Graphics() wrapper (needs_work)">#5128</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/4689" title="defect: save method for graphics objects does not have an example explicitly ... (closed: fixed)">#4689</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/4384" title="defect: Axes computation for constant function causes division by zero (closed: fixed)">#4384</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/4194" title="defect: pylab plots cut off (closed: fixed)">#4194</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/2900" title="defect: [with patch, positive review] matplotlib bug in imshow (probably fixed ... (closed: fixed)">#2900</a>, <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/2189" title="enhancement: [with patch, needs work] improve functionality of matrix_plot (needs_work)">#2189</a>, and <a class="closed ticket" href="https://trac.sagemath.org/ticket/1431" title="enhancement: basic plotting: add support for setting the location and labels of all ... (closed: fixed)">#1431</a>. Good things; transparent definitely DOES now work, complex plots and matrix plots look better because they're "set off" a bit, etc.
</p>
<p>
Here are things to address in a follow-up ticket, at least maybe:
</p>
<p>
Contour plot - if fill=False and contours are grayscale, the axes could be misinterpreted
</p>
<p>
Contour plot - show(axes=False) and show(axes=True) seem to be identical on the last example
</p>
<p>
Plotting - how well documented is the new axis behavior, where it does NOT intersect? This should be clear, e.g. the Riemann zeta example in plot.py looks funny, until you realize it's from 1 to 27. It still seems weird to me when it's that close, but I suppose it's okay as long as it is very very clear in documentation.
</p>
<p>
Axis labels - should point out difference between ['x','y'] and ['$x$','$y$']. Some people might not like the <a class="missing wiki">LaTeXed?</a> version
</p>
<p>
When scientific notation comes into play is not always clear, and should be in the documentation - compare plot(x<strong>2, 490,500) and plot(x</strong>2,-490,500), which have the same "height" but only one gets e, presumably since it covers a larger range
</p>
TicketmvnguMon, 07 Sep 2009 18:25:56 GMTstatus changed; reviewer, resolution, merged set
https://trac.sagemath.org/ticket/5448#comment:49
https://trac.sagemath.org/ticket/5448#comment:49
<ul>
<li><strong>status</strong>
changed from <em>assigned</em> to <em>closed</em>
</li>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>Sage 4.1.2.alpha1</em>
</li>
</ul>
<p>
Merged <code>trac-5448-matplotlib-axes-gridlines.4.patch</code>. The updated packages <code>matplotlib-0.99.0.spkg</code> and <code>networkx-0.99.p1-fake_really-0.36.p1.spkg</code> are merged in the standard packages repository.
</p>
Ticket