matplotlib-devel Mailing List for matplotlib (Page 4)

Andrew Straw wrote:
> Hi all,
> 
> I've added some functionality to my copy hexbin, and I thought I'd
> bounce it off folks (esp. Michael) to see if it seems like a good idea
> to add it to MPL.
> 
> Here's the beginning of the docstring of the new version. What I've
> added is the optional argument "C" -- inspired by scatter's "c" argument.
> 
>> call signature::
>>
>> hexbin(x, y, C = None, gridsize = 100, bins = None,
>> xscale = 'linear', yscale = 'linear',
>> cmap=None, norm=None, vmin=None, vmax=None,
>> alpha=1.0, linewidths=None, edgecolors='none'
>> reduce_C_function = np.mean,
>> **kwargs)
>>
>> Make a hexagonal binning plot of *x* versus *y*, where *x*,
>> *y* are 1-D sequences of the same length, *N*. If *C* is None
>> (the default), this is a histogram of the number of occurences
>> of the observations at (x[i],y[i]).
>>
>> If *C* is specified, it specifies values at the coordinate
>> (x[i],y[i]). These values are accumulated for each hexagonal
>> bin and then reduced according to *reduce_C_function*, which
>> defaults to numpy's mean function (np.mean). (If *C* is
>> specified, it must also be a 1-D sequence of the same length
>> as *x* and *y*.)
> 
> What do you think? I've also implemented a simple demo making use of
> this functionality and an image of the output of the demo. For my own
> selfish reasons, I'd love if we could stick this in 0.98.3, but I'm also
> happy to hold off to get the release out the door.
> 
> -Andrew
Andrew,
That sounds like a nice addition, and one that does not interfere in any 
way with the original hexbin functionality.
Eric

Hi,
I went through all the demos in pylab_examples to make sure that
the artist.contains() method would return true when the mouse
is on the object. I fixed a number of problems caused by the
new transforms code (collections, lines and images were not
detected). A few issues remain, but they are not show stoppers.
Broken examples:
 barcode_demo, image_interp, etc: wx doesn't implement draw_image
 dannys_example: wx doesn't implement draw_tex
 font_table_ttf: list index out of range
 geo_demo: invalid value in projections.geo for x = ... / sinc_alpha
 multi_image: AxesImage has no attribute add_observer
 stix_fonts_demo: error
 UnicodeDecodeError: 'rawunicodeescape' codec can't decode
 bytes in position 39-0: \Uxxxxxxxx out of range
 symlog_demo: rendering causes the following error
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
line 1072, in transform_point
 assert len(point) == self.input_dims
 running reindent.py causes lots of changes
Hit test issues:
 barb_demo: detecting filled areas but not lines
 dashtick: not detecting dash ticks, except by tick
 date_demo2: rotated text uses bounding box rather than rotated rectangle
 newscalarformatter_demo: axis offset label not detected
 quiver_demo: 1 m/s arrow legend not detected
 scatter_star_poly: plus and star not detected
If you want to turn on hit testing for a plot, use:
 gcf().canvas.mpl_connect("motion_notify_event",
 gcf().canvas.onHilite)
- Paul

On Sat, Jul 26, 2008 at 3:37 PM, Andrew Straw <str...@as...> wrote:
> Hi all,
>
> I've added some functionality to my copy hexbin, and I thought I'd
> bounce it off folks (esp. Michael) to see if it seems like a good idea
> to add it to MPL.
Do you mean Michiel, the hexbin author? I m CC-ing him.
> Here's the beginning of the docstring of the new version. What I've
> added is the optional argument "C" -- inspired by scatter's "c" argument.
>
>> call signature::
>>
>> hexbin(x, y, C = None, gridsize = 100, bins = None,
>> xscale = 'linear', yscale = 'linear',
>> cmap=None, norm=None, vmin=None, vmax=None,
>> alpha=1.0, linewidths=None, edgecolors='none'
>> reduce_C_function = np.mean,
>> **kwargs)
>>
>> Make a hexagonal binning plot of *x* versus *y*, where *x*,
>> *y* are 1-D sequences of the same length, *N*. If *C* is None
>> (the default), this is a histogram of the number of occurences
>> of the observations at (x[i],y[i]).
>>
>> If *C* is specified, it specifies values at the coordinate
>> (x[i],y[i]). These values are accumulated for each hexagonal
>> bin and then reduced according to *reduce_C_function*, which
>> defaults to numpy's mean function (np.mean). (If *C* is
>> specified, it must also be a 1-D sequence of the same length
>> as *x* and *y*.)
>
> What do you think? I've also implemented a simple demo making use of
> this functionality and an image of the output of the demo. For my own
> selfish reasons, I'd love if we could stick this in 0.98.3, but I'm also
> happy to hold off to get the release out the door.
The functionality looks really nice. I don't really have a problem
sneaking it in -- I'm a softie -- but we should hear from Michiel
first. I am still waiting to hear from Sandro about his sphinx problem
before trying to release anything anyhow.
JDH

