matplotlib-users Mailing List for matplotlib (Page 8)

Shot in the dark here, but what if you set the rcParam "path.simplify" 
to False?  There have been recent changes to that code.

Also, since the Agg backend doesn't have an associated GUI, you need to 
use the savefig() command and provide a filename, rather than using show().

Cheers,
Mike

Zane Selvans wrote:
> Um, yeah.  So my response got bounced because of the attachment.  Take 2:
>
> For some reason my script bombed when I switched to the Agg backend,
> trying to display to the screen (it said Figure has no method show())
>
> So I output the plot as both a PDF and a PNG (still having backend:
> agg in my rcfile) and in both of those cases, irregular gaps are
> visible between the polygons making up the filled contours.  This
> wasn't the case with my previously installed setup.  It looks as if
> for some reason the vertices of the filled polygons are being
> calculated differently from different sides of the same contour,
> leading to overlap in some places, and gaps in others.  You can download
> the PDF version (in which the exact geometry is much clearer).
> from:
>
> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>
> Zane
>
> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...> wrote:
>   
>> So you see this behavior if you switch to the Agg backend?  That's the
>> backend used to generate the images in the gallery.  If there's a difference
>> there, that would seem to suggest some tweaking of the macosx backend (which
>> is still relatively new) is in order.
>>
>> Mike
>>
>> Zane Selvans wrote:
>>     
>>> I just installed the latest SciPy Superpack in order to get access to
>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>> now when I use contourf() lines get drawn at the boundaries between
>>> the filled contours.  Additionally, there is always a single vertical
>>> line crossing from each contour boundary to the next.  I'm guessing
>>> that these are the edges of the filled polygons which are getting
>>> drawn.  This behavior doesn't seem to be consistent with the
>>> contourf() documentation and when I run code in griddata_demo.py it
>>> doesn't come out looking like the picture in the documentation/example
>>> gallery...
>>>
>>> Is anyone else seeing this behavior?  Is there a keyword I can use to
>>> force the edges of the polygons not to get drawn?
>>>
>>> This is on Mac OS X 10.5.7, with
>>> scipy.__version__ = 0.8.0.dev5635
>>> matplotlib.__version__ = 0.98.6svn
>>> numpy.__version__=1.4.0.dev6728
>>>
>>> As installed by superpack_2009.03.28.sh
>>> from http://macinscience.org/?page_id=6
>>>
>>> using:
>>> backend: macosx
>>>
>>> Cheers,
>>> Zane
>>>
>>>
>>>       
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>     
>
>
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,

On Fri, Jun 12, 2009 at 10:52 AM, JPKay<ka...@va...> wrote:
> from mpl_toolkits.basemap import Basemap

You have not so far imported mpl_toolkits into the namespace, only
Basemap.  You could do:

import mpl_toolkits.basemap

as another import line, or:

from mpl_toolkits.basemap import Basemap, NetCDFFile

followed by:

ncfile = NetCDFFile(output.nc, ...)

Best,

Matthew

Um, yeah.  So my response got bounced because of the attachment.  Take 2:

For some reason my script bombed when I switched to the Agg backend,
trying to display to the screen (it said Figure has no method show())

So I output the plot as both a PDF and a PNG (still having backend:
agg in my rcfile) and in both of those cases, irregular gaps are
visible between the polygons making up the filled contours.  This
wasn't the case with my previously installed setup.  It looks as if
for some reason the vertices of the filled polygons are being
calculated differently from different sides of the same contour,
leading to overlap in some places, and gaps in others.  You can download
the PDF version (in which the exact geometry is much clearer).
from:

http://zaneselvans.org/dropbox/LinDensity_Grid.pdf

Zane

