matplotlib-users Mailing List for matplotlib

I had to compile and install Python 2.7 on RHEL with the
--enable-unicode=USC4 to get it to work with Tkinter. Unfortunately, I'm
now trying to install numpy, and get an error when importing it into python
"ImportError: numpy/core/multiarray.so: undefined symbol:
PyUnicodeUCS2_AsASCIIString".
Is there are way to get the two to play together nicely? Such as
recompiling numpy with USC4 support?
KURT

Hi,
I used to make animated figures generated with scripts similar to the 
one attached. It works fine with GTKAgg backend, but does not work with 
QT4Agg one: the figure just flashes at the end of the animation!
Is it a bug in Qt4Agg, or an unimplemented feature? Is there any way 
other than switching back to GTKAgg specifically?
Cheers,
Yannick
PS: I now about the recent Animation module, but I don't want to update 
all my scripts to this new framework.

On Fri, Dec 14, 2012 at 8:55 AM, p.bingham <p.b...@ke...> wrote:
> I've created a class that allows a user to add several charts to a
> MATPLOTLIB
> window. These can be either a line chart or a bar chart. It also has the
> feature that when a chart has already been added to the window (as
> identified from rowID) rather than draw a new plot it will replace the data
> in the old plot. ie it allows for updates (animation)
>
> This works grand for the line plot but I get corruption when plotting
> several bar charts. The class looks like:
>
> import math
>
> class TFrmPlot():
>
> def __init__(self, point_lists, deleteCallback, plotType, rowID):
> import matplotlib
> matplotlib.interactive( True )
> matplotlib.use( 'WXAgg' )
>
> import matplotlib.pyplot as plt
> self.plt = plt
> self.fig = plt.figure()
> self.fig.canvas.mpl_connect('close_event', self.on_close)
>
> import matplotlib.axes as ax
> self.ax = ax
>
> self.deleteCallback = deleteCallback
> self.chartArray = []
> self.addChart(point_lists, plotType, rowID)
>
> def close(self):
> self.plt.close('all')
> #self.fig.close()
>
> def replaceChartDataIfChartExists(self, point_lists, rowID):
> if rowID==0:
> pass
> for chart in self.chartArray:
> for plot in chart.plots:
> if plot.rowID == rowID:
> plot.points = point_lists
> if plot.plotType=="Point":
>
> plot.plotItem.set_data(point_lists[0],point_lists[1])
> chart.subPlot.draw_artist(plot.plotItem)
> self.fig.canvas.blit(chart.subPlot.bbox)
> else:
> for rect, h in zip(plot.plotItem,
> point_lists[1]):
> rect.set_height(h)
> chart.subPlot.relim()
> chart.subPlot.autoscale_view(True,True,True)
> self.plt.draw()
> return True
> return False
>
> def addChart(self, point_lists, plotType, rowID):
> self.chartArray.append(TChart(rowID,plotType,point_lists))
> self._drawAll()
>
> def addPlot(self, point_lists, plotType, rowID):
> chartNum = len(self.chartArray)
>
> self.chartArray[chartNum-1].plots.append(TPlot(rowID,plotType,point_lists))
> self._drawAll()
>
> def on_close(self, event):
> self.deleteCallback()
>
> def _drawAll(self):
> self.plt.clf()
> numSubPlots = len(self.chartArray)
> numCols = self._noCols(numSubPlots)
> IndexConverter = TIndexConverter(numCols)
> subPlot = None
> for chartIndex in range(0,numSubPlots):
> if numSubPlots==1:
> subPlot = self.fig.add_subplot(1,1,1)
> elif numSubPlots==2:
> subPlot = self.fig.add_subplot(1,2,chartIndex+1)
> else:
> subPlot =
> self.fig.add_subplot(2,numCols,IndexConverter._getSubPlotIndex(chartIndex))
> subPlot.relim()
> subPlot.autoscale_view(True,True,True)
> self.chartArray[chartIndex].subPlot = subPlot
> self._drawSubs(self.chartArray[chartIndex])
> self.plt.show()
>
> def _drawSubs(self, chart):
> for plot in chart.plots:
> if plot.plotType=="Point":
> chart.subPlot.plot(plot.points[0],plot.points[1])
> plot.plotItem =
> chart.subPlot.lines[len(chart.subPlot.lines)-1]
> else:
> kwargs = {"alpha":0.5}
> plot.plotItem =
> chart.subPlot.bar(plot.points[0],plot.points[1],
> width=self._calculateleastDiff(plot.points[0]), **kwargs)
>
> def _noCols(self, numSubPlots):
> return math.ceil(float(numSubPlots)/2.0)
>
> def _calculateleastDiff(self, xValues):
> xValues2 = sorted(xValues)
> leastDiff = None
> lastValue = None
> for value in xValues2:
> if lastValue is not None:
> diff = value-lastValue
> if leastDiff is None or diff < leastDiff:
> leastDiff = diff
> lastValue = value
> return leastDiff
>
> This is a bit long so to summarise:
>
> addChart -- basically adds a new subplot
>
> addPlot -- adds a new line or bar to an existing subplot
>
> replaceChartDataIfChartExists -- refreshes the data if the ID already
> exists
>
> The dummy data that I'm using just plots a positive gradient and a negative
> gradient line in succession. My plots however can get into a state where
> one/some or all of the bar plots become corrupted. It looks almost like the
> x/y axis has been rotated, with the individual bars not starting from the
> x-axis. The issue is intermittent; sometimes I will get several plots as
> expected. Once a plot becomes corrupted all future updates remain
> corrupted.
>
> Corrupted Chart:
> <http://matplotlib.1069221.n5.nabble.com/file/n40023/corrupted.png>
>
>
Your code is needlessly complex, and it is more likely that the bug lies in
there rather than with matplotlib. First, you really shouldn't ever do
imports within a class, and it makes no sense to assign those imports as
members of the class. Second, you shouldn't need to do complex subplot
management to do what you need, matplotlib has done it for you already.
For example, the fig.add_subplot() command will simply return the axes to
you if it has already been created. Alternatively, you might be interested
in using the mpl_toolkit.axes_grid1 module:
http://matplotlib.org/mpl_toolkits/axes_grid/users/overview.html
but it might be overkill in your case.
If you can simplify your code significantly, and still encounter the
corruption issue, please come back and post the code so we can help you out.
Cheers!
Ben Root

On Sun, Dec 16, 2012 at 4:41 PM, David Huard <dav...@gm...> wrote:
> Hi all,
>
> I'm wondering if anyone knows how to compute colorbar limits (vmin, vmax)
> based only on the visible portion of the figure. My use-case is a
> pcolormesh(x, y, z) drawn over a Basemap instance. The coordinates x and y
> cover the entire globe, but I'm only mapping the Arctic. What happens is
> that the normalization is done over the entire z array, while only a subset
> of z actually appears on the map. The colors appearing on the map thus
> cover only a small fraction of the entire color range.
>
> From what I managed to understand, pcolormesh creates a collections of
> patches colorcoded based on the array attribute. So my question is if there
> is a builtin way to know which items of this collections are clipped so I
> can mask this part of the array ?
>
> Thanks a lot,
>
> David
>
>
As far as I know, no, there is not a built-in way of doing so. There is
the clipping mechanism to prevent drawing things outside of bounding boxes
(used for easy zooming and panning among other things), but as far as I
know, that is done mostly in the backends, and it doesn't provide
information on which elements in the array was chosen drawn. I would
suggest making a feature request on the github page, and hopefully, someone
will have an epiphany on how to implement such a feature (maybe with the
scalar mappable objects?).
Cheers!
Ben Root

On Tue, Dec 18, 2012 at 2:05 PM, Darren Dale <dsd...@gm...> wrote:
> On Mon, Dec 10, 2012 at 3:45 AM, Phil Elson <pel...@gm...> wrote:
> > Thanks for bringing this up, it is certainly valuable to highlight this
> on
> > the mailinglist. As you say, the change is hard to spot and, I agree,
> makes
> > library code supporting v1.1.1 and v1.2 harder than one would like.
> > Typically, anything which is going to break core APIs (even slightly)
> should
> > be documented under the "API Changes" page here
> > http://matplotlib.org/api/api_changes.html#changes-in-1-2-x
>
> I suggest that an API change should have triggered a major version
> bump to mpl-2.0.0. It seems a well-established expectation for a
> major.minor.bugfix versioning scheme that bugfix releases will not
> introduce new features, and minor releases will not introduce API
> changes.
>
> Darren
>
>
Agreed. I think what happened here was short-sightedness (somewhat on my
part since I was involved in that PR). I didn't realize this sort of
situation when I reviewed it. This originally looked more like an
enhancement that a more fundamental change. My apologies.
Ben Root