matplotlib-devel Mailing List for matplotlib (Page 2)

Abe,
That bug has been fixed in CVS; like you, I tripped over it in 0.82 and 
tracked it down--but someone else had already fixed it. A workaround, 
if you don't want to install from CVS, is to use the old subplot(211) 
form instead of subplot(2,1,1).
Eric
Abraham Schneider wrote:
> Hi. I just installed the newest version of matplotlib (0.82), and 
> discovered all my subplots were ending on top of each other. After going 
> through my code and verifying everything looked okay, I tried a simple:
> 
> subplot(2, 1, 1); plot(range(0, 10)); subplot(2, 2, 2); plot(range(0, 10))
> 
> and still only got one subplot. I went to the matplotlib code, and after 
> some prodding, discovered that all the keys for the _seen map were 
> exactly the same. Going to the _make_key function revealed that my use 
> of subplot (i.e. three seperate arguments), was not working. Here is a 
> fix that seems to work for me:
> 
> (int _make_key function):
> if iterable(args[0]):
> key = tuple(args[0]), tuple( fixitems(kwargs.items()))
> ## NEW
> elif len(args) > 1:
> key = args, tuple( fixitems(kwargs.items()))
> ## \NEW
> else:
> key = args[0], tuple(fixitems( kwargs.items()))
> 
> Abe
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi. I just installed the newest version of matplotlib (0.82), and 
discovered all my subplots were ending on top of each other. After going 
through my code and verifying everything looked okay, I tried a simple:
subplot(2, 1, 1); plot(range(0, 10)); subplot(2, 2, 2); plot(range(0, 10))
and still only got one subplot. I went to the matplotlib code, and after 
some prodding, discovered that all the keys for the _seen map were 
exactly the same. Going to the _make_key function revealed that my use 
of subplot (i.e. three seperate arguments), was not working. Here is a 
fix that seems to work for me:
(int _make_key function):
 if iterable(args[0]):
 key = tuple(args[0]), tuple( fixitems(kwargs.items()))
## NEW
 elif len(args) > 1:
 key = args, tuple( fixitems(kwargs.items()))
## \NEW
 else:
 key = args[0], tuple(fixitems( kwargs.items()))
Abe

John,
Attached is the diff against CVS for lines.py, with a fix for the 
set_xdata/set_ydata bug that Torsten found. The changes are:
(0) (Sorry--looks like part of the diff is caused merely by trailing 
space characters that my editor strips off.)
1) I replaced _masked_x and _masked_y attributes with _x_orig and 
_y_orig, which hold the inputs to set_data with no changes; they are 
always used, regardless of whether the inputs are masked or not. This 
leads to some simplification, and solves the problem Torsten found. The 
penalty is that if neither x nor y is masked and both are already 1-D 
numerix float arrays, then both are needlessly stored twice, once in 
_x_orig/_y_orig, and again in _x and _y. (Actually, this may not be 
true; I am not sure whether the arrays are duplicated or whether there 
are merely separate references to the same data arrays. I could figure 
it out, but I don't want to spend time on that now unless it is deemed 
urgent.)
2) I made some other changes in set_data to make it simpler and more 
readable; in particular, using ma.ravel() at the start eliminates 
several later conditionals and calls to ravel.
3) There seems to have been half-way support for letting either x or y 
be of length 1, and having it automatically expanded to match the other 
variable; I completed this support and moved it to near the top of the 
function. If it is not useful, it can be removed easily with no ill 
effects. (All it would be good for is making horizontal or vertical lines.)
Eric

