matplotlib-users Mailing List for matplotlib

On Wed, Dec 17, 2008 at 1:19 PM, Ken Schutte <kts...@gm...> wrote:
> It might be nice if eventually there were extra styles, e.g. "-|>", "<|-|>"
> for single lines with solid arrowheads
This is now added in the trunk.
-JJ

John,
I updated api_chages.rst (but you'd better check my english). I also
made a few changes so that a warning is issued when deprecated
parameters are used in rc file. I deleted deprecated parameters in
lib/matplotlib/rcsetup.py and also from
lib/matplotlib/mpl-data/matplotlib.conf.template. I did my own test
and it worked well for me, and I hope it does not cause any problem.
Regards,
-JJ
On Fri, Dec 19, 2008 at 9:44 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Dec 19, 2008 at 8:36 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> The legend class has been reimplemented recently and the name of some
>> keyword arguments (and their meaning) has been changed. Those
>> parameters you're using are deprecated ones. It is supposed to show
>> you some warnings if deprecated parameters are used, so what you see
>> is a bug. I'll take a look. I also noticed that the documentaion of
>> the pylab.legend is outdated. Take a look at
>
> Jae-Joon,
>
> I don't think these changes ever made it into doc/api/api_changes.rst.
> Could you update that file in the branch, and I'll push it out the
> web site.
>
> Thanks,
> JDH
>

OK:
Downloaded latest (Friday, Dec 19: 1200 Pacific Time) egg and mpkg from 
sourceforge:
egg:
* cleared out all previous installs and cleaned out easy_install.pth file.
* easy_install matplotlib-0.98.5.2-py2.5.egg
Whoo hoo! all works great!
* cleared it all out again...
* Installed the mpkg
Whoo Hoo! another success!
One note on the mpkg -- it's called:
Matplotlib-0.98.5.2-py2.5-macosx10.5.mpkg
but it seems to work fine on 10.4 as well as 10.5 -- perhaps a re-naming 
is in order to save some confusion.
Mac OS-C 10.4.11 Dual G5 PPC - python.org Python 2.5.2
Thanks for everyone's work getting this put together.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Ramiro Simões Lopes wrote:
> Thanks, it works.
> But I also found out that I was setting figsize to a smaller size than 
> the plot was occupying thus it wasn't working. The anchor kwarg isn't 
> needed if the figure is big enough.
> 
> I still don't understand why the axes aspect ratio should depend on 
> figsize though.
> I mean, if I set figsize=(10,10) and plot everything, it works. But if I 
> set it to like (10,15) then the axes have spacing between them in the 
> vertical direction, even though I'm very specific about the coordinates.
> How can 0.01 mean one thing in the horizontal direction and other in the 
> vertical direction?
> 
> Ramiro
Ramiro,
(When corresponding on the list, please use "reply to all" so that 
everything stays on the list.)
First, the 0.01 is 0.01 times the figure width for the horizontal, and 
0.01 times the figure height for the vertical, so they are different 
physical dimensions if the figure aspect ratio is not 1:1. Second, 
setting the aspect='equal' tells mpl to *adjust* the axes box so that it 
 has a 1:1 aspect ratio *regardless* of the figure dimensions. It can 
only do this by adding space, either on the sides or top and bottom.
Eric
> 
> 
> 
> 2008年12月18日 Eric Firing <ef...@ha... <mailto:ef...@ha...>>
> 
> ramirodsl wrote:
> 
> Can someone explain to me how/why the figure normalized [0,1]
> coordinates
> depends on the figsize property? At least this is what it looks
> like to me.
> This affects axes placement and so far I haven't been able to do
> what I
> want.
> 
> I want to have square plots placed without spacing between them
> and with a
> little margin on the left and top. So I tried:
> 
> s=0.4
> axes([0.01, 0.99-s, s, s],aspect='equal')
> axes([0.01+s, 0.99-s, s, s],aspect='equal')
> axes([0.01, 0.99-2*s, s, s],aspect='equal')
> axes([0.01+s, 0.99-2*s, s, s],aspect='equal')
> 
> The vertical positioning works as I expected but the x
> positioning does not
> work. The axes have spacing between them - which means that 0.1
> represents a
> different size in x or in y - and I just can't understand that
> behavior.
> 
> 
> The problem is that you are giving conflicting instructions. Your
> axes command is initially saying to make the boxes with the given
> proportions of the figure, regardless of the dimensions or aspect
> ratio of that figure; but setting the aspect is overriding that by
> requiring the boxes to be square. You can still get the behavior
> you want, however, by adding an anchor kwarg to each axes call. To
> make sure the
> boxes cluster together, add anchor='SE' to the upper left axes,
> anchor='SW' to the upper right, and 'NE' and 'NW' to the lower left
> and right, respectively.
> 
> Eric
> 
> 
> Now if I add:
> figure(figsize=(5,5))
> it works
> 
> But this is not the solution I need because the real plot I'm
> trying to do
> is a 6x5 (6 axes per 5 axes, subplots if you mean) plot with
> horizontal
> spacing only between the 3rd and 4th axes. There is no way I
> could now the
> correct aspect ratio that I should set figsize to, to get it right.
> 
> How could I manage this?
> 
> Thank you
> 
> Ramiro
> 
> 
> 

On Fri, Dec 19, 2008 at 18:47, Ondrej Certik <on...@ce...> wrote:
> On Fri, Dec 19, 2008 at 6:34 PM, Sandro Tosi <mo...@de...> wrote:
>> This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
>> on uploading it Debian, together with John and Michael (and all dev
>> team), to have a feasable release.
>
> Ah, I didn't know you are on the mpl dev team as well. That's great.
Oh no no: I bother them for something, and they (to force me to
silence) release a fix :D
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Fri, Dec 19, 2008 at 6:34 PM, Sandro Tosi <mo...@de...> wrote:
> Hello Ondrej,
>
> On Fri, Dec 19, 2008 at 18:18, Ondrej Certik <on...@ce...> wrote:
>> we got this Debian bug:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
> ...
>> I tested that this applies to 0.98.3. Is this a bug?
>
> This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
> on uploading it Debian, together with John and Michael (and all dev
> team), to have a feasable release.
Ah, I didn't know you are on the mpl dev team as well. That's great.
Ondrej

Hello Ondrej,
On Fri, Dec 19, 2008 at 18:18, Ondrej Certik <on...@ce...> wrote:
> we got this Debian bug:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
...
> I tested that this applies to 0.98.3. Is this a bug?
This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
on uploading it Debian, together with John and Michael (and all dev
team), to have a feasable release.
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi,
we got this Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
Citing:
"
the following python code creates a histogram with an x-axis range of
0.1 min to 0.3 max (based on the mins and maxes of the x rather than bin).
the bins should be used to size the axis since the user specified that
he wanted to see those specific bins (even though they are empty). note
that the 'range=' option would be a potential solution, but it is ignored
when bin is a sequence (presumably because the range would be chosen
based on bin's limits, but this isn't so).
 from pylab import *
 x = [0.18,0.22,0.19]
 bin = [0,0.1,0.2,0.3,0.4,0.5]
 hist(x,bin)
 show()
i believe that the x-axis ranges should instead be based on the mins and
maxes of bin when it is a sequence.
please forward this report upstream or let me know if you believe that it
belongs there.
thank you for your consideration
"
I tested that this applies to 0.98.3. Is this a bug?
Thanks,
Ondrej

On Fri, Dec 19, 2008 at 8:36 AM, Jae-Joon Lee <lee...@gm...> wrote:
> The legend class has been reimplemented recently and the name of some
> keyword arguments (and their meaning) has been changed. Those
> parameters you're using are deprecated ones. It is supposed to show
> you some warnings if deprecated parameters are used, so what you see
> is a bug. I'll take a look. I also noticed that the documentaion of
> the pylab.legend is outdated. Take a look at
Jae-Joon,
I don't think these changes ever made it into doc/api/api_changes.rst.
 Could you update that file in the branch, and I'll push it out the
web site.
Thanks,
JDH

The legend class has been reimplemented recently and the name of some
keyword arguments (and their meaning) has been changed. Those
parameters you're using are deprecated ones. It is supposed to show
you some warnings if deprecated parameters are used, so what you see
is a bug. I'll take a look. I also noticed that the documentaion of
the pylab.legend is outdated. Take a look at
http://matplotlib.sourceforge.net/api/artist_api.html#module-matplotlib.legend
These are lists of deprecated parameteres
 pad = None, # deprecated; use borderpad
 labelsep = None, # deprecated; use labelspacing
 handlelen = None, # deprecated; use handlelength
 handletextsep = None, # deprecated; use handletextpad
 axespad = None, # deprecated; use borderaxespad
So,
 pylab.rc('legend', borderaxespad=0.0, borderpad=0.0,
handlelength=0.0, labelspacing=0.0)
should work.
Thanks,
-JJ
On Fri, Dec 19, 2008 at 3:25 AM, Lebostein <Leb...@gm...> wrote:
>
> Hi,
>
> please open the legend_demo3:
> http://matplotlib.sourceforge.net/plot_directive/mpl_examples/pylab_examples/legend_demo3.py
>
> 1. add this line:
> pylab.rc('legend', axespad=0.0, pad=0.0, handlelen=0.0, labelsep=0.0)
>
> 2. add this line:
> pylab.rc('legend', axespad=10.0, pad=10.0, handlelen=10.0, labelsep=10.0)
>
> Why all these parameters have no effect? In this two cases I see the same
> plot...
> --
> View this message in context: http://www.nabble.com/legend%3A-axespad%2C-pad%2C-handlelen%2C-labelsep---without-effect-tp21087472p21087472.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Can you please provide a screenshot of what you are seeing?
I don't run Mac OS-X myself, so have no experience with the Mac 
OS-X-specific backend... however, it appears to be drawing regular text 
with native APIs (ATSUI etc.) and mathtext using matplotlib's freetype 
backend and blitting an image. If done correctly, there is no reason 
why one should be significantly lower quality than the other, but it is 
an obvious source of *difference*, particularly if font size is being 
handled differently in each case.
I would suggest to Michiel de Hoon (author of Mac OS-X backend), to 
implement a full interface to mathtext for his backend (as PDF does, for 
instance) and do all glyph rendering with ATSUI, or the opposite -- do 
all glyph rendering by blitting freetype-rendered glyphs -- but not 
both. I have some concerns about the use of ATSUI, which, while 
arguably the better text system, will give different results than the 
Agg backends and cause cross-platform differences between plots, which 
is something in general we like to avoid.
Cheers,
Mike
Zane Selvans wrote:
> First, *thank you* to whoever did the Mac OS X backend. It's much 
> faster and smoother, and seems to behave much more reasonably all 
> around. As in, show() actually does what it says it's supposed to do, 
> and the figures don't have to be re-sized to draw themselves!
>
> However, there seems to be some kind of strangeness with using 
> mathtext. When an axis label, tick label, title, or other text has 
> any mathtext embedded within it, the font that the entire text object 
> is rendered in changes, becoming larger, and often fuzzier (in an 
> anti-aliased kind of way).
>
> On the plus (though confusing) side, the ticklabels that are being 
> output by the basemap toolkit are now the same size as all my normal 
> ticklabels, even though they appear to contain a mathtext character 
> (the ^\circ for the degrees symbol), whereas previously, all the 
> basemap ticklabels were coming out larger than the rest of my 
> ticklabels, and I didn't seem to be able to alter them in the normal 
> text object manipulation ways.
>
> I'm running on:
> Matplotlib SVN: v6677
> Mac OS 10.5.6
> macosx backend
> python 2.5.1
> ipython 0.9.1
>
> After I noticed this the first time, I quit out of the interpreter, 
> and deleted the font cache from my .matplotlib directory, restarted, 
> and the problem persisted.
>
> Any suggestions? I don't have any of the alternate tex rendering 
> options set in my rcfile, just using plain mathtext.
>
> --
> Zane Selvans
> Amateur Earthling
> za...@id... <mailto:za...@id...>
> 303/815-6866
> http://zaneselvans.org
> PGP Key: 55E0815F
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
please open the legend_demo3:
http://matplotlib.sourceforge.net/plot_directive/mpl_examples/pylab_examples/legend_demo3.py
1. add this line:
pylab.rc('legend', axespad=0.0, pad=0.0, handlelen=0.0, labelsep=0.0)
2. add this line:
pylab.rc('legend', axespad=10.0, pad=10.0, handlelen=10.0, labelsep=10.0)
Why all these parameters have no effect?
-- 
View this message in context: http://www.nabble.com/legend%3A-axespad%2C-pad%2C-handlelen%2C-labelsep---without-effect-tp21087472p21087472.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Dear all,
I'm using matplotlib together with ipython --pylab and have a plot 
open and can select/deselect points there with the picker and they 
toggle between o and x. When I do that my matplotlib running under 
Leopard 10.5.6 and MacOSX backend raises an exception:
------------------------------------
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/ 
backend_bases.pyc in button_press_event(self, x, y, button, guiEvent)
 1147 s = 'button_press_event'
 1148 mouseevent = MouseEvent(s, self, x, y, button, 
self._key, guiEvent=guiEvent)
-> 1149 self.callbacks.process(s, mouseevent)
 1150
 1151 def button_release_event(self, x, y, button, 
guiEvent=None):
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/cbook.pyc 
in process(self, s, *args, **kwargs)
 153 self._check_signal(s)
 154 for func in self.callbacks[s].values():
--> 155 func(*args, **kwargs)
 156
 157
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/ 
backend_bases.pyc in pick(self, mouseevent)
 1052 def pick(self, mouseevent):
 1053 if not self.widgetlock.locked():
-> 1054 self.figure.pick(mouseevent)
 1055
 1056 def blit(self, bbox=None):
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/artist.pyc 
in pick(self, mouseevent)
 271 # Pick children
 272 for a in self.get_children():
--> 273 a.pick(mouseevent)
 274
 275 def set_picker(self, picker):
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/axes.pyc 
in pick(self, *args)
 2483 raise DeprecationWarning('New pick API 
implemented -- '
 2484 'see API_CHANGES in the 
src distribution')
-> 2485 martist.Artist.pick(self,args[0])
 2486
 2487 def __pick(self, x, y, trans=None, among=None):
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/artist.pyc 
in pick(self, mouseevent)
 271 # Pick children
 272 for a in self.get_children():
--> 273 a.pick(mouseevent)
 274
 275 def set_picker(self, picker):
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/artist.pyc 
in pick(self, mouseevent)
 267 inside,prop = self.contains(mouseevent)
 268 if inside:
--> 269 self.figure.canvas.pick_event(mouseevent, 
self, **prop)
 270
 271 # Pick children
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/ 
backend_bases.pyc in pick_event(self, mouseevent, artist, **kwargs)
 1113 s = 'pick_event'
 1114 event = PickEvent(s, self, mouseevent, artist, 
**kwargs)
-> 1115 self.callbacks.process(s, event)
 1116
 1117 def scroll_event(self, x, y, step, guiEvent=None):
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/cbook.pyc 
in process(self, s, *args, **kwargs)
 153 self._check_signal(s)
 154 for func in self.callbacks[s].values():
--> 155 func(*args, **kwargs)
 156
 157
/Users/wkerzend/scripts/python/pyphot/plot/statplot.pyc in 
__call__(self, event)
 52 if 
self.selected.has_key(artist):self.togglemarker(dot_artist)
 53 else:
---> 54 self.togglemarker(dot_artist)
 55
 56 def togglemarker(self,artist,on_mark='o',off_mark='x'):
/Users/wkerzend/scripts/python/pyphot/plot/statplot.pyc in 
togglemarker(self, artist, on_mark, off_mark)
 68 if 
type(self.selected)==list:self.selected[sel_index]=True
 69 elif 
type(self.selected)==dict:self.selected[artist]=True
---> 70 self.axis.draw()
 71
 72 class keyhandler:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/axes.pyc 
in draw(self, renderer, inframe)
 1535 # will draw the edges
 1536 if self.axison and self._frameon:
-> 1537 self.patch.draw(renderer)
 1538
 1539 artists = []
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/ 
patches.pyc in draw(self, renderer)
 267 if not self.get_visible(): return
 268 #renderer.open_group('patch')
--> 269 gc = renderer.new_gc()
 270
 271 if cbook.is_string_like(self._edgecolor) and 
self._edgecolor.lower()=='none':
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib-0.98.4-py2.5-macosx-10.3.egg/matplotlib/backends/ 
backend_macosx.pyc in new_gc(self)
 66
 67 def new_gc(self):
---> 68 self.gc.reset()
 69 return self.gc
 70
RuntimeError: CGContextRef is NULL
-------------------------------------------------
I'm also using start_event_loop and stop event_loop to make the 
application blocking when starting and unblocking when finished. The 
application works its just annoying seeing this traceback everytime I 
select or deselect a point.
Another thing that sort of worked under linux was that when I clicked, 
it would change immediatley and not wait until I do a refit. Any ideas 
on what to do there?
Thanks
 Wolfgang

ramirodsl wrote:
> Can someone explain to me how/why the figure normalized [0,1] coordinates
> depends on the figsize property? At least this is what it looks like to me.
> This affects axes placement and so far I haven't been able to do what I
> want.
> 
> I want to have square plots placed without spacing between them and with a
> little margin on the left and top. So I tried:
> 
> s=0.4
> axes([0.01, 0.99-s, s, s],aspect='equal')
> axes([0.01+s, 0.99-s, s, s],aspect='equal')
> axes([0.01, 0.99-2*s, s, s],aspect='equal')
> axes([0.01+s, 0.99-2*s, s, s],aspect='equal')
> 
> The vertical positioning works as I expected but the x positioning does not
> work. The axes have spacing between them - which means that 0.1 represents a
> different size in x or in y - and I just can't understand that behavior.
The problem is that you are giving conflicting instructions. Your axes 
command is initially saying to make the boxes with the given proportions 
of the figure, regardless of the dimensions or aspect ratio of that 
figure; but setting the aspect is overriding that by requiring the boxes 
to be square. You can still get the behavior you want, however, by 
adding an anchor kwarg to each axes call. To make sure the
boxes cluster together, add anchor='SE' to the upper left axes, 
anchor='SW' to the upper right, and 'NE' and 'NW' to the lower left and 
right, respectively.
Eric
> 
> Now if I add:
> figure(figsize=(5,5))
> it works
> 
> But this is not the solution I need because the real plot I'm trying to do
> is a 6x5 (6 axes per 5 axes, subplots if you mean) plot with horizontal
> spacing only between the 3rd and 4th axes. There is no way I could now the
> correct aspect ratio that I should set figsize to, to get it right.
> 
> How could I manage this?
> 
> Thank you
> 
> Ramiro