[matplotlib-devel] errorbar *lims kwarg
The errorbar_limits.py demo is failing on my machine: Traceback (most recent call last): File "errorbar_limits.py", line 13, in P.errorbar(x,y,yerr=0.1,capsize=3) File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, in errorbar ret = gca().errorbar(*args, **kwargs) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3735, in errorbar caplines.extend( self.plot(x, lower, 'k_', **plot_kw) ) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2634, in plot for line in self._get_lines(*args, **kwargs): File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 403, in _grab_next_args for seg in self._plot_3_args(remaining, **kwargs): File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 349, in _plot_3_args x, y, multicol = self._xy_from_xy(x, y) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 244, in _xy_from_xy assert nrx == nry, 'Dimensions of x and y are incompatible' AssertionError: Dimensions of x and y are incompatible It looks like the API has changed and does not allow scalar arguments for the errors. I tried setting yerr=ones(len(y))*0.1, and got a different error: Traceback (most recent call last): File "errorbar_limits.py", line 18, in P.errorbar(x,y,yerr=yerr, uplims=True) File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, in errorbar ret = gca().errorbar(*args, **kwargs) File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3738, in errorbar caplines.extend( self.plot(x[uplims], upper[uplims], ls='None', marker=mlines.CARETUP, **plot_kw) ) TypeError: only integer arrays with one element can be converted to an index Maybe the patch commited on September 3 needs to be revisited. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] contour linestyle patch
On 11/2/07, Manuel Metz <[EMAIL PROTECTED]> wrote: > Hi, > attached is a patch for contour.py against latest svn that adds support > for the keyword "linestyles" for contour plots. Could someone commit > that to svn? Thanks Manuel -- I applied this to svn. JDH - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] contour linestyle patch
Hi,
attached is a patch for contour.py against latest svn that adds support
for the keyword "linestyles" for contour plots. Could someone commit
that to svn?
Manuel
Index: contour.py
===
--- contour.py (revision 4093)
+++ contour.py (working copy)
@@ -390,7 +390,8 @@
self.levels = kwargs.get('levels', None)
self.filled = kwargs.get('filled', False)
self.linewidths = kwargs.get('linewidths', None)
-
+self.linestyles = kwargs.get('linestyles', 'solid')
+
self.alpha = kwargs.get('alpha', 1.0)
self.origin = kwargs.get('origin', None)
self.extent = kwargs.get('extent', None)
@@ -457,11 +458,13 @@
else:
tlinewidths = self._process_linewidths()
self.tlinewidths = tlinewidths
+tlinestyles = self._process_linestyles()
C = _cntr.Cntr(x, y, z.filled(), _mask)
-for level, width in zip(self.levels, tlinewidths):
+for level, width, lstyle in zip(self.levels, tlinewidths, tlinestyles):
nlist = C.trace(level, points = 0)
col = collections.LineCollection(nlist,
- linewidths = width)
+ linewidths = width,
+ linestyle = lstyle)
if level < 0.0 and self.monochrome:
ls = mpl.rcParams['contour.negative_linestyle']
@@ -696,6 +699,18 @@
linewidths = [linewidths] * Nlev
tlinewidths = [(w,) for w in linewidths]
return tlinewidths
+
+def _process_linestyles(self):
+linestyles = self.linestyles
+Nlev = len(self.levels)
+if linestyles is None:
+tlinestyles = ['solid'] * Nlev
+else:
+if cbook.is_string_like(linestyles):
+tlinestyles = [linestyles] * Nlev
+elif cbook.iterable(linestyles) and len(linestyles) < Nlev:
+tlinestyles = list(linestyles) * int(npy.ceil(Nlev/len(linestyles)))
+return tlinestyles
def get_alpha(self):
'''For compatibility with artists, return self.alpha'''
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] arbitrary rotation of images
Bug 1750527 reports that, with usetex, it is not possible to rotate text or ticklabels by 45 degrees. It looks like this limitation is caused by _backend_agg's draw_image method, which does not accept an angle argument, while draw_text_image does. I am out of my depth in _backend_agg.cpp, can draw_image be updated to accept an angle? Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errorbar *lims kwarg
Darren Dale wrote: > The errorbar_limits.py demo is failing on my machine: > > Traceback (most recent call last): > File "errorbar_limits.py", line 13, in > P.errorbar(x,y,yerr=0.1,capsize=3) > File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, > in errorbar > ret = gca().errorbar(*args, **kwargs) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3735, in > errorbar > caplines.extend( self.plot(x, lower, 'k_', **plot_kw) ) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2634, in > plot > for line in self._get_lines(*args, **kwargs): > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 403, in > _grab_next_args > for seg in self._plot_3_args(remaining, **kwargs): > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 349, in > _plot_3_args > x, y, multicol = self._xy_from_xy(x, y) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 244, in > _xy_from_xy > assert nrx == nry, 'Dimensions of x and y are incompatible' > AssertionError: Dimensions of x and y are incompatible > > > It looks like the API has changed and does not allow scalar arguments for the > errors. I tried setting yerr=ones(len(y))*0.1, and got a different error: > > Traceback (most recent call last): > File "errorbar_limits.py", line 18, in > P.errorbar(x,y,yerr=yerr, uplims=True) > File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, > in errorbar > ret = gca().errorbar(*args, **kwargs) > File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3738, in > errorbar > caplines.extend( self.plot(x[uplims], upper[uplims], ls='None', > marker=mlines.CARETUP, **plot_kw) ) > TypeError: only integer arrays with one element can be converted to an index > > > Maybe the patch commited on September 3 needs to be revisited. I'm not sure that the problem is just in that patch, or in that patch at all--the whole errorbar method needs to be reviewed. (The patch contributes to the extent that it makes the code much more complicated.) It looks to me like there are several fossils from John's early work with units support--places where list comprehensions are used instead of arrays "to preserve units". I don't think these are directly causing the problem, but if they are indeed fossils they should certainly be corrected. Eric > > Darren > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ghostscript version fix
Thanks. I updated the gs version checker in svn. On Thursday 01 November 2007 05:29:03 pm Gary Ruben wrote: > Yep. Works. > > C:\WINDOWS>gswin32c --version > 8.51 > > Darren Dale wrote: > > gs --version works with AFPL. Could someone please check that this works > > on windows: gswin32c --version > > > > - > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > ___ > > Matplotlib-devel mailing list > > Matplotlib-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errorbar *lims kwarg
On 11/2/07, Eric Firing <[EMAIL PROTECTED]> wrote: > It looks to me like there are several fossils from John's early work > with units support--places where list comprehensions are used instead of > arrays "to preserve units". I don't think these are directly causing > the problem, but if they are indeed fossils they should certainly be > corrected. I just fixed this in svn -- the unit support has certainly proven fragile in the errorbar code, because the inability to assume arrays is a major handicap, and barring oneself from all the numpyisms like logical masks and fancy indexing, not to mention the performance that comes with it, is frustrating. The unit support code grew out of an attempt to solve a somewhat important use case: the JPL has unit enabled data structures that are iterable but do not implement the basic array uses we need. Apparently, they use these objects with mpl and are unable to wrap them or modify them because they must also be passed on to other libraries in their system, which they also do not control, unmodified. The current mpl implementation, in which users can register their objects with converter classes, works fine and supports the very nice ability to pass in datetime objects directly to mpl (this is another clear use case where you want to work with some object you can't wrap or modify). I think it is a bit too onerous inside mpl to not be able to assume we can do array operations, so I will give this some more thought on how we can satisfy these use cases w/o writing tedious, fragile code. JDH - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] units
John, Now I am not so sure that the use of lists in errorbar is a fossil, but I certainly don't understand it. Would you give a summary of when one can and cannot use arrays in axes.py, please? The errorbar and bar methods seem to be the only victims of this restriction, and it looks like some of the instances are accomplishing nothing--the arguments get converted to arrays with the next method call anyway. I haven't tried to trace things carefully, obviously. Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units
On 11/2/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> Now I am not so sure that the use of lists in errorbar is a fossil, but
> I certainly don't understand it. Would you give a summary of when one
> can and cannot use arrays in axes.py, please? The errorbar and bar
> methods seem to be the only victims of this restriction, and it looks
> like some of the instances are accomplishing nothing--the arguments get
> converted to arrays with the next method call anyway. I haven't tried
> to trace things carefully, obviously.
I just wrote some related stuff in the other thread, but will jump in
here. I think I may be being overzealous in my avoidance of arrays. What
we cannot assume is that asarray is creating an array of floats, so we
cannot do scalar array operations, eg 2*x. But we should be able to
assume object arrays, with indexing, and element wise opertations
which are well defined, eg for the canonical date example.
In [3]: import datetime
In [4]: date0 = datetime.date(2004,1,1)
In [5]: days = datetime.timedelta(days=1)
In [6]: d = [date0, date0+days, date0+2*days, date0+3*days]
In [7]: import numpy as n
In [8]: x1 = n.array(d)
In [9]: xerr = n.array([days]*len(x1))
In [10]: x1.dtype
Out[10]: dtype('object')
In [11]: x2.dtype
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'x2' is not defined
In [12]: xerr.dtype
Out[12]: dtype('object')
In [13]: x1 + xerr
Out[13]: array([2004-01-02, 2004-01-03, 2004-01-04, 2004-01-05], dtype=object)
The reason we are bumping into so may problems with errorbar is not
only because it is complex, but because it is doing more arithmetic
than other plotting code.
Ted, can you clarify what kinds of operations are permitted with your
iterable unit objects if they are initialized into numpy object
arrays?
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Encapsulated postscript output without %%pages
On Thursday 27 September 2007 05:54:45 pm Stefan van der Walt wrote: > Hi all, > > When trying to print a matplotlib-generated .eps file with CUPS, it > aborts, complaining > > No %%Pages: comment in header! > > An easy workaround is to do > > eps2eps broken.eps fixed.eps > > but maybe the %%Pages directive should be included in the output? According to the EPS specification (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf), the only required comments in the header are: %!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: llx lly urx ury I have never seen an error from CUPS due to a missing PAGES comment, what version of cups are you using? Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