>>>>> "Adrian" == Adrian E Feiguin <afe...@uc...> writes:
 Adrian> Hi everybody, I just found your application, and I'm
 Adrian> stunned. You've done a great job. I'm the lead developer
 Adrian> of another application called SciGraphica
 Adrian> (http://scigraphica.sourceforge.net) and GtkExtra, a
 Adrian> package of widgets for (among other things) plotting 2d,
 Adrian> contour, 3d, and polar plots. SciGraphica is built on top
 Adrian> of gtkextra and it's not competing with matplot in the
 Adrian> sense that it aims at having a GUI based program ala
 Adrian> Microcal Origin, with spreadsheets for editing and
 Adrian> manipulating the data. I hope you agree that we can learn
 Adrian> from each others experiences with algorithms, etc. This is
 Adrian> precisely why I'm contacting you, guys!
Hi Adrian,
Thanks for the kind words. scigraphica looks like an incredible
project; combined with gtkextra it must keep you pretty busy.
 Adrian> I have to confess that my contour and 3d plots are pretty
 Adrian> "raw" in the sense that the algorithms I use are quite
 Adrian> primitive and slow. I basicaly generate a delaunay
 Adrian> triangulation and cut the triangles with planes, and draw
 Adrian> the resulting polygons. I was wondering if you guys could
 Adrian> give me some feedback about a good algorithm for plotting
 Adrian> 2d contour plots, or at least, tell me where to look in
 Adrian> your code to see if I can learn from it. Whare are the
 Adrian> actual engines to plot the pie charts and contours, for
 Adrian> instance?
The contouring engine is pure C code and is borrowed from the gist
library; see src/cntr.c. There are some python classes that sit on
top of this to create the graphics objects and labeling, and these are
in lib/matplotlib/contour.py. As far as we are able to determine, the
C code from gist does not have any licensing restrictions, and the
matplotlib contouring routines are all PSF/BSD compatible in their
licenses so you are welcome to borrow them for your own code. There
are many more publicly available routines you can consider since you
have a GPL license; matplotlib has a more permissive license and we
tryu to avoid GPL code for that reason. Most of the contouring
routines we considered, along with the licenses and possible patent
encumbrances, were discussed on the devel list last year in this
thread http://sourceforge.net/mailarchive/message.php?msg_id=9890501 .
As far as the "actual engines" we use to make plots, matplotlib has
several engines it can use (PS, SVG, antigrain, GTK, Cairo, GD, ...)
All of the screenshots were produced with the antigrain renderer, a
C++ library for 2D antialiased rendering with full alpha channel
support (http://antigrain.com). We embed the antigrain rendered
images into a variety of GUI canvases (Tk, GTK, WX, FLTK, Qt) using a
bitmap transfer.
Hope this helps!
JDH

Hi everybody,
I just found your application, and I'm stunned. You've done a great job. 
I'm the lead developer of another application called SciGraphica 
(http://scigraphica.sourceforge.net) and GtkExtra, a package of widgets 
for (among other things) plotting 2d, contour, 3d, and polar plots. 
SciGraphica is built on top of gtkextra and it's not competing with 
matplot in the sense that it aims at having a GUI based program ala 
Microcal Origin, with spreadsheets for editing and manipulating the 
data. I hope you agree that we can learn from each others experiences 
with algorithms, etc. This is precisely why I'm contacting you, guys!
I have to confess that my contour and 3d plots are pretty "raw" in the 
sense that the algorithms I use are quite primitive and slow. I basicaly 
generate a delaunay triangulation and cut the triangles with planes, and 
draw the resulting polygons. I was wondering if you guys could give me 
some feedback about a good algorithm for plotting 2d contour plots, or 
at least, tell me where to look in your code to see if I can learn from 
it. Whare are the actual engines to plot the pie charts and contours, 
for instance?
I hope you guys don't mind sharing info with me, actually this is one of 
the reasons for doing OSS. I hope we can enjoy a fruitful communication. 
All the best, and congratulations again for your project.
Saludos,
<ADRIAN>
PS: If by any chance you feel inclined to trying SG, I suggest you to go 
directly for the CVS code, since the latest release is not very stable.

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> Fernando> Stephen Walton wrote:
> >> Fernando Perez wrote:
> >>> Well, it could be something like $HOME/.tex.cache, where $HOME
> >>> can be determined via a routine like the below (this is what
> >>> ipython uses to try and guess a sensible value for $HOME):
> >> I *like* it.
> 
> Fernando> Though I'd personally vote for matplotlib holding
> Fernando> $HOME/.matplotlib/ as a directory, and putting in there
> Fernando> a tex.cache dir, the matplotlibrc file, and anything
> Fernando> else it may need in the future.
> 
> I am in the process of moving all of matplotlib's config files and
> outputs to HOME/.matplotlib.
Great!
> what I am really after is a simple print >> sys.stderr. Is there
> anything wrong with using sys.stderr for this kind of thing, error
> mavens? I know when we discussed this many moons ago we converged on
> using exceptions and the warnings module everywhere. But now I am a
> bit confounded by the inability to make the warnings print pretty
> messages that the typical user will read and understand. Or is there
> a way to tell warning.warn to just print the error message with no
> lineno/traceback info?
Dunno, sorry. In ipython, I have a trivial warn() routine which is just a 
print >> sys.stderr wrapper. I've never used the stdlib's warnings module.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Stephen Walton wrote:
 >> Fernando Perez wrote:
 >>> Well, it could be something like $HOME/.tex.cache, where $HOME
 >>> can be determined via a routine like the below (this is what
 >>> ipython uses to try and guess a sensible value for $HOME):
 >> I *like* it.
 Fernando> Though I'd personally vote for matplotlib holding
 Fernando> $HOME/.matplotlib/ as a directory, and putting in there
 Fernando> a tex.cache dir, the matplotlibrc file, and anything
 Fernando> else it may need in the future.
I am in the process of moving all of matplotlib's config files and
outputs to HOME/.matplotlib.
I want to issue a warning to users if I find a .matplotlibrc file (the
new name is matplotlibrc (no hidden "dot") and the default location is
HOME/.matplotlib/matplotlibrc. As before, you can put an rc file in
the current dir.
I am using warnings.warn to issue the warning
 home = get_home()
 oldname = os.path.join( home, '.matplotlibrc')
 if os.path.exists(oldname):
 warnings.warn('Old rc filename "%s" found and ignored; new default rc file name is HOME/.matplotlib/matplotlibrc"'%oldname)
But this results in a warning that looks like this
 > python ~/python/projects/matplotlib/examples/subplot_demo.py
 /usr/lib/python2.4/site-packages/matplotlib/__init__.py:737: UserWarning: Old rc filename "/home/jdhunter/.matplotlibrc" found and ignored; new default rc file name is HOME/.matplotlib/matplotlibrc"
 warnings.warn('Old rc filename "%s" found and ignored; new default rc file name is HOME/.matplotlib/matplotlibrc"'%oldname)
which I find hard to read. I can add a stacklevel=0 argument to warn
which is slightly more legible
 > python ~/python/projects/matplotlib/examples/subplot_demo.py
 /usr/lib/python2.4/warnings.py:41: UserWarning: Old rc filename "/home/jdhunter/.matplotlibrc" found and ignored; new default rc file name is HOME/.matplotlib/matplotlibrc"
 lineno = caller.f_lineno 
but still has the annoying "lineno = caller.f_lineno"
what I am really after is a simple print >> sys.stderr. Is there
anything wrong with using sys.stderr for this kind of thing, error
mavens? I know when we discussed this many moons ago we converged on
using exceptions and the warnings module everywhere. But now I am a
bit confounded by the inability to make the warnings print pretty
messages that the typical user will read and understand. Or is there
a way to tell warning.warn to just print the error message with no
lineno/traceback info?
JDH

>>>>> "Tom" == Tom Denniston <tom...@gm...> writes:
 Tom> I have been using matplotlib a few days now and think I it is
 Tom> great but recently I have gotten hung up on a problem
 Tom> plotting negative numbers.
 Tom> I am trying to plot data where the y values are all negative.
 Tom> When I do this I get the No positive data to plot error. I
 Tom> have tracked it down to the following two line is
 Tom> /matplotlib/ticker.py: if minpos<=0: raise RuntimeError('No
 Tom> positive data to plot')
This should only be occurring if you have log scaling set. Could you
get a fresh copy of matplotlib CVS and see if you can replicate the
bug. And if so, please post a script that exposes it.
Thanks,
JDH

Matt Newville wrote:
> Marcin,
>
> I think it's a known feature of the Toolbars that they use a
> Frame not a Panel, at least for the wx backend. It's hard for
Usually they use Frame, but they can also work with another Windows.
> me to get excited about this as I don't use the Toolbars, but if
> you can send a patch that makes them work for a Panel, that's
> fine with me.
Toolbars work fine, the only problem was with the parent of FileDialogs.
Very simple patch is attached.
>
>> I haven't solved the second problem yet. It can be seen on
>> simple_plot.py.. When I decrease window's size plot doesn't
>> shrink like in GTK backend, and only part of the plot is
>> visible. It used to work properly in older wx and MPL
>> versions.
>
> You didn't specify an OS, which probably means linux ;). I
yes :-)
Marcin
--=20
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr