From: Nils W. <nw...@ia...> - 2007-03-27 07:49:05
|
Hi all, The script available at http://projects.scipy.org/scipy/scipy/ticket/390 yields True parameters: (5.0, 1.0, -5.0), Guess parameters: (4.0, 1.5, -4.0) Optimization terminated successfully. Current function value: 33.309244 Iterations: 15 Function evaluations: 23 Gradient evaluations: 23 Bfgs: [ 5.2463809 1.00388921 -4.71114799] Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line 284, in expose_event self._render_figure(self._pixmap, w, h) File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", line 73, in _render_figure FigureCanvasAgg.draw(self) File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_agg.py", line 392, in draw self.figure.draw(renderer) File "/usr/lib64/python2.4/site-packages/matplotlib/figure.py", line 567, in draw for a in self.axes: a.draw(renderer) File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line 1281, in draw a.draw(renderer) File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line 208, in draw self._update_positions(renderer) File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line 570, in _update_positions ox, oy = self._find_best_position(w, h) File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line 440, in _find_best_position verts, bboxes, lines = self._auto_legend_data() File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line 357, in _auto_legend_data hlines = handle.get_lines() AttributeError: LineCollection instance has no attribute 'get_lines' Nils |
From: <jk...@ik...> - 2007-04-07 10:17:21
|
Nils Wagner <nw...@ia...> writes: > File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line > 357, in _auto_legend_data > hlines = handle.get_lines() > AttributeError: LineCollection instance has no attribute 'get_lines' It seems that get_lines() was removed from LineCollection in revision 2052 by Eric Firing: | r2052 | efiring | 2006-02-11 22:56:42 +0200 (Sat, 11 Feb 2006) | 3 lines | | Add autolim kwarg to axes.add_collection; change get_verts() | methods of collections accordingly. Perhaps Eric knows best how to fix _auto_legend_data()? -- Jouni K. Seppänen http://www.iki.fi/jks |
From: Eric F. <ef...@ha...> - 2007-04-07 19:42:36
|
Jouni K. Seppänen wrote: > Nils Wagner <nw...@ia...> writes: > >> File "/usr/lib64/python2.4/site-packages/matplotlib/legend.py", line >> 357, in _auto_legend_data >> hlines = handle.get_lines() >> AttributeError: LineCollection instance has no attribute 'get_lines' > > It seems that get_lines() was removed from LineCollection in revision > 2052 by Eric Firing: > > | r2052 | efiring | 2006-02-11 22:56:42 +0200 (Sat, 11 Feb 2006) | 3 lines > | > | Add autolim kwarg to axes.add_collection; change get_verts() > | methods of collections accordingly. > > Perhaps Eric knows best how to fix _auto_legend_data()? > It is fixed now in svn--to the extent that it ever was. I put back get_lines() in collections and fixed a related bug in legend, so the test script now works in the sense that it makes a legend. It puts in an unlabeled line, presumably corresponding to the line collection making up the error bars. Maybe legend provides a way to avoid this. I haven't looked. The larger problem, and the one that probably made me yank get_lines (without realizing the legend code was using it--my mistake--I do try to check for things like that) is that legend really wants to know the draw-time locations of all plot elements, and for collections (among other things) this cannot be determined in general. The collection get_lines and get_verts methods can give the right answer to legend only if the data and offset transforms are the same. Sometimes they are, sometimes they are not. LineCollection.get_lines() probably could be improved to do a better job than at present, but never a perfect one. This is an example of a more widespread problem that we have thought about and discussed (including some good ideas from John, of course), but solving it is not simple. For the time being, at least, we are stuck with some imperfections. In any case, thanks for bringing the legend/LineCollection bug to my attention. This is the sort of thing it is nice to get cleaned up before the next release, coming soon. Do you know of some other simple bugs like this we should look at ASAP? Eric |
From: John H. <jd...@gm...> - 2007-04-07 20:07:07
|
On 4/7/07, Eric Firing <ef...@ha...> wrote: > I put back get_lines() in collections and fixed a related bug in legend, > so the test script now works in the sense that it makes a legend. It > puts in an unlabeled line, presumably corresponding to the line > collection making up the error bars. Maybe legend provides a way to > avoid this. I haven't looked. If I'm understanding the problem you are describing correctly, it looks like _nolegend_ needs to be set here. For artists we do not want to be included in the legend, the label should be set to '_nolegend_' and legend will ignore it in auto-legending. Or at least it should and if it is not it is a bug. > The larger problem, and the one that probably made me yank get_lines > (without realizing the legend code was using it--my mistake--I do try to > check for things like that) is that legend really wants to know the > draw-time locations of all plot elements, and for collections (among > other things) this cannot be determined in general. The collection > get_lines and get_verts methods can give the right answer to legend only > if the data and offset transforms are the same. Sometimes they are, > sometimes they are not. LineCollection.get_lines() probably could be > improved to do a better job than at present, but never a perfect one. One approach is to make every artist provide a get window extent which returns a bounding box. There is the issue of how to get the renderer before draw time, but we could fix this. It would be nice for draw time layout algorithms to be able to assume this method, and a few objects already provide it, eg text. > This is an example of a more widespread problem that we have thought > about and discussed (including some good ideas from John, of course), > but solving it is not simple. For the time being, at least, we are > stuck with some imperfections. > > In any case, thanks for bringing the legend/LineCollection bug to my > attention. This is the sort of thing it is nice to get cleaned up > before the next release, coming soon. Do you know of some other simple > bugs like this we should look at ASAP? I added unit/legend_unit.py script to create legends using a scatter and vlines, which create RegPolyCollections and LineCollections. We should use more stuff like this in general, unit scripts which exercise the more arcane usages. JDH |
From: Eric F. <ef...@ha...> - 2007-04-08 01:51:03
|
John Hunter wrote: > On 4/7/07, Eric Firing <ef...@ha...> wrote: > >> I put back get_lines() in collections and fixed a related bug in legend, >> so the test script now works in the sense that it makes a legend. It >> puts in an unlabeled line, presumably corresponding to the line >> collection making up the error bars. Maybe legend provides a way to >> avoid this. I haven't looked. > > If I'm understanding the problem you are describing correctly, it > looks like _nolegend_ needs to be set here. For artists we do not want > to be included in the legend, the label should be set to '_nolegend_' > and legend will ignore it in auto-legending. Or at least it should > and if it is not it is a bug. I have made more changes in svn to fix this bug. The collection initializers, vlines, and hlines lacked label support, so I added it. errorbar() was already trying to set the line collection label to _nolegend_, but it was not getting passed on down the line. Eric |
From: <jk...@ik...> - 2007-04-08 03:25:42
|
Eric Firing <ef...@ha...> writes: > In any case, thanks for bringing the legend/LineCollection bug to my > attention. This is the sort of thing it is nice to get cleaned up > before the next release, coming soon. Do you know of some other simple > bugs like this we should look at ASAP? Of the bugs listed at http://sf.net/tracker/?group_id=80706&atid=560720 I suspect a few would be simple to fix: 1671570 Invalid CSS 2 styles in SVG output 1650523 inconsistent use of tabs and spaces in indentation 1605288 import pylab with python -OO -- Jouni K. Seppänen http://www.iki.fi/jks |
From: <jk...@ik...> - 2007-04-08 04:57:38
|
Jouni K. Seppänen <jk...@ik...> writes: > Eric Firing <ef...@ha...> writes: > >> Do you know of some other simple >> bugs like this we should look at ASAP? > > Of the bugs listed at http://sf.net/tracker/?group_id=80706&atid=560720 > I suspect a few would be simple to fix: Also I'm not at all sure that my solution to the Circle problem is correct: http://thread.gmane.org/gmane.comp.python.matplotlib.devel/2667/focus=2670 -- Jouni K. Seppänen http://www.iki.fi/jks |
From: Eric F. <ef...@ha...> - 2007-04-08 06:07:55
|
Jouni K. Seppänen wrote: > Jouni K. Seppänen <jk...@ik...> writes: > > Also I'm not at all sure that my solution to the Circle problem is > correct: > > http://thread.gmane.org/gmane.comp.python.matplotlib.devel/2667/focus=2670 > Your solution is correct; the docstring was wrong, and there were some other vestiges of an earlier implementation. I will have these cleaned up shortly. Eric |
From: Eric F. <ef...@ha...> - 2007-04-09 07:06:19
|
Jouni K. Seppänen wrote: > Eric Firing <ef...@ha...> writes: > >> In any case, thanks for bringing the legend/LineCollection bug to my >> attention. This is the sort of thing it is nice to get cleaned up >> before the next release, coming soon. Do you know of some other simple >> bugs like this we should look at ASAP? > > Of the bugs listed at http://sf.net/tracker/?group_id=80706&atid=560720 > I suspect a few would be simple to fix: > Thanks for the suggestions. > 1671570 Invalid CSS 2 styles in SVG output In this the invalid styles seem to be coming from freetype itself, as nearly as I can see. Someone who understands ft2font needs to look at this one. > 1650523 inconsistent use of tabs and spaces in indentation > 1605288 import pylab with python -OO I fixed these. I also closed a couple others. It would be nice to get many more of the bug reports closed; I think some are obsolete, but some are pointing to things that really should be fixed. I am out of time for a while, though; I need to work on other things. Eric |
From: John H. <jd...@gm...> - 2007-04-09 14:24:29
|
On 4/9/07, Eric Firing <ef...@ha...> wrote: > I also closed a couple others. It would be nice to get many more of the > bug reports closed; I think some are obsolete, but some are pointing to > things that really should be fixed. I am out of time for a while, > though; I need to work on other things. I think it is a good plan to try and knock out as many of these as possible before the next release. I'm pretty swamped until after next Monday because all my free time will be going to preparing for a python workshop with Fernando, but let's all try and do a bug or patch per day, and shoot for some time after Monday a week for Monday to do the release. In related news, Eric, I say you were working on the date format problem in the finance module. Just so everyone is on the same page, yahoo changed their output format to '%Y-%m-%d' so I changed the format string in the finance module. But people who have cached downloads in ~/.matplotlib/finance.cache will still have data in the old format. Eric made some changes to support both with a try/except, but at some point we'll want to remove that for performance reasons, so the best course is to flush your cache. JDH |
From: Eric F. <ef...@ha...> - 2007-04-09 18:01:27
|
John Hunter wrote: > On 4/9/07, Eric Firing <ef...@ha...> wrote: > >> I also closed a couple others. It would be nice to get many more of the >> bug reports closed; I think some are obsolete, but some are pointing to >> things that really should be fixed. I am out of time for a while, >> though; I need to work on other things. > > I think it is a good plan to try and knock out as many of these as > possible before the next release. I'm pretty swamped until after next > Monday because all my free time will be going to preparing for a > python workshop with Fernando, but let's all try and do a bug or patch > per day, and shoot for some time after Monday a week for Monday to do > the release. > In related news, Eric, I say you were working on the date format > problem in the finance module. Just so everyone is on the same page, > yahoo changed their output format to '%Y-%m-%d' so I changed the > format string in the finance module. But people who have cached > downloads in ~/.matplotlib/finance.cache will still have data in the > old format. Eric made some changes to support both with a try/except, > but at some point we'll want to remove that for performance reasons, > so the best course is to flush your cache. John, Thanks for the explanation. I made another change. It should still support both formats, but with only a single try/except to decide which format to use, so the performance penalty should be negligible. The advantage is that we won't get questions (as we have at least once) about "why doesn't finance_demo.py work?" Here are the relevant lines from finance.py (slightly mangled by the mailer, as usual): datefmt = None for line in lines[1:]: vals = line.split(',') if len(vals)!=7: continue datestr = vals[0] if datefmt is None: try: datefmt = '%Y-%m-%d' dt = datetime.date(*time.strptime(datestr, datefmt)[:3]) except ValueError: datefmt = '%d-%b-%y' # Old Yahoo--cached file? dt = datetime.date(*time.strptime(datestr, datefmt)[:3]) d = date2num(dt) Eric > > JDH |
From: Ted D. <ted...@jp...> - 2007-04-10 17:36:20
|
John, One of the problems we've had is trying to design an auto-scaling algorithm that works well with any type date format since the date strings can be so large horizontally. I believe that having the draw time elements be able to query the renderer for things would help this out tremendously since we could then have the tick generator space out the dates along nice boundaries without overlapping the date strings. Ted At 01:07 PM 4/7/2007, John Hunter wrote: >On 4/7/07, Eric Firing <ef...@ha...> wrote: > > > I put back get_lines() in collections and fixed a related bug in legend, > > so the test script now works in the sense that it makes a legend. It > > puts in an unlabeled line, presumably corresponding to the line > > collection making up the error bars. Maybe legend provides a way to > > avoid this. I haven't looked. > >If I'm understanding the problem you are describing correctly, it >looks like _nolegend_ needs to be set here. For artists we do not want >to be included in the legend, the label should be set to '_nolegend_' >and legend will ignore it in auto-legending. Or at least it should >and if it is not it is a bug. > > > The larger problem, and the one that probably made me yank get_lines > > (without realizing the legend code was using it--my mistake--I do try to > > check for things like that) is that legend really wants to know the > > draw-time locations of all plot elements, and for collections (among > > other things) this cannot be determined in general. The collection > > get_lines and get_verts methods can give the right answer to legend only > > if the data and offset transforms are the same. Sometimes they are, > > sometimes they are not. LineCollection.get_lines() probably could be > > improved to do a better job than at present, but never a perfect one. > >One approach is to make every artist provide a get window extent which >returns a bounding box. There is the issue of how to get the renderer >before draw time, but we could fix this. It would be nice for draw >time layout algorithms to be able to assume this method, and a few >objects already provide it, eg text. > > > This is an example of a more widespread problem that we have thought > > about and discussed (including some good ideas from John, of course), > > but solving it is not simple. For the time being, at least, we are > > stuck with some imperfections. > > > > In any case, thanks for bringing the legend/LineCollection bug to my > > attention. This is the sort of thing it is nice to get cleaned up > > before the next release, coming soon. Do you know of some other simple > > bugs like this we should look at ASAP? > > >I added unit/legend_unit.py script to create legends using a scatter >and vlines, which create RegPolyCollections and LineCollections. We >should use more stuff like this in general, unit scripts which >exercise the more arcane usages. > >JDH > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Matplotlib-users mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: Eric F. <ef...@ha...> - 2007-04-10 18:12:08
|
Ted Drain wrote: > John, > One of the problems we've had is trying to design an auto-scaling > algorithm that works well with any type date format since the date > strings can be so large horizontally. I believe that having the draw > time elements be able to query the renderer for things would help > this out tremendously since we could then have the tick generator > space out the dates along nice boundaries without overlapping the date strings. This is only half of the solution; the other half is controlling the order in which things are done. In its most general form, this would involve some sort of dependency tree, automatically generated. I imagine this is how layout engines work. I know that Andrew contributed one quite some time ago, and so far I have done nothing with it. (Sorry, Andrew.) A simpler mechanism suggested by John was a set of pre- and post- hooks in draw functions that would enable one to manually put in dependencies and ensure that dependent calculations are done in the right order. In all of this, it is critical to avoid chicken-and-egg situations: e.g., label font size depends on physical room available, but tick spacing adjusts to accommodate the labels. The transforms module already does part of what we are talking about here; dependency information is accumulated as BinOps are built from other BinOps, and everything is resolved at rendering time. I think that any changes like this need to wait in line behind the upcoming numpyfication, and it would be nice to have some full outlines of alternative strategies before picking one and proceeding. Ideas and strategy sketches tend to get lost in the email stack; would it help to have a wiki page for discussion of major design questions like this? Or is this overkill? Eric > > Ted > > At 01:07 PM 4/7/2007, John Hunter wrote: >> On 4/7/07, Eric Firing <ef...@ha...> wrote: >> >>> I put back get_lines() in collections and fixed a related bug in legend, >>> so the test script now works in the sense that it makes a legend. It >>> puts in an unlabeled line, presumably corresponding to the line >>> collection making up the error bars. Maybe legend provides a way to >>> avoid this. I haven't looked. >> If I'm understanding the problem you are describing correctly, it >> looks like _nolegend_ needs to be set here. For artists we do not want >> to be included in the legend, the label should be set to '_nolegend_' >> and legend will ignore it in auto-legending. Or at least it should >> and if it is not it is a bug. >> >>> The larger problem, and the one that probably made me yank get_lines >>> (without realizing the legend code was using it--my mistake--I do try to >>> check for things like that) is that legend really wants to know the >>> draw-time locations of all plot elements, and for collections (among >>> other things) this cannot be determined in general. The collection >>> get_lines and get_verts methods can give the right answer to legend only >>> if the data and offset transforms are the same. Sometimes they are, >>> sometimes they are not. LineCollection.get_lines() probably could be >>> improved to do a better job than at present, but never a perfect one. >> One approach is to make every artist provide a get window extent which >> returns a bounding box. There is the issue of how to get the renderer >> before draw time, but we could fix this. It would be nice for draw >> time layout algorithms to be able to assume this method, and a few >> objects already provide it, eg text. >> >>> This is an example of a more widespread problem that we have thought >>> about and discussed (including some good ideas from John, of course), >>> but solving it is not simple. For the time being, at least, we are >>> stuck with some imperfections. >>> >>> In any case, thanks for bringing the legend/LineCollection bug to my >>> attention. This is the sort of thing it is nice to get cleaned up >>> before the next release, coming soon. Do you know of some other simple >>> bugs like this we should look at ASAP? >> >> I added unit/legend_unit.py script to create legends using a scatter >> and vlines, which create RegPolyCollections and LineCollections. We >> should use more stuff like this in general, unit scripts which >> exercise the more arcane usages. >> >> JDH |
From: John H. <jd...@gm...> - 2007-04-10 18:14:08
|
On 4/10/07, Eric Firing <ef...@ha...> wrote: > Ideas and strategy sketches tend to get lost in the email stack; would > it help to have a wiki page for discussion of major design questions > like this? Or is this overkill? My preference is for (possibly structured) text documents in the svn repo, ala CODING_GUIDE |