matplotlib-users — Discussion related to using matplotlib

[Matplotlib-users] line style

[Massimo S. <sab...@de...>]

Dear group,

is it possible to set the default sequence of line styles, colors, 
widths, etc. to be used when plotting multiple lines ?
pylab.rc seems to set the default parameters only for the first line.

I've googled about it, but it does not seem a very popular question.

Thank you in advance,
Massimo

Re: [Matplotlib-users] GTKAgg Win XP

[matthew a. <ma...@ca...>]

I went through the pygtk win32 setup thing again this month, and it's 
still a bit fiddly, but it's getting better. I updated the pygtk FAQ:

http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq21.002.htp

Alas ipython slows to a crawl using GTK interactively. It started 
happening sometime between gtk 2.2 and gtk 2.4.

I'm still a bit dubious about gtk support for non-English win32. I've 
had some fatal problems with Japanese windows. The vibe I get from gtk 
developer lists about win32 is a bit negative.

So I'm thinking of switching to wx on win32. It seems to work fine with 
ipython at least.

m.

On 12/02/2005 7:36 PM, Mark Hailes wrote:
> Hi
>  
> I think that GTK has some parallel development strands, which 
> is confusing ...

Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

[Darren D. <dd...@co...>]

oops, I just noticed a bug, the first script I posted wont run. This updated script 
worked for me with a fresh 0.72.1 installation. Sorry about the error.

Darren

from matplotlib import *
rc('font',size='smaller')
rc('tick',labelsize='smaller')
from matplotlib.ticker import ScalarFormatter, LinearLocator
import math
from matplotlib.numerix import absolute, average

from pylab import *

class ScalarFormatterScientific(ScalarFormatter):
    """
    Tick location is a plain old number.  If useOffset==True and the data range
    <1e-4* the data average, then an offset will be determined such that the
    tick labels are meaningful. Scientific notation is used for data < 1e-4 or 
    data >= 1e4. Scientific notation is presented once for each axis, in the 
    last ticklabel.
    """
    def __init__(self, useOffset=True):
        """
        useOffset allows plotting small data ranges with large offsets:
        for example: [1+1e-9,1+2e-9,1+3e-9]
        """
        self._useOffset = useOffset
        self.offset = 0
        self.orderOfMagnitude = 0
        self.format = None
        
    def set_locs(self, locs):
        self.locs = locs
        self._set_offset()
        self._set_orderOfMagnitude()
        self._set_format()
        
    def _set_offset(self):
        # offset of 20,001 is 20,000, for example
        if self._useOffset:
            ave_loc = average(self.locs)
            std_loc = std(self.locs)
            if ave_loc: # dont want to take log10(0)
                ave_oom = math.floor(math.log10(absolute(ave_loc)))
                if std_loc/math.fabs(ave_loc) < 1e-4: # four sig-figs
                    # add 1e-15 because of floating point precision, fixes conversion
                    self.offset = int(ave_loc/10**ave_oom+1e-15)*10**ave_oom
        else: self.offset = 0
        
    def _set_orderOfMagnitude(self):
        # if scientific notation is to be used, find the appropriate exponent
        # if using an offset, find the OOM after applying the offset
        locs = array(self.locs)-self.offset
        ave_loc_abs = average(absolute(locs))
        oom = math.floor(math.log10(ave_loc_abs))
        # need to special-case for range of 0-1e-5
        if oom <= 0 and std(locs) < 1e-4:#10**(2*oom):
            self.orderOfMagnitude = oom
        elif oom <=0 and oom >= -5:
            pass
        elif math.fabs(oom) >= 4:
            self.orderOfMagnitude = oom
                
    def _set_format(self):
        # set the format string to format all the ticklabels
        locs = (array(self.locs,'d')-self.offset) / \
                10**self.orderOfMagnitude+1e-15
        sigfigs = [len(str('%1.4f'% loc).split('.')[1].rstrip('0')) \
                   for loc in locs]
        sigfigs.sort()
        self.format = '%1.' + str(sigfigs[-1]) + 'f'
                
    def pprint_val(self, x, d):
        # d is no longer necessary, x is the tick location.
        xp = (x-self.offset)/10**self.orderOfMagnitude
        if x==self.locs[-1] and (self.orderOfMagnitude or self.offset):
            offsetStr = ''
            sciNotStr = ''
            xp = self.format % xp
            if self.offset: 
                p = '%1.e+'% self.offset
                offsetStr = self._formatSciNotation(p)
            if self.orderOfMagnitude: 
                p = 'x%1.e'% 10**self.orderOfMagnitude
                sciNotStr = self._formatSciNotation(p)
            return ''.join((offsetStr,xp,sciNotStr[2:]))
        elif xp==0: return '%d'% xp
        else: return self.format % xp
            
    def _formatSciNotation(self,s):
        # transform 1e+004 into 1e4, for example
        tup = s.split('e')
        mantissa = tup[0]
        sign = tup[1][0].replace('+', '')
        exponent = tup[1][1:].lstrip('0')
        return '%se%s%s' %(mantissa, sign, exponent)
        

figure(1,figsize=(6,6))
ax1 = axes([.2,.74,.75,.2])
ax1.plot(arange(11)*5e2)
ax1.yaxis.set_major_formatter(ScalarFormatterScientific())
ax1.xaxis.set_visible(False)
ax1.set_title('BIG NUMBERS',fontsize=14)

ax2 = axes([.2,.51,.75,.2])
ax2.plot(arange(11)*1e4)
ax2.yaxis.set_major_formatter(ScalarFormatterScientific())
ax2.text(1,6e4,'y=1e4*x')
ax2.xaxis.set_visible(False)

ax3 = axes([.2,.28,.75,.2])
ax3.plot(arange(11)*1e4+1e10)
ax3.yaxis.set_major_formatter(ScalarFormatterScientific())
ax3.text(1,6e4+1e10,'y=1e4*x+1e10')
ax3.xaxis.set_visible(False)

ax4 = axes([.2,.05,.75,.2])
ax4.plot(arange(11)*1e4+1e10)
ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False))
ax4.text(1,1e10+6e4,'y=1e4*x+1e10, no offset')


figure(2,figsize=(6,6))
ax1 = axes([.225,.74,.75,.2])
ax1.plot(arange(11)*1e-4)
ax1.yaxis.set_major_formatter(ScalarFormatterScientific())
ax1.xaxis.set_visible(False)
ax1.set_title('small numbers',fontsize=8)

ax2 = axes([.225,.51,.75,.2])
ax2.plot(arange(11)*1e-5)
ax2.yaxis.set_major_formatter(ScalarFormatterScientific())
ax2.text(1,6e-5,'y=1e-5*x')
ax2.xaxis.set_visible(False)

ax3 = axes([.225,.28,.75,.2])
ax3.plot(arange(11)*1e-10+1e-5)
ax3.yaxis.set_major_formatter(ScalarFormatterScientific())
ax3.text(1,1e-5+6e-10,'y=1e-10*x+1e-5')
ax3.xaxis.set_visible(False)

ax4 = axes([.225,.05,.75,.2])
ax4.plot(arange(11)*1e-10+1e-5)
ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False))
ax4.text(1,1e-5+6e-10,'y=1e-10*x+1e-5, no offset')
show()

[Matplotlib-users] matplotlib

[Brian R. <br...@se...>]

Hi,

I am a new matplotlib (and new to this list) interested in use for
digital printing.

I made a post in response to a recent presentation on matplotlib in
Chicago:

http://brianray.chipy.org/Python/matplotlib.html

BTW, thanks to John Hunter for the ground breaking presentation at
http://chipy.org. You and anyone on this list is invited to come to our
future meetings.

Thanks!

Brian Ray - Chicago IL 773 835 9876 http://brianray.chipy.org
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: [Matplotlib-users] Legend Font Size

[Robert L. <ro...@le...>]

Alex Rada wrote:
> Hi,
> 
> I'm new to pylab, and I find it very usefull. I want to know how is 
> possibile to change font properties in legend (I particular fontsize): I 
> tried adding "prop = FontProperties("smaller")" in legend(), but this 
> give me an error... maybe I'm wrong...
> 

Try:

  prop = FontProperties( size="smaller" )


 From font_manager.py:

   size    - Either an absolute value of xx-small, x-small, small,
             medium, large, x-large, xx-large; or a relative value
             of smaller or larger; or an absolute font size, e.g. 12;
             or scalable.


Robert

[Matplotlib-users] Legend Font Size

[Alex R. <ale...@gm...>]

Hi,

I'm new to pylab, and I find it very usefull. I want to know how is 
possibile to change font properties in legend (I particular fontsize): I 
tried adding "prop = FontProperties("smaller")" in legend(), but this 
give me an error... maybe I'm wrong...

Thanks, Alex.

[Matplotlib-users] plot array starting or ending with nan

[Darren D. <dd...@co...>]

I need to plot some arrays that may begin or end with nan's. Currently, mpl 
does a good job handling something like plot([1,2,nan,4]), but the has 
trouble with plot([nan,2,3,4]) and plot([1,2,3,nan]).

Could somebody point me in the right direction: where can I look in the 
sourcecode to learn how mpl deals with plotting nans?

-- 

Darren

Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

[Darren D. <dd...@co...>]

