matplotlib-users Mailing List for matplotlib

 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.

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.

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

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

>>>>> "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

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

>>>>> "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

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

> > 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

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

> 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

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

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

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

>>>>> "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

>>>>> "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

>>>>> "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