matplotlib-devel Mailing List for matplotlib (Page 3)

 I will have to do more testing, but I am calling
figure.subplots_adjust, not adjusting with the widget. This is also
through the oo interface. I will try to write a sample script and get
back to the list.
Thanks,
On 11/9/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> I guess I should have mentioned TkAgg CVS. I didn't
> Charlie> think the problem would be specific to a backend, so I
> Charlie> didn't try any others. Also, when I have more than one
> Charlie> subplot, nothing is drawn period.
>
> tkagg works for me, as do multiple subplots. Weird. I'm using
> examples/span_selector.py. You too?
>
> JDH
>

I guess I should have mentioned TkAgg CVS. I didn't think the problem
would be specific to a backend, so I didn't try any others. Also,
when I have more than one subplot, nothing is drawn period.
- Charlie
On 11/9/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> First of all I just committed a generalized SpanSelector
> Charlie> widget that allows for a horizontal or vertical
> Charlie> selection.
>
> Charlie> I am running into a problem (and HorizontalSpanSelector
> Charlie> suffered from the same problem) that the rect is drawn
> Charlie> incorrectly if I adjust the sublot params. Any of the
> Charlie> MPL transforms experts know what I need to do?
>
> I'm having trouble replicating your problem. I launch span_selector,
> draw a rect, and it looks ok. Then I click on subplot params button,
> change the limits, and repeat, and it still looks right to me, both on
> the drawn rectangle and the limits printed by the callback.
>
> Tested on gtkagg with cvs head.
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> I guess I should have mentioned TkAgg CVS. I didn't
 Charlie> think the problem would be specific to a backend, so I
 Charlie> didn't try any others. Also, when I have more than one
 Charlie> subplot, nothing is drawn period.
tkagg works for me, as do multiple subplots. Weird. I'm using
examples/span_selector.py. You too?
JDH

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> First of all I just committed a generalized SpanSelector
 Charlie> widget that allows for a horizontal or vertical
 Charlie> selection.
 Charlie> I am running into a problem (and HorizontalSpanSelector
 Charlie> suffered from the same problem) that the rect is drawn
 Charlie> incorrectly if I adjust the sublot params. Any of the
 Charlie> MPL transforms experts know what I need to do?
I'm having trouble replicating your problem. I launch span_selector,
draw a rect, and it looks ok. Then I click on subplot params button,
change the limits, and repeat, and it still looks right to me, both on
the drawn rectangle and the limits printed by the callback.
Tested on gtkagg with cvs head.
JDH

fre...@oc... writes:
> When I try to complile with Tk in cygwin I fail in a different manner than
> you do:
[snip]
> build/temp.cygwin-1.5.18-i686-2.4/src/_tkagg.o
> C:\cygwin\bin\python2.4.exe (3292): *** unable to remap
> C:\cygwin\bin\tk84.dll to same address as parent(0x18CC0000) != 0x19200000
> 3 [main] python 3228 fork_parent: child 3292 died waiting for dll
> loading
> error: Error
> 
> I'm compiling it with Tkagg disabled at the moment and just using the PS
> backend. Any ideas what I'm doing different than you?
You need to run 'rebaseall' see:
http://sourceforge.net/mailarchive/forum.php?thread_id=8924137&forum_id=33405
/etc/setup contains lists of the files it rebases - and this doesn't
include packages you have compiled yourself - I've added a list of the
contents of /usr/lib/python2.4/site-packages to this directory so it
rebases them as well.
Chris

When I try to complile with Tk in cygwin I fail in a different manner than
you do:
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-IC:/cygwin/usr/share/tcl8.4/../../include
-IC:/cygwin/usr/share/tk8.4/../../include -I/usr/local/include
-I/usr/include -I. -Isrc -Iswig -Iagg23/include -I. -I/usr/local/include
-I/usr/include -I. -IC:/cygwin/usr/share/tcl8.4/../../include/freetype2
-IC:/cygwin/usr/share/tk8.4/../../include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/usr/include/python2.4 -c src/_tkagg.cpp -o
build/temp.cygwin-1.5.18-i686-2.4/src/_tkagg.o
C:\cygwin\bin\python2.4.exe (3292): *** unable to remap
C:\cygwin\bin\tk84.dll to same address as parent(0x18CC0000) != 0x19200000
 3 [main] python 3228 fork_parent: child 3292 died waiting for dll