On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...> wrote:
> So you see this behavior if you switch to the Agg backend?  That's the
> backend used to generate the images in the gallery.  If there's a difference
> there, that would seem to suggest some tweaking of the macosx backend (which
> is still relatively new) is in order.
>
> Mike
>
> Zane Selvans wrote:
>>
>> I just installed the latest SciPy Superpack in order to get access to
>> the scipy.spatial.KDTree class, and discovered that for some reason
>> now when I use contourf() lines get drawn at the boundaries between
>> the filled contours.  Additionally, there is always a single vertical
>> line crossing from each contour boundary to the next.  I'm guessing
>> that these are the edges of the filled polygons which are getting
>> drawn.  This behavior doesn't seem to be consistent with the
>> contourf() documentation and when I run code in griddata_demo.py it
>> doesn't come out looking like the picture in the documentation/example
>> gallery...
>>
>> Is anyone else seeing this behavior?  Is there a keyword I can use to
>> force the edges of the polygons not to get drawn?
>>
>> This is on Mac OS X 10.5.7, with
>> scipy.__version__ = 0.8.0.dev5635
>> matplotlib.__version__ = 0.98.6svn
>> numpy.__version__=1.4.0.dev6728
>>
>> As installed by superpack_2009.03.28.sh
>> from http://macinscience.org/?page_id=6
>>
>> using:
>> backend: macosx
>>
>> Cheers,
>> Zane
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>



-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

Hello,
Is there a way to plot half-filled markers in matplotlib ?

For example, I would like to use a circle marker, lower half filled in black
while the upper half is white.

Thanks,
Eli

The suggestion to install matplotlib.basemap seems to be the right direction
to go. However, I have been unsuccessful in importing the file by this
method. This is what I have been trying. 

from mpl_toolkits.basemap import Basemap
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.mlab as mlab
mpl_toolkits.basemap.NetCDFFile(output.nc, mode='r', maskandscale=True,
cache=None, mmap=True, username=None, password=None, verbose=False)

I am getting the following error as a result.  

Traceback (most recent call last):
  File "/Users/interpott/Documents/trial.py", line 6, in <module>
    mpl_toolkits.basemap.NetCDFFile(output.nc, mode='r', maskandscale=True,
cache=None, mmap=True, username=None, password=None, verbose=False)
NameError: name 'mpl_toolkits' is not defined

How do I force the location of the Netcdf file? and Why am I getting that
mpl_toolkits are not defined? 
Thanks for the help, 

Jon 


