matplotlib-users Mailing List for matplotlib

>On the bright side, at least w/matplotlib, you're not paying out the 
>wazoo :-) for such things.
>
I actually made the mistake of buying the matlab student edition.

On Dec 16, 2006, at 8:10 PM, John Hunter wrote:
> Simson> 3. If I was going to make a major change to the API at
> Simson> this point, it would be to make it so that you don't have
> Simson> a class/function/ identifier called "axes" and another one
> Simson> called "axis." I frequently get confused between these two
> Simson> words; I imagine that non-native English speakers get
> Simson> confused even more frequently. Irregular noun plurals in
> Simson> English are confusing, and it probably isn't necessary to
> Simson> use both. One approach would be to never allow "axis," to
> Simson> only allow "xaxis" and "yaxis" and perhaps something
> Simson> (either_axis?) for the abstract super-class, but this may
> Simson> be a bigger change than you wish to consider at the
> Simson> present time.
>
> Yes, this is a confusing and poor nomenclature. We're probably stuck
> with it at this point, since it fairly deeply ingrained.
The axis/axes function names are Matlab relics, so to have used 
something else would probably have caused other complaints.
On the bright side, at least w/matplotlib, you're not paying out the 
wazoo :-) for such things.
--b

> How is the irregular boundary defined? Is it defined in terms of the 
> data you are plotting (i.e. all values exceeding a threshold)? Or, do 
> you have the vertices of a polygon you want to use as a mask?
> 
> -Jeff
Jeff,
 thanks for answering my question. I have the vertices of a polygon
used as a mask.
 shu
-- 
 <>

shu...@16... wrote:
> hi,everybody.first say sorry for my poor english.
> I want to make a contour plot with part out of the irregular boundary
> blank.just as http://www.pyngl.ucar.edu/Examples/Images/ngl05p.3.png
> shows.
> how can i do?
>
> 
How is the irregular boundary defined? Is it defined in terms of the 
data you are plotting (i.e. all values exceeding a threshold)? Or, do 
you have the vertices of a polygon you want to use as a mask?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

hi,everybody.first say sorry for my poor english.This is my first email
to matplotlib user list.
I want to make a contour plot with part out of the irregular boundary
blank.just as http://www.pyngl.ucar.edu/Examples/Images/ngl05p.3.png
shows.
how can i do?
-- 
 <>

hi,everybody.first say sorry for my poor english.
I want to make a contour plot with part out of the irregular boundary
blank.just as http://www.pyngl.ucar.edu/Examples/Images/ngl05p.3.png
shows.
how can i do?
-- 
 <>

I'm trying to install the matplotlib egg on Debian Etch.
I got g++, pygtk and everything else I could think that matplotlib
wants. It froze with following mysterious message...
The package setup script has attempted to modify files on your system
that are not within the EasyInstall build area, and has been aborted.
This package cannot be safely installed by EasyInstall, and may not
support alternate installation locations even if you run its setup
script by hand. Please inform the package's author and the EasyInstall
maintainers to find out if a fix or workaround is available.
Chris

Simson,
Using your example I get most of the values around 0.5, and the ends 
near 2.3. This is correct for a probability density function; the 
integral of the pdf over the range of the bins should be 1. This way 
the pdf values as a function of x don't change with changes in the 
number of bins, apart from the change in resolution. The probability of 
a datum appearing in any subrange is the integral of the pdf over that 
subrange.
Having the sum of the bars add to 1 would be a different sort of 
normalization. Undoubtedly it has a name, but I don't know what it is. 
And I don't know why you were getting a y-axis up to 7.
Eric
Simson Garfinkel wrote:
> I'm plotting some histograms with hist() --- well, actually with 
> ax.hist(), where ax is an axis --- and the "normed=1" isn't working 
> the way I would expect.
> 
> from pylab import *
> 
> data = sin(arange(0.0,100,.01))
> 
> fig = figure()
> ax = fig.add_subplot(111)
> ax.hist(data,bins=50,normed=1,align='center')
> show()
> 
> If I do not include normed=1, then the Y scale is an actual count 
> inside each bin. (The scale goes from 1-1000).
> 
> If I include normed=1, the Y scale goes from 1 - 7. What does that 
> mean? normed is supposed to make the first result from ax.hist be a 
> normalized probability distribution. But I would think that it would 
> change the Y axis to be a probability as well, and it doesn't do that.
> 
> The docstrings do not give any insight, so I looked at the source 
> code. It certainly *looks* like it's plotting the probability 
> distribution. But why does the above example give a Y scale going 
> from 1 to 7? Perhaps I'm showing my lack of statistics here, but I 
> would think that a strict probability distribution would have the 
> value of all of the bars adding to 1,
> 
> Sorry to send out so many messages today. I really am trying to 
> figure this out on my own...
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

