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