matplotlib-users Mailing List for matplotlib

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:
 Robert> When attempting to generate a larger number of graph sets
 Robert> (i.e. 3 graphs of similar style over different data
 Robert> ranges), I'm intermittently getting a GPF on XP in
 Robert> na_backend_agg.pyd according to the report that M$ offers
 Robert> to send to itself.
Ouch.
 Robert> It is repeatable in one sense, in that if I restart the
 Robert> graph generation from the beginning it will fail at the
 Robert> same set, but if skip the first set of graphs it doesn't
 Robert> produce one additional set and then die, it dies at 15 (5
 Robert> sets) earlier. I can restart from any of the sets where it
 Robert> failed and it will continue on for some random number
 Robert> before GPF'ing again - anything from 9 thru to 150 graphs
 Robert> or so.
Repeatable is good. Standalone much better. So you are running the
pure Agg backend (no GUI?). It would help to post the output of 
 c:> python myscript.py --verbose-helpful
 Robert> If I use Numeric (23.7, the latest) it is a lot worse -
 Robert> meaning fewer sets before failure. Also matplotlib 0.72
 Robert> was a lot worse with either Numeric and numarray.
It probably won't happen with 0.71 and this would be worth testing. I
did a bunch of changes in backend agg in 0.72, including using the
numeric API rather than the sequence protocol. If you want to verify
that the problem was introduced in 0.72 (which will help me narrow
down the possible culprits) remove site-packages/matplotlib and then
install 0.71 and see if the crash disappears.
 Robert> I'm not sure of the best way to proceed from here - is
 Robert> this a known issue or related to one or should I attempt
 Robert> to produce a standalone test that causes the problem?
That would help immensely.
One thing I can do is send you a debug build of mpl for windows that
has a bunch of extra diagnostic information turned on. This might
help isolate which function is causing the problem. But if you can
get a standalone script, that would be most efficient.
Thanks,

When attempting to generate a larger number of graph sets (i.e. 3 graphs of 
similar style over different data ranges), I'm intermittently getting a GPF on 
XP in na_backend_agg.pyd according to the report that M$ offers to send to itself.
It is repeatable in one sense, in that if I restart the graph generation from 
the beginning it will fail at the same set, but if skip the first set of graphs 
it doesn't produce one additional set and then die, it dies at 15 (5 sets) 
earlier. I can restart from any of the sets where it failed and it will continue 
on for some random number before GPF'ing again - anything from 9 thru to 150 
graphs or so.
If I use Numeric (23.7, the latest) it is a lot worse - meaning fewer sets 
before failure. Also matplotlib 0.72 was a lot worse with either Numeric and 
numarray.
The environment is Python 2.4, XP (sp2), matplotlib 0.72.1, numarray 1.2.2, 
Numeric 23.7 with the data coming from Postgres 8.0 via SQLObject and psycopg.
I'm not sure of the best way to proceed from here - is this a known issue or 
related to one or should I attempt to produce a standalone test that causes the 
problem?
Robert

Hi,
I'm using matplotlib 0.71 and I think I found a bug in polyfit.
This simple linear regression on two data points gives the correct answer:
 >>> polyfit([731.924,731.988],[915,742],1)
array([ -2703.12505517, 1979397.10294428])
However, if I multiply my x values by 1000 the result is wrong:
 >>> polyfit([731924,731988],[915,742],1)
array([ 5.17650790e-009, 8.28496211e+002])
Could that be some kind of overflow problem ???
 Alex

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.
>
>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.
>
yup.. i did get a little "lost in the stars" - I forgot about it in 
fact. I promise I will post it in the next few days - this time I mean 
it. ;)
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 9742509 670 N. A'ohoku Place
Fax: +1 808 9359235 Hilo, Hawai'i 96720, USA 

Hi John,
On Monday 28 February 2005 12:11 pm, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> oops, I just noticed a bug, the first script I posted wont
> Darren> run. This updated script worked for me with a fresh 0.72.1
> Darren> installation. Sorry about the error.
>
> Hi Darren, this is very nice work. Sorry for the delay in getting
> back but I've been tied up for the last week or so.
Thanks. 
>
> One comment I have is that I think we might choose the default offset
> label differently. Visually
>
> 1e-5+12e-10
> 10
> 8
> 6
> 4
> 2
>
> is hard to read because the two 10s line up when you should be
> comparing the 12 with the 10. I wonder if this is better
>
> 1e-5+1e-10*12
> 10
> 8
> 6
> 4
> 2
>
> Still an eyeful but at least the significant part of the ticks are
> co-registered. What so you think?
I originally did it the way you suggest, and changed it to make it more 
compact....
[...]
>
> Another comment is that these labels take up a lot of space, and will
> pretty much break any default subplot which doesn't leave enough room
> for them. 
>
> Although I like the idea of using one of the tick labels 
> itself to handle the offset formatting, I wonder if we might be better
> off using a special axis.set_offset command, so that for example, the
> yaxis could place the offset above the ticks and thus take up less
> horizontal space. Just a thought.
Yeah, my intention this weekend was just to get the information into the plot, 
so it was clear what I was trying to accomplish. I would really like to get 
the scientific notation out of that last ticklabel, and put it above the axis 
as you suggest.
Can we do proper exponential formatting, like with the logscale? I know there 
are scholarly journals out there that will complain about using the 'e' 
notation.
>
> Also, I'm inclined to make this the default formatter --
I am glad to hear that. 
> do you see 
> any problems with this? What troubles did you run into when you tried
> to add these changes to the ScalarFormatter class and then rolled them
> back because of clashes with derived classes?
I originally hijacked ScalarFormatter, then noticed that the LogFormatter* 
classes inherited the pprint_val method from ScalarFormatter. That is really 
not a problem, we could just copy the old ScalarFormatter.pprint_val method 
to LogFormatter, then it will override the new ScalarFormatter method.
Questions/problems before making this the default formatter:
1) Will the gui windows still report the appropriate coordinates? I noticed in 
the script I posted that the y coordinate was only reported as an integer.
2) in the script, near the bottom, try changing
	figure(2,figsize=(6,6))
	ax1 = axes([.225,.74,.75,.2])
	ax1.plot(arange(11)*1e-4)