I just fixed a small bug when bins were not filled and C was specified.
Attached is the revised version.

Hi all,
I've added some functionality to my copy hexbin, and I thought I'd
bounce it off folks (esp. Michael) to see if it seems like a good idea
to add it to MPL.
Here's the beginning of the docstring of the new version. What I've
added is the optional argument "C" -- inspired by scatter's "c" argument.
> call signature::
> 
> hexbin(x, y, C = None, gridsize = 100, bins = None,
> xscale = 'linear', yscale = 'linear',
> cmap=None, norm=None, vmin=None, vmax=None,
> alpha=1.0, linewidths=None, edgecolors='none'
> reduce_C_function = np.mean,
> **kwargs)
> 
> Make a hexagonal binning plot of *x* versus *y*, where *x*,
> *y* are 1-D sequences of the same length, *N*. If *C* is None
> (the default), this is a histogram of the number of occurences
> of the observations at (x[i],y[i]).
> 
> If *C* is specified, it specifies values at the coordinate
> (x[i],y[i]). These values are accumulated for each hexagonal
> bin and then reduced according to *reduce_C_function*, which
> defaults to numpy's mean function (np.mean). (If *C* is
> specified, it must also be a 1-D sequence of the same length
> as *x* and *y*.)
What do you think? I've also implemented a simple demo making use of
this functionality and an image of the output of the demo. For my own
selfish reasons, I'd love if we could stick this in 0.98.3, but I'm also
happy to hold off to get the release out the door.
-Andrew

On Fri, Jul 25, 2008 at 4:12 PM, Sandro Tosi <mat...@gm...> wrote:
> 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".
The docs require sphinx 0.4, which if I recall correctly, we got
pushed into debian on short notice precisely to support the mpl docs.
 What version of sphinx are you using?
>From our earlier thread on the subject:
Mikhail Gusarov
 to Chris, me, Sandro, Michael
	
	
Twas brillig at 00:26:04 19.06.2008 UTC+07 when
dot...@do... did gyre and gimble:
 MG> I just got a confirmation from Georg that he will release the next
 MG> version of sphinx this weekend, and I'll immediately prepare the
 MG> package.
Here we are:
Accepted:
python-sphinx_0.4-1_all.deb
 to pool/main/s/sphinx/python-sphinx_0.4-1_all.deb

On Sat, Jul 26, 2008 at 7:19 AM, David M. Kaplan <Dav...@ir...> wrote:
> I started looking at this reorganization, but it seems to me that mlab
> already has a number of functions that don't seem to have much to do
> with its initial purpose - matlab compatibility. This was pretty
> confusing for me when I initially started using matplotlib as the mlab
> namespace was a mix of familiar and unfamiliar.
I'm not too keen on having general math in one module and matlab
compatible math in another, in part because this will be confusing to
folks not too familiar with matlab, and as time passes (I never use it
anymore) that is starting to include me. I think we could avoid some
confusion by simply fixing the docstring in mlab. So I'd rather put
all the math stuff in mlab, and possibly pull the geometry specific
stuff into a separate module.
> As these changes may be debatable, I haven't committed them. Instead, I
> am attaching a patchset. I probably won't check email this weekend, so
> I will let the powers that be decide what to do with this.
OK, thanks. I will try nd look at this over the weekend.
> Along the way, I noticed these is some duplication in the examples
> directory between pylab_examples and mpl_examples.
mpl_examples is a sym link we use for the rest doc builds so the
examples can be included w/o the doc writer needing to know the path
structure. That way if we want to reorganize later, we can update the
symlink rather than all the docs
jdhunter@bic128:mpl> ls -ld lib/mpl_examples
lrwxrwxrwx 1 jdhunter jdhunter 11 2008年07月25日 20:37 lib/mpl_examples ->
../examples
jdhunter@bic128:mpl> ls -ld doc/mpl_examples
lrwxrwxrwx 1 jdhunter jdhunter 12 2008年06月02日 07:31 doc/mpl_examples ->
../examples/
JDH