>
> Simson> 3. If I was going to make a major change to the API at
> Simson> this point, it would be to make it so that you don't have
> Simson> a class/function/ identifier called "axes" and another one
> Simson> called "axis." I frequently get confused between these two
> Simson> words; I imagine that non-native English speakers get
> Simson> confused even more frequently. Irregular noun plurals in
> Simson> English are confusing, and it probably isn't necessary to
> Simson> use both. One approach would be to never allow "axis," to
> Simson> only allow "xaxis" and "yaxis" and perhaps something
> Simson> (either_axis?) for the abstract super-class, but this may
> Simson> be a bigger change than you wish to consider at the
> Simson> present time.
>
> Yes, this is a confusing and poor nomenclature. We're probably stuck
> with it at this point, since it fairly deeply ingrained.
It's never to late to change something. For any successful project, 
there will always be more users in the future than in the past. The 
key thing is to make the change without breaking backwards 
compatibility. But that's not hard: you can accept the old value 
while nevertheless standardizing on the new one.
>
> Simson> Ah, the matplotlibrc file. It seems that you are trying
> Simson> to do too much with this file. Is the point of the file
> Simson> to have default graphing behavior, or to have site-wide
> Simson> configuration information? You may wish to split the file
> Simson> into two parts --- a config part and a graphing
> Simson> preferences part --- because it seems that sometimes
> Simson> people wish to change one without changing the other. Or
> Simson> you may want to have explicit inheritance --- like an
> Simson> "-include" feature so that a local file can just shadow
> Simson> some variables and then include the master file. I
> Simson> understand that this can be done with a few lines of
> Simson> python at the top of a program. Of course, given that
> Simson> option, you may wish to do away with the local files
> Simson> entirely. I'm not sure.
>
> The rc file is meant to support local customization, and directory
> specific files are meant to support project specific customizations.
> The idea here is: you may want a general configuration for most plots,
> interactive plotting, etc, but you may want something entirely
> different for a directory which contains a figure for a journal
> article: PS backend, latex text, larger fontsizes, thicker lines...
The problem with the RC file this way, though, is that I can give you 
a pice of python code and it will plot differently on your computer 
than on mine because of a change in your rc file.
If you think that's okay, then it's okay. You're the designer, not 
me! But it is clearly a concern that I would have.
>
> The current implementation certainly has some limitations: we'd prefer
> the file to be python rather than our own yet-another-rc-file-markup
> and yes, we'd like to support includes and overrides with a basic
> inheritance and namespace support, which we would get for free by
> simply making the rc file python. This is an idea waiting to be
> implemented. We'd probably borrow some work from recent changes to
> ipython which were implemented to solve some of the same problems.
>
> Simson> Have the matplotlib developers put together a roadmap of
> Simson> their directions that they want to take this project?
>
> http://matplotlib.sf.net/goals.html
Thanks!
>
> though it is not updated as often as it should be and is not 
> entirely current.
>
> JDH
>

>>>>> "Simson" == Simson Garfinkel <si...@ac...> writes:
 Simson> That's odd. I would think that it makes more sense to set
 Simson> the format *before* the data is plot, not after.
When normed is True, hist returns a probability density so that the
integral of the histogram equals one, assuming equally spaced bins.
See
 http://en.wikipedia.org/wiki/Probability_density_function
You should be able to verify this with 
 # trapezoidal integration of the probability density function
 from matplotlib.mlab import trapz
 pdf, bins, patches = ax.hist(...)
 print trapz(bins, pdf) 
JDH

>>>>> "Simson" == Simson Garfinkel <si...@ac...> writes:
 Simson> I'm very interested in putting together a document that
 Simson> would be incorporated into the user's manual that would
 Simson> describe the abstractions used by matplotlib. I think that
 Simson> this would help me to understand it better, and would also
 Simson> be useful to the community. Does anything like this
 Simson> currently exist?