to read
	figure(2,figsize=(6,6))
	ax1 = axes([.225,.74,.75,.2])
	ax1.plot(arange(11)*1e-15) #<--- changed order of magnitude
The resulting plot does not render the last ticklabel. I checked my script, 
and the string is generated by pprint_val, but it is not rendered. I dont 
understand why. Several orders of magnitude wont render. For example, 1e-107 
doesnt render, nor does 1e-60, but 1e-61 does. I didnt see a problem with 
scientific notation containing positive exponents. Maybe this odd bug will 
not be reproducible once the information is rendered in its own space, I dont 
know.
3) (Almost not worth mentioning) I could run the same script 10 times and once 
it would yield an unsubscriptable object error message. When this happened, 
self.locs was set to None, and pprint_val was choking on this line:
if x==self.locs[-1] and (self.orderOfMagnitude or self.offset):
This problem will not exist when we stop rendering the offset/sci.not. in the 
ticklabel. I hesitate to even bring this nonexistent problem up, but if 
somebody notices this behavior, they should know it will not exist in the 
final product.
-- 
Darren

>>>>> "Massimo" == Massimo Sabbatini <sab...@de...> writes:
 Massimo> Dear group, is it possible to set the default sequence of
 Massimo> line styles, colors, widths, etc. to be used when
 Massimo> plotting multiple lines ? pylab.rc seems to set the
 Massimo> default parameters only for the first line.
 Massimo> I've googled about it, but it does not seem a very
 Massimo> popular question.
No, this is not currently possible. The default line style does not
cycle, and the default color cycle is hardcoded. It would be possible
to make these configurable, but since it is relatively easy to specify
which linestyles you want, I'm not sure it's necessary.
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> oops, I just noticed a bug, the first script I posted wont
 Darren> run. This updated script worked for me with a fresh 0.72.1
 Darren> installation. Sorry about the error.
Hi Darren, this is very nice work. Sorry for the delay in getting
back but I've been tied up for the last week or so.
One comment I have is that I think we might choose the default offset
label differently. Visually
 1e-5+12e-10
 10 
 8
 6
 4
 2
is hard to read because the two 10s line up when you should be
comparing the 12 with the 10. I wonder if this is better
 1e-5+1e-10*12
 10 
 8
 6
 4
 2
Still an eyeful but at least the significant part of the ticks are
co-registered. What so you think?
Likewise
10e-5
 8
 6
 4
 2
Becomes
1e-5*10
 8
 6
 4
 2 
It takes more room but I find it easier to read because one naturally
expects the significant digits to be in the same place.
Another comment is that these labels take up a lot of space, and will
pretty much break any default subplot which doesn't leave enough room
for them. Although I like the idea of using one of the tick labels
itself to handle the offset formatting, I wonder if we might be better
off using a special axis.set_offset command, so that for example, the
yaxis could place the offset above the ticks and thus take up less
horizontal space. Just a thought.
Also, I'm inclined to make this the default formatter -- do you see
any problems with this? What troubles did you run into when you tried
to add these changes to the ScalarFormatter class and then rolled them
back because of clashes with derived classes?
JDH

>>>>> "oliver" == oliver tomic <oli...@ma...> writes:
 oliver> Hi folks,
 oliver> this might be a trivial question, but I could not figure
 oliver> it out from the documentation or the examples.
 oliver> I have a plot where the x-scale ranges from 0 to 20. When
 oliver> I plot a line it automatically starts at x=0. I would like
 oliver> the line to start at x=1. Is there a way to how I can do
 oliver> that?
If I understand your question correctly, you want to set the xlim to
range from 1-20 even if your data range from 0-20
 >>> plot(x,y)
 >>> xlim(1,20)
http://matplotlib.sf.net/matplotlib.pylab.html#-xlim
http://matplotlib.sf.net/matplotlib.pylab.html#-axis
JDH

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

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

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

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

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

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.

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

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

 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