Hi,
On Fri, 2008年07月25日 at 12:43 -0500, John Hunter wrote:
> 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.
> 
I started looking at this reorganization, but it seems to me that mlab
already has a number of functions that don't seem to have much to do
with its initial purpose - matlab compatibility. This was pretty
confusing for me when I initially started using matplotlib as the mlab
namespace was a mix of familiar and unfamiliar.
I decided instead to group several functions into a "numerical_methods"
module that includes most of my new cbook functions as well as some
linear interpolation and polygon stuff from mlab. I moved isvector to
mlab since this really is an imitation of a matlab function of the same
name. I have propagated these changes through to other functions in
matplotlib that use them and added remarks in CHANGELOG and API_CHANGES.
As these changes may be debatable, I haven't committed them. Instead, I
am attaching a patchset. I probably won't check email this weekend, so
I will let the powers that be decide what to do with this.
Along the way, I noticed these is some duplication in the examples
directory between pylab_examples and mpl_examples.
Cheers,
David
> JDH
-- 
**********************************
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
**********************************

John Hunter wrote:
> On Fri, Jul 25, 2008 at 7:02 PM, Eric Firing <ef...@ha...> wrote:
> 
>> This looks incomplete--shouldn't the QuiverKey initializer be using this
>> function to set the figure from Q.ax.figure, and then should be using
>> self.figure to get the transform?
>>
>> I don't want to jump in if you are in the middle of working with it, though.
>> I don't know what your motivation for adding this function was.
> 
> All artists which contain other artists (eg QuiverKey contains a Text
> instance) should override set_figure to pass the figure on to the
> childen (we should have an ArtistContainer base class to facilitate
> stuff like this). When we later call ax.add_artist(quiverkey), the ax
> instance will call quiverkey.set_figure so the figure will get passed
> down to the Text. I needed to get the figure instance set on the text
> instance because the Text prop key method was using the renderer dpi
> instance in the cache key, and renderer.dpi no longer exists. Now I
> am not nearly as familiar with QuiverKey as you are, but this was just
> a simple fix to make sure the quiverkey text instance gets its figure
> set. If it appears to you that something is still missing, please
> clarify.
Thanks for the explanation. The change I had in mind would not hurt, 
but it would not help, either, so we'll leave it out.
Eric

Hi,
I fixed some of the contains() methods so at least the simple
cases work.
Degenerate rectangles cause problems in axes_demo:
>>> import matplotlib.patches
>>> r = matplotlib.patches.Rectangle((0,0),1,0) 
>>> r.get_transform().inverted()
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py", line 1338, in inverted
 self._inverted = Affine2D(inv(mtx))
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 332, in inv
 return wrap(solve(a, identity(a.shape[0], dtype=a.dtype)))
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 235, in solve
 raise LinAlgError, 'Singular matrix'
numpy.linalg.linalg.LinAlgError: Singular matrix
I've only gone through the a*.py samples, but there are a few other glitches
such as not detecting axhline/axvline, not handling rotated text properly,
and not doing very well on polar plots. These will have to wait for another
release.
	- Paul

John Hunter wrote:
> On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <ef...@ha...> wrote:
> 
>> 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.
> 
> I just committed a fix here -- I renamed the renderer dpi instance to
> imagedpi to avoid confusion, and modified the various places in the
> artist code (collections, text) which were using renderer.dpi (they
> now use figure.dpi). Right now the only backend that was using the
> image magnification was backend ps.
Good, thank you.
> 
>> 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.
> 
> Yes, certainly points or some other physical dimension is the right
> way to specify pads. Where in the code are dots/pixels used?
Sorry, I was misremembering; it looks like such cases were purged a long 
time ago.
Eric
> 
> JDH

John Hunter wrote:
> On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <ef...@ha...> wrote:
> 
>> 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.
> 
> I just committed a fix here -- I renamed the renderer dpi instance to
> imagedpi to avoid confusion, and modified the various places in the
> artist code (collections, text) which were using renderer.dpi (they
> now use figure.dpi). Right now the only backend that was using the
> image magnification was backend ps.
It fixes the problems that barb_demo.py was having saving to EPS files 
here. No noticable changes to the png files or displayed figure (as one 
would expect).
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 25, 2008 at 7:11 PM, Ryan May <rm...@gm...> wrote:
> try:
> from hashlib import md5
> except ImportError:
> from md5 import md5
Looks good to me -- thanks for the offer to fix this. In general, we
only actively want to be supporting 2 python versions at a time, but
if there is an easy way to extend support to a broader range, there is
no reason not to.
JDH

