matplotlib-devel Mailing List for matplotlib (Page 5)

Hi,

In my attempt to get scroll wheel zooming working for this release I added
support for the scroll wheel to TkAgg, and added support for draw_idle to
the wx backend.

I'm attaching the wheel zoom demonstration code.  This is standalone code
which is not yet ready to go into backend_bases.  It only supports linear
and log axes.  Using transform magic would be better here.  Also, colormap
zooming is hacked (I don't know how to determine if the axes contain a
colorbar, and what the corresponding mappable is, so I put a list of
colorbars in the figure).

In the process of developing this code I noticed that a lot of the contains
tests are broken by the new transforms.  Try attaching onHilite to the
motion notify event on any canvas --- objects should turn light blue as you
hover over them.

E.g.,

  from pylab import plot, gcf, show
  plot([1,2,3],[1,5,2])
  cvs = gcf().canvas
  cvs.mpl_connect('motion_notify_event',cvs.onHilite)
  show()

I can fixes the axis hit test.  I'm not sure how many other problems there
are, but I'm pretty sure I won't get to them all before next Tuesday.

   - Paul

David Kaplan wrote:
> The second patch is to pyplot.py to create a plotyy function.  This is
> like a matlab function of the same name that puts two curves with
> different y ranges on the same x axis.  It basically wraps the
> two_scales.py demo functionality with a bit of extra stuff.  I had to
> use a real hack to change the colors of the y axes.  Perhaps someone can
> think of a better way or perhaps this sub-function should be moved out
> of plotyy so it can be reused.  Also, I couldn't find a way to color the
> actual y-axis - i.e. the vertical line that is the y-axis.  Is there an
> easy way to do this?

Do you have an example of how to use this (or at least what the results 
look like)?  I'm having trouble seeing how this differs from twinx.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 25, 2008 at 10:09 AM, John Hunter <jd...@gm...> wrote:

> The problem is after the double colon in the following block::

David, I cleaned up a few more of these warnings.  I notice on most of
the functions you added to cbook, you added call signature lines, in
many cases where they are not needed.  I want to try and clarify where
they are needed.  If your function uses *args or **kwargs that pass
through, you want to give the user some idea what those are.  This is
most important in pylab, which pass the args and kwargs through to the
equivalent Axes method.  Since the pylab docstring just reads *args,
**kwargs, we use the Axes method of the same name to show the call
signature.  In general, you do not need to add these, especially if
your function declaration explicitly lists the args and keyword args,
so I have removed most of these.

Also, I would rather not put the geometry functions in cbook, eg
distances_along_curve and path_length and friends.  Perhaps we should
have some sort of geometry module where all these things live (there
are some in mlab as well) but barring that I would rather have
math/geometry stuff in mlab and general purpose helpers in cbook.
Let's move all those before the release so we don't have to worry
about API breakage later.

JDH

On Fri, Jul 25, 2008 at 10:42 AM, Sandro Tosi <mat...@gm...> wrote:

> Thanks! i've just downlaoded: is 55M tarball the real intended size?
> it seems a little too big... ;)

Argg, I forgot to svn clean before I did the sdist.  Please try again.

  http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz

The new file is under 6M

JDH

On Fri, Jul 25, 2008 at 5:23 AM, David Kaplan <Dav...@ir...> wrote:

> I have committed to SVN the change making twinx work like twiny.  As an
> aside, this would not be necessary if there was an easy after the fact
> way of sharing and unsharing axes (i.e., ax.set_shared_x_axes(ax2)).

Yes, the sharex attr should be set on twinx -- perhaps someone
commented this out while debugging and forgot to restore it.  I have
been known to make this mistake on more than one occasion, so thanks
for catching it.  As for the duplicated ticklabels, I think we should
make the ticklabels invisible for ax2

for tick in ax2.xaxis.get_major_ticks() + ax2.get_minor_ticks():
    tick.set_visible(False)