Jeff Whitaker wrote:
> 
> Eric Firing wrote:
>> Gökhan SEVER wrote:
>>   
>>> On Thu, Jun 11, 2009 at 1:09 PM, JPKay <ka...@va... 
>>> <mailto:ka...@va...>> wrote:
>>>
>>>
>>>     Hello,
>>>     I am trying to use matplotlib to create a quiver plot of a NetCDF
>>>     file with
>>>     the extension .nc. The Netcdf file is a series of arrays that
>>> contain
>>>     information about the stress tensors on a globe.
>>>
>>>     I am struggling to import the file into python and having the quiver
>>>     data
>>>     show up.
>>>     To import the file I have been using:
>>>     “ncdump file.nc <http://file.nc>”
>>>
>>>
>>>     Any thoughts would be appreciated.
>>>     Thanks,
>>>     Jon
>>>     --
>>>     View this message in context:
>>>    
>>> http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p23986313.html
>>>     Sent from the matplotlib - users mailing list archive at Nabble.com.
>>>
>>>
>>> I recommend you to check netcdf4-python 
>>> (http://code.google.com/p/netcdf4-python/)
>>> You can load both netcdf3 and 4 files. Additionally, there are date 
>>> conversion utilities which help to do transforms between numbers and 
>>> dates and vice versa.
>>>     
>>
>> Caution: it's great, and I use it, but it is not trivial to build and 
>> install.  I think the OP would do best to start with pupynere. The web 
>> site for download looks like it is working: 
>> http://pypi.python.org/pypi/pupynere/
>>
>> Eric
>>
>>
>>   
> Note that if the OP is using basemap, an interface to pupynere is 
> already included (see 
> http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html#mpl_toolkits.basemap.NetCDFFile).
> 
> -Jeff
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24003499.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

2009/6/12 Virgil Stokes <vs...@it...>

> I am rather new to matplotlib and would appreciate help on how I can install
> matplotlib with Python 2.6.2 on a Windows Vista platform.
>
>
>
You have to build it manually. Assumed you have Visual Studio 2008
installed:

   1. install freetype (freetype-2.3.5-1-setup.exe)
   2. install libpng (libpng-1.2.35-setup.exe)
   3. install zlib (zlib-1.2.3.exe)
   4. download and unzip the matplotlib sources
   (matplotlib-0.98.5.2.tar.gz), I will refer to this folder as
   [matplotlib_home]
   5. download and unzip win32_static_vs.tar.gz into [matplotlib_home]
   6. read [matplotlib_home] /INSTALL
   7. type the install commands from the VisualStudio2008-Command-Shell in
   [matplotlib_home]
      - 7.1 python setup.py build
      - 7.2 python setup.py install

Regards
Magnus

The description of 'n' vs 'f' below doesn't seem to align with what the 
spec says: that 'n' is for in-use objects and 'f' is for free objects.  
However, the spec does say:

"The first entry in the table (object number 0) is always free and has a 
generation number of 65,535; it is the head of the linked list of free 
objects."

So it seems reasonable to make this change.

This has now been fixed in the SVN 0.98.x maintenance branch and trunk, 
but not tested against ReportLab's parser.  Mike: are you able to check 
out from SVN and test this for us?

Mike

Michael Hearne wrote:
> All: I am using PDF files generated from matplotlib, and a PDF parser 
> from ReportLab, Inc.  Their tool encountered a bug in the PDF 
> specification.  The company's email to me follows:
>
>>
>> ...matplotlib is violating the PDF specification.   There
>> is a structure near the end of the file shown below, and they have put
>> an 'n' instead of an 'f' which tells a (suitably pedantic) parser that
>> the first meaningful content is to be found at byte 0 in the file, not
>> byte 16 where it really lives.
>>
>> xref
>> 0 62
>> 0000000000 65535 n   <---- should be 'f'
>> 0000000016 00000 n
>> 0000000065 00000 n
>> 0000000218 00000 n
>>
>> That row with the '00000000 65535' is present in all PDF files.  I
>> change the 'n' to an 'f' in a good binary editor and it goes through
>> fine.
>>
>> I have also added a special case to our code to correct for this. I
>> suspect other PDF viewers just skip the first row so were not bitten.
>
> I was able to figure out which module contains the offending code, but 
> not which lines actually print out that data.
>
> I submitted a bug report here:
> https://sourceforge.net/tracker/?func=detail&aid=2805455&group_id=80706&atid=560720 
> <https://sourceforge.net/tracker/?func=detail&aid=2805455&group_id=80706&atid=560720>
>
> Thanks,
>
> Mike
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

On Wed, Jun 10, 2009 at 12:55 AM, Steve
Nicholes<ema...@ya...> wrote:
> Thanks John.  I hope you aren't receiving this reply twice (my email kicked
> me out when I hit send).  I actually am importing pylab so it isn't an
> entirely qt app.  I didn't post all of the code originally b/c it is long
> (and it would reveal how poor of a programmer I am :) ), but here are the
> relevant sections.  The problematic section is in blue.  Please let me know
> if you need anything else.

Importing pylab or pyplot into a GUI app is simply not supported.
There is never a reason to do it, and it is fraught with perils.  I
don't know if this has anything to do with the problem you are
experiencing, but you need to remove these imports before we can
proceed.

JDH

All: I am using PDF files generated from matplotlib, and a PDF parser  
from ReportLab, Inc.  Their tool encountered a bug in the PDF  
specification.  The company's email to me follows:

>
> ...matplotlib is violating the PDF specification.   There
> is a structure near the end of the file shown below, and they have put
> an 'n' instead of an 'f' which tells a (suitably pedantic) parser that
> the first meaningful content is to be found at byte 0 in the file, not
> byte 16 where it really lives.
>
> xref
> 0 62
> 0000000000 65535 n   <---- should be 'f'
> 0000000016 00000 n
> 0000000065 00000 n
> 0000000218 00000 n
>
> That row with the '00000000 65535' is present in all PDF files.  I
> change the 'n' to an 'f' in a good binary editor and it goes through
> fine.
>
> I have also added a special case to our code to correct for this. I
> suspect other PDF viewers just skip the first row so were not bitten.

