matplotlib-users Mailing List for matplotlib

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

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

Johann,

Jouni K. Seppänen wrote:
> "Werner F. Bruhin" <wer...@fr...> writes:
>
>   
>>>> Actually, I have other problems : I cannot save in many formats. The
>>>> bmp is deemed usueless by gimp,
>>>>         
>>> I didn't even know you can save in bmp format. Does png format work
>>> better?
>>>   
>>>       
>> .png works for me and GIMP does not complain when opening the
>> generated png file.
>>     
>
> Could you file a bug about the bmp problem at 
>
> http://sf.net/tracker/?group_id=80706&atid=560720
>
> so it doesn't get overlooked? Please include a short example script
> and the error message from Gimp. Thanks for reporting the problem!
>   
I think you had the problem with the bmp file.  Could you do the bug report?

Werner

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

"johann cohen-tanugi" <joh...@gm...> writes:

> Actually, I have other problems : I cannot save in many formats. The
> bmp is deemed usueless by gimp,

I didn't even know you can save in bmp format. Does png format work
better?

> and ps and eps save options gives the following
> error message (I am using matplotlib-0.90 on python/ipython 2.4) :
> In [1]: show()
> ---------------------------------------------------------------------------
> exceptions.ValueError                                Traceback (most recent
> call  last)
 [...]
> /usr/lib/python2.4/site-packages/matplotlib/mathtext.py in _get_info(self,
> font,  sym, fontsize, dpi)
>    748             num = 0
>    749             sym = '.notdef'
> --> 750             raise ValueError('unrecognized symbol "%s, %d"' % (sym,
> num) )
>    751         filename = os.path.join(self.basepath, basename) + '.ttf'
>    752         if filename not in bakoma_fonts:
>
> ValueError: unrecognized symbol ".notdef, 0"

Not a very useful error message, given that it sets the values of the
sym and num variables just before reporting the error. In current svn
the line corresponding to your 749 is commented out, so if you could
try either with the svn version or just comment out the line in your
version, you would get a more useful diagnostic. The code looks like

        if latex_to_bakoma.has_key(sym): ...
        elif len(sym) == 1: ...
        else: ... raise ValueError(...)

so it looks like you have used a symbol that mathtext doesn't know
about and that isn't a single letter. I'm guessing that could mean a
misspelled backslash command or a parsing problem like I mentioned in
my previous email where "\tilde{}" is seen as "\tild".

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"johann cohen-tanugi" <joh...@gm...> writes:

> If I do r'$A\tilde{B}$'  the tilde is actually on the A !! 

It doesn't do that for me. Either this has been fixed between your
question and now, or it depends on the specifics of your environment.
The following simple test puts the tilde on B in both cases:

In [22]:rcParams['text.usetex']
Out[22]:False

In [23]:text(0,0,r'$A\tilde{B}$')
Out[23]:<matplotlib.text.Text instance at 0x17b814e0>

In [24]:text(1,0,r'$A\tilde B$')
Out[24]:<matplotlib.text.Text instance at 0x17b81508>

This is with the TkAgg backend and current svn version of matplotlib.
What does this experiment produce for you?

However, the following might be considered a bug:

In [28]:text(1,1,r'$A\tilde{}B$')
---------------------------------------------------------------------------
exceptions.ValueError                                Traceback (most recent call last)

/private/tmp/<ipython console> 
  ...
ValueError: unrecognized symbol "\tild"

I think John Hunter once said that Matplotlib's mathtext attempts to
support a subset of LaTeX syntax, and any inconsistencies within that
subset should be considered bugs. Admittedly it doesn't seem very
likely that someone wants to but a raised tilde between two letters,
but the error message indicates that the parsing is somehow very
different from TeX.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi all,

In June '06, there was a short discussion on getting images displayed on log 
axes (thread: "showing an image on log axes?").  John Hunter posted this 
example code:

from pylab import figure, show, nx
fig = figure()
ax = fig.add_subplot(111)
im = nx.mlab.rand(500,500)
ax.imshow(im, extent=(1,501,1,501))
ax.set_xscale('log')
ax.set_yscale('log')
show()

This works, until one tries to change the display limits:

ax.set_xlim(.1, 1e3)
ax.set_ylim(.1, 1e3)
show()

The image is incorrectly drawn in the corner of the axes, instead of in the 
rectangular region defined by the image's extent.  I think this is a bug (as 
of r3166).

I've been trying to get around this problem with existing code, including the 
use of NonUniformImage()s.  Perhaps it would be useful to have a 
general-purpose image class, something like a DataImage (rather than an 
AxesImage) that is similar to the NonUniformImage but respects 
transformations from data to axes coordinates (and could be used in log or 
polar plots).  Something for the wishlist.

Mike

On 4/6/07, Eric Firing <ef...@ha...> wrote:

> The size argument, s, is given in squared points; that is, it is a
> measure of area, not of linear dimensions.
>
> This strikes me as counterintuitive and not particularly useful.  It
> seems more natural that the size be a linear dimension; if a user wants
> size to vary with area, the user can pass in the square root of the area.
>
> Would anyone object to this change?  How strenuously?  I am not actually

This strikes me as a foolish consistency that may be best to live
with.  The basic scatter signature is the same as matlab's, which also
uses size in points squared.  It has never been intuitive to me
either, but I simply slavishly followed their convention.  By now we
have three constituencies who may find a change  irksome: current
users who have written code around the long-standing implementation,
prospective users coming from matlab who will find it confusing that
the signature is otherwise the same as matlab's but the size argument
is different, and developers who have to update the code, the
examples, the website screenshots, and the user's guide.

Since this irksome, somewhat counter-intuitive feature is well
documented, it seems preferable to me to let people simply square
their sizes for scatter and not break anyone's code.  It's not too
hard to do

  r = 10*rand(20)  # radii
  scatter(x, y, 2*pi*r**2)

Maybe we should simply add an example like the one above to the docstring.

Now there are those who are dusting off their pens as I type, getting
ready to point out that we should not slavishly follow matlab but
rather do the best thing possible.  Fair enough.  But we should also
be hesitant to break the API and existing code to fix a minor
annoyance that is easy to work around.  I think one thing that has
contributed to the success of matplotlib is that the API has been
extremely stable.

Code written against mpl 0.1 for the most part still runs, though
maybe an import statement needs to be changed (replace
matplotlib.matlab with matplotlib.pylab).  The major reason for this
is that we emulated matlab's API from the start.  In many cases we've
extended the matlab functionality significantly, particularly with all
of the stuff we do with keyword args, but we have rarely if ever
removed matlab compatibility once it was in place.  Hence people who
wrote their code against the original matlab-like API can still use
their code now.

JDH

In the course of responding to a request regarding the color handling in 
Axes.scatter and pylab.scatter, I decided to raise a more general 
question for input from users:

The scatter method has the following signature:


     def scatter(self, x, y, s=20, c='b', marker='o', cmap=None, norm=None,
                     vmin=None, vmax=None, alpha=1.0, linewidths=None,
                     faceted=True, verts=None,
                     **kwargs):

The size argument, s, is given in squared points; that is, it is a 
measure of area, not of linear dimensions.

This strikes me as counterintuitive and not particularly useful.  It 
seems more natural that the size be a linear dimension; if a user wants 
size to vary with area, the user can pass in the square root of the area.

Would anyone object to this change?  How strenuously?  I am not actually 
all that eager to make the change right now myself, so if someone else 
wants to do it, that is fine.  But in the interests of having mpl 
converge on an API that is easy to use and doesn't surprise people any 
more than necessary, I think this change is needed.

If the change is made, some mechanism could be used to provide a gradual 
changeover so that existing code specifying the squared points would not 
suddenly break without warning.

Comments, please.

Eric