matplotlib-users Mailing List for matplotlib

i apologize in advance for what is undoubtedly a silly question, but, having
looked through the coding examples and the forum i am still a little
confused...

am i correct in understanding that the only way to draw / display a path on
an axes is by converting it to a PathPatch and adding that to the axes?

ideally i would like to display a PathPatch as well as parts of the path
that surround it. to do this i would like to show the PathPatch with no edge
and then also show part of the path (with no fill).

thanks in advance,

lb
-- 
View this message in context: http://www.nabble.com/display-a-path--tp23805921p23805921.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Sat, May 30, 2009 at 6:46 PM, Eric Firing <ef...@ha...> wrote:

> Possible, but I think there is a much better solution along the lines I
> suggested earlier.  I have it partly implemented.  To really do it right
> will require a little bit of work on all the interactive backends; it might
> be very little and very easy.  It prompted my question starting another
> thread as to whether we can drop support for GTK < 2.4 so as to simplify
> that backend.

Sorry I forgot to answer -- I answered you in my mind <wink>.  While I
am never in favor of dropping support for l packages just because they
are old, if they are impeding adding good functionality because it is
too difficult to code/test against too many interfaces, then by all
means yes, we can drop <2.4.  I thnk we could safely drop <2.6.

JDH

You are welcome Gus :)

Go ahead and try these too.. I am assuming that you are experimenting in
Ipython with --pylab.

Use ? or ?? or browse and read for more information regarding to the usage
of functions (http://matplotlib.sourceforge.net/api/pyplot_api.html) I am
sure gallery has some extra demonstration, too

setp(labels, 'rotation', 'vertical')
xticklabels = getp(gca(), 'xticklabels')
setp(xticklabels, fontsize=14, weight='bold')

Have fun :)

Gökhan


On Sat, May 30, 2009 at 8:17 PM, W. Augustine Dunn III
<wad...@gm...>wrote:

> Gökhan == "awesome"
> Thanks, I KNEW it had to pretty simple.
>
> Gus
>
> On Sat, May 30, 2009 at 6:12 PM, Gökhan SEVER <gok...@gm...>wrote:
>
>> Hey,
>>
>> Try this:
>>
>> plot([1,2,3])
>> locs, labels = xticks([0,1,2], ['Trial1', 'Trial2', 'Control'])
>>
>> Gökhan
>>
>>
>> On Sat, May 30, 2009 at 8:05 PM, W. Augustine Dunn III <
>> wad...@gm...> wrote:
>>
>>> I am sorry if this has been covered in teh archives or is RTFM-sh but I
>>> looked in both places and am low on time.  I want to use text as the value
>>> for the X-axis ticks not numbers.  Something like 'Trial1', 'Trial2',
>>> 'Control' instead of 1,2,3.
>>>
>>> Is this even possible? It seems that this would be a VERY common need.  I
>>> think that it must be obvious but I just can not figure it out.  I fi just
>>> try to supply the text labels as a list the same place the normal xVals
>>> would be used (pl.plot(xVals,yVals)) it does not understand.
>>>
>>>
>>> Thanks.
>>>
>>> Gus
>>>
>>> --
>>> Experience is not what happens to a man; it is what a man does with what
>>> happens to him.
>>> - Aldous Huxley
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>> is a gathering of tech-side developers & brand creativity professionals.
>>> Meet
>>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>>> iPhoneDevCamp as they present alongside digital heavyweights like
>>> Barbarian
>>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>
>
>
> --
> Experience is not what happens to a man; it is what a man does with what
> happens to him.
> - Aldous Huxley
>

Gökhan == "awesome"
Thanks, I KNEW it had to pretty simple.

Gus

On Sat, May 30, 2009 at 6:12 PM, Gökhan SEVER <gok...@gm...> wrote:

> Hey,
>
> Try this:
>
> plot([1,2,3])
> locs, labels = xticks([0,1,2], ['Trial1', 'Trial2', 'Control'])
>
> Gökhan
>
>
> On Sat, May 30, 2009 at 8:05 PM, W. Augustine Dunn III <wad...@gm...
> > wrote:
>
>> I am sorry if this has been covered in teh archives or is RTFM-sh but I
>> looked in both places and am low on time.  I want to use text as the value
>> for the X-axis ticks not numbers.  Something like 'Trial1', 'Trial2',
>> 'Control' instead of 1,2,3.
>>
>> Is this even possible? It seems that this would be a VERY common need.  I
>> think that it must be obvious but I just can not figure it out.  I fi just
>> try to supply the text labels as a list the same place the normal xVals
>> would be used (pl.plot(xVals,yVals)) it does not understand.
>>
>>
>> Thanks.
>>
>> Gus
>>
>> --
>> Experience is not what happens to a man; it is what a man does with what
>> happens to him.
>> - Aldous Huxley
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals.
>> Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like
>> Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>


-- 
Experience is not what happens to a man; it is what a man does with what
happens to him.
- Aldous Huxley

Hey,

Try this:

plot([1,2,3])
locs, labels = xticks([0,1,2], ['Trial1', 'Trial2', 'Control'])

Gökhan


On Sat, May 30, 2009 at 8:05 PM, W. Augustine Dunn III
<wad...@gm...>wrote:

> I am sorry if this has been covered in teh archives or is RTFM-sh but I
> looked in both places and am low on time.  I want to use text as the value
> for the X-axis ticks not numbers.  Something like 'Trial1', 'Trial2',
> 'Control' instead of 1,2,3.
>
> Is this even possible? It seems that this would be a VERY common need.  I
> think that it must be obvious but I just can not figure it out.  I fi just
> try to supply the text labels as a list the same place the normal xVals
> would be used (pl.plot(xVals,yVals)) it does not understand.
>
>
> Thanks.
>
> Gus
>
> --
> Experience is not what happens to a man; it is what a man does with what
> happens to him.
> - Aldous Huxley
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

I am sorry if this has been covered in teh archives or is RTFM-sh but I
looked in both places and am low on time.  I want to use text as the value
for the X-axis ticks not numbers.  Something like 'Trial1', 'Trial2',
'Control' instead of 1,2,3.

Is this even possible? It seems that this would be a VERY common need.  I
think that it must be obvious but I just can not figure it out.  I fi just
try to supply the text labels as a list the same place the normal xVals
would be used (pl.plot(xVals,yVals)) it does not understand.


Thanks.

Gus

-- 
Experience is not what happens to a man; it is what a man does with what
happens to him.
- Aldous Huxley

John Hunter wrote:
> On Sat, May 30, 2009 at 11:52 AM, Eric Firing <ef...@ha...> wrote:
> 
>> No, that applies to the axis ticks but not to the readout, and I think it is
>> the latter that Xavier is concerned with--at least that is what I have been
>> talking about, and want to improve.
> 
> Just to clarify -- by "readout" do you mean the toolbar strings?
> 
> At first I was assuming that since the toolbar formatting picks up the
> tick Formatter to format the strings, and ScalarFormatter uses
> rcParams['axes.formatter.limits'] to determine when to fall over to
> scientific notation, that this setting would be picked up by the
> toolbar.  The reason it does not is because ScalarFormatter overrides
> Formatter.format_data_short, which is what the toolbar uses via
> Axes.format_xdata/format_ydata, and ScalarFormatter.format_data_short
> does not use the formatter.limits setting.  Are we at least on the
> same page now?  If so, is it advisable/possible to make
> format_data_short respect the formatter.limits setting so Xavier can
> customize it to his heart's content.

Possible, but I think there is a much better solution along the lines I 
suggested earlier.  I have it partly implemented.  To really do it right 
will require a little bit of work on all the interactive backends; it 
might be very little and very easy.  It prompted my question starting 
another thread as to whether we can drop support for GTK < 2.4 so as to 
simplify that backend.

Eric
> 
> JDH
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

John Hunter wrote:
> On Sat, May 30, 2009 at 11:52 AM, Eric Firing <ef...@ha...> wrote:
>
>   
>> No, that applies to the axis ticks but not to the readout, and I think it is
>> the latter that Xavier is concerned with--at least that is what I have been
>> talking about, and want to improve.
>>     
>
> Just to clarify -- by "readout" do you mean the toolbar strings?
>
> At first I was assuming that since the toolbar formatting picks up the
> tick Formatter to format the strings, and ScalarFormatter uses
> rcParams['axes.formatter.limits'] to determine when to fall over to
> scientific notation, that this setting would be picked up by the
> toolbar.  The reason it does not is because ScalarFormatter overrides
> Formatter.format_data_short, which is what the toolbar uses via
> Axes.format_xdata/format_ydata, and ScalarFormatter.format_data_short
> does not use the formatter.limits setting.  Are we at least on the
> same page now?  If so, is it advisable/possible to make
> format_data_short respect the formatter.limits setting so Xavier can
> customize it to his heart's content.
>
> JDH
>   
...and this way my brain and my heart would be fully satisfied :)
Please perform this change ;)

Xavier

Hi,

Given that the values of ordinates are changing monotonically, I found that
in some cases, stineman interpolation is monotonic even when the slopes are
not monotonic. And in other cases, it overshoots. Like in the following one:

x = (0, 10, 70, 100)
y = (0, 535, 595, 1000)
xx = arange(0,100,1)
yy = stineman_interp(xx,x,y,yp=None)
plot(x,y,'x')
plot(xx,yy)

Are there some factors that can make the interpolation monotonic, when the
slopes are not monotonic? or does it depend on case by case basis?

On Sat, May 30, 2009 at 11:52 AM, Eric Firing <ef...@ha...> wrote:

> No, that applies to the axis ticks but not to the readout, and I think it is
> the latter that Xavier is concerned with--at least that is what I have been
> talking about, and want to improve.

Just to clarify -- by "readout" do you mean the toolbar strings?

At first I was assuming that since the toolbar formatting picks up the
tick Formatter to format the strings, and ScalarFormatter uses
rcParams['axes.formatter.limits'] to determine when to fall over to
scientific notation, that this setting would be picked up by the
toolbar.  The reason it does not is because ScalarFormatter overrides
Formatter.format_data_short, which is what the toolbar uses via
Axes.format_xdata/format_ydata, and ScalarFormatter.format_data_short
does not use the formatter.limits setting.  Are we at least on the
same page now?  If so, is it advisable/possible to make
format_data_short respect the formatter.limits setting so Xavier can
customize it to his heart's content.

JDH

John Hunter wrote:
> On Sat, May 30, 2009 at 2:49 AM, Xavier Gnata <xav...@gm...> wrote:
> 
>> ok. My bad! Sorry.
>> I have changed the default to %1.4g so that is matches my usecases *but* I
>> agree that correct way to improve it in not that trivial...
> 
> 
> You can control the point at which mpl falls over to scientific
> notation.  From the matplotlibrc file (see
> http://matplotlib.sourceforge.net/users/customizing.html)
> 
> axes.formatter.limits : -7, 7 # use scientific notation if log10
>                                # of the axis range is smaller than the
>                                # first or larger than the second
> 
> I'm actually surprised you are seeing problems with images of
> 1000x1000 -- it makes me suspect you have an older matplotlib version
> or an older matplotlibrc laying around because at -7,7, which is the
> current default, you should not see exponential formatting until you
> get to much larger sizes.
> 
> JDH

John,

No, that applies to the axis ticks but not to the readout, and I think 
it is the latter that Xavier is concerned with--at least that is what I 
have been talking about, and want to improve.

Eric

On Sat, May 30, 2009 at 3:50 AM, Paul Anton Letnes
<pau...@gm...> wrote:
> Hello again,
>
>
> I can set the figure size and font size, that all works fine. However,
> the legend is prohibitively large: for a plot 3 inches wide (why
> doesn't matplotlib use centimeters or similar?), the legend takes up
> about one third of the plot. This does not look too good...

Please post a complete example.  As for inches vs cm, that is my fault
--  I can't remember if it was for matlab compatibility, or due to my
provincial ways this side of the pond.

JDH

On Sat, May 30, 2009 at 2:49 AM, Xavier Gnata <xav...@gm...> wrote:

> ok. My bad! Sorry.
> I have changed the default to %1.4g so that is matches my usecases *but* I
> agree that correct way to improve it in not that trivial...


You can control the point at which mpl falls over to scientific
notation.  From the matplotlibrc file (see
http://matplotlib.sourceforge.net/users/customizing.html)

axes.formatter.limits : -7, 7 # use scientific notation if log10
                               # of the axis range is smaller than the
                               # first or larger than the second

I'm actually surprised you are seeing problems with images of
1000x1000 -- it makes me suspect you have an older matplotlib version
or an older matplotlibrc laying around because at -7,7, which is the
current default, you should not see exponential formatting until you
get to much larger sizes.

JDH

Hello again,


I can set the figure size and font size, that all works fine. However,  
the legend is prohibitively large: for a plot 3 inches wide (why  
doesn't matplotlib use centimeters or similar?), the legend takes up  
about one third of the plot. This does not look too good...

cheers,
Paul

On 29. mai. 2009, at 17.38, Damon McDougall wrote:

> Hi Paul,
>
> You could set the figure size and font size in inches of your plot  
> in matplotlib to be the same as that of the physical size it will  
> appear on paper. That way, all your axes labels and plot text will  
> be the same size as the text in your latex document.
>
> Is this what you want?
> Regards,
> --Damon
>
> On 29 May 2009, at 16:25, Paul Anton Letnes wrote:
>
>> Howdy y'all!
>>
>> I'm trying to make a publication quality plot for a two-column latex
>> article. I'm using latex for text processing, so the plot quality
>> itself is impeccable. However, as I scale the plot size down, the
>> legend becomes extremely large compared to the plot itself.  Has
>> anyone solved this problem in a good manner? I'm not willing to make
>> do without the legend.
>>
>> cheers,
>> Paul.
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity  
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity,  
>> Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like  
>> Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Eric Firing wrote:
> Xavier Gnata wrote:
>>
>>>
>>>>
>
>>> Right now, the default is very simple:
>>>
>>>     def format_data_short(self,value):
>>>         'return a short formatted string representation of a number'
>>>         return '%1.3g'%value
>>>
>>> It looks like changing it to something like "%-12g" would facilitate 
>>> considerable improvement in reducing the jumping around of the 
>>> numbers, as well as in providing much more precision.  I think that 
>>> 12 is the max number of characters in g conversion.  Or maybe it is 
>>> 13; I might not have tested negative numbers.
>>>
>>> The problem is that then it crowds out the other part of the 
>>> message, the pan/zoom status notification etc.
>>>
>>> Breaking the message into two lines almost works (so far only 
>>> checking with gtkagg), but the plot gets resized depending on 
>>> whether there is a status or not.
>>>
>>> I think that with some more fiddling around with that part of the 
>>> toolbar--probably including breaking the message up into separate 
>>> messages for status and readout, and maybe making the readout use 
>>> two lines and always be present--we could make the readout and 
>>> status display much nicer.  I have never liked the way it jumps around.
>>>
>> I also agree.
>> However, I would like to be sure I understand one point correctly:
>> As long as x<1000, the default format *is* an integer (at least when 
>> imshow(M) is used).
>
> No. Try
>
> imshow(rand(4,4))
>
> There is nothing special about imshow that makes the cursor readout an 
> integer, nor should there be.
>
> Again, the present default is "%1.3g". I think we can and will do 
> better, but it is not necessarily trivial.
>
> Eric
>
ok. My bad! Sorry.
I have changed the default to %1.4g so that is matches my usecases *but* 
I agree that correct way to improve it in not that trivial...

Xavier

Xavier Gnata wrote:
> 
>>
>>>

>> Right now, the default is very simple:
>>
>>     def format_data_short(self,value):
>>         'return a short formatted string representation of a number'
>>         return '%1.3g'%value
>>
>> It looks like changing it to something like "%-12g" would facilitate 
>> considerable improvement in reducing the jumping around of the 
>> numbers, as well as in providing much more precision.  I think that 12 
>> is the max number of characters in g conversion.  Or maybe it is 13; I 
>> might not have tested negative numbers.
>>
>> The problem is that then it crowds out the other part of the message, 
>> the pan/zoom status notification etc.
>>
>> Breaking the message into two lines almost works (so far only checking 
>> with gtkagg), but the plot gets resized depending on whether there is 
>> a status or not.
>>
>> I think that with some more fiddling around with that part of the 
>> toolbar--probably including breaking the message up into separate 
>> messages for status and readout, and maybe making the readout use two 
>> lines and always be present--we could make the readout and status 
>> display much nicer.  I have never liked the way it jumps around.
>>
> I also agree.
> However, I would like to be sure I understand one point correctly:
> As long as x<1000, the default format *is* an integer (at least when 
> imshow(M) is used).

No. Try

imshow(rand(4,4))

There is nothing special about imshow that makes the cursor readout an 
integer, nor should there be.

Again, the present default is "%1.3g". I think we can and will do 
better, but it is not necessarily trivial.

Eric

>
>>
>> However, everyone would be happy if the default format would be 
>> consistent :
>>
>> As it is, *by default*, when <1000 it displays an int and after 1000 
>> it displays 1.42e3.
>> Why? What do you think this scientific format is a good for?
>>
>> I understand some users would like to see floats by default.
>> Some other users would like to see integers by default.
>
> It is not just a matter of integer versus float; the formatting 
> algorithm must accomodate both.
>
I agree.

>>
>> I'm fine with integers or floats by default (I don't cadre) but I 
>> don't get the logic of the scientific format.
>> I only would like to see all the digits of the integer parts.
>> I would be fine if I would get 1.422e3 instead of 1.42e3 (we could 
>> for instance assume that images larger than (100 000, 100 000) are 
>> really a corner case ;)).
>>
>> Why should be the *default* logic so strange?
>> Ok, it is easy to change but the default should at least make sense.
>> As it is, I don't think it does...but there could be a good rational 
>> I'm missing.
>
>
> Right now, the default is very simple:
>
>     def format_data_short(self,value):
>         'return a short formatted string representation of a number'
>         return '%1.3g'%value
>
> It looks like changing it to something like "%-12g" would facilitate 
> considerable improvement in reducing the jumping around of the 
> numbers, as well as in providing much more precision.  I think that 12 
> is the max number of characters in g conversion.  Or maybe it is 13; I 
> might not have tested negative numbers.
>
> The problem is that then it crowds out the other part of the message, 
> the pan/zoom status notification etc.
>
> Breaking the message into two lines almost works (so far only checking 
> with gtkagg), but the plot gets resized depending on whether there is 
> a status or not.
>
> I think that with some more fiddling around with that part of the 
> toolbar--probably including breaking the message up into separate 
> messages for status and readout, and maybe making the readout use two 
> lines and always be present--we could make the readout and status 
> display much nicer.  I have never liked the way it jumps around.
>
I also agree.
However, I would like to be sure I understand one point correctly:
As long as x<1000, the default format *is* an integer (at least when 
imshow(M) is used).
Fine for me. Why do we need to move to another *default* format for 
numbers larger than 1000?

Anyhow, I think that we should at least always display all the digits of 
the integer part of the coordinates.

BTW, ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d')) is 
fine but it prevents you to do a simple imshow(M) to look at your data. 
You have to create ax. Easy...yes...but not as simple/nice as the 
one-liner imhow(M)

Xavier


> Eric
>
>>
>> pylab is so easy and fun to use because the default settings are 
>> always the best one.
>> IMHO, there is one exception :(
>>
>> Xavier
>>
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
>> is a gathering of tech-side developers & brand creativity 
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, 
>> & iPhoneDevCamp as they present alongside digital heavyweights like 
>> Barbarian Group, R/GA, & Big Spaceship. 
>> http://p.sf.net/sfu/creativitycat-com 
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Xavier Gnata wrote:

> 
> However, everyone would be happy if the default format would be consistent :
> 
> As it is, *by default*, when <1000 it displays an int and after 1000 it 
> displays 1.42e3.
> Why? What do you think this scientific format is a good for?
> 
> I understand some users would like to see floats by default.
> Some other users would like to see integers by default.

It is not just a matter of integer versus float; the formatting 
algorithm must accomodate both.

> 
> I'm fine with integers or floats by default (I don't cadre) but I don't 
> get the logic of the scientific format.
> I only would like to see all the digits of the integer parts.
> I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for 
> instance assume that images larger than (100 000, 100 000) are really a 
> corner case ;)).
> 
> Why should be the *default* logic so strange?
> Ok, it is easy to change but the default should at least make sense.
> As it is, I don't think it does...but there could be a good rational I'm 
> missing.


Right now, the default is very simple:

     def format_data_short(self,value):
         'return a short formatted string representation of a number'
         return '%1.3g'%value

It looks like changing it to something like "%-12g" would facilitate 
considerable improvement in reducing the jumping around of the numbers, 
as well as in providing much more precision.  I think that 12 is the max 
number of characters in g conversion.  Or maybe it is 13; I might not 
have tested negative numbers.

The problem is that then it crowds out the other part of the message, 
the pan/zoom status notification etc.

Breaking the message into two lines almost works (so far only checking 
with gtkagg), but the plot gets resized depending on whether there is a 
status or not.

I think that with some more fiddling around with that part of the 
toolbar--probably including breaking the message up into separate 
messages for status and readout, and maybe making the readout use two 
lines and always be present--we could make the readout and status 
display much nicer.  I have never liked the way it jumps around.

Eric

> 
> pylab is so easy and fun to use because the default settings are always 
> the best one.
> IMHO, there is one exception :(
> 
> Xavier
> 
> 
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

I'm trying to add label to a histogram with multiple data. The doc says 
"label can also be a sequence of strings" but when I try:

plt.hist([listA, listB, listC], bins=25, histtype='bar', 
alpha=0.75,rwidth=0.85,label=['A','B','C'])

I got an error:
"AttributeError: 'tuple' object has no attribute 'startswith'"
(for the entire traceback see http://paste.pocoo.org/show/119820/ )

is it me or a bug?

Can I add a legend in another way?

thanks in advance!

-Yva.

John Hunter wrote:
> On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata <xav...@gm...> wrote:
>
>   
>>> I had the same problem and fixed it by changing just two lines of code in the axes.py (line 1812 and 1814). Just change the formatter in 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the same for y).
>>>       
>
> You don't need to modify the internals of axes.py -- just set the
> formatter on the axes instance itself.
>
>   http://matplotlib.sourceforge.net/search.html?q=codex+set_major_formatter
>
>   
>> Indeed, but it should really be fixed in the svn.
>>     
>
> We could perhaps be a little smarter about this, but consider that one
> can easily plot lines over images
>
> In [30]: imshow(np.random.rand(512,512))
> Out[30]: <matplotlib.image.AxesImage object at 0x151c4f4c>
>
> In [31]: plot(np.arange(512), np.arange(512))
>
> Since the plot can be a mix of images, polygons, lines, etc, it is not
> obvious that the formatter should be int.  We could trap the case
> where you have only an image, no other data, and haven't set the
> extent, but it would be complicated because you may add data to the
> plot later and we would have to track that we had attempted to be
> clever but we should now undo our cleverness.  Our general philosophy
> is to make is easy for you to customize when the default behavior
> doesn't suit you, so try
>
>   import matplotlib.ticker as ticker
>   ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d'))
>   .. and ditto for yaxis ..
>
> in addition to the ticks, you can customize how the coords appear in
> the toolbar by setting
>
>   ax.fmt_xdata = ticker.FormatStrFormatter('%d')
>   ... and ditto for fmt_ydata
>
> There are a variety of formatters available
>
>   http://matplotlib.sourceforge.net/api/ticker_api.html
>
> JDH
>   
Hi John,

Ok, well; the way I use pylab may be a corner case ;)

However, everyone would be happy if the default format would be consistent :

As it is, *by default*, when <1000 it displays an int and after 1000 it 
displays 1.42e3.
Why? What do you think this scientific format is a good for?

I understand some users would like to see floats by default.
Some other users would like to see integers by default.

I'm fine with integers or floats by default (I don't cadre) but I don't 
get the logic of the scientific format.
I only would like to see all the digits of the integer parts.
I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for 
instance assume that images larger than (100 000, 100 000) are really a 
corner case ;)).

Why should be the *default* logic so strange?
Ok, it is easy to change but the default should at least make sense.
As it is, I don't think it does...but there could be a good rational I'm 
missing.

pylab is so easy and fun to use because the default settings are always 
the best one.
IMHO, there is one exception :(

Xavier

Thanks, it works well.

However, I forgot that computer modern does not include accented 
characters (unlike latin modern), so I eventually used Stix :

mpl.rc('font', family = 'serif', serif = 'STIXGeneral')

By the way, is there any way to use Stix for sans-serif as well, or even 
cursive and monospace ? I don't know how to do that, since Stix seems to 
contain all of them in a single file (STIXGeneral.ttf) ?

Nicolas


Michael Droettboom a écrit :
> The name of the Computer Modern Roman font that ships with matplotlib 
> is "cmr10", so
>
>   mpl.rc('font', family = 'serif', serif = 'cmr10')
>
> should work.
>
> Mike
>
> Nicolas Pourcelot wrote:
>> Hi,
>>
>> is there any way to use Computer Modern in any text in matplotlib ?
>>
>> In http://matplotlib.sourceforge.net/users/customizing.html, I read 
>> the following :
>>
>> #font.serif          : Bitstream Vera Serif, New Century Schoolbook, 
>> Century Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 
>> L, Times New Roman, Times, Palatino, Charter, serif
>> #font.sans-serif     : Bitstream Vera Sans, Lucida Grande, Verdana, 
>> Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif
>> #font.cursive        : Apple Chancery, Textile, Zapf Chancery, Sand, 
>> cursive
>> #font.fantasy        : Comic Sans MS, Chicago, Charcoal, Impact, 
>> Western, fantasy
>> #font.monospace      : Bitstream Vera Sans Mono, Andale Mono, Nimbus 
>> Mono L, Courier New, Courier, Fixed, Terminal, monospace
>>   So, Computer Modern is not listed there.
>>
>> However, Computer Modern is used in mathtext, so I suppose there is a 
>> way to use it also in plain text, but I can't figure it...
>>
>> I tried :
>> /mpl.rc('font', family = 'serif', serif = 'computer modern roman')/
>> but it did not work.
>>
>> Thanks a lot,
>>
>> Nicolas P.
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------ 
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
>> is a gathering of tech-side developers & brand creativity 
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, 
>> & iPhoneDevCamp as they present alongside digital heavyweights like 
>> Barbarian Group, R/GA, & Big Spaceship. 
>> http://p.sf.net/sfu/creativitycat-com 
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>   
>

Gurus,

I am implementing some simple Principal Component Analysis (PCA) in  
Python but I have run into trouble with the graphical output. I have  
calculated my scores and my loadings (just matrices with  
mean-centered, univariate values) and I want to scatterplot them.  
However, to make the graph more useful I want to label each dot in the  
scatter plot and also color it. I am using Matplotlib, Pylab, and Scipy.

For example, given a 3x3 matrix of scores called T, I want to:

T,P,E = PCA_svd( X, standardize = True )
t1, t2 = T[:,0], T[:,1]

properties = dict( alpha = 0.75, c = some_colors )
s1 = scatter( t1, t2 ,s = 50, **properties )
legend()
grid( True )
show()

And the result should show three dots of various colors with a legend  
describing each color, and a data-label (say a two-character code,  
like AA, BB, CC) for each data-point.

I understand that pylab.scatter objects are not formatted correctly to  
use the pylab.legend command, and I was wondering if a patch has been  
written for this yet. I use Python 2.5.3
I have found one work-around for the legend that plots each group in  
color and then hacks with a Rectangle object, as follows:

props = dict( alpha = 0.75, faceted = False )
Scores = scatter( t1, t2, c = 'red', s = 50, **props )
Loadings = scatter( p1, p2, c = 'blue', s = 50, **props )
redp = Rectangle( ( 0,0 ), 1, 1, facecolor = 'red' )
bluep = Rectangle( ( 0,0 ), 1, 1, facecolor = 'blue' )
legend( ( redp,bluep ),( 'Scores','Loadings' ) )
grid( True )
show()

This works for varying colors across two groups of points, but it  
doesn't work for single data-points (it says "ValueError: First  
argument must be a sequence") and it also does not allow me to label  
each data-point with a two-char code.

Any shoves in the right direction would be very much appreciated.  
Links to online examples and source-code especially so.

-Timothy Kinney

Yannick Copin wrote:
> Hi,
> 
> I have an error while trying to use mpl.axes.set_default_color_cycle to 
> define my own color cycle based on the set1 colormap:
> 
> In [1]: set1 = array([[228,55, 77, 152,255,255,166,247,153],
>     ...:               [26, 126,175,78, 127,255,86, 129,153],
>     ...:               [28, 184,74, 163,0,  51, 40, 191,153]],'d').T / 255.
> 
> In [2]: mpl.axes.set_default_color_cycle(set1)
> ---------------------------------------------------------------------------
> AttributeError                            Traceback (most recent call last)

I just committed a change that should fix this bug.

Eric

> 
> /autofs/home/ycopin/<ipython console> in <module>()
> 
> /usr/lib/python2.5/site-packages/matplotlib/axes.py in 
> set_default_color_cycle(clist)
>      113     """
>      114     _process_plot_var_args.defaultColors = clist[:]
> --> 115     rcParams['lines.color'] = clist[0]
>      116
>      117 class _process_plot_var_args:
> 
> /usr/lib/python2.5/site-packages/matplotlib/__init__.pyc in 
> __setitem__(self, key, val)
>      588 instead.'% (key, alt))
>      589                 key = alt
> --> 590             cval = self.validate[key](val)
>      591             dict.__setitem__(self, key, cval)
>      592         except KeyError:
> 
> /usr/lib/python2.5/site-packages/matplotlib/rcsetup.pyc in validate_color(s)
>      156 def validate_color(s):
>      157     'return a valid color arg'
> --> 158     if s.lower() == 'none':
>      159         return 'None'
>      160     if is_color_like(s):
> 
> AttributeError: 'numpy.ndarray' object has no attribute 'lower'
> 
> I'm using matplotlib 0.98.3 but I checked on the SVN repository that the 
> offending lines ("rcParams['lines.color'] = clist[0]","if s.lower() == 
> 'none'") are still there.
> 
> Cheers.

On Fri, May 29, 2009 at 19:09, Neal Becker <ndb...@gm...> wrote:
>
> from pylab import semilogy, show, grid
> grid()
> semilogy (result[0])
>
> This gave me just a vertical grid.  What do I do to get both horiz and vert
> grids?

(without looking at a screenshot or to the dataset is hard to tell
but) is it possible that you have Y values contained in a single
logarithmic inteval (or even closer)? if so, there is no line on Y to
draw and only vertival lines (relative to X values) are displayed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

from pylab import semilogy, show, grid
grid()
semilogy (result[0])

This gave me just a vertical grid.  What do I do to get both horiz and vert 
grids?