I was able to figure out which module contains the offending code, but  
not which lines actually print out that data.

I submitted a bug report here:
https://sourceforge.net/tracker/?func=detail&aid=2805455&group_id=80706&atid=560720

Thanks,

Mike

On Tue, Jun 9, 2009 at 6:17 PM, Steve Nicholes
<ema...@ya...>wrote:

> Hi,
>
> I am writing some code for automated testing via GPIB using MPL and PyQt.
> To simulate automated data collection while debugging the program, I have
> added a for loop (see below) after reading in a data file that plots each
> point one by one.  When I run the program in Linux, I see each point appear
> on the canvas one by one as designed, but when I run the same code in
> Windows, nothing shows up on the canvas during the for loop.  Instead, once
> the loop has completed, all points appear simulataneously.  Is there any
> reason the why calls to canvas.draw() show nothing when run in Windows?



I have seen similar discrepancies between PyQt4 behavior on linux and
windows in a few situations. In my experience, a call to
PyQt4.QtGui.qApp.processEvents() is sufficient to force an update in your
view.

Darren

On Fri, Jun 12, 2009 at 2:01 PM, John Hunter<jd...@gm...> wrote:
> On Fri, Jun 12, 2009 at 6:10 AM, Sebastian Haase<seb...@gm...> wrote:
>> On Fri, Jun 12, 2009 at 11:21 AM, Matthias
>> Michler<Mat...@gm...> wrote:
>>> Hi Sebastian,
>>>
>>> You are right. A large number of numpy functions is part of pylab, but I think
>>> this problem was solved by introducing matplotlib.pyplot, which holds all
>>> plotting functions of matplotlib. The module pylab imports these plotting
>>> functions and all the numpy-stuff in order to offer plotting + numerical
>>> functions by one import.
>>>
>>> kind regards Matthias
>>>
>> Matthias,
>> thanks for the info. thats the info I was missing.
>>>>> from matplotlib import pyplot
>>>>> len(pyplot.__dict__)
>> 191
>>
>> Now I'm somewhat wondering about the things in pylab that are not in
>> pyplot nor in numpy.
>> E.g.:
>> pyplot.log2  is not numpy.log2
>> or
>> pyplot.window_hanning   vs.  numpy.hanning
>> or
>> pyplot.chisquare  (which however is in numpy.random)
>
>
> These symbols are not in svn:
>
>
> In [59]: plt.log2
> ------------------------------------------------------------
> Traceback (most recent call last):
>  File "<ipython console>", line 1, in ?
> AttributeError: 'module' object has no attribute 'log2'
>
>
> In [60]: plt.window_hanning
> ------------------------------------------------------------
> Traceback (most recent call last):
>  File "<ipython console>", line 1, in ?
> AttributeError: 'module' object has no attribute 'window_hanning'
>

Sorry - I meant pylab ! not pyplot ...
There are those symbols.

-S.

So you see this behavior if you switch to the Agg backend?  That's the 
backend used to generate the images in the gallery.  If there's a 
difference there, that would seem to suggest some tweaking of the macosx 
backend (which is still relatively new) is in order.

Mike

Zane Selvans wrote:
> I just installed the latest SciPy Superpack in order to get access to
> the scipy.spatial.KDTree class, and discovered that for some reason
> now when I use contourf() lines get drawn at the boundaries between
> the filled contours.  Additionally, there is always a single vertical
> line crossing from each contour boundary to the next.  I'm guessing
> that these are the edges of the filled polygons which are getting
> drawn.  This behavior doesn't seem to be consistent with the
> contourf() documentation and when I run code in griddata_demo.py it
> doesn't come out looking like the picture in the documentation/example
> gallery...
>
> Is anyone else seeing this behavior?  Is there a keyword I can use to
> force the edges of the polygons not to get drawn?
>
> This is on Mac OS X 10.5.7, with
> scipy.__version__ = 0.8.0.dev5635
> matplotlib.__version__ = 0.98.6svn
> numpy.__version__=1.4.0.dev6728
>
> As installed by superpack_2009.03.28.sh
> from http://macinscience.org/?page_id=6
>
> using:
> backend: macosx
>
> Cheers,
> Zane
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Jun 12, 2009 at 6:10 AM, Sebastian Haase<seb...@gm...> wrote:
> On Fri, Jun 12, 2009 at 11:21 AM, Matthias
> Michler<Mat...@gm...> wrote:
>> Hi Sebastian,
>>
>> You are right. A large number of numpy functions is part of pylab, but I think
>> this problem was solved by introducing matplotlib.pyplot, which holds all
>> plotting functions of matplotlib. The module pylab imports these plotting
>> functions and all the numpy-stuff in order to offer plotting + numerical
>> functions by one import.
>>
>> kind regards Matthias
>>
> Matthias,
> thanks for the info. thats the info I was missing.
>>>> from matplotlib import pyplot
>>>> len(pyplot.__dict__)
> 191
>
> Now I'm somewhat wondering about the things in pylab that are not in
> pyplot nor in numpy.
> E.g.:
> pyplot.log2  is not numpy.log2
> or
> pyplot.window_hanning   vs.  numpy.hanning
> or
> pyplot.chisquare  (which however is in numpy.random)


These symbols are not in svn:


In [59]: plt.log2
------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in ?
AttributeError: 'module' object has no attribute 'log2'


In [60]: plt.window_hanning
------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in ?
AttributeError: 'module' object has no attribute 'window_hanning'

On Fri, Jun 12, 2009 at 11:21 AM, Matthias
Michler<Mat...@gm...> wrote:
> Hi Sebastian,
>
> You are right. A large number of numpy functions is part of pylab, but I think
> this problem was solved by introducing matplotlib.pyplot, which holds all
> plotting functions of matplotlib. The module pylab imports these plotting
> functions and all the numpy-stuff in order to offer plotting + numerical
> functions by one import.
>
> kind regards Matthias
>
Matthias,
thanks for the info. thats the info I was missing.
>>> from matplotlib import pyplot
>>> len(pyplot.__dict__)
191

Now I'm somewhat wondering about the things in pylab that are not in
pyplot nor in numpy.
E.g.:
pyplot.log2  is not numpy.log2
or
pyplot.window_hanning   vs.  numpy.hanning
or
pyplot.chisquare  (which however is in numpy.random)

In summary, could one say that some functions are "left" in pylab to
keep backwards- and/or Matlab- compatibility ?
But does window_hanning behave exactly like numpy.hanning ?

I remember that some functions where decidedly implemented differently
than in numpy --  (sqrt for sqrt(-1) => 1j -- or was this scipy vs.
numpy)


Cheers,
Sebastian