On Fri, Jul 25, 2008 at 7:02 PM, Eric Firing <ef...@ha...> wrote:
> This looks incomplete--shouldn't the QuiverKey initializer be using this
> function to set the figure from Q.ax.figure, and then should be using
> self.figure to get the transform?
>
> I don't want to jump in if you are in the middle of working with it, though.
> I don't know what your motivation for adding this function was.
All artists which contain other artists (eg QuiverKey contains a Text
instance) should override set_figure to pass the figure on to the
childen (we should have an ArtistContainer base class to facilitate
stuff like this). When we later call ax.add_artist(quiverkey), the ax
instance will call quiverkey.set_figure so the figure will get passed
down to the Text. I needed to get the figure instance set on the text
instance because the Text prop key method was using the renderer dpi
instance in the cache key, and renderer.dpi no longer exists. Now I
am not nearly as familiar with QuiverKey as you are, but this was just
a simple fix to make sure the quiverkey text instance gets its figure
set. If it appears to you that something is still missing, please
clarify.
JDH

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.
Yeah, I figured it was more complex thatn that. While the 
IdentityTransform() might be a bit of a red herring, the fact remains 
that changing the dpi still changes the size of the of the marker 
relative to the canvas in a scatter plot saved with backend_ps, which 
doesn't occur with the image backends (at least I tested for png).
>> 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.
Therein lies the problem, 2.5 deprecated md5 in favor of hashlib, which 
was added in 2.5. So the options are:
1)Do nothing now. Go back and fix the problem when we get around to
 supporting 3.x. md5 has officially been removed from SVN for python
 3.0.
2)Move completely over to hashlib, drop support for <2.5
3)try to import md5() from hashlib, if that fails fall back to importing
 md5() from the md5 module.
Option 2 is not really an option, so never mind it. Option 1 is the 
status quo, and it just means we need to keep it in mind as one of the 
issues that will have to be handled later when we move to 3.x. I just 
read that in 2.6, md5 will issue a DeprecationWarning. That probably 
kicks us to option 3.
Option 3 isn't too bad. Both the md5 objects from hashlib and from the 
md5 module support the same API. Hashlib lacks a module level function 
new() which md5 has, but this is just an alternative to using a class 
constructor, so code that uses new() (backend_svg) is easily moved over 
to code that works for both.
I'll volunteer to do the ports, which will mostly consist of:
try:
 from hashlib import md5
except ImportError:
 from md5 import md5
Thoughts?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <ef...@ha...> wrote:
> 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.
I just committed a fix here -- I renamed the renderer dpi instance to
imagedpi to avoid confusion, and modified the various places in the
artist code (collections, text) which were using renderer.dpi (they
now use figure.dpi). Right now the only backend that was using the
image magnification was backend ps.
> 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.
Yes, certainly points or some other physical dimension is the right
way to specify pads. Where in the code are dots/pixels used?
JDH

jd...@us... wrote:
> Revision: 5881
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=5881&view=rev
> Author: jdh2358
> Date: 2008年07月25日 23:54:37 +0000 (2008年7月25日)
> 
> Log Message:
> -----------
> added set_figure method for quiverkey
> 
> Modified Paths:
> --------------
> trunk/matplotlib/lib/matplotlib/quiver.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/quiver.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/quiver.py	2008年07月25日 23:52:46 UTC (rev 5880)
> +++ trunk/matplotlib/lib/matplotlib/quiver.py	2008年07月25日 23:54:37 UTC (rev 5881)
> @@ -296,7 +296,7 @@
> quiverkey_doc = _quiverkey_doc
> 
> def set_figure(self, fig):
> - Artist.set_figure(self, fig)
> + martist.Artist.set_figure(self, fig)
> self.text.set_figure(fig)
> 
> class Quiver(collections.PolyCollection):
This looks incomplete--shouldn't the QuiverKey initializer be using this 
function to set the figure from Q.ax.figure, and then should be using 
self.figure to get the transform?
I don't want to jump in if you are in the middle of working with it, 
though. I don't know what your motivation for adding this function was.
Eric

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