Are there any potential problems with this that you can see?
Obviously we would want to document and mention it in the CHANGELOG,
because it might affect some code that is using the twin axes to
configure tick labels, but it should be an easy fix for those users to
simply use the original axes and it will get it right in most cases
(no duplicate labels or ticks).

I agree that being able to set the sharex and sharey after the fact
would be useful.

JDH

Hi John,

On Thu, Jul 24, 2008 at 21:17, John Hunter <jd...@gm...> wrote:
> I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if
> the weekday doesn't work for you Charlie we might do a source release
> on Friday or Saturday (for Sandro/debian) and you can get the build

As usual, thanks for the huge support to Debian!

> Sandro, here is a release candidate tarball for you to test with:
> http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz

Thanks! i've just downlaoded: is 55M tarball the real intended size?
it seems a little too big... ;)

$ du * -hs | grep "[0-9]M"
2.8M    agg24
146M    doc
97M     examples
108M    lib

And there is a file I can't extract:

tar: matplotlib-0.98.3rc1/lib/matplotlib/delaunay/table.csv?s=^VIX:
Cannot open: No such file or directory

Some cleanup missing? ;)

Cheers,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Fri, Jul 25, 2008 at 2:48 AM, David Kaplan <Dav...@ir...> wrote:
> Hi,
>
> On Thu, 2008-07-24 at 13:08 -0700,
> mat...@li... wrote:
>> WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py:docstring
>> of matplotlib.axes.Axes.acorr:36: (ERROR/3) Unexpected indentation.
>> WARNING: <autodoc>:0: (ERROR/3) Unexpected indentation.
>> WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring
>> of
>> matplotlib.backend_bases.FigureCanvasBase.start_event_loop_default:15:
>> (WARNING/2) Literal block expected; none found.
>>
>
> I looked at my doc strings and as far as I can tell, they are identical
> in format to other functions around them.  What does this error mean?

The problem is after the double colon in the following block::

        This function provides default event loop functionality based
        on time.sleep that is meant to be used until event loop
        functions for each of the GUI backends can be written.  As
        such, it throws a deprecated warning.

        Call signature::

        start_event_loop_default(self,timeout=0)

you need to indent relative to the line containing the double colon, eg::

        Call signature::

            start_event_loop_default(self,timeout=0)

        This call blocks until a callback function triggers
        stop_event_loop() or *timeout* is reached.  If *timeout* is
        <=0, never timeout.

I went ahead and committed this change.
JDH

Hi,

Attached are two patch sets for you to review and comment on.  I am not
intending for these to go in this release.

One is the beginning of a patch set that lets you choose whether text
rotation angle is with respect to screen or axes coordinates.  The idea
is that you might want text that is properly rotated with respect to
some object in a plot (e.g., contours), as opposed to being at some
particular angle with respect to screen coordinates.  Along the way I
added a method to transforms.py that transforms angles at a location.
The method included is generic and not at all optimized for simple
linear transforms, but it works fairly well.  This transform might be
useful for other functions (e.g., quiver?).

This patch basically works.  For example, try the following:

plot(arange(5))
th = text(3,3,'abcd',rotation=45,rotationscreen=False)
th2 = text(2,2,'ABCD',rotation=45)

and then try changing the size of your plot window.  'abcd' doesn't
rotate with respect to the line as the window changes size, but 'ABCD'
does.  There are still some imperfections - the text seems to move above
or below the line - I am not sure why this is.  Also, I have no idea
whether I should be using unitless (self._x,_y) or unitful coordinates
(self.convert_(x|y)units) in the transformations.  Perhaps someone can
enlighten me.  It doesn't really matter until one tries non-linear
transformations (aka basemap).

I also haven't tried to integrate this into TextWithDash.  I imagine it
can be done, but I wasn't sure it was worth the effort since
TextWithDash is mostly used for axes ticks I believe.  I am thinking of
just forcing rotationscreen to True for this class.  Comments?

Once these issues are worked out, I would integrate this into contour.py
so that windows can be resized without affecting label rotation.