On Friday 25 February 2005 08:45 am, Darren Dale wrote:
> On Thursday 24 February 2005 11:02 pm, John Hunter wrote:
> > >>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:
> >
> >     Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show()
> >
> >     Hans> All works fine when I subtract the mean of x but there seems
> >     Hans> to be a problem with labelling axes for plotted data which
> >     Hans> is not close to zero but shows only small variations.
> >
> > I agree it's a bug.  It's not immediately clear to me what the labels
> > should be though
> >
> >   1.0000000002
> >   1.0000000004
> >   1.0000000006
> >
> > and so on?  That takes up a lot of room.  Granted, correct but ugly
> > is better than incorrect but pretty, but I'm curious if there is a
> > better way to format these cases.  Perhaps ideal would be an indicator
> > at the bottom or top of the y axis that read '1+' and then use 2e-9,
> > 4e-9, etc as the actual tick labels.  Do you agree this is ideal?

I worked on a new formatter yesterday and today. It includes the indicator 
that John described above, right now in the last ticklabel at the top of the 
axis. This custom formatter also includes scientific notation in the last 
ticklabel only. The ultimate goal is to have scientific notation be formatted 
like in the logplots, but I havent gotten that far yet.

Using the offset makes a large ticklabel at the moment. You can pass 
useOffset=False to ScalarFormatterScientific to turn this feature off (see end 
of script below). Interested parties, please give this script a whirl and send 
me your comments.

(John, I have now subclassed ScalarFormatter, I didnt realize I had altered 
a method that other formatters were inheriting.)

Darren


from matplotlib import *
rc('font',size='smaller')
rc('tick',labelsize='smaller')
from matplotlib.ticker import ScalarFormatter, LinearLocator
import math
from matplotlib.numerix import absolute, average

from pylab import *

class ScalarFormatterScientific(ScalarFormatter):
    """
    Tick location is a plain old number.  If viewInterval is set, the
    formatter will use %d, %1.#f or %1.ef as appropriate.  If it is
    not set, the formatter will do str conversion
    """
    def __init__(self, useOffset=True):
        """
        useOffset allows plotting small data ranges with large offsets:
        for example: [1+1e-9,1+2e-9,1+3e-9]
        """
        self._useOffset = useOffset
        
    def set_locs(self, locs):
        self.locs = locs
        self._set_offset()
        self._set_orderOfMagnitude()
        self._set_format()
        
    def _set_offset(self):
        # offset of 20,001 is 20,000, for example
        if self._useOffset:
            ave_loc = average(self.locs)
            std_loc = std(self.locs)
            if ave_loc: # dont want to take log10(0)
                ave_oom = math.floor(math.log10(absolute(ave_loc)))
                if std_loc/math.fabs(ave_loc) < 1e-4: # four sig-figs
                    # add 1e-15 because of floating point precision, fixes conversion
                    self.offset = int(ave_loc/10**ave_oom+1e-15)*10**ave_oom
        else: self.offset = 0
        
    def _set_orderOfMagnitude(self):
        # if using an offset, oom applies after applying the offset
        locs = array(self.locs)-self.offset
        ave_loc_abs = average(absolute(locs))
        oom = math.floor(math.log10(ave_loc_abs))
        # need to special-case for range of 0-1e-5
        if oom <= 0 and std(locs) < 1e-4:#10**(2*oom):
            self.orderOfMagnitude = oom
        elif oom <=0 and oom >= -5:
            pass
        elif math.fabs(oom) >= 4:
            self.orderOfMagnitude = oom
                
    def _set_format(self):
        locs = (array(self.locs,'d')-self.offset) / \
                10**self.orderOfMagnitude+1e-15
        sigfigs = [len(str('%1.4f'% loc).split('.')[1].rstrip('0')) \
                   for loc in locs]
        sigfigs.sort()
        self.format = '%1.' + str(sigfigs[-1]) + 'f'
                
    def pprint_val(self, x, d):
        xp = (x-self.offset)/10**self.orderOfMagnitude
        if x==self.locs[-1] and (self.orderOfMagnitude or self.offset):
            offsetStr = ''
            sciNotStr = ''
            xp = self.format % xp
            if self.offset: 
                p = '%1.e+'% self.offset
                offsetStr = self._formatSciNotation(p)
            if self.orderOfMagnitude: 
                p = 'x%1.e'% 10**self.orderOfMagnitude
                sciNotStr = self._formatSciNotation(p)
            return ''.join((offsetStr,xp,sciNotStr))
        elif xp==0: return '%d'% xp
        else: return self.format % xp
            
    def _formatSciNotation(self,s):
        tup = s.split('e')
        mantissa = tup[0]
        sign = tup[1][0].replace('+', '')
        exponent = tup[1][1:].lstrip('0')
        return '%se%s%s' %(mantissa, sign, exponent)
        

