matplotlib-users Mailing List for matplotlib

FormatStrFormatter (and other formatters) rely on Python's string
interpolation, and It does not seem to be possible to get rid of the
leading zero (http://docs.python.org/library/stdtypes.html).
I think what you can do is to replace "0." with "." after the
interpolation. Something like below works for me.
from matplotlib.ticker import ScalarFormatter
s = subplot(111)
class ScalarFormatterNoLeadingZero(ScalarFormatter):
 def pprint_val(self, x):
 s = ScalarFormatter.pprint_val(self, x)
 return s.replace("0.",".")
s.xaxis.set_major_formatter(ScalarFormatterNoLeadingZero())
HTH,
-JJ
On Sat, Feb 28, 2009 at 4:52 PM, per freem <per...@gm...> wrote:
> hi all,
>
> when i make any numeric scatter plot containing floats, the formatted tick
> labels always have leading zeros, e.g "0.5" as opposed to ".5" in the
> labels.
>
> for example:
>
> x = rand(10)
> scatter(x,x)
>
> is there any way to change this to remove the leading zeros? i have tried:
>
> s = subplot(111)
> majorFormatter = FormatStrFormatter('%0.1f')
> s.xaxis.set_major_formatter(majorFormatter)
> scatter(x,x)
>
> but it does not work. i also tried "%.f" but it does not work either. the
> matlab default is to plot without the leading zero and i am trying to
> recreate this.
>
> thank you.
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

On Sat, Feb 28, 2009 at 5:31 PM, per freem <per...@gm...> wrote:
> thank you for your reply. when i try either of the first suggestions about
> changing the fonts, i get the error:
>
> AttributeError: 'FontProperties' object has no attribute 'get_slant'
>
> any idea what this means?
It seems that you're using v0.98.3 or before. See if following code works.
from matplotlib.font_manager import FontProperties
def my_hash(self):
 l = [self.get_family(),
 self.get_style(),
 self.get_variant(),
 self.get_weight(),
 self.get_stretch(),
 self.get_size()]
 return hash(repr(l))
FontProperties.__hash__ = my_hash
>
> also, i do not mind setting the position of each tickmark individually but i
> cannot find a way to do this -- could you please explain how this can be
> done?
>
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.xticks
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.yticks
-JJ
> thanks again.
>
>
> On Sat, Feb 28, 2009 at 5:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> > but it does not work. i tried similarly setting the font size (with
>> > set_size() or through rcParams) but it did not work either. how can i do
>> > this? i'd like to do this either on per axes basis, or for the entire
>> > figure.
>>
>> It seems that changing rcParams is not effective because of the way
>> how the font caching is done. Here is a little monkey patching to
>> change this behavior.
>>
>> from matplotlib.font_manager import FontProperties
>>
>> def my_hash(self):
>>  l = dict([(k, getattr(self, "get" + k)()) for k in self.__dict__])
>>  return hash(repr(l))
>>
>> FontProperties.__hash__ = my_hash
>>
>>
>> With this code, changing rcParams will affect (most of) the text in the
>> figure.
>>
>> As far as I know, you cannot have a default font properties on per
>> axes basis. You need to manually change the font properties of Text
>> artists in your interests.
>>
>> For example, to change the font properties of the xtick labels,
>>
>> fp = FontProperties(family="Lucida Sans Typewriter")
>> ax = gca()
>> for t in ax.get_xticklabels():
>>  t.set_fontproperties(fp)
>>
>>
>> >
>> > second, how can i make it so axes labels do not overlap? in many plots,
>> > including ones in the gallery, you see the labels at the origin of plots
>> > get
>> > too close to each other. (i.e. the 0.0 of x-axis and 0.0 of y-axis) -
>> > how
>> > can you prevent this from happening?
>> >
>>
>> I don't think there is a smart way to prevent it other than manually
>> changing the tick positions. Other may have better ideas.
>>
>> -JJ
>
>

thank you for your reply. when i try either of the first suggestions about
changing the fonts, i get the error:
AttributeError: 'FontProperties' object has no attribute 'get_slant'
any idea what this means?
also, i do not mind setting the position of each tickmark individually but i
cannot find a way to do this -- could you please explain how this can be
done?
thanks again.
On Sat, Feb 28, 2009 at 5:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
> > but it does not work. i tried similarly setting the font size (with
> > set_size() or through rcParams) but it did not work either. how can i do
> > this? i'd like to do this either on per axes basis, or for the entire
> > figure.
>
> It seems that changing rcParams is not effective because of the way
> how the font caching is done. Here is a little monkey patching to
> change this behavior.
>
> from matplotlib.font_manager import FontProperties
>
> def my_hash(self):
> l = dict([(k, getattr(self, "get" + k)()) for k in self.__dict__])
> return hash(repr(l))
>
> FontProperties.__hash__ = my_hash
>
>
> With this code, changing rcParams will affect (most of) the text in the
> figure.
>
> As far as I know, you cannot have a default font properties on per
> axes basis. You need to manually change the font properties of Text
> artists in your interests.
>
> For example, to change the font properties of the xtick labels,
>
> fp = FontProperties(family="Lucida Sans Typewriter")
> ax = gca()
> for t in ax.get_xticklabels():
> t.set_fontproperties(fp)
>
>
> >
> > second, how can i make it so axes labels do not overlap? in many plots,
> > including ones in the gallery, you see the labels at the origin of plots
> get
> > too close to each other. (i.e. the 0.0 of x-axis and 0.0 of y-axis) - how
> > can you prevent this from happening?
> >
>
> I don't think there is a smart way to prevent it other than manually
> changing the tick positions. Other may have better ideas.
>
> -JJ
>

> but it does not work. i tried similarly setting the font size (with
> set_size() or through rcParams) but it did not work either. how can i do
> this? i'd like to do this either on per axes basis, or for the entire
> figure.
It seems that changing rcParams is not effective because of the way
how the font caching is done. Here is a little monkey patching to
change this behavior.
from matplotlib.font_manager import FontProperties
def my_hash(self):
 l = dict([(k, getattr(self, "get" + k)()) for k in self.__dict__])
 return hash(repr(l))
FontProperties.__hash__ = my_hash
With this code, changing rcParams will affect (most of) the text in the figure.
As far as I know, you cannot have a default font properties on per
axes basis. You need to manually change the font properties of Text
artists in your interests.
For example, to change the font properties of the xtick labels,
fp = FontProperties(family="Lucida Sans Typewriter")
ax = gca()
for t in ax.get_xticklabels():
 t.set_fontproperties(fp)
>
> second, how can i make it so axes labels do not overlap? in many plots,
> including ones in the gallery, you see the labels at the origin of plots get
> too close to each other. (i.e. the 0.0 of x-axis and 0.0 of y-axis) - how
> can you prevent this from happening?
>
I don't think there is a smart way to prevent it other than manually
changing the tick positions. Other may have better ideas.
-JJ

hi all,
when i make any numeric scatter plot containing floats, the formatted tick
labels always have leading zeros, e.g "0.5" as opposed to ".5" in the
labels.
for example:
x = rand(10)
scatter(x,x)
is there any way to change this to remove the leading zeros? i have tried:
s = subplot(111)
majorFormatter = FormatStrFormatter('%0.1f')
s.xaxis.set_major_formatter(majorFormatter)
scatter(x,x)
but it does not work. i also tried "%.f" but it does not work either. the
matlab default is to plot without the leading zero and i am trying to
recreate this.
thank you.

Jae-Joon Lee wrote:
> Hi Erick,
> 
> Is there any particular reason to introduce _xaxison and _yaxison,
> instead of using set_visible(False) on the xaxis and yaxis? Just
> wondering..
Good catch--I just didn't think of it. That is a much better solution. 
 I'll do it shortly.
Thank you.
Eric
> 
> -JJ
> 
> 
> 
> On Sat, Feb 28, 2009 at 1:52 PM, Eric Firing <ef...@ha...> wrote:
>> Christoffer Aberg wrote:
>>> Hi all,
>>>
>>> I have noticed a funny behaviour when using twinx to do two plots on the
>>> same axes: the xticklabels are printed twice, once for each axes. This
>>> shows up as slightly thicker labels than for a single axes. It is
>>> particularly visible for ps or pdf output, but can be seen also in an
>>> interactive session.
>>>
>>> I can also see this in the figure shown for the two_scales.py example
>>> (http://matplotlib.sourceforge.net/_images/two_scales.png), where the
>>> xticklabels are thicker than the yticklabels (though it is not so
>>> apparent due to different colours. I therefore assume it is not just my
>>> installation. (Adding
>>>
>>> for tl in ax2.get_xticklabels():
>>> tl.set_fontsize(16)
>>>
>>> just before the last plt.show() in two_scales.py makes it even more
>>> visible)
>>>
>>> Does anyone know of a reasonable work-around? Surely it is not the
>>> intended behaviour?
>> It is now fixed in svn.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a 600ドル discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>

Sandro Tosi wrote:
> Hi!
> I have this configuration file:
> 
> $ cat matplotlibrc
> figure.figsize : 4, 3
> figure.dpi	 : 300
> savefig.dpi	 : 300
> font.size	 : 9.0
> 
> and using this code
> 
> import matplotlib.pyplot as plt
> plt.plot([1, 2, 3])
> plt.xlabel('This is the X axis')
> plt.ylabel('This is the Y axis')
> plt.savefig('7900_02_06.png')
> 
> I obtain the attached image that, as you can see, has xlabel tect cut.
> 
> What is the best way to avoid it? reducing the actual "plot" area
> (axes and line)? or reducing the font size?
> 
> Now that I look better at it, isn't it a bug after all? I see ylabel
> correctly rendered, and xlabel not (but it's late in the night, so I
> might be mistaken :) ) .
It is not really a bug; it is an inherent limitation in mpl's default 
automatic Axes positioning. Axes positions are given in normalized 
coordinates relative to the figure, so if you shrink the height of the 
figure (relative to the default, for which the default positioning 
parameters are designed), there is less physical space available for the 
x-axis ticks, ticklabels, and label--and things can get cut off. If you 
are adjusting the figsize and/or the font size, then chances are you 
need to adjust these normalized coordinate Axes position parameters as 
well. Trial and error is typically needed; it can be facilitated by 
using the subplot adjuster widget in an interactive window (second to 
last button on the toolbar) to decide what looks good. Then use the 
figure.subplot.* entries in matplotlibrc, or call 
plt.subplots_adjust(bottom=0.15) (for example), or call it as a method 
of the figure you have just created.
For doing the interactive adjustment, you will want to use a smaller 
figure dpi, something to match your screen. Everything will scale 
correctly when you save the figure at higher dpi.
Eric
> 
> Thanks in advance,
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi Erick,
Is there any particular reason to introduce _xaxison and _yaxison,
instead of using set_visible(False) on the xaxis and yaxis? Just
wondering..
-JJ
On Sat, Feb 28, 2009 at 1:52 PM, Eric Firing <ef...@ha...> wrote:
> Christoffer Aberg wrote:
>> Hi all,
>>
>> I have noticed a funny behaviour when using twinx to do two plots on the
>> same axes: the xticklabels are printed twice, once for each axes. This
>> shows up as slightly thicker labels than for a single axes. It is
>> particularly visible for ps or pdf output, but can be seen also in an
>> interactive session.
>>
>> I can also see this in the figure shown for the two_scales.py example
>> (http://matplotlib.sourceforge.net/_images/two_scales.png), where the
>> xticklabels are thicker than the yticklabels (though it is not so
>> apparent due to different colours. I therefore assume it is not just my
>> installation. (Adding
>>
>> for tl in ax2.get_xticklabels():
>>   tl.set_fontsize(16)
>>
>> just before the last plt.show() in two_scales.py makes it even more
>> visible)
>>
>> Does anyone know of a reasonable work-around? Surely it is not the
>> intended behaviour?
>
> It is now fixed in svn.
>
> Eric
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

hi all,
two quick questions about plotting: i am trying to very simply reset the
font family to be 'helvetica' for my figure, in particular for the
ticklabels. i have tried using the following:
def axes_square(plot_handle):
 plot_handle.axes.set_aspect(1/plot_handle.axes.get_data_ratio())
rcParams['font.family'] = 'Helvetica'
p = matplotlib.font_manager.FontProperties()
p.set_family('Helvetica')
x = rand(20)
ax = plot(x, x, 'bo', markeredgecolor='blue', mfc='none')
axes_square(p)
but it does not work. i tried similarly setting the font size (with
set_size() or through rcParams) but it did not work either. how can i do
this? i'd like to do this either on per axes basis, or for the entire
figure.
second, how can i make it so axes labels do not overlap? in many plots,
including ones in the gallery, you see the labels at the origin of plots get
too close to each other. (i.e. the 0.0 of x-axis and 0.0 of y-axis) - how
can you prevent this from happening?
thank you!

Christoffer Aberg wrote:
> Hi all,
> 
> I have noticed a funny behaviour when using twinx to do two plots on the
> same axes: the xticklabels are printed twice, once for each axes. This
> shows up as slightly thicker labels than for a single axes. It is
> particularly visible for ps or pdf output, but can be seen also in an
> interactive session.
> 
> I can also see this in the figure shown for the two_scales.py example
> (http://matplotlib.sourceforge.net/_images/two_scales.png), where the
> xticklabels are thicker than the yticklabels (though it is not so
> apparent due to different colours. I therefore assume it is not just my
> installation. (Adding
> 
> for tl in ax2.get_xticklabels():
> tl.set_fontsize(16)
> 
> just before the last plt.show() in two_scales.py makes it even more
> visible)
> 
> Does anyone know of a reasonable work-around? Surely it is not the
> intended behaviour?
It is now fixed in svn.
Eric

Hi,
I have a simple script that plots x,y vals in an animation called anim.py
data = read('data.dat')
for i in range(10):
 plot(data[:,0], data[:,1])
I am using ipython -pylab but when I do run anim.py it doesn't show
anything until I say show(). On the other hand, if I do one of these
plotting commands from the ipython terminal it shows up right away.
It seems that everything works fine once one thing has been plotted
from the ipython command line. Is there any way to fix this so that
it plots right away as expected?
Thanks,
Jon.

David,
This seems to work for me:
(here ax2 is the second axis)
The only work around I can see is to add
for tl in ax2.get_xticklabels():
 tl.set_visible(False)
To prevent the ticklines being drawn twice I guess we should also do
for tline in ax2.get_xticklines():
 tline.set_visible(False)
HTH, George.
2009年2月27日 David Huard <dav...@gm...>:
> I'd also be interested in a workaround. I tried to remove the tick labels
> from the second axe, but it also removed the labels from the first axe.
>
> Thanks,
>
> David
>
> On Sun, Feb 8, 2009 at 9:14 AM, Christoffer Aberg
> <Chr...@fk...> wrote:
>>
>> Hi all,
>>
>> I have noticed a funny behaviour when using twinx to do two plots on the
>> same axes: the xticklabels are printed twice, once for each axes. This
>> shows up as slightly thicker labels than for a single axes. It is
>> particularly visible for ps or pdf output, but can be seen also in an
>> interactive session.
>>
>> I can also see this in the figure shown for the two_scales.py example
>> (http://matplotlib.sourceforge.net/_images/two_scales.png), where the
>> xticklabels are thicker than the yticklabels (though it is not so
>> apparent due to different colours. I therefore assume it is not just my
>> installation. (Adding
>>
>> for tl in ax2.get_xticklabels():
>>  tl.set_fontsize(16)
>>
>> just before the last plt.show() in two_scales.py makes it even more
>> visible)
>>
>> Does anyone know of a reasonable work-around? Surely it is not the
>> intended behaviour?
>>
>> Thanks for any help,
>> Christoffer Åberg
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code
>> to
>> build responsive, highly engaging applications that combine the power of
>> local
>> resources and data with the reach of the web. Download the Adobe AIR SDK
>> and
>> Ajax docs to start building applications
>> today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi guys,
I was wondering if it's possible to rotate a legend ?
Thanks for your help.
Naoli

Hi!
I have this configuration file:
$ cat matplotlibrc
figure.figsize : 4, 3
figure.dpi	 : 300
savefig.dpi	 : 300
font.size	 : 9.0
and using this code
import matplotlib.pyplot as plt
plt.plot([1, 2, 3])
plt.xlabel('This is the X axis')
plt.ylabel('This is the Y axis')
plt.savefig('7900_02_06.png')
I obtain the attached image that, as you can see, has xlabel tect cut.
What is the best way to avoid it? reducing the actual "plot" area
(axes and line)? or reducing the font size?
Now that I look better at it, isn't it a bug after all? I see ylabel
correctly rendered, and xlabel not (but it's late in the night, so I
might be mistaken :) ) .
Thanks in advance,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello all, I'd like to create a "matplotlib.pyplot.figure(...)" object
and specify the size while I'm at it. I see this argument list from
the matplotlib's documentation:
pyplot.figure(num=None, figsize=(8, 6), dpi=80, facecolor='w', edgecolor='k')
The on-screen size is being computed using inches (for height and
width) and dpi. But I don't know what the dpi is in advance. What can
I do? In case it's relevant, I'm using Python 2.5 and the latest
download of matplotlib.
Thanks in advance.
-L

I'd also be interested in a workaround. I tried to remove the tick labels
from the second axe, but it also removed the labels from the first axe.
Thanks,
David
On Sun, Feb 8, 2009 at 9:14 AM, Christoffer Aberg <
Chr...@fk...> wrote:
> Hi all,
>
> I have noticed a funny behaviour when using twinx to do two plots on the
> same axes: the xticklabels are printed twice, once for each axes. This
> shows up as slightly thicker labels than for a single axes. It is
> particularly visible for ps or pdf output, but can be seen also in an
> interactive session.
>
> I can also see this in the figure shown for the two_scales.py example
> (http://matplotlib.sourceforge.net/_images/two_scales.png), where the
> xticklabels are thicker than the yticklabels (though it is not so
> apparent due to different colours. I therefore assume it is not just my
> installation. (Adding
>
> for tl in ax2.get_xticklabels():
> tl.set_fontsize(16)
>
> just before the last plt.show() in two_scales.py makes it even more
> visible)
>
> Does anyone know of a reasonable work-around? Surely it is not the
> intended behaviour?
>
> Thanks for any help,
> Christoffer Åberg
>
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK
> and
> Ajax docs to start building applications today-
> http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hansen, Dr. Jim wrote:
> Hello All
> 
> I'm making the transition from Matlab to Python/Pylab/matplotlib, etc. 
> 
> In Matlab contour plots I can specify the rotation angle of contour labels (e.g. rotation=0). I'm unable to figure out the equivalent in matplotlib's clabel. The inline documentation doesn't mention the option, but I'm confident there's a workaround.
with ipython -pylab:
CS = contour(rand(20,30))
tl = CS.clabel()
setp(tl, rotation=0)
Eric

Hello All
I'm making the transition from Matlab to Python/Pylab/matplotlib, etc. 
In Matlab contour plots I can specify the rotation angle of contour labels (e.g. rotation=0). I'm unable to figure out the equivalent in matplotlib's clabel. The inline documentation doesn't mention the option, but I'm confident there's a workaround.
Best,
Jim

I recommend you to use the Wedge class in matplotlib.patches.
from matplotlib.patches import Wedge
# draw a wedge in the axes coordinate. (0.5, 0.5) in axes coordinate
corresponds to (0,0) in polar coordinate.
trans = ax.transAxes
center, R = (0.5, 0.5), 0.5
twopi=360.
pie1 = Wedge(center, R, 0, r1*twopi, fc="g")
pie2 = Wedge(center, R, r1*twopi, r2*twopi, fc="y")
pie3 = Wedge(center, R, r2*twopi, twopi, fc="r")
for mypie in [pie1, pie2, pie3]:
 mypie.set_transform(trans)
 mypie.set_alpha(0.25)
 mypie.set_ec("none")
 ax.add_patch(mypie)
-JJ
On Thu, Feb 26, 2009 at 5:00 PM, bubye <joe...@gm...> wrote:
>
> I made a little more progress, but i'm not sure i'm doing this the right way.
> Suggestions?
>
> from pylab import *
> import numpy as np
>
> #generate random temperature data
> snp=[]
> for i in range(0,65):
>  snp.append(np.random.randint(35,122))
>
> #hide the labels. I don't want them.
> rc('xtick', labelsize=0)
> rc('ytick', labelsize=0)
>
> fig=figure(figsize=(8,8),facecolor='0.0')
>
> ax = fig.add_subplot(111,polar=True,frameon=False)
> tempTuple=array(snp)
> r = tempTuple/10
> theta = ((tempTuple*2.9508)*pi)/180
> area = r**2*(tempTuple/5.4)
> colors = theta
>
> #this is the fancy green,yellow,red background
> #it's actually a scatter plot that sits behind (zorder)
> #of the rest of the scatter plots.
>
> #radius
> r1 = 0.7   # 20%
> r2 = r1 + 0.2 # 40%
>
> # define some sizes of the scatter marker
> sizes = [55000]
> x = [0] + np.cos(np.linspace(0, 2*math.pi*r1, 100)).tolist()
> y = [0] + np.sin(np.linspace(0, 2*math.pi*r1, 100)).tolist()
> xy1 = zip(x,y)
>
> x = [0] + np.cos(np.linspace(2*math.pi*r1, 2*math.pi*r2, 100)).tolist()
> y = [0] + np.sin(np.linspace(2*math.pi*r1, 2*math.pi*r2, 100)).tolist()
> xy2 = zip(x,y)
>
> x = [0] + np.cos(np.linspace(2*math.pi*r2, 2*math.pi, 100)).tolist()
> y = [0] + np.sin(np.linspace(2*math.pi*r2, 2*math.pi, 100)).tolist()
> xy3 = zip(x,y)
>
> ax.scatter([0,0,0], [0,0,0], marker=(xy1,0), s=sizes,
> facecolor='green',alpha=.25,zorder=1)
> ax.scatter([0,0,0], [0,0,0], marker=(xy2,0), s=sizes, facecolor='yellow'
> ,alpha=.25,zorder=1)
> ax.scatter([0,0,0], [0,0,0], marker=(xy3,0), s=sizes,
> facecolor='red',alpha=.25,zorder=1)
> ax.scatter(theta, r, c=colors, s=area,zorder=2)
> ax.grid(False)
>
> show()
>
> --
> View this message in context: http://www.nabble.com/polar-graph-tp22230232p22234721.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi all,
(A bit off-topic, hope this is ok, please redirect me if this is more
appropriate on a different list).
I am interested in using the mathtext rendering functionality separate
from the plotting part of matplotlib. To be precise, I would like to
use mathtext as a replacement mathematics renderer in the notebook
front-end of my symbolic computer algebra system 'cadabra',
 http://www.aei.mpg.de/~peekas/cadabra/
(right now I am using latex/dvipng to render mathematical expressions,
which is slow and not very flexible). 
I would prefer to use mathtext to render onto a cairo drawing surface
(since I already have plans to use cairo to improve the
front-end). Are there any examples showing how to do this, or could
someone perhaps post a small code snippet to get me started? Thanks!
Cheers,
Kasper

Michael Droettboom wrote:
> Which backend are you using? I don't see any explicit calls to chdir in 
> matplotlib that would make this happen. It would certainly be 
> unintentional if it is.
I don't know about any other back-ends, but the wx FileDialog has an 
option to change the working dir when the user selects a file I also 
don't know if this flag is set in the MPL code, but it shouldn't be.
> Søren Nielsen wrote:
>> my program can 
>> no longer locate the icons (used in my GUI) that I am using in my 
>> .\ressources directory. So saving the plot changed the working 
>> directory of my program?
>> How do I change it back? Isn't this an error in matplotlib?
I'd say yes, but it's also an error in the design of your code -- as 
you've discovered, the working dir is a tenuous concept -- you should 
set that resources dir in your code start-up and keep it around for when 
you need it.
wxPython has wx.StandardPaths which can be helpful for finding your aps 
data, etc -- I'm sure the other toolkits have something, too.
-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...

Matthias Michler wrote:
> On Thursday 26 February 2009 20:52:17 Christopher Brown wrote:
>> Hi,
>>
>> If I have a figure:
>>
>> h = pp.figure(num=14)
>>
>> What is the best way to check to see if Figure 14 exists? I'm writing a
>> function that adds plots to a figure window. I want the function to
>> check if the figure exists, and if so, turn off autoscaling (using
>> Eric's suggested axes.set_autoscale_on(False)) in case the user has zoomed.
> 
> Hi Christopher,
> 
> I don't know if my suggestion is the best way, but at least it may be 
> useful ...
I think your suggestion is the only way at present, but it suggests that 
we should provide this capability as part of the API; we don't want to 
force people to access the private _pylab_helpers module directly.
Eric
> 
> regards Matthias
> 
> example code:
> 
> import matplotlib
> import matplotlib.pyplot as plt
> 
> 
> for i in range(5)+[14]:
> plt.figure(i) # generating some figures
> 
> # get the figure numbers of all existing figures
> fig_numbers = [x.num
> for x in matplotlib._pylab_helpers.Gcf.get_all_fig_managers()]
> 
> if 14 in fig_numbers:
> print "figure 14 exists" 
> 
> if plt.figure(14).number in fig_numbers:
> print "figure 14 exists" 
> 
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Which backend are you using? I don't see any explicit calls to chdir in 
matplotlib that would make this happen. It would certainly be 
unintentional if it is.
Mike
Søren Nielsen wrote:
> Hi,
>
> When I save a plot using the toolbar save function, and I save to a 
> different directory than the one where my program is, my program can 
> no longer locate the icons (used in my GUI) that I am using in my 
> .\ressources directory. So saving the plot changed the working 
> directory of my program?
>
> How do I change it back? Isn't this an error in matplotlib?
>
> Thanks
> Soren
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Gökhan SEVER wrote:
> Hello,
>
> My first message in the list. I would like to mention a few things 
> about the matplotlib PDF document.
>
> Firstly, the download link for the pdf document (@ 
> http://matplotlib.sourceforge.net/contents.html) is for release 
> 0.98.5.1, compiled on December 17, instead of 0.98.5.2, on Dec-18.
Thanks. I don't recall the current policy under which documentation is 
being pushed to the site, so I'll leave that for others to address.
>
> Next, is there a way to get functions separately listed under each 
> bookmark listing in the pdf file? For example if I go IV Matplotlib 
> API section from the bookmarks menu and click the matplotlib.pyplot 
> seb-menu I would like to see the function names listed. In addition to 
> module indexing (where keywords highlighted back to original names) 
> this would be a nice feature to add the pdf documentation.
This sounds like something to be added/fixed within the documentation 
system we use -- Sphinx. If you want to tackle this yourself, I would 
head over there and read some documentation and mailing lists and see if 
it's been done -- otherwise pursue what it might take to make it work. 
We would definitely welcome this change.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

There are obviously geometric solutions to this that wouldn't require 
interpolation -- though the interpolation is a good easy workaround. I 
think it would be great to file a bug for this in the tracker so it 
doesn't get forgotten.
Mike
Ryan Wagner wrote:
>
> Is this a bug in fill_between, or is there a known workaround?
>
> In the attached picture, I’m calling fill_between as follows, and I 
> can’t fill the entire area between the line (50+thresh) and the 
> signal, s. I realize that the areas that aren’t filled are boundary 
> conditions, but there should be some sort of interpolation I can do to 
> fix this I would think...
>
> ax.fill_between(stockData.inds, s[stockData.rinds], 50+thresh, 
> where=s[stockData.rinds]>50+thresh, color=color, alpha=0.3 )
>
> So for example: stockData.inds = range(6), s[stockData.rinds] = 
> [20,30,70,80,40,20] and thresh = 0. I need the areas filled with color 
> where stockData.rinds is greater than 50. It does fully fill in the 
> xrange(2,3), but the border conditions xrange(1,2) and xrange(3,4) are 
> not fully filled under the line.
>
> I had the same problem with fill_over and was hoping it would be 
> resolved with the move to fill_between. Any ideas?
>
> -Ryan
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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