The second patch is to pyplot.py to create a plotyy function.  This is
like a matlab function of the same name that puts two curves with
different y ranges on the same x axis.  It basically wraps the
two_scales.py demo functionality with a bit of extra stuff.  I had to
use a real hack to change the colors of the y axes.  Perhaps someone can
think of a better way or perhaps this sub-function should be moved out
of plotyy so it can be reused.  Also, I couldn't find a way to color the
actual y-axis - i.e. the vertical line that is the y-axis.  Is there an
easy way to do this?

Cheers,
David

-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

On Thu, Jul 24, 2008 at 6:12 PM, Tony Yu <ts...@gm...> wrote:
> I noticed a couple of really minor typos as shown below:

Thanks Tony, committed to 5873

Hi,

I just noticed a bug in twinx/twiny in axes.py.  twinx has:

        ax2 = self.figure.add_axes(self.get_position(True), # sharex=self,
            frameon=False)

while twiny has:

        ax2 = self.figure.add_axes(self.get_position(True), sharey=self,
            frameon=False)

Therefore twiny will share the y axis, while twinx will not share the x
axis.  I am not sure what the "desired" behavior is, but one has to be
wrong.  As the principle use for this is making plots of two curves
sharing one axis, but different in the other, I imagine that the twiny
behavior is the desired one.  If not, then the following doesn't look
quite right:

from numpy import *
from matplotlib.pylab import *
x = linspace(0,pi,20)
y = sin(x)
x2 = x + 0.1 * randn(*x.shape)
y2 = 10 + y + 0.1 * randn(*y.shape)

a1 = gca()
plot(x,y) 

a2 = twinx()
plot(x2,y2, 'o')

The pylab_examples/two_scales.py only works because the two curves have
identical x values.

However, forcing them to share has the undesirable consequence that both
x-axes must have the same labels and formatting, producing overlayed
labels that are slightly noticeable.  

I have committed to SVN the change making twinx work like twiny.  As an
aside, this would not be necessary if there was an easy after the fact
way of sharing and unsharing axes (i.e., ax.set_shared_x_axes(ax2)).  

Cheers,
David

-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hi all,

Is there a way to use

title(r'$ M= I_3 K=\left[\begin{array}{rrr} 2\,k & -k & 0 
\\ -k & 2\,k+p & -(k+p) \\ 0 & -(k+p) & 
k+p\end{array}\right]$')

It currently fails with

Exception in Tkinter callback
Traceback (most recent call last):
   File 
"/data/home/nwagner/local/lib/python2.5/lib-tk/Tkinter.py", 
line 1403, in __call__
     return self.func(*args)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
line 202, in resize
     self.show()
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
line 205, in draw
     FigureCanvasAgg.draw(self)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 261, in draw
     self.figure.draw(self.renderer)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/figure.py", 
line 759, in draw
     for a in self.axes: a.draw(renderer)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/axes.py", 
line 1514, in draw
     a.draw(renderer)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/text.py", 
line 297, in draw
     bbox, info = self._get_layout(renderer)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/text.py", 
line 197, in _get_layout
     line, self._fontproperties, 
ismath=self.is_math_text(line))
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 135, in get_text_width_height_descent
     self.mathtext_parser.parse(s, self.dpi, prop)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py", 
line 2735, in parse
     box = self._parser.parse(s, font_output, fontsize, 
dpi)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py", 
line 2208, in parse
     self._expression.parseString(s)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 1048, in parseString
     loc, tokens = self._parse( instring, 0 )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 981, in _parseCache
     value = self._parseNoCache( instring, loc, doActions, 
callPreParse )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 924, in _parseNoCache
     loc,tokens = self.parseImpl( instring, preloc, 
doActions )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 2559, in parseImpl
     return self.expr._parse( instring, loc, doActions, 
callPreParse=False )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 981, in _parseCache
     value = self._parseNoCache( instring, loc, doActions, 
callPreParse )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 924, in _parseNoCache
     loc,tokens = self.parseImpl( instring, preloc, 
doActions )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 2307, in parseImpl
     loc, exprtokens = e._parse( instring, loc, doActions 
)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 981, in _parseCache
     value = self._parseNoCache( instring, loc, doActions, 
callPreParse )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 924, in _parseNoCache
     loc,tokens = self.parseImpl( instring, preloc, 
doActions )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 2672, in parseImpl
     loc, tokens = self.expr._parse( instring, loc, 
doActions, callPreParse=False )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 981, in _parseCache
     value = self._parseNoCache( instring, loc, doActions, 
callPreParse )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 924, in _parseNoCache
     loc,tokens = self.parseImpl( instring, preloc, 
doActions )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 2307, in parseImpl
     loc, exprtokens = e._parse( instring, loc, doActions 
)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 981, in _parseCache
     value = self._parseNoCache( instring, loc, doActions, 
callPreParse )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 924, in _parseNoCache
     loc,tokens = self.parseImpl( instring, preloc, 
doActions )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 2416, in parseImpl
     ret = e._parse( instring, loc, doActions )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 981, in _parseCache
     value = self._parseNoCache( instring, loc, doActions, 
callPreParse )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
line 950, in _parseNoCache
     tokens = fn( instring, tokensStart, retTokens )
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py", 
line 1963, in raise_error
     raise ParseFatalException(msg + "\n" + s)
ParseFatalException: Expected end of math '$'

Hi,

On Thu, 2008-07-24 at 13:08 -0700,
mat...@li... wrote:
> WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py:docstring
> of matplotlib.axes.Axes.acorr:36: (ERROR/3) Unexpected indentation.
> WARNING: <autodoc>:0: (ERROR/3) Unexpected indentation.
> WARNING: /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring
> of
> matplotlib.backend_bases.FigureCanvasBase.start_event_loop_default:15:
> (WARNING/2) Literal block expected; none found.
> 

I looked at my doc strings and as far as I can tell, they are identical
in format to other functions around them.  What does this error mean?

Cheers,
David

-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hi,

I am still getting crashes using the WX backend with the latest SVN.
For example:

In [1]: figure()
------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 1092, in _onSize
    self.draw()
  File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 892, in draw
    self.figure.draw(self.renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
724, in draw
    if self.frameon: self.patch.draw(renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
257, in draw
    gc = renderer.new_gc()
  File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 366, in new_gc
    self.gc = GraphicsContextWx(self.bitmap, self)
  File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 463, in __init__
    gfx_ctx = wx.GraphicsContext.Create(dc)
<type 'exceptions.AttributeError'>: 'module' object has no attribute
'GraphicsContext'

It appears that this GraphicsContext either isn't in my version of
wxPython or isn't initialized properly.  Updating to wxPython 2.8 fixed
the problem, but I think that breaks other things on my system (like
system tools on Ubuntu that I need to use).  For now I will just use
2.8, but I may have to revert.  Is supporting wx 2.6 a goal?

Cheers,
David

On Thu, 2008-07-24 at 11:55 -0400, Paul Kienzle wrote:
> On Thu, Jul 24, 2008 at 05:14:42PM +0200, David Kaplan wrote:
> > Hi,
> > 
> > No, it doesn't appear to work with or without my changes.  Also, it
> > looks to me like the following code is now misplaced in backend_wx.py:
> > 
> > # Event binding code changed after version 2.5
> > if wx.VERSION_STRING >= '2.5':
> >     def bind(actor,event,action,**kw):
> >         actor.Bind(event,action,**kw)
> > else:
> >     def bind(actor,event,action,id=None):
> >         if id is not None:
> >             event(actor, id, action)
> >         else:
> >             event(actor,action)
> > 
> > It now appears after some functions not in the class.  Is this OK?
> 
> This code is not part of any class.  Anyway, I moved it to the top
> of the file.
> 
> > Also, I noticed that this defines bind, while elsewhere in the class
> > self.Bind is used.  Is this correct?  If so, should these other
> > references perhaps take advantage of your abstraction?
> 
> I've committed a change so that all functions now use 
> 
>     bind(self, wx.EVT, callback, id=id)
> 
> rather than
> 
>     if wx.VERSION_STRING >= '2.5':
>         self.Bind(wx.EVT,callback,id=id)
>     else:
>         wx.EVT(self, id, callback)
> 
> I'm not set up to test against wx < 2.5, though given its age
> and the small user base of matplotlib wx, I'm not sure that
> it is relevant anymore.
> 
> 
> - Paul
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

I forgot to attach the patch.

-JJ


On Fri, Jul 25, 2008 at 2:39 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi,
>
> While playing a little bit with "custom_projection_example.py", I
> found that "plot" command with projection="hammer" plots too many
> markers.
>
> For example,
>
>    subplot(111, projection="hammer")
>    grid(True)
>    p = plot([-1, 1, 1], [-1, -1, 1], "o")
>    show()
>
> plots more than 100 circles, instead of 3. And I presume that this is
> a bug not a feature.
> This seems to be because the draw() method of the Line2D class  uses
> self._transformed_path for plotting Markers, but  number of vertices
> in the _transformed_path increases in the curved coordinate system as
> in the example.
>
> A patch to fix this is attached. It defines a new property
> "self._transformed_path_mark" in the recache() method as follows
>
>        tr = self.get_transform()
>        self._transformed_path = TransformedPath(self._path, tr)
>        self._transformed_path_mark =
> Path(tr.transform_non_affine(self._path.vertices))
>
>
> and draw() method uses this for plotting markers.
>
>                tpath, affine = self._transformed_path_mark, \
>                                self.get_transform().get_affine()
>
> As I'm not 100% sure about how the transform things work, I may have
> missed something. But I got correct results for cases I tried.
> So I hope this patch is reviewed and applied.
>
> Regards,
>
> -JJ
>

Hi,

While playing a little bit with "custom_projection_example.py", I
found that "plot" command with projection="hammer" plots too many
markers.

For example,

    subplot(111, projection="hammer")
    grid(True)
    p = plot([-1, 1, 1], [-1, -1, 1], "o")
    show()

plots more than 100 circles, instead of 3. And I presume that this is
a bug not a feature.
This seems to be because the draw() method of the Line2D class  uses
self._transformed_path for plotting Markers, but  number of vertices
in the _transformed_path increases in the curved coordinate system as
in the example.

A patch to fix this is attached. It defines a new property
"self._transformed_path_mark" in the recache() method as follows

        tr = self.get_transform()
        self._transformed_path = TransformedPath(self._path, tr)
        self._transformed_path_mark =
Path(tr.transform_non_affine(self._path.vertices))


and draw() method uses this for plotting markers.

                tpath, affine = self._transformed_path_mark, \
                                self.get_transform().get_affine()

As I'm not 100% sure about how the transform things work, I may have
missed something. But I got correct results for cases I tried.
So I hope this patch is reviewed and applied.

Regards,

-JJ

John Hunter wrote:
> On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <rm...@gm...> wrote:
> 
>> What else is confusing is how that relates to DPI.  When I change the
>> figure's dpi, using set_dpi, (and redraw), I get physically *bigger* barbs.
>>  To me, if I'm actually specifying pixels, there's no way that they should
>> get bigger when I change the DPI.

Ryan,  I think you are giving the length in points (sort of, because of 
the bizarre size kwarg), not pixels.  So you are right--the barbs are 
not 7 pixels long.  The translation from points to pixels for the Agg 
backend depends on the dpi, as John says below.

> 
> When you increase the dpi, the canvas gets bigger (inches*dpi equals
> canvas size in pixels).  If you are drawing in pixels, and not
> scaling, the barbs should look smaller, since they are a smaller
> proportion of the canvas size.  So if this explanation is right, the
> barbs will look smaller with larger dpi.
> 
>> Then I also can't figure out what the PS backend is doing.  If PS is
>> hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect?
> 
> ps should be unaffected, but dpi dependent backends will.  By setting
> the dpi to be 72, it should make the *other* backend look like the ps
> backend and the ps backend should be unaffected.

I don't think so, unless I am misunderstanding your phrase "make the 
*other* backend look like the ps backend".  If you pass 72 dpi to the 
Agg backend, you will get a relatively small number of pixels, and when 
you display it at natural size on the screen, it will be tiny--only a 
little more than half-size on my laptop screen, for example.  Whereas, 
if the ps renderer knows the screen dpi, then it will display full-size.

> 
> JDH

Ryan May wrote:
> Hi,
> 
> This is probably best directed to Eric, but to anyone who knows how 
> quiver works with regard to units: QuiverKey right now is failing if 
> coordinates="inches".  There are a couple of non-defined variables 
> accesses in there, and it just doesn't look right.  The offending part 
> of the if chain starts at line 292 of quiver.py.  I'm not familiar 
> enough with how this code works to try and fix it.  None of the example 
> code seems to exercise the coordinates parameter of quiverkey, just the 
> units parameter for quiver.
> 
> Ryan
> 

Fixed in 5865, after stripping whitespace in the previous commit.

Eric

On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <rm...@gm...> wrote:

> What else is confusing is how that relates to DPI.  When I change the
> figure's dpi, using set_dpi, (and redraw), I get physically *bigger* barbs.
>  To me, if I'm actually specifying pixels, there's no way that they should
> get bigger when I change the DPI.

When you increase the dpi, the canvas gets bigger (inches*dpi equals
canvas size in pixels).  If you are drawing in pixels, and not
scaling, the barbs should look smaller, since they are a smaller
proportion of the canvas size.  So if this explanation is right, the
barbs will look smaller with larger dpi.

> Then I also can't figure out what the PS backend is doing.  If PS is
> hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect?

ps should be unaffected, but dpi dependent backends will.  By setting
the dpi to be 72, it should make the *other* backend look like the ps
backend and the ps backend should be unaffected.

JDH

Eric Firing wrote:
> John Hunter wrote:
>> On Wed, Jul 23, 2008 at 10:05 PM, Ryan May <rm...@gm...> wrote:
>>
>>> <grumble> Ok, it fixes the problem if I pass dpi=72 to savefig(). 
>>> Curiously,
>>> passing dpi=72 to Figure() does not have the same effect.  So now how 
>>> do I
>>
>> That is because "savefig" has its own dpi, which overrides the figure
>> dpi.  Tee ideas is that you typically want a different dpi for the UI
>> window and for the harcopy
>>
>>> fix it?  I'm really not sure what's going wrong here.  If I had to 
>>> guess,
>>> it's a problem between figure size being in inches while I'm drawing in
>>> pixels (still don't know how that works, because there's no way those 
>>> barbs
>>> are 9 pixels long).
>>
>> I'm not familiar enough with the windbarb code to know where the "9
>> pixel" thing that is bothering you is creeping in, I'm just saying
>> that using an identity transform means you are drawing in canvas
>> (pixel) space and not accounting for dpi.  The Figure instance has a
>> "dpi_scale_transform" that is designed to handle dpi scaling, and
>> updates itself when the figure dpi is changed so you don't have to
>> handle the callbacks.  Take a look at this and see if you can
>> incorporate it.  If you have troubles, Michael or I can advise
>> further.
>>
>> If you clarify the "9 pixel" problem that is bothering you, I may be
>> able to help more sooner...
> 
> Part of the problem is the horrible and misleading sizes arg in 
> PolyCollections, probably a hangover (yes, a headache) from supporting a 
> Matlab-compatible argument in scatter.  I can try to straighten this out 
> and clarify the situation after the release, not before.  I will add an 
> alternative kwarg to scatter at the same time, and hope the old usage 
> gradually dies out.

That might be part of it, I'm not sure.  My problem is that I have 
length set to 7 in the code.  That implies that when I draw, the 
distance along the y-axis between where I start and where I end is 7 
units (which is then rotated).  What gets shown on my screen (when the 
BarbCollection transform is set to IdentityTransform()) is not possibly 
7 pixels long.  My gnome-panel bar is 22 pixels high, and that looks 
like a pretty good fit to how long things are actually in the figure I 
see on screen.  This is at my default figure dpi of 72.

What else is confusing is how that relates to DPI.  When I change the 
figure's dpi, using set_dpi, (and redraw), I get physically *bigger* 
barbs.  To me, if I'm actually specifying pixels, there's no way that 
they should get bigger when I change the DPI.

Then I also can't figure out what the PS backend is doing.  If PS is 
hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect?

I found the fig.dpi_scale_trans.  However, this then makes things too 
big on the on screen figure when I use this as the tranform for the 
BarbCollection.

Thoughts?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,

This is probably best directed to Eric, but to anyone who knows how 
quiver works with regard to units: QuiverKey right now is failing if 
coordinates="inches".  There are a couple of non-defined variables 
accesses in there, and it just doesn't look right.  The offending part 
of the if chain starts at line 292 of quiver.py.  I'm not familiar 
enough with how this code works to try and fix it.  None of the example 
code seems to exercise the coordinates parameter of quiverkey, just the 
units parameter for quiver.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Eric Firing wrote:
>> Anyone have any ideas?
> 
> I don't, but it appears that the set_clip_path method was introduced in 
> 4817 by Mike D., complete with the commented-out lines.
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 

Uncommenting them doesn't seem to break anything and it solves my 
problem as well.  I guess there could be performance impacts so I'll 
wait for Mike to weigh in.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

David Kaplan wrote:
>> * Using an empty list in a python kwarg as the default is a gotcha, as in
>>
>>     def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ):
>>
>> The reason is that if the function mutates the list, this often leads
>> to unintended consequences as the list is module level and thus shared
>> between instances and method calls.  The standard idiom for mutable
>> (lists and dicts) keyword args s
>>
>>     def func(x=None):
>>         if x is None: x = []
>>
>> I have fixed this in contour.py
>>
> 
> I don't really understand how this can be a problem, but it probably
> isn't that important unless you feel like enlightening me.

The default value for the function is created when the interpreter 
executes the define statement.  Thus, if you were to do something that 
modifies the list inplace, like append(), the default argument will 
retain those changes.  For instance, try this:

def foo(l=[]):
     l.append('foo')
     print l
foo()
foo()
foo(['bar'])
foo()

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jul 24, 2008 at 12:25 PM, Paul Kienzle <pki...@ni...> wrote:

>  canvas interface for interactive plotting applications

The Chaco devs (in particular Peter Wang) will be there, so it would
be worthwhile having a detailed conversation with him on this matter,
as this is definitely Chaco's strong suit and I'm sure he'd have a lot
of good ideas on the matter.  Who knows, we might even inch a bit
closer towards that mythical mpl/chaco unification :)

Cheers,

f

Paul Kienzle wrote:
> Hi,
> 
> I added support for scroll wheel events in wx.  This includes
> a new attribute event.step since the wx mouse wheel event
> reports larger steps when scrolling faster.  I don't see
> how to check step in gtk, so I set step to +1 and -1 for up 
> and down.
> 
> Can someone with gtk please run the following to make sure
> I didn't break anything:
> 
>     examples/pylab_examples/image_slices_viewer.py
> 
> 

Works for me.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Paul Kienzle wrote:
> Hello,
> 
> Anyone planning to attend post-SciPy2008 code sprints?
> 
> Some projects I'm interested in:
> 
>   support for units (px, pt/in/cm/mm, em/ex/<font height>, %axis/%figure)
>   style sheet editor (needs backend support for forms and menus)
>   canvas interface for interactive plotting applications
> 
> - Paul

I'll be there the whole week, Monday-Sunday.  I'm good to help out where 
I can.  My personal goal is to get some work on OpenGL going, but that's 
less sprinty and more by myself kind of stuff (unless someone else is 
interested).

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma