Sage: Ticket #10980: Make sure symbolic gridline values are okay
https://trac.sagemath.org/ticket/10980
<p>
From <a class="ext-link" href="http://ask.sagemath.org/question/454/can-gridlines-be-painted-at-sqrt2"><span class="icon"></span>this ask.sagemath.org question</a>.
</p>
<pre class="wiki">plot(x,0,2,gridlines=([sqrt(2)],[]))
</pre><p>
blows up.
</p>
<p>
The fix is probably to make sure that symbolic input with a <code>n()</code> method passes something right to matplotlib, which of course cannot handle <code>sqrt(2)</code>. Possibly beginner ticket.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/10980
Trac 1.1.6kcrismanTue, 22 Mar 2011 14:18:30 GMTcc changed
https://trac.sagemath.org/ticket/10980#comment:1
https://trac.sagemath.org/ticket/10980#comment:1
<ul>
<li><strong>cc</strong>
<em>dsm</em> added
</li>
</ul>
<p>
Update: perhaps this is something that could be considered an upstream bug - or a bug that we give a <code>len()</code> to symbolic expressions, see DSM's answer in the question.
</p>
TicketkcrismanWed, 23 Mar 2011 12:13:04 GMTupstream changed
https://trac.sagemath.org/ticket/10980#comment:2
https://trac.sagemath.org/ticket/10980#comment:2
<ul>
<li><strong>upstream</strong>
changed from <em>N/A</em> to <em>Not yet reported upstream; Will do shortly.</em>
</li>
</ul>
<p>
Update: From the question, Jason says
</p>
<pre class="wiki">I think matplotlib should check for iterability by either: calling iter(obj) and checking for a TypeError, or doing isinstance(obj, collections.Iterable).
</pre><p>
Changing to 'not yet reported upstream'.
</p>
TicketkcrismanWed, 23 Mar 2011 12:13:55 GMT
https://trac.sagemath.org/ticket/10980#comment:3
https://trac.sagemath.org/ticket/10980#comment:3
<p>
We'll still have to include a fix, of course; an mpl change will just make sure the error is caught earlier by them, but we should be making sure we turn sqrt(2) into something plottable.
</p>
TicketjasonWed, 23 Mar 2011 15:15:53 GMTupstream changed
https://trac.sagemath.org/ticket/10980#comment:4
https://trac.sagemath.org/ticket/10980#comment:4
<ul>
<li><strong>upstream</strong>
changed from <em>Not yet reported upstream; Will do shortly.</em> to <em>Reported upstream. Little or no feedback.</em>
</li>
</ul>
<p>
It is reported: <a class="ext-link" href="http://thread.gmane.org/gmane.comp.python.matplotlib.devel/10009"><span class="icon"></span>http://thread.gmane.org/gmane.comp.python.matplotlib.devel/10009</a>
</p>
TicketmdboomThu, 24 Mar 2011 00:41:04 GMT
https://trac.sagemath.org/ticket/10980#comment:5
https://trac.sagemath.org/ticket/10980#comment:5
<p>
Committed to matplotlib master here:
</p>
<p>
<a class="ext-link" href="https://github.com/matplotlib/matplotlib/commit/0a9e86a91d9cb180919b99363cea1839a8f6196c"><span class="icon"></span>https://github.com/matplotlib/matplotlib/commit/0a9e86a91d9cb180919b99363cea1839a8f6196c</a>
</p>
<p>
Since this has a likelihood of accidental breakage, this is not on the bugfix branch.
</p>
TicketdsmThu, 24 Mar 2011 16:51:00 GMTupstream changed
https://trac.sagemath.org/ticket/10980#comment:6
https://trac.sagemath.org/ticket/10980#comment:6
<ul>
<li><strong>upstream</strong>
changed from <em>Reported upstream. Little or no feedback.</em> to <em>N/A</em>
</li>
</ul>
<p>
So what now? This bug had three causes: (1) we weren't passing floats, (2) symbolic expressions have a <code>__len__</code> even though they probably shouldn't, and (3) matplotlib used a suboptimal way of determining iterability. If any of those three didn't fire then there's no bug..
</p>
<p>
(3) is fixed upstream and we'll eventually pick it up, which leaves (1) and (2). Should we fix (1) here and open a new ticket to fix (2)?
</p>
TicketkcrismanThu, 24 Mar 2011 17:01:50 GMTupstream changed
https://trac.sagemath.org/ticket/10980#comment:7
https://trac.sagemath.org/ticket/10980#comment:7
<ul>
<li><strong>upstream</strong>
changed from <em>N/A</em> to <em>Fixed upstream, but not in a stable release.</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10980#comment:6" title="Comment 6">dsm</a>:
</p>
<blockquote class="citation">
<p>
So what now? This bug had three causes: (1) we weren't passing floats, (2) symbolic expressions have a <code>__len__</code> even though they probably shouldn't, and (3) matplotlib used a suboptimal way of determining iterability. If any of those three didn't fire then there's no bug..
</p>
<p>
(3) is fixed upstream and we'll eventually pick it up, which leaves (1) and (2). Should we fix (1) here and open a new ticket to fix (2)?
</p>
</blockquote>
<p>
Yes, we fix (1) here. I don't think that (2) necessarily has to be fixed, as long as we're aware of it. It's presumably been around a while, and we'd have to deprecate it. Though of course <code>number_of_operands</code> is more accurate.
</p>
<pre class="wiki">sage: f(x)=x^2+1+sin(ln(x))
sage: len(f)
3
</pre><p>
seems reasonable...
</p>
<p>
Changing the upstream report. NA is only if literally NA. In this case, there were a couple things going on, so not NA; according to the post above, it's fixed but not yet in the bugfix branch i.e. stable release.
</p>
TicketdsmThu, 24 Mar 2011 17:39:33 GMT
https://trac.sagemath.org/ticket/10980#comment:8
https://trac.sagemath.org/ticket/10980#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10980#comment:7" title="Comment 7">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Changing the upstream report. NA is only if literally NA. In this case, there were a couple things going on, so not NA; according to the post above, it's fixed but not yet in the bugfix branch i.e. stable release.
</p>
</blockquote>
<p>
Oops! That wasn't intended. I couldn't decide if it counted as a stable or unstable release, and I guess I set it to NA instead of restoring it. [I find it surprisingly easy to make errors on trac. I think I've assigned a couple of tickets to myself now..]
</p>
<p>
As for the len issue, I'm inclined to agree with Jason that it should go. If there's no interpretation of iter(sqrt(x)) natural enough to be canonical, then IMHO len(sqrt(2)) shouldn't work either. OTOH if we think that it's natural that len(sqrt(2)) should be two, because len counts the operands, then list(sqrt(2)) should be list((sqrt(2)).operands()) and give [2, 1/2]. That goes against my instincts, because I'd assume that taking the len of an expression, or iterating over it, would work over the "terms" of an expression. But len(x) == 0, because there are no operations so there are no operands, which is completely consistent but isn't what I'd have expected.
</p>
<p>
I don't think it's important enough for me to learn how Sage deprecation policies work, though, given that I'm still having trouble counting colons. <code>:-)</code>
</p>
TicketkcrismanSun, 27 May 2012 06:46:39 GMT
https://trac.sagemath.org/ticket/10980#comment:9
https://trac.sagemath.org/ticket/10980#comment:9
<p>
This does actually work now, by the way.
</p>
<pre class="wiki">plot(x,0,2,gridlines=([sqrt(2)],[]))
</pre><p>
This doesn't resolve the issue of whether symbolic things should have a <code>len</code>.
</p>
<pre class="wiki">
def __len__(self):
"""
Returns the number of arguments of this expression.
EXAMPLES::
sage: var('a,b,c,x,y')
(a, b, c, x, y)
sage: len(a)
0
sage: len((a^2 + b^2 + (x+y)^2))
3
sage: len((a^2))
2
sage: len(a*b^2*c)
3
"""
return self.number_of_operands()
</pre><p>
But this has been in for at least three years (the Pynac switch).
</p>
TicketkcrismanSun, 27 May 2012 06:46:55 GMTupstream changed
https://trac.sagemath.org/ticket/10980#comment:10
https://trac.sagemath.org/ticket/10980#comment:10
<ul>
<li><strong>upstream</strong>
changed from <em>Fixed upstream, but not in a stable release.</em> to <em>Fixed upstream, in a later stable release.</em>
</li>
</ul>
Ticketjhonrubia6Thu, 21 Jan 2016 18:49:13 GMT
https://trac.sagemath.org/ticket/10980#comment:11
https://trac.sagemath.org/ticket/10980#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10980#comment:9" title="Comment 9">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
This does actually work now, by the way.
</p>
<pre class="wiki">plot(x,0,2,gridlines=([sqrt(2)],[]))
</pre><p>
This doesn't resolve the issue of whether symbolic things should have a <code>len</code>.
</p>
<pre class="wiki">
def __len__(self):
"""
Returns the number of arguments of this expression.
EXAMPLES::
sage: var('a,b,c,x,y')
(a, b, c, x, y)
sage: len(a)
0
sage: len((a^2 + b^2 + (x+y)^2))
3
sage: len((a^2))
2
sage: len(a*b^2*c)
3
"""
return self.number_of_operands()
</pre><p>
But this has been in for at least three years (the Pynac switch).
</p>
</blockquote>
<p>
so, should this go to a <em>closed</em> state? or instead go to a <em>need_work</em> state? in my opinion it should move to a sage-devel discussion before
</p>
TicketcturoMon, 05 Jun 2017 20:59:35 GMTkeywords deleted
https://trac.sagemath.org/ticket/10980#comment:12
https://trac.sagemath.org/ticket/10980#comment:12
<ul>
<li><strong>keywords</strong>
<em>beginner</em> removed
</li>
</ul>
<p>
I'm a beginner, and found this too hard!
</p>
TickettscrimTue, 06 Jun 2017 02:44:01 GMTupstream changed; keywords, milestone set
https://trac.sagemath.org/ticket/10980#comment:13
https://trac.sagemath.org/ticket/10980#comment:13
<ul>
<li><strong>keywords</strong>
<em>beginner</em> added
</li>
<li><strong>milestone</strong>
set to <em>sage-8.1</em>
</li>
<li><strong>upstream</strong>
changed from <em>Fixed upstream, in a later stable release.</em> to <em>N/A</em>
</li>
</ul>
<p>
This is fixed now, so it just needs a doctest added.
</p>
Ticket