matplotlib-devel Mailing List for matplotlib

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

On 11/2/07, Eric Firing <ef...@ha...> 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 "<ipython console>", 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?

On 11/2/07, Eric Firing <ef...@ha...> 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

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

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 <module>
> 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 <module>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

The errorbar_limits.py demo is failing on my machine:
Traceback (most recent call last):
 File "errorbar_limits.py", line 13, in <module>
 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 <module>
 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

On 11/2/07, Manuel Metz <mm...@as...> 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

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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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