figure(1,figsize=(6,6))
ax1 = axes([.2,.74,.75,.2])
ax1.plot(arange(11)*5e2)
ax1.yaxis.set_major_formatter(ScalarFormatterScientific())
ax1.xaxis.set_visible(False)
ax1.set_title('BIG NUMBERS',fontsize=14)

ax2 = axes([.2,.51,.75,.2])
ax2.plot(arange(11)*1e4)
ax2.yaxis.set_major_formatter(ScalarFormatterScientific())
ax2.text(1,6e4,'6e4')
ax2.xaxis.set_visible(False)

ax3 = axes([.2,.28,.75,.2])
ax3.plot(arange(11)*1e4+1e10)
ax3.yaxis.set_major_formatter(ScalarFormatterScientific())
ax3.text(1,6e4+1e10,'1e10+6e4')
ax3.xaxis.set_visible(False)

ax4 = axes([.2,.05,.75,.2])
ax4.plot(arange(11)*1e4+1e10)
ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False))
ax4.text(1,1e10+6e4,'same as above, no offset')


figure(2,figsize=(6,6))
ax1 = axes([.225,.74,.75,.2])
ax1.plot(arange(11)*5e-5)
ax1.yaxis.set_major_formatter(ScalarFormatterScientific())
ax1.xaxis.set_visible(False)
ax1.set_title('small numbers',fontsize=8)

ax2 = axes([.225,.51,.75,.2])
ax2.plot(arange(11)*1e-5)
ax2.yaxis.set_major_formatter(ScalarFormatterScientific())
ax2.text(1,6e-5,'6e-5')
ax2.xaxis.set_visible(False)

ax3 = axes([.225,.28,.75,.2])
ax3.plot(arange(11)*1e-10+1e-5)
ax3.yaxis.set_major_formatter(ScalarFormatterScientific())
ax3.text(1,1e-5+6e-10,'6e-10+1e-5')
ax3.xaxis.set_visible(False)

ax4 = axes([.225,.05,.75,.2])
ax4.plot(arange(11)*1e-10+1e-5)
ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False))
ax4.text(1,1e-5+6e-10,'same as above, no offset')
show()

[Matplotlib-users] autoscale

[Humufr <hu...@ya...>]

       Hi,

I see a problem when I'm using autoscale. I have a spectra with huge 
difference in y. I used xlim to look only a part of my spectra and the 
ylim is not autoscale to this peculiar part of the spectra but on all 
the spectra.

I'm using the last CVS version.

Thanks,

N.

[Matplotlib-users] strange thing inside eps file

[Humufr <hu...@ya...>]

Hi,

I found something strange inside the eps file create with matplotlib. I
used matplotlib to trace a port of a spectra (I used the
function plot and axis). I have been very surprise to see that all the
spectra was inside the eps file. To see it, I must admit that I did
something weird. I create an eps file with matplotlib and I transform
the file in svg format with pstoedit and I edit this file with inkscape.

I don't know where is the problem but I don't think that it's necessary
to have all the point inside the output file, perhaps it's not possible
to do anything to change it but that can create some huge file. So if
nothing can be done, that will be a good idea to put it in the FAQ to
let the users cut their data if needed.

N.

Re: [Matplotlib-users] Newbie question.

[Perry G. <pe...@st...>]

On Feb 25, 2005, at 12:40 PM, John Hunter wrote:

>>>>>> "Andrea" == Andrea Riciputi <ari...@pi...> writes:
>
>     Andrea> Hi all, I'm an absolutely matplotlib newbie, so I'm sorry
>     Andrea> if my question is trivial. Anyway I've read the user guide
>     Andrea> and looked at the examples without finding out a solution.
>
>     Andrea> Here it is my problem. Suppose I have a 2-dimensional
>     Andrea> array containg my data, and I want to produce a surface or
>     Andrea> a contour plot with it. Now the imshow() function seems
>     Andrea> the right way to go through. So far so good. Now suppose I
>     Andrea> want to draw the x,y axes for this plot, and suppose my
>     Andrea> axes are represented by **not-uniform** 1-dimensional
>     Andrea> array x[i], y[j]. How can I get the right ticks on the
>     Andrea> plot axes??
>
> You need to interpolate your data onto a rectilinear grid and then use
> pcolor.  imshow requires that your data be an image -- eg the dx and
> dy between rows and columns is the same between every row and column.
> pcolor only assumes a rectilinear grid, so the dx and dy can vary from
> row to row and column to column.  But you have unstructured data.
>
I'm not sure if that is what is being said. What may be referred to is 
a structured 2-d image for which it is intended that the data 
coordinates be taken from the x and y arrays (for corresponding 
locations). The contour task does allow one to give such x and y 
arrays, but not the image display tasks (if I remember correctly). Some 
clarification is needed.

Perry

Re: [Matplotlib-users] filled contours: progress, a minor bug (?), and a point of curiosity

[Eric F. <ef...@ha...>]

John,

>     Eric> Having solved that problem, I am getting more optimistic
>     Eric> about being able to come up with a usable filled contour
>     Eric> capability fairly quickly.  Still no promises, though.
> 
> Great -- be mindful of the contourf matlab docstrings.  Strict
> adherence is not required, but it is nice to be compatible where
> possible.

I have the basic filled contour functionality working, with the 
following caveats, comments, and questions:

0) I've done only the simplest of testing so far.

1) There is a fundamental difference in strategy between Matlab's 
contour patch generation algorithm and gcntr.c: Matlab makes all patches 
as simply connected regions without branch cuts, but gcntr polygons have 
branch cuts.  This means that we can't use the polygon edges; if one 
wants line contours at the contour levels, they must be drawn 
separately, by asking gcntr for lines, as contour does.  My inclination 
is to leave it this way: the user can simply call contourf to get the 
filled regions, and then call contour to add lines as needed.  Typically 
I draw lines at only a few of the color boundaries, and sometimes I draw 
additional lines within colored regions, so this is the way I normally 
use matlab contourf and contour anyway.

2) In the present version, there is much too much duplication of code 
between contour and contourf in axes.py; I copied the contour function 
to contourf, modified what I needed to, and moved only the 
ContourMappable class out to the module level.  I would like to factor 
out more of the common code.

3) The docstrings in axes.py are driving me nuts--lacking proper 
indentation, they make it very difficult to find the function 
definitions.  I presume this is because of the way boilerplate.py is 
generating the pylab.py functions and their docstrings.  I haven't 
looked at boilerplate.py (I haven't used it yet at all), but I suspect 
it would be easy to change things so that it would handle properly 
indented docstrings.  Is it OK if I do this?

4) ToDo: it is not standard in matlab, but for filled contouring I 
always use a matching colorbar--essentially a colorbar contoured with 
the same levels and colors as the contour plot itself, rather than one 
that shows the whole colormap.

5) ToDo: I haven't tried to do anything with region masking yet; maybe I 
will get to it soon, since it is something I need.

5) gcntr.c uses global variables, which presumably means that it will 
fail if called from more than one thread at a time.  Longer term, should 
I/we/someone modify it so that this not the case?  Or is this 
characteristic of other routines used by matplotlib, so there is no 
point in worrying about gcntr.c in particular?

6) When the time comes to send you my modifications, how should I do it: 
diffs, or complete files? Send to you directly, or to the list?  If you 
would prefer diffs, please give me an example of the exact diff command 
options to use.  (I am working with matplotlib-0.72.1 as a starting 
point.)  Modified files will include axes.py, pylab.py (and/or 
boilerplate.py), _contour.c, and an example.

Eric

Re: [Matplotlib-users] Newbie question.

[John H. <jdh...@ac...>]

>>>>> "Andrea" == Andrea Riciputi <ari...@pi...> writes:

    Andrea> Hi all, I'm an absolutely matplotlib newbie, so I'm sorry
    Andrea> if my question is trivial. Anyway I've read the user guide
    Andrea> and looked at the examples without finding out a solution.

    Andrea> Here it is my problem. Suppose I have a 2-dimensional
    Andrea> array containg my data, and I want to produce a surface or
    Andrea> a contour plot with it. Now the imshow() function seems
    Andrea> the right way to go through. So far so good. Now suppose I
    Andrea> want to draw the x,y axes for this plot, and suppose my
    Andrea> axes are represented by **not-uniform** 1-dimensional
    Andrea> array x[i], y[j]. How can I get the right ticks on the
    Andrea> plot axes??

You need to interpolate your data onto a rectilinear grid and then use
pcolor.  imshow requires that your data be an image -- eg the dx and
dy between rows and columns is the same between every row and column.
pcolor only assumes a rectilinear grid, so the dx and dy can vary from
row to row and column to column.  But you have unstructured data.

In matlab, the interpolation is handled by the griddata function.
Peter Groszkowski promised to post some code he uses to for this
purpose back in December, but apparently he got lost in the stars.
matlab uses a delaunay triangulation according to the documentation
for griddata -- I think Peter uses a different approach.  I looked at
the scipy interpolate module but didn't see anything that looked just
right -- perhaps I missed it.  It surprises that scipy doesn't
have a delaunay triangulation routine, but apparently it does not.

A quick google for revealed
http://www.python.org/pypi?:action=display&name=Delny&version=0.1.0a2
which relies on the gnu qhull library...

A griddata function for mpl would be a nice complement to the meshgrid
function.

JDH

Re: [Matplotlib-users] cant find numerix in cvs

[Darren D. <dd...@co...>]

