matplotlib-devel Mailing List for matplotlib (Page 4)

Thanks Eric.
You know that this has been on my wish list for a long time.
Let me know if I can test anything or help in any other way,
Mark
On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <ef...@ha...> wrote:
> Mark Bakker wrote:
>
>> Hello list (especially Erik, who can fix this I hope) -
>>
>> I have had problems with shared axes, especially when one of the axis has
>> an aspect ratio that is set 'equal'. It has been discussed on the list
>> before (mostly with Erik Firing), but it hasn't been fixed yet. What I want
>> to do is have two plots. The top plot has an aspect ratio that is 'equal'.
>> The idea is to have a contour plot in the top figure, while the bottom
>> figure gives a cross-sectional picture of what I am plotting. This used to
>> work well (quite some time ago), including zooming and such. But now I
>> cannot plot it at all, let alone zoom.
>>
>> My first problem is when I add a subplot with a shared x-axis, it changes
>> the limits on the original x-axis. That seems to be a bug:
>> ax1 = subplot(211)
>> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
>> subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.
>>
>> After all, the new subplot shares the axis with the existing subplot, so
>> why doesn't it copy the axis limits from that subplot?
>>
>
> I may have the fix for this, but I need more time to check and refine
> it--and try to make sure that I don't break anything else in the process.
>
>
>> But the bigger problem occurs when I want the aspect ratio of one of the
>> first axis to be 'equal'.
>>
>> ax1 = subplot(211,aspect='equal')
>> plot([1,2,3]) subplot(212,sharex=ax1)
>>
>> The second subplot is added, but the length of the graph is not the same
>> as for the first subplot. It also resets the xlimits to go from 0 to 1, as
>> before, which means the first subplot becomes unreadable (it still enforces
>> 'equal' in the first subplot by changing the limits of the y-axis). When I
>> now change the limits on the x-axis, the aspect ratio is not equal anymore
>>
>>
> I will see what I can do. There are definitely some bugs that need to be
> squashed.
>
> Eric
>
>
> ax1.set_xlim(0,2)
>> draw()
>>
>> Thanks for your help. I am willing to help in testing any changes.
>>
>> Best regards, Mark
>>
>

Mark Bakker wrote:
> Hello list (especially Erik, who can fix this I hope) -
> 
> I have had problems with shared axes, especially when one of the axis 
> has an aspect ratio that is set 'equal'. It has been discussed on the 
> list before (mostly with Erik Firing), but it hasn't been fixed yet. 
> What I want to do is have two plots. The top plot has an aspect ratio 
> that is 'equal'. The idea is to have a contour plot in the top figure, 
> while the bottom figure gives a cross-sectional picture of what I am 
> plotting. This used to work well (quite some time ago), including 
> zooming and such. But now I cannot plot it at all, let alone zoom.
> 
> My first problem is when I add a subplot with a shared x-axis, it 
> changes the limits on the original x-axis. That seems to be a bug:
> ax1 = subplot(211)
> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
> subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.
> 
> After all, the new subplot shares the axis with the existing subplot, so 
> why doesn't it copy the axis limits from that subplot?
I may have the fix for this, but I need more time to check and refine 
it--and try to make sure that I don't break anything else in the process.
> 
> But the bigger problem occurs when I want the aspect ratio of one of the 
> first axis to be 'equal'.
> 
> ax1 = subplot(211,aspect='equal')
> plot([1,2,3]) 
> subplot(212,sharex=ax1)
> 
> The second subplot is added, but the length of the graph is not the same 
> as for the first subplot. It also resets the xlimits to go from 0 to 1, 
> as before, which means the first subplot becomes unreadable (it still 
> enforces 'equal' in the first subplot by changing the limits of the 
> y-axis). When I now change the limits on the x-axis, the aspect ratio is 
> not equal anymore
> 
I will see what I can do. There are definitely some bugs that need to 
be squashed.
Eric
> ax1.set_xlim(0,2)
> draw()
> 
> Thanks for your help. I am willing to help in testing any changes.
> 
> Best regards, Mark

Here's an updated patch:
I decided to go with 'c' and 'v' for Back and Forward since these keys
are in the same place on most localized keyboard layouts (sorry, dvorak
users) (as JDH pointed out, I could not use 'z' and 'x' because 'x' is
used as a modifier in Pan/Zoom mode)
I've added a ReST table detailing all of the key bindings as per JDH's
suggestion.
I included 'g' and 'l' for toggling grid and y scale under the heading
of "In axes only" though there's probably a better way of saying that.
Not sure if those belong there, but they seem to have not been
documented elsewhere ( same with 'f' for fullscreen)
navigation_toolbar.rst compiled and looked fine with rst2html.py and
rst2newlatex.py. The bullets ('- ') created extra vertical whitespace in
the table when I ran latex on the rst2latex.py output. If that's a
problem, those can be replaced with '-- '
looking forward to your feedback,
Paul Ivanov
John Hunter, on 2008年10月17日 04:02, wrote:
> On Thu, Oct 16, 2008 at 9:18 PM, Paul Ivanov <piv...@gm...> wrote:
>> Hi,
>>
>> I'm a big fan of keyboard shortcuts, so I decided to add these guys to
>> lib/matplotlib/backend_bases.py
>>
>> I'm not sure if this is too much, and maybe these should be configurable
>> down the line, but here's my first stab at it, what do you all think?
>>
>> in the same order as they appear in the toolbar:
>> 'h' or 'r' for Home/Reset
>> left arrow or 'z' or backspace for Back
>> right arrow and 'x' for Forward
>> 'p' for pan axes with right, zoom with left mode toggle
>> 'o' for z*o*om to rectangle mode toggle
>> 's' for save
> 
>> 'z' and 'x' I borrowed from the Opera browser, very handy to for
>> righties who can have their left hand on the keyboard while using the mouse.
> 
> Hi Paul,
> 
> I'm amenable to additional keys, but check out
> http://matplotlib.sourceforge.net/users/navigation_toolbar.html which
> details which keys are already in play. Also, with your patch, please
> submit a patch against the navigation toolbar doc
> doc/users/navigation_toolbar.rst . Maybe a ReST table that details all
> of the key bindings?
> 
> Thanks,
> JDH

On Tue, Oct 21, 2008 at 8:57 PM, Paul Ivanov <piv...@gm...> wrote:
> Here's an updated patch:
>
> I decided to go with 'c' and 'v' for Back and Forward since these keys
> are in the same place on most localized keyboard layouts (sorry, dvorak
> users) (as JDH pointed out, I could not use 'z' and 'x' because 'x' is
> used as a modifier in Pan/Zoom mode)
>
> I've added a ReST table detailing all of the key bindings as per JDH's
> suggestion.
Thanks Paul, for the enhancements, and especially for doing the extra
work to document the functionality and test the docs. Applied to svn
6291. If you are inclined, we probably need an rc param or something
like that to determine which keys mpl responds to since, as we have
more of these, we increase the risk that we get in the way of
application developers embedding mpl.
Eg, in matplotlibrc, one could do
 toolbar.keys : x, y, c, v, g, f, p, z, control, left, right # with
docs describing what key does what
So the user could turn off any or all of these. Then in
backend_bases, before we issue an event based on a key stroke, we
could check this default list to make sure the user wants mpl handling
these events.
JDH

