matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Fri, Jul 25, 2008 at 5:47 PM, Ryan May <rm...@gm...> wrote:
> 
>> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
>> _print_ps()):
>>
>> self.figure.set_dpi(72) # Override the dpi kwarg
>> dpi = kwargs.get("dpi", 72)
>>
>> The problem here is that while it sets the figure dpi here to 72, it's using
>> the dpi that's passed in down the chain. Since I don't give it a dpi
>> explicity, it grabs the default dpi from my matplotlibrc, which has it set
>> to 300 dpi. So 300 is getting passed down into the chain and I believe the
>> drawing commands are using 300 dpi. If I change the second line above to
>> dpi = 72, I get the proper results.
> 
> Yes, we definitely need to get this fixed before any release, but we
> need to be careful here. I had forgotten that Nicholas Young had
> submitted a patch to make the ps backend respect higher resolutions
> for embedded images
> 
> http://www.mail-archive.com/mat...@li.../msg00353.html
> 
> so we cannot simply revert this to 72. I also see the problem you
> pointed out in the collections module too. While I don't have a quick
> fix at hand, at least we are starting to converge onto where the
> problems lie. Note that in the collections module the
> IdentityTransform is bit of a red herring in the set_transforms
> method, since the collection maintains a list of transforms in
> _transforms that incorporates a dpi a draw time so I don't thing the
> standard artist transform property is used.
I was alluding to this in my earlier rants about scatter and 
PolyCollection. The mechanism of the list of transforms is fine, but 
the kwarg name and API are bad, and additional comments are needed. I 
was going to hold off until after the release, but maybe I should go 
ahead and try to improve this, in a 100% backwards-compatible way, as 
soon as I can get to it.
> 
>> 2) backend_ps._print_figure() uses the md5 module to create a temporary
>> filename. This module is deprecated in python 2.5 and removed (I believe)
>> in 3.0, replaced by hashlib. Is there any opposition to changing the direct
>> use of md5.md5() to using a try...except to import md5() from it's proper
>> place?
> 
> I wasn't aware of the deprecation so I don't have any strong opinion,
> except that it wold be better if you can find a non-deprecated
> equivalent which is python 2.4 and 2.5 compatible.
If it is a temporary file, why not use one of the functions in the 
tempfile module? I have not looked at the code to see whether one of 
them would be appropriate, but it seems odd to have to use some other 
module.
Eric

Ryan May wrote:
> 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.
>>
>> 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.
> 
> Ok, I think I found our problem, at line 859 of backend_ps.py (inside 
> _print_ps()):
> 
> self.figure.set_dpi(72) # Override the dpi kwarg
> dpi = kwargs.get("dpi", 72)
> 
> The problem here is that while it sets the figure dpi here to 72, it's 
> using the dpi that's passed in down the chain. Since I don't give it a 
> dpi explicity, it grabs the default dpi from my matplotlibrc, which has 
> it set to 300 dpi. So 300 is getting passed down into the chain and I 
> believe the drawing commands are using 300 dpi. If I change the second 
> line above to dpi = 72, I get the proper results.
> 
> So what's the proper fix in this case, or is this it? It'd probably be 
> good to get this in for a release.
This is the kind of thing I would want to look at and test *very* 
carefully, or know that someone like John or Mike has done so--which 
perhaps one of them can do quickly. I have looked at this dpi business 
with puzzlement before; I don't have it all straight in my head; and I 
would need a chunk of time to review it, which I might get in the next 
day or so, but can't guarantee.
It would be nice to not only fix the bug, if such there is, but also 
clarify the whole mess for all backends, maybe with some additional 
variable names. I think that for pixel backends, there is a single dpi 
per rendered figure, so the situation is simple; but for vector backends 
(ps, pdf, svg), there are fundamentally two: one that is used for 
translating dots to inches as measures of length, and another that sets 
the dpi (hence resolution, not size) for raster images that are 
contained within the figure. (I don't know where the cairo backend 
sits, since it can render either raster or vector file types.)
Another aspect of the problem is that at least for use with vector 
backends, specifying lengths in dots is unnatural; and it seems to me 
like something to be avoided when possible even for raster backends. I 
would argue that pad variables should be in physical or relative units, 
where relative could mean relative to the figure size, or to a font em, 
for example. Specifying lengths in dots is just asking for trouble 
except when the plot is not intended to be scaled; when making a small 
png for the web, precise control via lengths in dots may be helpful.
Eric
> 
> There were a couple other things I noticed:
> 
> 1) The canvas.print_figure() method goes to the trouble of saving the 
> facecolor and edgecolor before resetting them to what's passed in for 
> purposes of writing out the image. Then later, 
> backend_ps._print_figure() does the same thing a few calls down the 
> stack. Is one of these redundant, or is there a reason for the 
> duplication?
> 
> 2) backend_ps._print_figure() uses the md5 module to create a temporary 
> filename. This module is deprecated in python 2.5 and removed (I 
> believe) in 3.0, replaced by hashlib. Is there any opposition to 
> changing the direct use of md5.md5() to using a try...except to import 
> md5() from it's proper place?
> 
> Ryan
> 

On Fri, Jul 25, 2008 at 5:32 PM, Paul Kienzle <pki...@ni...> wrote:
> Hi,
>
> I commited a fixto the axis contains methods, and now have working scroll
> wheel zooming code. I still need to use transforms properly before it can
> go into matplotlib, so for now I provide it only for demonstration
> purposes.
I haven't tested this yet, but on a quick read through I notice.
 try:
	step = event.step
 except:
	if event.button == 'up':
	 step = 1
	else:
	 step = -1
Just a reminder that blanket try/except clauses are forbidden in mpl,
so you can either do "except AttributeError" or use "if not
hasattr(event, 'step')"
JDH

On Fri, Jul 25, 2008 at 5:47 PM, Ryan May <rm...@gm...> wrote:
> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
> _print_ps()):
>
> self.figure.set_dpi(72) # Override the dpi kwarg
> dpi = kwargs.get("dpi", 72)
>
> The problem here is that while it sets the figure dpi here to 72, it's using
> the dpi that's passed in down the chain. Since I don't give it a dpi
> explicity, it grabs the default dpi from my matplotlibrc, which has it set
> to 300 dpi. So 300 is getting passed down into the chain and I believe the
> drawing commands are using 300 dpi. If I change the second line above to
> dpi = 72, I get the proper results.
Yes, we definitely need to get this fixed before any release, but we
need to be careful here. I had forgotten that Nicholas Young had
submitted a patch to make the ps backend respect higher resolutions
for embedded images
 http://www.mail-archive.com/mat...@li.../msg00353.html
so we cannot simply revert this to 72. I also see the problem you
pointed out in the collections module too. While I don't have a quick
fix at hand, at least we are starting to converge onto where the
problems lie. Note that in the collections module the
IdentityTransform is bit of a red herring in the set_transforms
method, since the collection maintains a list of transforms in
_transforms that incorporates a dpi a draw time so I don't thing the
standard artist transform property is used.
> 2) backend_ps._print_figure() uses the md5 module to create a temporary
> filename. This module is deprecated in python 2.5 and removed (I believe)
> in 3.0, replaced by hashlib. Is there any opposition to changing the direct
> use of md5.md5() to using a try...except to import md5() from it's proper
> place?
I wasn't aware of the deprecation so I don't have any strong opinion,
except that it wold be better if you can find a non-deprecated
equivalent which is python 2.4 and 2.5 compatible.
JDH

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.
> 
> 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.
Ok, I think I found our problem, at line 859 of backend_ps.py (inside 
_print_ps()):
 self.figure.set_dpi(72) # Override the dpi kwarg
 dpi = kwargs.get("dpi", 72)
The problem here is that while it sets the figure dpi here to 72, it's 
using the dpi that's passed in down the chain. Since I don't give it a 
dpi explicity, it grabs the default dpi from my matplotlibrc, which has 
it set to 300 dpi. So 300 is getting passed down into the chain and I 
believe the drawing commands are using 300 dpi. If I change the second 
line above to dpi = 72, I get the proper results.
So what's the proper fix in this case, or is this it? It'd probably be 
good to get this in for a release.
There were a couple other things I noticed:
1) The canvas.print_figure() method goes to the trouble of saving the 
facecolor and edgecolor before resetting them to what's passed in for 
purposes of writing out the image. Then later, 
backend_ps._print_figure() does the same thing a few calls down the 
stack. Is one of these redundant, or is there a reason for the duplication?
2) backend_ps._print_figure() uses the md5 module to create a temporary 
filename. This module is deprecated in python 2.5 and removed (I 
believe) in 3.0, replaced by hashlib. Is there any opposition to 
changing the direct use of md5.md5() to using a try...except to import 
md5() from it's proper place?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
I commited a fixto the axis contains methods, and now have working scroll
wheel zooming code. I still need to use transforms properly before it can
go into matplotlib, so for now I provide it only for demonstration
purposes.
	- Paul

Eric Firing wrote:
> 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.
Now I know what you were saying, I was too braindead to understand last 
night. I am drawing in points (or whatever scatter uses for size), 
because I modeled my code off of scatter. Scatter also uses an Identity 
Transform() for it's Collection objects (which is where I got the idea). 
 Not coincidentally, it shows a similar issue. While it's not as bad 
as my barbs issue (for reasons unknown to me), you can change the size 
of the scatter object relative to the size of the canvas just by 
changing the dpi passed to savefig. Again, it takes passing in dpi=72 to 
get a figure to match what's on screen, even though 72 is supposedly 
what's hard coded.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 25, 2008 at 18:37, John Hunter <jd...@gm...> wrote:
> 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
Yeah, much better :)
I've updated the package in our trunk and it's building fine.
Playing with the generated doc I got an error on "matplotlib.colorbar":
"
System Message: ERROR/3
(/home/morph/deb/build-area/matplotlib-0.98.3rc1/doc/api/colorbar_api.rst,
line 9)
Error in "automodule" directive: unknown option: "show-inheritance".
.. automodule:: matplotlib.colorbar
 :members:
 :undoc-members:
 :show-inheritance:
"
Err, I got it for ever API documentation page: is there something
wrong on my side? I build doc this way:
( cd doc ; MATPLOTLIBDATA=../lib/matplotlib/mpl-data/ \
 PYTHONPATH=../build/lib.$(shell dpkg-architecture
-qDEB_BUILD_ARCH_OS)-$(shell dpkg-architecture
-qDEB_BUILD_GNU_CPU)-$(DEFPY) ./make.py )
dpkg-architecture calls are needed to identify the directory for the
mpl lib code, and all the relative paths are because we build in a
chroot, so only minimal packages installation are available.
Thanks,
Sandro
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

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