The best starting point for this is the "Leftwich tutorial"
 http://matplotlib.sourceforge.net/leftwich_tut.txt
This is written in structured text. If you are interested in
extending this (and a lot can be done here) the best place to start
IMO is to get this into the proper format for the matplotlib wiki and
uploaded there, so we can all make contributions to it. There may be
minor differences in the structured text format that need to be
addressed.
 Simson> To answer Eric's most recent posting:
 Simson> 1. I think that scientific notation should not be the
 Simson> default, unless numbers exceed 1E+7. 
I agree with this -- scientific notation kicks in too soon IMO. I
think an rc setting would be fine. I am not adverse to more rc
settings personally. I haven't seen too many problems arising from
having a lot of rc settings.
 Simson> 2. It would be nice if there was an easy way to get commas
 Simson> into numbers. (This is forever a problem; I wish that the
 Simson> original C folks had thought to put commas into their
 Simson> original printf formatting. I have a nice python commas
 Simson> function if you want it, although you can probably create
 Simson> one that is more efficient.)
This would be a great custom formatter -- see
http://matplotlib.sf.net/matplotlib.ticker.html for details on the
Formatter. Please contribute one if you can.
 Simson> 3. If I was going to make a major change to the API at
 Simson> this point, it would be to make it so that you don't have
 Simson> a class/function/ identifier called "axes" and another one
 Simson> called "axis." I frequently get confused between these two
 Simson> words; I imagine that non-native English speakers get
 Simson> confused even more frequently. Irregular noun plurals in
 Simson> English are confusing, and it probably isn't necessary to
 Simson> use both. One approach would be to never allow "axis," to
 Simson> only allow "xaxis" and "yaxis" and perhaps something
 Simson> (either_axis?) for the abstract super-class, but this may
 Simson> be a bigger change than you wish to consider at the
 Simson> present time.
Yes, this is a confusing and poor nomenclature. We're probably stuck
with it at this point, since it fairly deeply ingrained.
 Simson> Ah, the matplotlibrc file. It seems that you are trying
 Simson> to do too much with this file. Is the point of the file
 Simson> to have default graphing behavior, or to have site-wide
 Simson> configuration information? You may wish to split the file
 Simson> into two parts --- a config part and a graphing
 Simson> preferences part --- because it seems that sometimes
 Simson> people wish to change one without changing the other. Or
 Simson> you may want to have explicit inheritance --- like an
 Simson> "-include" feature so that a local file can just shadow
 Simson> some variables and then include the master file. I
 Simson> understand that this can be done with a few lines of
 Simson> python at the top of a program. Of course, given that
 Simson> option, you may wish to do away with the local files
 Simson> entirely. I'm not sure.
The rc file is meant to support local customization, and directory
specific files are meant to support project specific customizations.
The idea here is: you may want a general configuration for most plots,
interactive plotting, etc, but you may want something entirely
different for a directory which contains a figure for a journal
article: PS backend, latex text, larger fontsizes, thicker lines...
The current implementation certainly has some limitations: we'd prefer
the file to be python rather than our own yet-another-rc-file-markup
and yes, we'd like to support includes and overrides with a basic
inheritance and namespace support, which we would get for free by
simply making the rc file python. This is an idea waiting to be
implemented. We'd probably borrow some work from recent changes to
ipython which were implemented to solve some of the same problems.
 Simson> Have the matplotlib developers put together a roadmap of
 Simson> their directions that they want to take this project?
 http://matplotlib.sf.net/goals.html
though it is not updated as often as it should be and is not entirely current.
JDH

I'm plotting some histograms with hist() --- well, actually with 
ax.hist(), where ax is an axis --- and the "normed=1" isn't working 
the way I would expect.
from pylab import *
data = sin(arange(0.0,100,.01))
fig = figure()
ax = fig.add_subplot(111)
ax.hist(data,bins=50,normed=1,align='center')
show()
If I do not include normed=1, then the Y scale is an actual count 
inside each bin. (The scale goes from 1-1000).
If I include normed=1, the Y scale goes from 1 - 7. What does that 
mean? normed is supposed to make the first result from ax.hist be a 
normalized probability distribution. But I would think that it would 
change the Y axis to be a probability as well, and it doesn't do that.
The docstrings do not give any insight, so I looked at the source 
code. It certainly *looks* like it's plotting the probability 
distribution. But why does the above example give a Y scale going 
from 1 to 7? Perhaps I'm showing my lack of statistics here, but I 
would think that a strict probability distribution would have the 
value of all of the bars adding to 1,
Sorry to send out so many messages today. I really am trying to 
figure this out on my own...

>>>>> "Simson" == Simson Garfinkel <si...@ac...> writes:
 Simson> That's odd. I would think that it makes more sense to set
 Simson> the format *before* the data is plot, not after.
...
 Simson> Probably a good thing for people like me who have never
 Simson> used Matlab.
This is not a matlab vs non-matlab thing, it's just a plain-ol-bug.
As far as I know, matlab doesn't have a concept of tick locators and
formatters, it's an idea loosely borrowed from pyx. The order of
operations bug crept in because matplotlib has a default tick locator
and formatter that are not appropriate for date plotting, and when you
call ax.plot_date, which just forwards the call on to ax.xaxis_date,
the tick locator and formatter were being forcibly reset to the
AutoDateLocator and AutoDateFormatter. If you are a naive user and
have done no customization, 99% of the time this is what you want. But
if you have set your DateFormatter or DateLocator already, then this
is not what you want.
I made a change will help: now I check and see of the
formatter/locator is of the right type before forcibly resetting, eg
 def xaxis_date(self, tz=None):
 #...snip
 thisformatter = self.xaxis.get_major_formatter()
 if not isinstance(thisformatter, DateFormatter):
 formatter = AutoDateFormatter(locator)
 self.xaxis.set_major_formatter(formatter)
This will help, and should address your use case, but it is not a complete
solution because it doesn't cover the use-case where the user may have
supplied a custom date formatter not derived from DateFormatter. We'd
rather use duck-typing here rather than isinstance but there is no
clear way to do this. We might be able to manage this by checking for
explicit user calls to set_major_formatter and friends but this is
probably brittle. To address this (rare) use case, I've
modified the Axes.plot_date docstring:
 Note if you are using, custom date tickers and formatters, it
 may be necessary to set the formatters/locators after the call
 to plot_date
Changes in svn.
JDH

On Dec 16, 2006, at 10:25 PM, John Hunter wrote:
>>>>>> "Simson" == Simson Garfinkel <si...@ac...> writes:
>
> Simson> Greetings. I've been having lots of luck with my date
> Simson> plots. But I've been having a problem getting the
> Simson> dateformatter to work. I'm using the code below. The dates
> Simson> keep getting formatted with the default, "Sep 28 2006"
> Simson> instead of what I want, "Sep 28"
>
> This is an order of opertations problem. The call to "plot_date" sets
> the DateFormatter, overriding your choices. You need to set your
> custom formatter after the call to plot_date:
That's odd. I would think that it makes more sense to set the format 
*before* the data is plot, not after.
>
>
> ax.plot_date(dates, vals, 'bo')
> ax.xaxis.set_major_formatter(DateFormatter('%b %d'))
> ax.yaxis.set_major_formatter(FormatStrFormatter('%3.0f KBps'))
>
> This is an annoyance that we can fix by setting the date formatter
> only if the current formatter is *not* a date formatter instance.
Probably a good thing for people like me who have never used Matlab.

>>>>> "Simson" == Simson Garfinkel <si...@ac...> writes:
 Simson> Greetings. I've been having lots of luck with my date
 Simson> plots. But I've been having a problem getting the
 Simson> dateformatter to work. I'm using the code below. The dates
 Simson> keep getting formatted with the default, "Sep 28 2006"
 Simson> instead of what I want, "Sep 28"
This is an order of opertations problem. The call to "plot_date" sets
the DateFormatter, overriding your choices. You need to set your
custom formatter after the call to plot_date:
 ax.plot_date(dates, vals, 'bo')
 ax.xaxis.set_major_formatter(DateFormatter('%b %d'))
 ax.yaxis.set_major_formatter(FormatStrFormatter('%3.0f KBps'))
This is an annoyance that we can fix by setting the date formatter
only if the current formatter is *not* a date formatter instance.
JDH