loading
error: Error
I'm compiling it with Tkagg disabled at the moment and just using the PS
backend. Any ideas what I'm doing different than you?
Jordan

First of all I just committed a generalized SpanSelector widget that
allows for a horizontal or vertical selection.
I am running into a problem (and HorizontalSpanSelector suffered from
the same problem) that the rect is drawn incorrectly if I adjust the
sublot params. Any of the MPL transforms experts know what I need to
do?
Thanks,
 Charlie

After adding the paths for cygwin to 'basedir' in setupext.py (see
attached patch), I can now compile matplotlib 0.84 under cygwin. I do
however have problems with Tk.
I get the following error if I try to compile with Tk:
c++ -shared -Wl,--enable-auto-image-base 
build/temp.cygwin-1.5.18-i686-2.4/src/_tkagg.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/cxxsupport.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/cxx_extensions.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/IndirectPythonInterface.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/cxxextensions.o 
-LC:/cygwin/usr/share/tcl8.4/../ -LC:/cygwin/usr/share/tk8.4/../ 
-L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/lib 
-L/usr/lib/python2.4/config -ltk8.4 -ltcl8.4 -lpng -lz -lstdc++ -lm 
-lfreetype -lz -lstdc++ -lm -lpython2.4 -o 
build/lib.cygwin-1.5.18-i686-2.4/matplotlib/backends/_tkagg.dll
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: 
cannot find -ltk8.4
collect2: ld returned 1 exit status
error: command 'c++' failed with exit status 1
The problem with Tk, seems to comes from the fact that when it is
linked, the flags -ltk8.4 and -ltcl8.4 are used.
However, although /usr/lib/tk8.4 exists, the libs seem to be '84', not 
'8.4':
$ ls -l /usr/lib/libtk*
lrwxrwxrwx 1 walker Users 9 Feb 29 2004 /usr/lib/libtk.a -> libtk84.a
-rwxr-x---+ 1 walker Users 490984 Sep 2 2003 /usr/lib/libtk84.a
lrwxrwxrwx 1 walker Users 13 Feb 29 2004 /usr/lib/libtkstub.a -> 
libtkstub84.a
-rwxr-x---+ 1 walker Users 2058 Sep 2 2003 /usr/lib/libtkstub84.a
If I link with the flags -ltk -ltcl, then it all seems to work:
 c++ -shared -Wl,--enable-auto-image-base 
build/temp.cygwin-1.5.18-i686-2.4/src/_tkagg.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/cxxsupport.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/cxx_extensions.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/IndirectPythonInterface.o 
build/temp.cygwin-1.5.18-i686-2.4/CXX/cxxextensions.o 
-LC:/cygwin/usr/share/tcl8.4/../ -LC:/cygwin/usr/share/tk8.4/../ 
-L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/lib 
-L/usr/lib/python2.4/config -ltk -ltcl -lpng -lz -lstdc++ -lm -lfreetype 
-lz -lstdc++ -lm -lpython2.4 -o 
build/lib.cygwin-1.5.18-i686-2.4/matplotlib/backends/_tkagg.dll
I'm not sure if this is a bug in the tcl/tk implementation on cygwin,
or a problem with matplotlib.
Chris
PS Cygwin doesn't come with things like numeric - these have to be 
compiled separately
PPS This is the patch fof setupext:
--- matplotlib-0.84/setupext.py 2005年09月09日 19:12:33.000000000 +0100
+++ matplotlib-0.84.n2/setupext.py 2005年11月07日 22:54:29.162923200 +0000
@@ -35,6 +35,7 @@
 basedir = {
 'win32' : ['win32_static',],
+ 'cygwin' : ['/usr/local', '/usr',],
 'linux2' : ['/usr/local', '/usr',],
 'linux' : ['/usr/local', '/usr',],
 # Charles Moad recommends not putting in /usr/X11R6 for darwin

Eric Firing wrote:
> Maybe not so false--regardless of the dataset, if mpl produces an eps 
> file, it should work, shouldn't it?
After messing around a bit more, I'm beginning to think it might be an 
Illustrator bug. I'm contouring a very large (850x350) matrix, with a 
lot of finescale variability, so it's got tons of polygons being 
generated. GS opens the big one fine, and Illustrator is fine if I 
halve the matrix size, but the full matrix makes it choke. I don't 
quite understand it yet.
I'm thinking of resetting the nchunk = 0 var to something else and 
seeing if that has any effect on the problem, but that'll have to wait 
until tonight.
Jordan

On Fri, 2005年11月04日 at 08:31 -0800, Jordan Dawe wrote:
> The current matplotlib CVS appears to have some kind of bug in its EPS 
> output. When I try to open a generated eps file in illustrator, it 
> displays "The operation cannot complete because of an unknown error." 
> Ghostscript can still open the eps files without errors. This bug must 
> have been introduced recently, because it didn't exist on Oct 30th (I 
> installed matplotlib from CVS then to test the new contouring without 
> subdivision code) so I'm guessing it must have to do with the "added afm 
> support for mathtext" patch.
To give me some idea where to look for whatever I've done wrong it would
be useful to know whether you are actually using the afm output or not.
Thanks,
Nick

Sorry, it appears the bug I described in my last email has something to 
do with the dataset I am using. The old CVS fails the same way on my 
new data, but it still works with other datasets I have (but didn't test 
originally). False alarm, just ignore me.
Jordan

The current matplotlib CVS appears to have some kind of bug in its EPS 
output. When I try to open a generated eps file in illustrator, it 
displays "The operation cannot complete because of an unknown error." 
Ghostscript can still open the eps files without errors. This bug must 
have been introduced recently, because it didn't exist on Oct 30th (I 
installed matplotlib from CVS then to test the new contouring without 
subdivision code) so I'm guessing it must have to do with the "added afm 
support for mathtext" patch.

> I get the feeling that two different ideas are being discussed here. A 
> discrete color map still would require someone to define a custom one 
> if they have a favorite set of colors they want to use for each 
> contour level. That involves some level of inconvenience. I gather 
> from what Jordan is saying is that he wants to be able to 
> automatically construct a colorbar from the colors assigned to each 
> contour level without having to construct a colormap in the first 
> place. That is, after the contour is done with its specific 
> color/level assignments, then a request for a colorbar would show a 
> linear relationship between data levels and the discrete colors 
> chosen. Do I understand correctly?
Yes, that's it exactly.
Jordan

Perry Greenfield wrote:
> 
> On Nov 3, 2005, at 12:55 AM, Jordan Dawe wrote:
> 
>>
>>> Isn't this closely related to the idea we've tslked about a number of
>>> times (mostly off list) to supplant the colormap infrastructure with a
>>> "DiscreteColormap" or something along those lines, which mapped data
>>> to a set of discrete colors, using nearest neighbor or what have
>>> you. Then you would have the best of both worlds: your favorite
>>> colors and consistency with the mpl colorbar/colormapping API. Would
>>> this work?
>>>
>> I don't quite understand the idea here, but the colorbar mapping is 
>> really only part of this. If you make classes for each plot type, you 
>> could do things like make legend() a call to the PlotClass.Legend() 
>> method, and each plot could make it's own kind of legend.
>>
>> I know this is a large architecture change, but it could be 
>> implimented incrimentally and I think it would give a lot of benefits 
>> in regards to what you could do with customizing different plot 
>> behaviours. But, as I said before, I don't really have nearly the 
>> grasp of the matplotlib codebase that the devs do. It doesn't look 
>> too difficult to me, but there are probably issues I am not aware of. 
>> Is there any reason each plot type shouldn't have it's own class?
>>
> I get the feeling that two different ideas are being discussed here. A 
> discrete color map still would require someone to define a custom one if 
> they have a favorite set of colors they want to use for each contour 
> level. That involves some level of inconvenience. I gather from what 
> Jordan is saying is that he wants to be able to automatically construct 
> a colorbar from the colors assigned to each contour level without having 
> to construct a colormap in the first place. That is, after the contour 
> is done with its specific color/level assignments, then a request for a 
> colorbar would show a linear relationship between data levels and the 
> discrete colors chosen. Do I understand correctly?
Automatic colorbar generation when the contourf (for example) colors are 
given explicitly is certainly one of the things Jordan is talking about, 
and it is something I have been intending to get to. I think that a 
first working version, for contour and contourf, can be done with little 
modification to the present code, and I am inclined to do that at least 
as an interim measure ASAP--within a few days--unless a better idea 
becomes clear.
That brings us to the larger framework, and here I think there are two 
or three general ideas rattling around, overlapping but not mutually 
exclusive.
1) The ScalarMappable class could be extended to include additional 
mapping methods. Here are four possibilities:
 - boundaries: this is what contourf already does; N-1 colors are 
mapped to the regions defined by N boundaries.
 - nearest-neighbor: similar but N-to-N
 - dictionary: maps hashable object to color, given an existing dictionary
 - indexed array: Matlab has this, and I use it extensively in Matlab 
to deal with exactly the problem that motivated Jordan's message; but it 
might not be necessary for mpl.
2) When I changed contourf to output a ContourSet object, John suggested 
that this approach might be used for other types of plot (certainly 
pcolor, for example), and this is getting closer to what Jordan is 
talking about as a framework, I think. The idea is to package all 
useful information in an object, so that either its methods can be 
called later, or it can be passed to a function (such as colorbar) that 
understands what to do with it.
3) Jordan's suggestion seems to be going a little farther; I think the 
idea is to design a class hierarchy for plot types to accomplish the 
goals of (2) in a more systematic way, rather than dealing with each 
plot type ad hoc as the demand arises.
Eric

On Nov 3, 2005, at 12:55 AM, Jordan Dawe wrote:
>
>> Isn't this closely related to the idea we've tslked about a number of
>> times (mostly off list) to supplant the colormap infrastructure with a
>> "DiscreteColormap" or something along those lines, which mapped data
>> to a set of discrete colors, using nearest neighbor or what have
>> you. Then you would have the best of both worlds: your favorite
>> colors and consistency with the mpl colorbar/colormapping API. Would
>> this work?
>>
> I don't quite understand the idea here, but the colorbar mapping is 
> really only part of this. If you make classes for each plot type, you 
> could do things like make legend() a call to the PlotClass.Legend() 
> method, and each plot could make it's own kind of legend.
>
> I know this is a large architecture change, but it could be 
> implimented incrimentally and I think it would give a lot of benefits 
> in regards to what you could do with customizing different plot 
> behaviours. But, as I said before, I don't really have nearly the 
> grasp of the matplotlib codebase that the devs do. It doesn't look 
> too difficult to me, but there are probably issues I am not aware of. 
> Is there any reason each plot type shouldn't have it's own class?
>
I get the feeling that two different ideas are being discussed here. A 
discrete color map still would require someone to define a custom one 
if they have a favorite set of colors they want to use for each contour 
level. That involves some level of inconvenience. I gather from what 
Jordan is saying is that he wants to be able to automatically construct 
a colorbar from the colors assigned to each contour level without 
having to construct a colormap in the first place. That is, after the 
contour is done with its specific color/level assignments, then a 
request for a colorbar would show a linear relationship between data 
levels and the discrete colors chosen. Do I understand correctly?
Perry

>Isn't this closely related to the idea we've tslked about a number of
>times (mostly off list) to supplant the colormap infrastructure with a
>"DiscreteColormap" or something along those lines, which mapped data
>to a set of discrete colors, using nearest neighbor or what have
>you. Then you would have the best of both worlds: your favorite
>colors and consistency with the mpl colorbar/colormapping API. Would
>this work?
> 
>
I don't quite understand the idea here, but the colorbar mapping is 
really only part of this. If you make classes for each plot type, you 
could do things like make legend() a call to the PlotClass.Legend() 
method, and each plot could make it's own kind of legend.
I know this is a large architecture change, but it could be implimented 
incrimentally and I think it would give a lot of benefits in regards to 
what you could do with customizing different plot behaviours. But, as I 
said before, I don't really have nearly the grasp of the matplotlib 
codebase that the devs do. It doesn't look too difficult to me, but 
there are probably issues I am not aware of. Is there any reason each 
plot type shouldn't have it's own class?
Jordan

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> Hi, I regularly use matplotlib on lots of systems I
 Nicholas> don't have root access to. On most of these
 Nicholas> installation of gs 8.15 is quite problematic (and buggy)
 Nicholas> and as I result using TeX with matplotlib is
 Nicholas> impractical. Additionally as all of the printers I have
 Nicholas> access to are HP made the use of embedded truetype fonts
 Nicholas> is also problematic. The combination of these two
 Nicholas> problems has made it difficult to use mpl for anything I
 Nicholas> need to print and for which I need mathtext.
 Nicholas> As a solution I've patched the mathtext library and
 Nicholas> backend_ps in order to support mathtext based upon the
 Nicholas> standard postscript Symbol font when ps.usetex = True.
 Nicholas> A function patch to CVS is attached.
Thanks Nick -- just committed this to CVS so it will be in the next
release
Checking in lib/matplotlib/mathtext.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/mathtext.py,v <--
matht\
ext.py
new revision: 1.21; previous revision: 1.20
done
Checking in lib/matplotlib/backends/backend_ps.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_ps.py,v
\
 <-- backend_ps.py
new revision: 1.69; previous revision: 1.68
done
JDH

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 Perry> Before you go off in this direction, could you outline how
 Perry> you think colormaps should work? From the sounds of it, you
 Perry> are addressing mostly cases where users have specifically
 Perry> picked colors and you would like colorbar() to work with
 Perry> the selected colors. Generally speaking, you seem to be
Isn't this closely related to the idea we've tslked about a number of
times (mostly off list) to supplant the colormap infrastructure with a
"DiscreteColormap" or something along those lines, which mapped data
to a set of discrete colors, using nearest neighbor or what have
you. Then you would have the best of both worlds: your favorite
colors and consistency with the mpl colorbar/colormapping API. Would
this work?
JDH

> Before you go off in this direction, could you outline how you think 
> colormaps should work? From the sounds of it, you are addressing 
> mostly cases where users have specifically picked colors and you would 
> like colorbar() to work with the selected colors. Generally speaking, 
> you seem to be concerned with discrete color sets. But colormaps were 
> primarily directed towards image display where a nearly continuous 
> range of levels might be encountered. So could you explain how you 
> would handle colormaps for images?
I think that there should essentially be 2 seperate systems, one for 
discrete color sets and one for colormaps. I think colormaps work great 
for things like image data or continuous data where transitions between 
levels are less important than getting a general feeling of magnitude 
and structure. Discrete contour levels are better for showing where a 
set of data exceeds threshold values. So both should be useable, but 
currently the architecture is focused on using colormaps.
As it stands, colorbar() seems perfectly usable if you are working with 
colormaps--I'm not sure about this though, because I almost never use 
colormaps in my figures. So I wouldn't change anything about colormaps 
for images: this is an extension of the functionality, not a modification.
Jordan

On Nov 1, 2005, at 1:34 PM, Jordan Dawe wrote:
> I have been hacking away at the colorbar( ) code because I wanted a 
> more flexible colorbar facility for my figures. However, the current 
> figure/axes architechture presents a few problems for me. My primary 
> problem is this: I never, ever, ever use the colormap facilities in 
> matplotlib; I specify the colors of each of my contour levels with rgb 
> tuples, because I have grown super-obsessed with graphics design and I 
> want exact control of the shades displayed. Not using colormaps 
> creates the problem that colorbar() doesn't work, as there is no 
> colormap for it to plot.
>
> Colormaps are, in my opinion, a horrible hack and one of the worst 
> parts of Matlab. In fact, one of the main reasons I have been using 
> matplotlib is because it's much easier to turn colormaps off. But 
> this does present a problem for automated colorbars.
>
> The solution that I am inclined to pursue is to create a set of 
> 'plot-type' objects; ie, objects called "contour", "contourf", "bar", 
> "pie", "plot", etc, which all inherit from a parent class. These 
> objects would contain information about the levels plotted, the colors 
> of the lines, links to the PolyCollections that are currently stored 
> by the axes, etc. This would allow colorbar() to, say, automatically 
> grab the last contourf plotted, figure out the colors, space the color 
> divisions in proportion to the data levels, and so on. I could see if 
> the axes have a contour plot as well as a contourf, and if the data 
> levels agreed, it could plot the contour levels onto the colorbar as 
> well. It would also allow for more flexible legends, and it wouldn't 
> neccessitate the abandonment of matlab compatibility, since colorbar() 
> would still default to searching for a colormap first.
>
> But I haven't been looking at the matplotlib code for that long, so 
> I'm not sure this is actually a good idea. Is there an obvious 
> problem with this idea? Is it worth me trying to start hacking 
> something together? Thanks.
>
> Jordan
Before you go off in this direction, could you outline how you think 
colormaps should work? From the sounds of it, you are addressing mostly 
cases where users have specifically picked colors and you would like 
colorbar() to work with the selected colors. Generally speaking, you 
seem to be concerned with discrete color sets. But colormaps were 
primarily directed towards image display where a nearly continuous 
range of levels might be encountered. So could you explain how you 
would handle colormaps for images?
Perry Greenfield

I have been hacking away at the colorbar( ) code because I wanted a more 
flexible colorbar facility for my figures. However, the current 
figure/axes architechture presents a few problems for me. My primary 
problem is this: I never, ever, ever use the colormap facilities in 
matplotlib; I specify the colors of each of my contour levels with rgb 
tuples, because I have grown super-obsessed with graphics design and I 
want exact control of the shades displayed. Not using colormaps creates 
the problem that colorbar() doesn't work, as there is no colormap for it 
to plot.
Colormaps are, in my opinion, a horrible hack and one of the worst parts 
of Matlab. In fact, one of the main reasons I have been using 
matplotlib is because it's much easier to turn colormaps off. But this 
does present a problem for automated colorbars.
The solution that I am inclined to pursue is to create a set of 
'plot-type' objects; ie, objects called "contour", "contourf", "bar", 
"pie", "plot", etc, which all inherit from a parent class. These 
objects would contain information about the levels plotted, the colors 
of the lines, links to the PolyCollections that are currently stored by 
the axes, etc. This would allow colorbar() to, say, automatically grab 
the last contourf plotted, figure out the colors, space the color 
divisions in proportion to the data levels, and so on. I could see if 
the axes have a contour plot as well as a contourf, and if the data 
levels agreed, it could plot the contour levels onto the colorbar as 
well. It would also allow for more flexible legends, and it wouldn't 
neccessitate the abandonment of matlab compatibility, since colorbar() 
would still default to searching for a colormap first.
But I haven't been looking at the matplotlib code for that long, so I'm 
not sure this is actually a good idea. Is there an obvious problem with 
this idea? Is it worth me trying to start hacking something together? 
Thanks.
Jordan