John Hunter wrote:
> On Tue, Oct 21, 2008 at 12:52 PM, Eric Firing <ef...@ha...> wrote:
>> I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the
>> docs. The Latex is failing with output ending in
>>
>> ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
>> (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
>> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
>> (/etc/texmf/tex/latex/config/graphics.cfg)))
>> (/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
>> ! Extra \fi.
>> l.62 \fi\fi
>>
>>
>> Is anyone else getting this? Is there something else I need to clean
>> out in order to make it work now?
> 
> Try again, and make sure you reinstall mpl from HEAD? There were a
> couple of bugs in the matplotlib.mlab.cohere math string that was
> causing an error on my box
> 
> C_{xy} = \\frac{|P_{xy}|^2}{P_{xx}P_{yy}}
> 
> It looks like I forgot to commit the change (now in r6289).
I did a build and install of mpl from a clean checkout, went to the doc 
subdir, and ran "python make.py". It failed in exactly the same place 
as before (but took quite a while to get there).
Sphinx is installed as Sphinx-0.5dev_20081020-py2.5.egg.
The line Latex is complaining about is in sphinx.sty. I found that by 
typing "E" after the Latex "?" output; I could never have figured it out 
from the actual Latex output preceding the "?".
Changing the \fi\fi to \fi fixes it, at least with respect to building 
mpl docs.
I filed it as bug 4166.
Eric

On Tue, Oct 21, 2008 at 3:31 AM, Manuel Metz <mm...@as...> wrote:
> David Huard wrote:
>> On Mon, Oct 20, 2008 at 10:19 AM, John Hunter <jd...@gm...> wrote:
>>> On Mon, Oct 20, 2008 at 9:01 AM, David Huard <dav...@gm...> wrote:
>>>
>>>> I would oppose any change to histogram calling convention that does not
>>>> fix a critical bug. I agree that using a built-in name as an argument is
>>>> a bug, but I believe it is the lesser evil compared to asking users to
>>>> change their code
>>>> again.
>>
>> It may not have been clear enough, but let me clarify that I was
>> opposing a change to numpy.histogram, not meddling in matplotlib's
>> hist.
>
> David,
>
> the only thing is that *if* we change the keyword in matplotlib, we
> should change it to the same keyword that will (probably) be in numpy.
>
> Put it the other way: I think it would be good to agree on a new keyword
> ("binrange", "cliprange", ...) and then change it gently in both
> projects, numpy and matplotlib, as John suggested (or alternatively
> leave the keyword as is, and use the arange workaround, but I personally
> don't like this idea).
>
> Cheers,
> Manuel
>
Hi Manuel, John and Eric,
What was the time line you had in mind for the change ?
My main concern is to avoid antagonizing the folks who were annoyed by
the semantic change to histogram. Some of them might not be happy to
go back and make another change to histogram in their code so soon
after having dealt with the `new` keyword, even if you are gentle
about it.
My second concern is to avoid breaking the interface in a minor
release. This would mean waiting for NumPy 2.0 before completely
removing the range argument.
David
>> Cheers,
>> David
>>
>>> I think in this case we have to change it, but we can do it gently.
>>> Ie, for a release cycle, if we detect "range" in the kwarg case, we'll
>>> set the correct kwarg, eg "binrange", issue a warning, but not raise
>>> an error. That way users can fairly easily change their code w/o
>>> breakage. Whoever does the deprecation should note the date and
>>> version of the deprecation warning, so we will know when enough time
>>> and releases have passed to remove range entirely.
>>>
>>> JDH
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tue, Oct 21, 2008 at 12:52 PM, Eric Firing <ef...@ha...> wrote:
> I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the
> docs. The Latex is failing with output ending in
>
> ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
> (/etc/texmf/tex/latex/config/graphics.cfg)))
> (/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
> ! Extra \fi.
> l.62 \fi\fi
>
>
> Is anyone else getting this? Is there something else I need to clean
> out in order to make it work now?
Try again, and make sure you reinstall mpl from HEAD? There were a
couple of bugs in the matplotlib.mlab.cohere math string that was
causing an error on my box
 C_{xy} = \\frac{|P_{xy}|^2}{P_{xx}P_{yy}}
 It looks like I forgot to commit the change (now in r6289).
JDH

I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the 
docs. The Latex is failing with output ending in
) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
(/etc/texmf/tex/latex/config/graphics.cfg)))
(/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
! Extra \fi.
l.62 \fi\fi
Is anyone else getting this? Is there something else I need to clean 
out in order to make it work now?
Thanks.
Eric

jd...@us... wrote:
> Revision: 6288
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6288&view=rev
> Author: jdh2358
> Date: 2008年10月21日 15:26:22 +0000 (2008年10月21日)
> 
> Log Message:
> -----------
> restored the support for multiple pyplots that I broke earlier
>
> def set_xlim(self, xmin=None, xmax=None, emit=True, **kwargs):
> """
> @@ -1944,7 +1944,7 @@
> """
> Get the y-axis range [*ymin*, *ymax*]
> """
> - return self.viewLim.intervaly
> + return tuple(self.viewLim.intervaly)
John,
It might be worth adding a comment in the code as to why a tuple is 
needed here.
Eric

John Hunter-4 wrote:
> 
> _validate_standard_backends = ValidateInStrings('backend',
> all_backends, ignorecase=True)
> def validate_backend(s):
> if s.startswith('module://'): return s
> else: return _validate_standard_backends(s)
> 
> 
> Should work...
> 
Thanks. Now matplotlib.use('module://...') works.
(The -d option still doesn't, but I don't need it.)
Jason
-- 
View this message in context: http://www.nabble.com/How-to-add-a-new-backend--tp20089848p20092273.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Tue, Oct 21, 2008 at 9:14 AM, jason_h <had...@ym...> wrote:
> Unfortunately that doesn't work for me. I get a "ValueError: Unrecognized
> backend string "module://mybackend"" in rcsetup.py. Any other suggestions?
> Matplotlib ist version 0.98.3.
Hmm, strangely, the rcsetup function was reverted and as you note, is
broken, I just fixed it in svn to respect the flag, and tested with
the use directive and -d, both of which worked for me. If you don't
want to update to svn HEAD, you can edit rcsetup.py on your system and
replace::
 validate_backend = ValidateInStrings('backend', all_backends,
ignorecase=True)
with::
 _validate_standard_backends = ValidateInStrings('backend',
all_backends, ignorecase=True)
 def validate_backend(s):
 if s.startswith('module://'): return s
 else: return _validate_standard_backends(s)
Should work...
JDH

John Hunter-4 wrote:
> 
> On Tue, Oct 21, 2008 at 8:40 AM, John Hunter <jd...@gm...> wrote:
> import matplotlib
> matplotlib.use('module://my_backend')
> 
Unfortunately that doesn't work for me. I get a "ValueError: Unrecognized
backend string "module://mybackend"" in rcsetup.py. Any other suggestions?
Matplotlib ist version 0.98.3.
Here is the output:
$ python
Python 2.5.1 (r251:54863, Mar 7 2008, 03:41:45) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.use("module://mybackend")
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python2.5/site-packages/matplotlib/__init__.py", line 809,
in use
 rcParams['backend'] = name
 File "/usr/lib/python2.5/site-packages/matplotlib/__init__.py", line 588,
in __setitem__
 cval = self.validate[key](val)
 File "/usr/lib/python2.5/site-packages/matplotlib/rcsetup.py", line 49, in
__call__
 % (self.key, s, self.valid.values()))
ValueError: Unrecognized backend string "module://mybackend": valid strings
are ['ps', 'Qt4Agg', 'FltkAgg', 'GTKAgg', 'agg', 'cairo', 'GTK', 'GTKCairo',
'WXAgg', 'TkAgg', 'QtAgg', 'svg', 'pdf', 'CocoaAgg', 'emf', 'gdk',
'template', 'WX']
>>>
Neither does the -d option work. "python --help" says:
...
-d : debug output from parser (also PYTHONDEBUG=x)
...
How is this option related to plotting backends?
Thanks
Jason
-- 
View this message in context: http://www.nabble.com/How-to-add-a-new-backend--tp20089848p20091178.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Tue, Oct 21, 2008 at 8:40 AM, John Hunter <jd...@gm...> wrote:
> If you set the backend to "module://my_backend" where my_backend.py is
> a backend in your PYTHONPATH, matplotlib will load it and use it.
And yes, I forgot to mention, "use" works as well
 import matplotlib
 matplotlib.use('module://my_backend')
and the syntax for the -d flag was wrong in my last email (it is
"module://" not "file://"), it should read::
 > python simple_ploy.py -d module://my_backend
JDH

On Tue, Oct 21, 2008 at 8:04 AM, jason_h <had...@ym...> wrote:
>
> Hello,
> we want to add a new backend for some specific XML format.
>
> Can I find somewhere a sort of How-To documentation about the required
> steps?
>
> In particular I want to avoid modifying the matplotlib installation which
> resides in system directories which not every user has access to. Is it
> possible to extend the backend base class to a full backend implementation
> located below my home directory, and then have matplotlib use this backend?
>
> How would I tell matplotlib about my new class, and how do I prepare things
> so that a simple
> matplotlib.use('MyXML')
> will plot in our file format?
If you set the backend to "module://my_backend" where my_backend.py is
a backend in your PYTHONPATH, matplotlib will load it and use it.
You can also use the -d flag, eg
 > python simple_ploy.py -d file://my_backend
Let us know how it goes!
JDH

Hello,
we want to add a new backend for some specific XML format.
Can I find somewhere a sort of How-To documentation about the required
steps?
In particular I want to avoid modifying the matplotlib installation which
resides in system directories which not every user has access to. Is it
possible to extend the backend base class to a full backend implementation
located below my home directory, and then have matplotlib use this backend?
How would I tell matplotlib about my new class, and how do I prepare things
so that a simple
matplotlib.use('MyXML')
will plot in our file format?
Thanks
Jason
-- 
View this message in context: http://www.nabble.com/How-to-add-a-new-backend--tp20089848p20089848.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hello list (especially Erik, who can fix this I hope) -
I have had problems with shared axes, especially when one of the axis has an
aspect ratio that is set 'equal'. It has been discussed on the list before
(mostly with Erik Firing), but it hasn't been fixed yet. What I want to do
is have two plots. The top plot has an aspect ratio that is 'equal'. The
idea is to have a contour plot in the top figure, while the bottom figure
gives a cross-sectional picture of what I am plotting. This used to work
well (quite some time ago), including zooming and such. But now I cannot
plot it at all, let alone zoom.
My first problem is when I add a subplot with a shared x-axis, it changes
the limits on the original x-axis. That seems to be a bug:
ax1 = subplot(211)
plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.
After all, the new subplot shares the axis with the existing subplot, so why
doesn't it copy the axis limits from that subplot?
But the bigger problem occurs when I want the aspect ratio of one of the
first axis to be 'equal'.
ax1 = subplot(211,aspect='equal')
plot([1,2,3])
subplot(212,sharex=ax1)
The second subplot is added, but the length of the graph is not the same as
for the first subplot. It also resets the xlimits to go from 0 to 1, as
before, which means the first subplot becomes unreadable (it still enforces
'equal' in the first subplot by changing the limits of the y-axis). When I
now change the limits on the x-axis, the aspect ratio is not equal anymore
ax1.set_xlim(0,2)
draw()
Thanks for your help. I am willing to help in testing any changes.
Best regards, Mark

David Huard wrote:
> On Mon, Oct 20, 2008 at 10:19 AM, John Hunter <jd...@gm...> wrote:
>> On Mon, Oct 20, 2008 at 9:01 AM, David Huard <dav...@gm...> wrote:
>>
>>> I would oppose any change to histogram calling convention that does not
>>> fix a critical bug. I agree that using a built-in name as an argument is
>>> a bug, but I believe it is the lesser evil compared to asking users to
>>> change their code
>>> again.
> 
> It may not have been clear enough, but let me clarify that I was
> opposing a change to numpy.histogram, not meddling in matplotlib's
> hist.
David,
 the only thing is that *if* we change the keyword in matplotlib, we 
should change it to the same keyword that will (probably) be in numpy.
Put it the other way: I think it would be good to agree on a new keyword 
("binrange", "cliprange", ...) and then change it gently in both 
projects, numpy and matplotlib, as John suggested (or alternatively 
leave the keyword as is, and use the arange workaround, but I personally 
don't like this idea).
Cheers,
 Manuel
> Cheers,
> David
> 
>> I think in this case we have to change it, but we can do it gently.
>> Ie, for a release cycle, if we detect "range" in the kwarg case, we'll
>> set the correct kwarg, eg "binrange", issue a warning, but not raise
>> an error. That way users can fairly easily change their code w/o
>> breakage. Whoever does the deprecation should note the date and
>> version of the deprecation warning, so we will know when enough time
>> and releases have passed to remove range entirely.
>>
>> JDH
>>
> 

Actually, looking more closely, there is one thing that's still
bothering me: as it is now, it's impossible to have, say, 2 points
for plotted values, and 3 points for scatter plots on the same legend
(you have to give a numpoints=# command that's shared by everything in
the legend, if I'm understanding it). It'd be nice to have a
property, say, "scatterpoints" (and presumably then an associated
rcParam "legend.scatterpoints" ) that sets the number of points to use
for scatter plots. That way, I can make plots just like in the
original form, but it can also be the same number for both if so
desired. I've attached a patch based on the last one that does this,
although it probably needs to be changed to allow for an rcParam
'legend.scatterplot' (I don't really know the procedure for adding a
new rcParam).
On Mon, Oct 20, 2008 at 3:22 AM, Erik Tollerud <eri...@gm...> wrote:
> The current patch looks good to me... it satisfies all the use cases I
> had in mind, and I can't think of much else that would be wanted.
> Thanks!
>
> I also very much like the idea of the "sizebar," although that's
> probably a substantially larger job to implement. I may look into it
> though, time permitting...
>
> On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>> To help clarify the original purpose of "update_from": I wrote this
>>> method when writing the original legend implementation so the legend
>>> proxy objects could easily copy their style attributes from the
>>> underlying objects they were a proxy for (so not every property is
>>> copied, eg the xdata for line objects is not copied). So the
>>> operating question should be: what properties do I need to copy to
>>> make the legend representation of the object. While you are in
>>> there, perhaps you could clarify this in the docstrings of the
>>> update_from method.
>>
>> Thanks for clarifying this, John.
>>
>> Manuel,
>> The patch looks good to me. We may submit the patch (I hope Erik is
>> okay with the current patch) and it would be great if you handle the
>> submission.
>>
>> -JJ
>>
>>
>>
>>
>>
>> On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <mm...@as...> wrote:
>>> Jae-Joon Lee wrote:
>>>> Thanks Manuel.
>>>>
>>>> Yes, we need rotation value and etc, but my point is, do we need to
>>>> update it within the update_from() method? Although my preference is
>>>> not to do it, it may not matter much as far as we state what this
>>>> method does clearly in the doc.
>>>
>>> Okay, it's probably better to create the object correctly (numsides ...)
>>> instead of copying the properties (see also JDHs mail !)
>>>
>>>> And, in your patch, I don't think updating the numsides value has any
>>>> effect as it does not recreate the paths.
>>>>
>>>> I'm attaching the revised patch. In this patch, update_from() only
>>>> update gc-related properties. And numsides, size, and rotations are
>>>> given during the object creation time.
>>>
>>> Yes, this looks better. But creating handle_sizes is a little bit too
>>> much effort. This is done internally. It will do passing a sizes list,
>>> that may or may not be shorter/longer than numpoints (see revised patch).
>>>
>>> I also changed the way the yoffsets are updated in _update_positions().
>>>
>>> One additional thing I have in mind (for a later time) is a "sizesbar"
>>> similar to a colorbar where you can read off values corresponding to
>>> marker sizes...
>>>
>>> Cheers,
>>> Manuel
>>>
>>>> Erik,
>>>> I see your points. My main concern is that the yoffsets makes the
>>>> results a bit funny when numpoints is 2. The attached patch has a
>>>> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only
>>>> introduced when numpints > 2 and you can also provide it as an
>>>> optional argument.
>>>>
>>>> Regards,
>>>>
>>>> -JJ
>>>>
>>>>
>>>> On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <mm...@as...> wrote:
>>>>> Manuel Metz wrote:
>>>>>> Jae-Joon Lee wrote:
>>>>>>> Hi Manuel,
>>>>>>>
>>>>>>> I think it is a good to introduce the update_from method in Collections.
>>>>>>> But, I'm not sure if it is a good idea to also update sizes, paths and
>>>>>>> rotation (in RegularPolyCoolection). My impression is that update_from
>>>>>>> method is to update gc related attributes. For comparison,
>>>>>>> Patch.update_from() does not update the path.
>>>>>> That's exactly the point why I wasn't fully happy with the patch. The
>>>>>> path is generated by the _path_generator, so instead of copying the path
>>>>>> it seems to be better to create an instance of the corresponding class
>>>>>> (e.g. the StarPolygonCollection class, as suggested before).
>>>>>>
>>>>>> One should update the rotation attribute (!!); it's only one number. A
>>>>>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
>>>>>> rotation=pi/4. That's the only difference between those two !
>>>>>>
>>>>>>> Also, is it okay to update properties without checking its length?. It
>>>>>>> does not seem to cause any problems though.
>>>>>> It's in principal not a problem to copy the sizes attribute without
>>>>>> checking the length. If it's shorter the the number of items the sizes
>>>>>> are repeated; if it's longer it gets truncated.
>>>>>>
>>>>>> mm
>>>>>>
>>>>>>> I guess It would better to use xdata_markers than xdata in the
>>>>>>> get_handle() method. The difference is when numpoints==1. Using xdata
>>>>>>> gives two marker points.
>>>>>>>
>>>>>>> I was actually about to to commit my patch. I'll try to account your
>>>>>>> changes and post my version of patch later today.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> -JJ
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>>>>>>> hmm
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Jae-Joon Lee wrote:
>>>>>>>>>> - the parameter numpoints should be used (it's ignored right now)
>>>>>>>>>>
>>>>>>>>> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> - Some private variables are accessed and a new RegularPolycollection is
>>>>>>>>>> created (does this work eg. with a StarPolygonCollection? I haven't
>>>>>>>>>> checked, but I don't think so !). Instead of creating a new
>>>>>>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>>>>>>> existing object... I was thinking about a update_from() method for the
>>>>>>>>>> Collection class(es) similar to update_from() for lines.
>>>>>>>>>>
>>>>>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>>>>>>> StarPolygonCollection.
>>>>>>>>>
>>>>>>>>> In Erik's current implementation, the markers in the legend have
>>>>>>>>> varying colors, sizes, and y offsets.
>>>>>>>>> The color variation seems fine. But do we need to vary the sizes and
>>>>>>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>>>>>>> y offset. How does Erik and others think?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> -JJ
>>>>>>>> Attached is my current version of the patch. I've moved all of the
>>>>>>>> properties-copying stuff to collections, which makes the changes
>>>>>>>> legend.py more clearer (but I'm not fully happy with the patch and
>>>>>>>> haven't commit anything yet)
>>>>>>>>
>>>>>>>> mm
>>>>>>>>
>>>>> Hi Jae-Joon,
>>>>> so here is my revised version of the patch. What do you think ?
>>>>>
>>>>> Manuel
>>>>>
>>>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
2142 Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2587
Cell: (651)307-9409
eto...@uc...

On Mon, Oct 20, 2008 at 12:12 PM, Christopher Barker
<Chr...@no...> wrote:
> Ben North wrote:
>
>> I tend to use matplotlib over an X connection,
Yep, we know this reason. Lee stated he was on a windows box, which
doesn't rule out X11 forwarding but makes it less likely, so I was
wondering if there was another reason.
I went ahead and applied the patch so those of you using native
backend wx can test his image support enhancements.
JDH

Ben North wrote:
> I tend to use matplotlib over an X connection,
well, I think that is THE reason to choose wx over wxAgg (or GTK over 
GTKAgg). However, I thought the newer versions of the wx back-end double 
buffered, and thus pretty much eliminated the advantage anyway.
Also note that last I looked into it, wxAgg was doing some extra 
unneeded blitting of the image to the screen, which makes little 
noticeable difference usually. but you might really feel that over an 
remote X connection.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Hope nobody minds if I jump into this discussion:
> Date: 2008年10月20日 07:55:06 -0500
> From: "John Hunter" <jd...@gm...>
>
> [...] could you tell us why you prefer or require backend wx over wxagg?
I tend to use matplotlib over an X connection, because the data I'm
working with is on a Linux system whereas the machine I sit in front of
is a Windows system. I therefore run python on the Linux machine, using
my Windows machine just as an X server. I use the WX backend rather
than WXAgg because WX is much more responsive for interactive use, e.g.,
zooming/panning. I'm willing to give up the much better-looking WXAgg
output to gain responsiveness. For final output, I tend to save as EPS
anyway.
Don't know whether this is a widespread use case, but thought I'd
mention it in case.
[Apologies if this message doesn't get threaded properly; I'm replying
to the digest.]

On Mon, Oct 20, 2008 at 10:40 AM, Lee Kamentsky <le...@br...> wrote:
> Thanks for your reply, John. It's mostly me being naive - my code works
> great when I choose WXAgg as my backend. I'll be using that for now. Feel
> free to accept / reject or ask for fixes to the patch.
OK, thanks. You may want to see this FAQ for more details on the backends
http://matplotlib.sourceforge.net/faq/installing_faq.html#what-is-a-backend
JDH

Thanks for your reply, John. It's mostly me being naive - my code works 
great when I choose WXAgg as my backend. I'll be using that for now. 
Feel free to accept / reject or ask for fixes to the patch.
--Lee
John Hunter wrote:
> On Mon, Oct 20, 2008 at 7:51 AM, Lee Kamentsky <le...@br...> wrote:
> 
>> Hi all,
>> I've submitted a patch to
>> matplotlib/lib/matplotlib/backends/backend_wx.py on the bug tracker
>> (http://sourceforge.net/tracker2/?func=detail&aid=2166139&group_id=80706&atid=560722
>> ). I'd appreciate feedback on it and am looking forward to the
>> functionality making it into an upcoming release.
>>
>> Briefly, the patch fixes a bug when running under Windows and implements
>> draw_image for the backend.
>> 
>
> We'll be happy to take a look at this, but since we are trying to
> figure out whether we should keep backend_ex at all, could you tell us
> why you prefer or require backend wx over wxagg?
>
> Thanks,
> JDH
> 

While trying to plot filled-circle markers without stroked edges, I believe
I've uncovered inconsistent behavior when markeredgewidth = 0. The attached
script creates a series of plots with 'o' markers; the plots are created
with and without connecting lines and with markeredgewidth alternating
between zero and nonzero values. In the PNG output (from the WxAgg
backend), when markeredgewidth = 0, the circles are unstroked and have the
desired size, which is what I expected. In the EPS output, however, when
markeredgewidth = 0, both the width and color seem to be inherited from
their prior values when linestyle = 'None' and from the line's attributes
when linestyle = '-'. In the PDF output, when markeredgewidth = 0, the
markers have hairline edges. My matplotlib version is 0.98.3, rev. 6281.
I worked around the issue by setting markeredgewidth to a small nonzero
value and markeredgecolor to match the marker face.
Does anyone see how to make the behavior consistent across these output
formats?
Thank you, developers, for an extensive and capable package.

On Mon, Oct 20, 2008 at 10:19 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Oct 20, 2008 at 9:01 AM, David Huard <dav...@gm...> wrote:
>
>> I would oppose any change to histogram calling convention that does not
>> fix a critical bug. I agree that using a built-in name as an argument is
>> a bug, but I believe it is the lesser evil compared to asking users to
>> change their code
>> again.
>
It may not have been clear enough, but let me clarify that I was
opposing a change to numpy.histogram, not meddling in matplotlib's
hist.
Cheers,
David
> I think in this case we have to change it, but we can do it gently.
> Ie, for a release cycle, if we detect "range" in the kwarg case, we'll
> set the correct kwarg, eg "binrange", issue a warning, but not raise
> an error. That way users can fairly easily change their code w/o
> breakage. Whoever does the deprecation should note the date and
> version of the deprecation warning, so we will know when enough time
> and releases have passed to remove range entirely.
>
> JDH
>