A friend of mine from MIT who is just finishing his PhD was over for 
dinner tonight. We discussed the learning curve of matplotlib and 
compared it with other plotting systems that we've both used, 
including gnuplot & PyX.
My friend said that he thought that the learning curve was really 
high, but that he had been motivated to do something with it, so he 
had persevered. He wasn't entirely happy with what he got, but it was 
okay. He co-author on a paper, though, couldn't figure it out and 
thought that it wasn't worth the effort.
Interestingly enough, Crossroads, the ACM student publication, had a 
really interested article on this in the Summer 2006 issue. The 
article, by Christopher Scaffidi, is titled "Why Are APIs Difficult 
to Learn and Use?" I would recommend it to anyone who is developing 
an API or a package. You can read it at http://www.acm.org/crossroads/ 
xrds12-4/difficultapis.html. The gist of the article is that 
documentation is extremely important, after which "hello world" 
programs can be helpful. However, it's really important to have an 
API that is orthogonal and has the right abstractions.
One of the things that I would have added to the article is the 
importance of having decent defaults.
I'm very interested in putting together a document that would be 
incorporated into the user's manual that would describe the 
abstractions used by matplotlib. I think that this would help me to 
understand it better, and would also be useful to the community. Does 
anything like this currently exist?
To answer Eric's most recent posting:
1. I think that scientific notation should not be the default, unless 
numbers exceed 1E+7.
2. It would be nice if there was an easy way to get commas into 
numbers. (This is forever a problem; I wish that the original C folks 
had thought to put commas into their original printf formatting. I 
have a nice python commas function if you want it, although you can 
probably create one that is more efficient.)
3. If I was going to make a major change to the API at this point, it 
would be to make it so that you don't have a class/function/ 
identifier called "axes" and another one called "axis." I frequently 
get confused between these two words; I imagine that non-native 
English speakers get confused even more frequently. Irregular noun 
plurals in English are confusing, and it probably isn't necessary to 
use both. One approach would be to never allow "axis," to only allow 
"xaxis" and "yaxis" and perhaps something (either_axis?) for the 
abstract super-class, but this may be a bigger change than you wish 
to consider at the present time.
> It may make sense to have a simpler interface to this--especially 
> simply turning scientific notation on or off on one or both axes-- 
> at the Axes class level and the pylab level, but I thought I would 
> take it a step at a time. I am open to suggestions as to method/ 
> function name and signature. The matplotlibrc interface could even 
> be used if people really want to be able to make no-scientific- 
> notation their default, but I am wary of dumping more and more 
> knobs into matplotlibrc.
Ah, the matplotlibrc file. It seems that you are trying to do too 
much with this file. Is the point of the file to have default 
graphing behavior, or to have site-wide configuration information? 
You may wish to split the file into two parts --- a config part and a 
graphing preferences part --- because it seems that sometimes people 
wish to change one without changing the other. Or you may want to 
have explicit inheritance --- like an "-include" feature so that a 
local file can just shadow some variables and then include the master 
file. I understand that this can be done with a few lines of python 
at the top of a program. Of course, given that option, you may wish 
to do away with the local files entirely. I'm not sure.
Have the matplotlib developers put together a roadmap of their 
directions that they want to take this project?
-Simson

Simson L. Garfinkel's Treo 700p wrote:
> Yep. I would like to pass in a list of lists, where each sublist (or array) 
> describes a boxplot to plot.
This is now present in svn.
> 
> Meanwhile, i've been having fun with histograms. The Y axis labels are a 
> pain. I think defaulting to scientific notation, as matplotlib frequently 
> does, is annoying...
I think you are not the first who has been annoyed by this, so I added a 
couple of methods to the ScalarFormatter class, which is used by default 
for labelling ticks with linear axes.
If you have a plot with linear axes and you want to turn off scientific 
notation on the x-axis, for example, this will do it:
gca().xaxis.major.formatter.set_scientific(False)
(If plotting interactively with ipython you will need to force a redraw. 
The draw() command is one way to do it.)
If you want to use scientific notation but with a different threshold, 
you can do:
gca().xaxis.major.formatter.set_powerlimits((-2,3))
to change the thresholds from the default, 1e-3 and 1e4, to 1e-2 and 1e3.
It may make sense to have a simpler interface to this--especially simply 
turning scientific notation on or off on one or both axes--at the Axes 
class level and the pylab level, but I thought I would take it a step at 
a time. I am open to suggestions as to method/function name and 
signature. The matplotlibrc interface could even be used if people 
really want to be able to make no-scientific-notation their default, but 
I am wary of dumping more and more knobs into matplotlibrc.
Eric