> On Friday 12 June 2009 10:49:52 Sebastian Haase wrote:
>> Hi,
>> long time ago there was a discussion on reducing the duplications of
>> functions / symbols between Numpy and Matplotlib.
>>
>> I think from this resulted the pylab module now having many fewer entries:
>> >>> import matplotlib
>> >>> matplotlib.__version__
>>
>> '0.98.5.2'
>>
>> >>> import pylab
>> >>> len(pylab.__dict__)
>>
>> 882
>>
>> However, I think these are still to many !  I wrote, already before
>> the cleanup, a "HACK"-cleanup routine, which makes a cut-down modules
>> (called P) like this:
>> # P = new.module("pylab_sparse","""pylab module minus stuff alreay in
>> numpy""") for k,v in pylab.__dict__.iteritems():
>>     try:
>>        if k[:2] == '__' or v is numpy.__dict__[k]:
>>            continue
>>     except KeyError:
>>        pass
>>     #P.__dict__[k] = v
>>     exec("%s = pylab.%s" % (k,k))
>>
>> ((the commented out lines did not work, but they might still
>> illustrate what I want to do -- now I have this code in a separate
>> module that I can import as "P"
>>
>> This way I get:
>> >>> len(P.__dict__)
>>
>> 395
>>
>> >>> numpy.__version__
>>
>> '1.3.0'
>>
>>
>> So why are there still that many -- more than half ! -- duplications
>> between pylab and numpy ?
>>
>> Regards,
>>
>> Sebastian Haase

On Fri, Jun 12, 2009 at 4:21 AM, Matthias
Michler<Mat...@gm...> wrote:

> You are right. A large number of numpy functions is part of pylab, but I think
> this problem was solved by introducing matplotlib.pyplot, which holds all
> plotting functions of matplotlib. The module pylab imports these plotting
> functions and all the numpy-stuff in order to offer plotting + numerical
> functions by one import.

See also http://matplotlib.sourceforge.net/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related

JDH

On Fri, Jun 12, 2009 at 5:34 AM, Virgil Stokes<vs...@it...> wrote:
> I am rather new to matplotlib and would appreciate help on how I can
> install matplotlib with Python 2.6.2 on a Windows Vista platform.

The matplotlib installer is broken for python2.6 -- I have been
working on fixing it, but it is not an easy problem.  A recent post on
the subject is here:

  http://www.nabble.com/binary-installers-for-python2.6--libpng-segfault%2C-MSVCR90.DLL-and-%09mingw-td23971661.html

if there is anyone out there who has time to spend on this problem,
that would be great.

JDH

----- Mensaje original ----
> De: Eric Firing <ef...@ha...>
> 
> import matplotlib.cbook as cbook
> 
> def to_sequence(arg):
>     if cbook.is_iterable(arg):
>         return arg
>     return [arg]
> 
> Above is an example of how one can turn a scalar into a sequence (a list, in 
> this case) if necessary.

When I enter this into ipython, I get:

In [67]: to_sequence(1)
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/jscandal/sw/python/myimports.py in <module>()
----> 1 
      2 
      3 
      4 
      5 

/home/jscandal/sw/python/myimports.py in to_sequence(arg)
      1 
----> 2 
      3 
      4 
      5 

AttributeError: 'module' object has no attribute 'is_iterable'

I have matplotlib 0.98.5.2, and it seems is_iterable is not there.


> Different types of sequence have different advantages and disadvantages. Tuples 
> are immutable.  Lists are much more flexible, and can be extended.  ndarrays are 
> fixed-size, but facilitate efficient computation.
> 
> If a function or method accepts any kind of sequence for a given argument, then 
> probably the thing to do is give it whatever you have already, or whatever is 
> most convenient to generate.  Lists are a good default if the sequence has only 
> a few elements and you are writing them out, rather than calculating them from 
> some other sequence.  In other words, if a function is flexible, then trust the 
> function to do whatever conversions it needs internally; there is no particular 
> advantage in doing the conversion yourself when you specify the argument.
> 

Thanks for the hints, I guess I get a bit frustrated or lost sometimes. Trying to get work done while being at the bottom of the learning curve might not be the best situation. I have the feeling, though, that I had to switch this way or else I would never really do it at all. I've been wanting to play with python for a long time now, but never did anything more than hello world examples. Until now ;)

Jorge


      

I am rather new to matplotlib and would appreciate help on how I can 
install matplotlib with Python 2.6.2 on a Windows Vista platform.

Thanks, :-)
V. Stokes

Hi Sebastian,

You are right. A large number of numpy functions is part of pylab, but I think 
this problem was solved by introducing matplotlib.pyplot, which holds all 
plotting functions of matplotlib. The module pylab imports these plotting 
functions and all the numpy-stuff in order to offer plotting + numerical 
functions by one import.

kind regards Matthias

On Friday 12 June 2009 10:49:52 Sebastian Haase wrote:
> Hi,
> long time ago there was a discussion on reducing the duplications of
> functions / symbols between Numpy and Matplotlib.
>
> I think from this resulted the pylab module now having many fewer entries:
> >>> import matplotlib
> >>> matplotlib.__version__
>
> '0.98.5.2'
>
> >>> import pylab
> >>> len(pylab.__dict__)
>
> 882
>
> However, I think these are still to many !  I wrote, already before
> the cleanup, a "HACK"-cleanup routine, which makes a cut-down modules
> (called P) like this:
> # P = new.module("pylab_sparse","""pylab module minus stuff alreay in
> numpy""") for k,v in pylab.__dict__.iteritems():
>     try:
>        if k[:2] == '__' or v is numpy.__dict__[k]:
>            continue
>     except KeyError:
>        pass
>     #P.__dict__[k] = v
>     exec("%s = pylab.%s" % (k,k))
>
> ((the commented out lines did not work, but they might still
> illustrate what I want to do -- now I have this code in a separate
> module that I can import as "P"
>
> This way I get:
> >>> len(P.__dict__)
>
> 395
>
> >>> numpy.__version__
>
> '1.3.0'
>
>
> So why are there still that many -- more than half ! -- duplications
> between pylab and numpy ?
>
> Regards,
>
> Sebastian Haase

Hi,
long time ago there was a discussion on reducing the duplications of
functions / symbols between Numpy and Matplotlib.
I think from this resulted the pylab module now having many fewer entries:
>>> import matplotlib
>>> matplotlib.__version__
'0.98.5.2'
>>> import pylab
>>> len(pylab.__dict__)
882

However, I think these are still to many !  I wrote, already before
the cleanup, a "HACK"-cleanup routine, which makes a cut-down modules
(called P) like this:
# P = new.module("pylab_sparse","""pylab module minus stuff alreay in numpy""")
for k,v in pylab.__dict__.iteritems():
    try:
       if k[:2] == '__' or v is numpy.__dict__[k]:
           continue
    except KeyError:
       pass
    #P.__dict__[k] = v
    exec("%s = pylab.%s" % (k,k))

((the commented out lines did not work, but they might still
illustrate what I want to do -- now I have this code in a separate
module that I can import as "P"

This way I get:
>>> len(P.__dict__)
395

>>> numpy.__version__
'1.3.0'


So why are there still that many -- more than half ! -- duplications
between pylab and numpy ?

Regards,

Sebastian Haase

jor...@ya... wrote:
> 

> Hi, The matplotlib.collections.Collection documentation reads: "All
> properties in a collection must be sequences or scalars; if scalars,
> they will be converted to sequences.  The property of the ith element
> of the collection is: prop[i % len(props)]". I had a look at the
> docstring documentation from ipython, but I didn't find out how the
> above is achieved (I am learning Python together with numpy,
> matplotlib, etc.). In my own code, how could I do something like
> this? If you point to a relevant location on the source code, that's

import matplotlib.cbook as cbook

def to_sequence(arg):
     if cbook.is_iterable(arg):
         return arg
     return [arg]

Above is an example of how one can turn a scalar into a sequence (a 
list, in this case) if necessary.

> alright. I also get confused sometimes because of the multiple (and
> sometimes interchangeable) ways of specifying arguments: sequences
> (list, tuples), numpy arrays, etc. I started using almost exclusively
> numpy arrays (probably due to my matlab background), but I am
> starting to mix a bit of everything now (depending on what "sources
> of inspiration" I use), so I wondered what a good guideline would be.

Different types of sequence have different advantages and disadvantages. 
Tuples are immutable.  Lists are much more flexible, and can be 
extended.  ndarrays are fixed-size, but facilitate efficient computation.

If a function or method accepts any kind of sequence for a given 
argument, then probably the thing to do is give it whatever you have 
already, or whatever is most convenient to generate.  Lists are a good 
default if the sequence has only a few elements and you are writing them 
out, rather than calculating them from some other sequence.  In other 
words, if a function is flexible, then trust the function to do whatever 
conversions it needs internally; there is no particular advantage in 
doing the conversion yourself when you specify the argument.

Eric

Hello,

Is there some reason the first and second figure in the simple program 
below should show any difference other than color?  (On my machine, the 
first plot is missing the 3 and 4 datapoints.)

import pylab as p
x1=[1, 2, 3, 4, 2, 2, 2, 3, 3, 3]
x2=[1, 2]
p.figure()
p.hist([x2, x1], histtype='barstacked')
p.figure()
p.hist([x1, x2], histtype='barstacked')
p.show()

It seems that the xrange is computed from the first data in the sequence 
and then anything in the second sequence that is outside that range is 
simply tossed.  If I force the bins to encompass the entire range with 
bins= in the hist() call, then all data is displayed in both plots.  Is 
this desired/expected?

I am running matplotlib 0.98.5.2-1ubuntu3.

Thanks for any help, and thanks for matplotlib!

Rich

I just installed the latest SciPy Superpack in order to get access to
the scipy.spatial.KDTree class, and discovered that for some reason
now when I use contourf() lines get drawn at the boundaries between
the filled contours.  Additionally, there is always a single vertical
line crossing from each contour boundary to the next.  I'm guessing
that these are the edges of the filled polygons which are getting
drawn.  This behavior doesn't seem to be consistent with the
contourf() documentation and when I run code in griddata_demo.py it
doesn't come out looking like the picture in the documentation/example
gallery...

Is anyone else seeing this behavior?  Is there a keyword I can use to
force the edges of the polygons not to get drawn?

This is on Mac OS X 10.5.7, with
scipy.__version__ = 0.8.0.dev5635
matplotlib.__version__ = 0.98.6svn
numpy.__version__=1.4.0.dev6728

As installed by superpack_2009.03.28.sh
from http://macinscience.org/?page_id=6

using:
backend: macosx

Cheers,
Zane

-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

Hi John,

John Hunter wrote:
> On Tue, Jun 9, 2009 at 3:05 PM, Lou Pecora<lou...@ya...> wrote:
> 
>> ---------------------------------------------------------------------------------------------
>> It is good news that matplotlib 3D functions are being upgraded.  Thank you.
>> But it is unclear from the message whether one still must stay with 0.91
>> version or the 3D functions in pylab now work with 0.98 and higher.  Can you
>> give us some information on that?
> 
> They now work in matplotlib svn in the toolkit mpl_toolkits.mplot3d,
> and will be available in the next release

That is great news indeed .. I haven't been using matplotlib for very
long at all, so I have no feel for the update frequency. Could you give us
a hint/ballpark timeframe as to when the next release with the 3D
functionality would be forthcoming?

If I can limit the number of plotting tools I'm using to matplotlib + python
and gnuplot (standalone) I'd be perfectly happy (though mayavi looks worth
exploring at some point possibly too - but no rush if matplotlib can do the 3D
thing :-)

Thanks,
Esmail

Eric Firing wrote:
> Gökhan SEVER wrote:
>   
>> On Thu, Jun 11, 2009 at 1:09 PM, JPKay <ka...@va... 
>> <mailto:ka...@va...>> wrote:
>>
>>
>>     Hello,
>>     I am trying to use matplotlib to create a quiver plot of a NetCDF
>>     file with
>>     the extension .nc. The Netcdf file is a series of arrays that contain
>>     information about the stress tensors on a globe.
>>
>>     I am struggling to import the file into python and having the quiver
>>     data
>>     show up.
>>     To import the file I have been using:
>>     “ncdump file.nc <http://file.nc>”
>>
>>
>>     Any thoughts would be appreciated.
>>     Thanks,
>>     Jon
>>     --
>>     View this message in context:
>>     http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p23986313.html
>>     Sent from the matplotlib - users mailing list archive at Nabble.com.
>>
>>
>> I recommend you to check netcdf4-python 
>> (http://code.google.com/p/netcdf4-python/)
>> You can load both netcdf3 and 4 files. Additionally, there are date 
>> conversion utilities which help to do transforms between numbers and 
>> dates and vice versa.
>>     
>
> Caution: it's great, and I use it, but it is not trivial to build and 
> install.  I think the OP would do best to start with pupynere. The web 
> site for download looks like it is working: 
> http://pypi.python.org/pypi/pupynere/
>
> Eric
>
>
>   
Note that if the OP is using basemap, an interface to pupynere is 
already included (see 
http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html#mpl_toolkits.basemap.NetCDFFile).

-Jeff