On Friday 25 February 2005 11:33 am, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> Hi, I am trying to install from cvs, but am getting error
>     Darren> messages that the numerix module is missing. It is not
>     Darren> listed on the "browse cvs repository" page at sourceforge
>     Darren> either.
>
> Try getting a new CVS checkout in a clean directory and rm -rf
> site-packages/matplotlib before rebuilding.  The numerix module does
> exist in CVS:
>
>  
> http://cvs.sourceforge.net/viewcvs.py/matplotlib/matplotlib/lib/matplotlib/
>numerix/
>
> The numerix code was reorganized in 0.71 so if you are using an older
> version that can cause problems.  The first line of defense when
> confronting a matplotlib bug is
>
>   > sudo rm -rf build /usr/local/lib/python2.3/site-packages/matplotib
>   > sudo python setup.py install
>
> distutils keeps old code around in the build directory.  If for
> example you have somemod.so from an older mpl version, and then we
> refactor to use somemod.py which conditionally imports _na_somemod.so
> or _nc_somemod.so depending on your numerix setting, the old
> somemod.so will be installed from your build dir into site-packages
> alongside somemod.py but the old *.so will be imported rather than the
> new *.py.  This has caused us lots of problems - I don't think a
> 'python setup.py clean' will solve every problem, but flushing the
> build directory and site-packages/matplotlib before a new install has
> cured lots of bugs.
>
> Or else sourceforge CVS is whacked, which would not bee too
> surprising.
>


My mistake. I thought I had cleared the build and site-packages/mpl directory, 
but I guess I overlooked something. I did a new cvs co and numerix is back. 
Thanks.

-- 

Darren

Re: [Matplotlib-users] cant find numerix in cvs

[John H. <jdh...@ac...>]

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> Hi, I am trying to install from cvs, but am getting error
    Darren> messages that the numerix module is missing. It is not
    Darren> listed on the "browse cvs repository" page at sourceforge
    Darren> either.

Try getting a new CVS checkout in a clean directory and rm -rf
site-packages/matplotlib before rebuilding.  The numerix module does
exist in CVS:

  http://cvs.sourceforge.net/viewcvs.py/matplotlib/matplotlib/lib/matplotlib/numerix/

The numerix code was reorganized in 0.71 so if you are using an older
version that can cause problems.  The first line of defense when
confronting a matplotlib bug is 

  > sudo rm -rf build /usr/local/lib/python2.3/site-packages/matplotib
  > sudo python setup.py install

distutils keeps old code around in the build directory.  If for
example you have somemod.so from an older mpl version, and then we
refactor to use somemod.py which conditionally imports _na_somemod.so
or _nc_somemod.so depending on your numerix setting, the old
somemod.so will be installed from your build dir into site-packages
alongside somemod.py but the old *.so will be imported rather than the
new *.py.  This has caused us lots of problems - I don't think a
'python setup.py clean' will solve every problem, but flushing the
build directory and site-packages/matplotlib before a new install has
cured lots of bugs.

Or else sourceforge CVS is whacked, which would not bee too
surprising.

JDH

[Matplotlib-users] cant find numerix in cvs

[Darren D. <dd...@co...>]

Hi,

I am trying to install from cvs, but am getting error messages that the 
numerix module is missing. It is not listed on the "browse cvs repository" 
page at sourceforge either.

-- 

Darren

Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

[Matt N. <new...@ca...>]

> > I agree it's a bug.  It's not immediately clear to me what the labels
> > should be though
> >
> >  1.0000000002
> >  1.0000000004
> >  1.0000000006
> >
> > and so on?  That takes up a lot of room.  Granted, correct but ugly
> > is better than incorrect but pretty, but I'm curious if there is a
> > better way to format these cases.  Perhaps ideal would be an indicator
> > at the bottom or top of the y axis that read '1+' and then use 2e-9,
> > 4e-9, etc as the actual tick labels.  Do you agree this is ideal?

More likely, the plot should be of 1-x, not x, with 1 subtracted
from the data before being sent to the plot.  Would you use
seconds-since-1970 to make a plot versus Time with a range of 1
sec and data every millisecond?  The data plotted should be the
"significant digits" after all.

FWIW, a custom tick formatter I've been using is below.  It's a
slight variation on the default, and won't solve the space
needed to display "1 + n*1.e-9", but it will do a reasonable job
of picking the number of significant digits to show based on the
data range for the Axis.  It could be expanded....

--Matt

! def myformatter(self, x=1.0, axis=None):
!     """ custom tick formatter to use with FuncFormatter():
!     x     value to be formatted
!     axis  Axis instance to use for formatting
!     """
!     fmt = '%1.5g'
!     if axis == None: 
!         return fmt % x
!     
!     # attempt to get axis span (range of values to format)
!     delta = 0.2
!     try:
!         ticks = axis.get_major_locator()()
!         delta = abs(ticks[1] - ticks[0])
!     except:
!         try:
!             delta = 0.1 * axis.get_view_interval().span()
!         except:
!             pass
! 
!     if   delta > 99999:     fmt = '%1.6e'
!     elif delta > 0.99:      fmt = '%1.0f'
!     elif delta > 0.099:     fmt = '%1.1f'
!     elif delta > 0.0099:    fmt = '%1.2f'
!     elif delta > 0.00099:   fmt = '%1.3f'
!     elif delta > 0.000099:  fmt = '%1.4f'
!     elif delta > 0.0000099: fmt = '%1.5f'
!     
!     s =  fmt % x
!     s.strip()
!     s = s.replace('+', '')
!     while s.find('e0')>0: s = s.replace('e0','e')
!     while s.find('-0')>0: s = s.replace('-0','-')
!
!     return s

[Matplotlib-users] plotting line from a certain position

[<oli...@ma...>]

Hi folks,

this might be a trivial question, but I could not figure it out from the
documentation or the examples.

I have a plot where the x-scale ranges from 0 to 20.
When I plot a line it automatically starts at x=0. I would like the line to
start at x=1. Is there a way to how I can do that?

Any help appreciated

regards
Oliver

Re: [Matplotlib-users] Keyword Parameters

[Steve C. <ste...@ya...>]

> You do have the option of using a GUI native drawing backend, eg GTK
> instead of GTKAgg or WX instead of WXAgg.  Because we use double
> buffering in GTK, it may not help (Steve -- would it be possible to
> make double buffering optional?)  The native GTK drawing is inferior
> to Agg, in my view, but you may be willing to trade quality for
> speed.  
I've added a 'DBL_BUFFER' variable to backend_gtk.py to switch on/off
double buffering for the GTK backend.
Switching off double buffering makes widget redraws flicker (as you'd
expect). I can't see how disabling double buffering has any value, or
how it could be useful when running python remotely, perhaps I'm wrong -
feel free to test it and let me know if it does have a use.

Steve

Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

[Darren D. <dd...@co...>]

Having some email problems, my original reply wasnt sent. Hopefully this one 
will be...

On Thursday 24 February 2005 11:02 pm, John Hunter wrote:
> >>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:
>
>     Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show()
>
>     Hans> All works fine when I subtract the mean of x but there seems
>     Hans> to be a problem with labelling axes for plotted data which
>     Hans> is not close to zero but shows only small variations.
>
> I agree it's a bug.  It's not immediately clear to me what the labels
> should be though
>
>   1.0000000002
>   1.0000000004
>   1.0000000006
>
> and so on?  That takes up a lot of room.  Granted, correct but ugly
> is better than incorrect but pretty, but I'm curious if there is a
> better way to format these cases.  Perhaps ideal would be an indicator
> at the bottom or top of the y axis that read '1+' and then use 2e-9,
> 4e-9, etc as the actual tick labels.  Do you agree this is ideal?

Matlab will not do an offset of this type, it goes to 4 decimal places and 
gives up. I have been meaning to do some work with the scalarFormatter for a 
while now. I think we can accomplish the above using the numerix mean,std,and 
maybe allclose functions. I will work on it this weekend, but will need some 
guidance to add a new bbox to add the result to the plot. At the same time, 
I'll work on an option to move the scientific notation to the same place, so 
1e10,2e10 will be come 1,2, with a x10^10 at the top of the axis.

It was also suggested to keep the significant decimal points in the labels. I 
agree with that 0,0.5,1.0,1.5 looks better than 0,0.5,1,1.5. If there are any 
suggestions or comments, please let me know.


-- 

Darren

Re: [Matplotlib-users] QTAgg backend

[Darren D. <dd...@co...>]

On Wednesday 23 February 2005 12:06 pm, Darren Dale wrote:
> On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> >     Darren> backend_qt.py is present in my cvs directory, but it looks
> >     Darren> like it didnt make it into the MPL-0.72 tarball.
> >
> > This was a problem with the MANIFEST file in the 0.72 release.  I
> > should be fixed in the 0.72.1 bugfix release, which is up on the sf
> > site.
>
> Great! One bug to report. Line 262 of backend_qt.py should read:
>
> error_msg = error_msg_qt
>
> or I get an error:
>
> File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py",
> line 262, in ?
>     error_msg = error_msg
> NameError: name 'error_msg' is not defined

I see my comments above do not apply to the version in cvs, due to changes in
error handling. In cvs, line 279 should be

if len( msg ) : error_msg_qt( msg )


Darren

-------------------------------------------------------

-- 

Darren

Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

[Hans F. <H.F...@so...>]

Hi John,

>    Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show()
>
>    Hans> All works fine when I subtract the mean of x but there seems
>    Hans> to be a problem with labelling axes for plotted data which
>    Hans> is not close to zero but shows only small variations.
>
> I agree it's a bug.  It's not immediately clear to me what the labels
> should be though
>
>  1.0000000002
>  1.0000000004
>  1.0000000006
>
> and so on?  That takes up a lot of room.  Granted, correct but ugly
> is better than incorrect but pretty, but I'm curious if there is a
> better way to format these cases.  Perhaps ideal would be an indicator
> at the bottom or top of the y axis that read '1+' and then use 2e-9,
> 4e-9, etc as the actual tick labels.  Do you agree this is ideal?

That would be very cool ;-) [but not soo easy to code I suppose]. I just 
checked what Matlab does (seeing that they have been in the business for a 
while), and if I run the equivalent program (i.e. plotting date from 
1+0e-9, 1+1e-9, 1+2e-9,...,1e-8), the plot just shows "1" at each tick.

So: yes, I agree with your suggested ideal solution but as long as Matlab 
doesn't do this and there is a workaround (as you show below), this is 
probably not a high-priority bug ;-)

> To achieve this, as you may know, you can pass in a custom tick
> formatter.  Eg
>
>  import pylab
>
>  def myformatter(x, pos):
>      return '%1.0e'%(x-1)
>
>  ax = pylab.subplot(111)
>  x=pylab.arange(0,1e-8,1e-9)+1.0
>  ax.plot(x)
>  formatter = pylab.FuncFormatter(myformatter)
>  ax.yaxis.set_major_formatter(formatter)
>  ax.text(-.125, 1.025, '1+', transform=ax.transAxes)
>  pylab.show()
>
> See also examples/custom_ticker1.py.
>
> This is not to say that I don't want to fix this bug; I just wanted to
> make sure you are aware of this workaround.
That's very useful information -- I wasn't aware of this possibility and 
am sure it will be useful to others searching the mailing list for 
answers.

Best wishes,

Hans

Re: [Matplotlib-users] Change color in matshow ?

[John H. <jdh...@ac...>]

>>>>> "Yann" == Yann Le Du <yan...@no...> writes:

    Yann> Hello, Is there a simple argument to pass to matshow so that
    Yann> it'll print 0 as white and 1 as black, and not the opposite
    Yann> as it defaults to ?

You can do this by passing a custom colormap to the matshow function.
See the following threads on the mailing list archive for more
information on creating custom colormaps

  http://sourceforge.net/mailarchive/message.php?msg_id=10482430

  http://sourceforge.net/mailarchive/message.php?msg_id=10020116

See also the user's guide section 6.4.4 "Defining your own colormap"

You might also want to spend a little time looking at the src code of
the matplotlib modules cm and colors for inspiration on how to define
your own.  

Hopefully we can improve the documentation and example code in this
area in the not too distant future...

Hope this helps,
JDH

Re: [Matplotlib-users] bug for marker 'x' (at least)

[John H. <jdh...@ac...>]

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:

    Humufr> the marker 'x' (ex: plot(a,b,'bx',markersize=5) are not
    Humufr> working anymore (at least version 0.72.1 and cvs) with Agg
    Humufr> backend (and TkAgg and GTKAgg). With PS backend it's ok.

OK, thanks for letting me know.  This will be fixed in the next bugfix
release of mpl.

JDH

Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

[John H. <jdh...@ac...>]

>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:

  
    Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show()

    Hans> All works fine when I subtract the mean of x but there seems
    Hans> to be a problem with labelling axes for plotted data which
    Hans> is not close to zero but shows only small variations.

I agree it's a bug.  It's not immediately clear to me what the labels
should be though

  1.0000000002
  1.0000000004
  1.0000000006

and so on?  That takes up a lot of room.  Granted, correct but ugly
is better than incorrect but pretty, but I'm curious if there is a
better way to format these cases.  Perhaps ideal would be an indicator
at the bottom or top of the y axis that read '1+' and then use 2e-9,
4e-9, etc as the actual tick labels.  Do you agree this is ideal?

To achieve this, as you may know, you can pass in a custom tick
formatter.  Eg

  import pylab

  def myformatter(x, pos):
      return '%1.0e'%(x-1)

  ax = pylab.subplot(111)
  x=pylab.arange(0,1e-8,1e-9)+1.0
  ax.plot(x)
  formatter = pylab.FuncFormatter(myformatter)
  ax.yaxis.set_major_formatter(formatter)
  ax.text(-.125, 1.025, '1+', transform=ax.transAxes)
  pylab.show()

See also examples/custom_ticker1.py.

This is not to say that I don't want to fix this bug; I just wanted to
make sure you are aware of this workaround.  

JDH