matplotlib-devel Mailing List for matplotlib (Page 501)

A challenge to the community! ;)

Run the current cursor.py example with the TkAgg backend. (blitting
should be on)
i.e.  python cursor.py -dTkAgg

Why does the blitting not update the entire axis?  Any help on this is
greatly appreciated.

Thanks,
     Charlie

On 11/10/05, Charlie Moad <cw...@gm...> wrote:
> So this happens with TkAgg and blitting.  Here is the sample script:
>
> #!/usr/bin/env python
> import matplotlib; matplotlib.use('TkAgg')
> import pylab
> from matplotlib.widgets import SpanSelector
>
> fig =3D pylab.figure()
> ax =3D fig.add_subplot(111)
>
> ax.plot(pylab.rand(100))
> def onselect(vmin, vmax):
>     print vmin, vmax
>
> span =3D SpanSelector(ax, onselect, 'horizontal', useblit=3DTrue,
>                     rectprops=3Ddict(alpha=3D0.5, facecolor=3D'red') )
>
> pylab.show()
>
> Adjust the subplot params then you will see the distortion.  With 2
> subplots the spanselector never visually appears, but the callback is
> called.
>
> Thanks,
>      Charlie
>
> On 11/9/05, Charlie Moad <cw...@gm...> wrote:
> >      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
> > >
> >
>

On Thursday 17 November 2005 10:24 pm, John Hunter wrote:
> Darren found this problem with creating a temporary dir with
> python2.2.  I don't have a 2.2 install laying around.  If someone
> does, could you take a minute and find what the proper way is to avoid
> this err:
>
>     t = tempfile.TemporaryFile(dir=p)
> TypeError: TemporaryFile() got an unexpected keyword argument 'dir'

Here is the docstring for tempfile.TemporaryFile in python-2.2:

TemporaryFile(mode='w+b', bufsize=-1, suffix='')
    Create and return a temporary file (opened read-write by default).

Darren

If I do 

  ax.yaxis.set_major_formatter(ScalarFormatter(useMathText=True))

only the "x1e6" multiplier is rendered in mathtext, which makes the
tick labels and the multiplier look different. Is this done on
purpose, or an inadvertent omission?

The following one-line change makes the tick labels use mathtext.

--- ticker.py.orig      2005-06-14 00:40:26.000000000 +0300
+++ ticker.py   2005-11-16 12:11:29.055601000 +0200
@@ -337,6 +337,7 @@
                    for loc in locs]
         sigfigs.sort()
         self.format = '%1.' + str(sigfigs[-1]) + 'f'
+        if self._useMathText: self.format = '$' + self.format + '$'
                 
     def pprint_val(self, x):
         xp = (x-self.offset)/10**self.orderOfMagnitude

-- 
Jouni K Seppänen

Hi,

I have recently started to make plots with matplotlib. It's a great tool!
When trying to change the width of ticklines, I noticed that
axis.get_ticklines() only returns the line2D objects for the major
ticks. But one might want to change the linewidth of the minor ticks.
Hence, I propose something like

    def get_minor_ticklines(self):
        'Return the minor ticklines lines as a list of Line2D instance'
        lines =3D []
        for tick in self.minorTicks:
            lines.append(tick.tick1line)
            lines.append(tick.tick2line)
        return silent_list('Line2D minor ticklines', lines)


in class Axis. What do people think?

Also note, that, in fact, ticks are 'markers' and one has to change the
markeredgewidth (mew).


 - Christian

SGkgdGhlcmUsCkkgaGF2ZSBwcm9ibGVtIHdpdGggZW1iZWRkaW5nIE1QTCBpbnRvIG15IGFwcGxp
Y2F0aW9uLgpGbyBleGFtcGxlOgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyBxdGVtYi5weSBmaWxlCmltcG9ydCBtYXRwbG90bGli
Cm1hdHBsb3RsaWIudXNlKCdBZ2cnKSAjIG5lZWQgdG8gc2V0IGJlZm9yZSBpbXBvcnRpbmcgcHls
YWIKCmZyb20gc3lzIGltcG9ydCBhcmd2LGV4aXQKZnJvbSBweWxhYiBpbXBvcnQgKgoKZnJvbSBt
YXRwbG90bGliLmJhY2tlbmRzLmJhY2tlbmRfcXRhZ2cgaW1wb3J0IEZpZ3VyZUNhbnZhc1FUQWdn
IGFzIEZpZ3VyZUNhbnZhcwpmcm9tIG1hdHBsb3RsaWIuZmlndXJlIGltcG9ydCBGaWd1cmUKCmZy
b20gcXQgaW1wb3J0ICoKCmEgPSBRQXBwbGljYXRpb24oYXJndikKdyA9IFFXaWRnZXQoKQoKZmln
dXJlKDEpCnN1YnBsb3QoMTExKQpwbG90KFsxLDIsM10sIFswLjIsIDIuMSwgMS4xXSkKCmNhbnZh
cyA9IEZpZ3VyZUNhbnZhcyhnY2YoKSkKY2FudmFzLnJlcGFyZW50KHcsIFFQb2ludCgwLCAwKSkK
CmwgPSBRVkJveExheW91dCh3KQpsLmFkZFdpZGdldChjYW52YXMpCgphLnNldE1haW5XaWRnZXQo
dykKCncuc2hvdygpCmV4aXQoYS5leGVjX2xvb3AoKSkKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMgcXRlbWIucHkgZmlsZQoKSSBo
YXZlIHByb2JsZW1zIHdpdGggcnVubmluZyBxdGVtYi5weS1pdCByZXBvcnRzOgoKUUFwcGxpY2F0
aW9uOiBUaGVyZSBzaG91bGQgYmUgbWF4IG9uZSBhcHBsaWNhdGlvbiBvYmplY3QKCmFuZCBpdCBp
cyBpbXBvc3NpYmxlIHRvIGNsb3NlIHdpbmRvdyAoc2ltcGx5IGZyZWV6ZXMpLgoKCgpGSVg6Cldo
ZW4gY29tbWVudCBvdXQgbGFzdCBsaW5lcyBpbiBiYWNrZW5kcy9iYWNrZW5kX3F0LnB5OgoKI2Ny
ZWF0ZVFBcHAgPSBxdC5RQXBwbGljYXRpb24uc3RhcnRpbmdVcCgpCiNpZiBjcmVhdGVRQXBwOgoj
ICAgIGlmIERFQlVHOiBwcmludCAiU3RhcnRpbmcgdXAgUUFwcGxpY2F0aW9uIgojICAgIHF0YXBw
bGljYXRpb24gPSBxdC5RQXBwbGljYXRpb24oIFsiICJdICkKCgppdCB3b3JrcyBmaW5lLgoKClNv
LCBJIG15IG9waW5pb24sIGl0IG5lZWRzIGRpZmZlcmVudCBRQXBwbGljYXRpb24gcnVubmluZyBp
bnN0YW5jZSBjaGVjay4KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgaXQ/CgpSZWdhcmRzCkppcmkK

> On Tue, 2005-11-15 at 20:30 -0800,
> mat...@li... wrote:
> > Hi,
> > 
> > With matplotlib-0.84, pythonw embedding_in_qt.py
> > returns several
> > of these messages:
> > ___
> > Traceback (most recent call last):
> >   File "embedding_in_qt.py", line 54, in sizeHint
> >     w, h = self.fig.get_width_height()    
> > AttributeError: Figure instance has no attribute
> > 'get_width_height'
> > ___
> > With matplotlib-0.82 the example works fine.
> > Changelog shows 
> > 2005-06-18 Move Figure.get_width_height() to
> > FigureCanvasBase and return 
> >            int instead of float. - SC  
> > Is this a bug, or am I missing something?
> > 
> > Thanks,
> > 
> > Virgil

The self.fig.get_width_height() should be
self.get_width_height(). Changed in CVS.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

Hi,

With matplotlib-0.84, pythonw embedding_in_qt.py
returns several
of these messages:
___
Traceback (most recent call last):
  File "embedding_in_qt.py", line 54, in sizeHint
    w, h = self.fig.get_width_height()    
AttributeError: Figure instance has no attribute
'get_width_height'
___
With matplotlib-0.82 the example works fine.
Changelog shows 
2005-06-18 Move Figure.get_width_height() to
FigureCanvasBase and return 
           int instead of float. - SC  
Is this a bug, or am I missing something?

Thanks,

Virgil


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Marco Presi wrote:

>Hi,
>
>        please find here a patch by Aurelien Jarno <au...@de...>,
>        that allow matplotlib to build on Debian GNU/kFreeBSD systems[1].
>  
>
Committed to CVS. Thanks.

Hi,

        please find here a patch by Aurelien Jarno <au...@de...>,
        that allow matplotlib to build on Debian GNU/kFreeBSD systems[1].

        This patch has been included in the official Debian package[2].

        We are glad to receive comments and suggestions about the Debian
        packaging of matplotlib.
        
        Regards

        Marco Presi 

[1] http://io.debian.net
[2] http://packages.debian.org/unstable/source/matplotlib

-- 
"I videogiochi non influenzano i bambini. Voglio dire, se Pac-Man avesse
influenzato la nostra generazione, staremmo tutti saltando in sale
scure, masticando pillole magiche e ascoltando musica elettronica
ripetitiva."

"Videogames do not influence kids. I mean, if Pac-Man influenced our
generation, we were all jumping in dark rooms, chomping pills and
listening to electronic repeating music."

Kristian Wilson, Nintendo Inc. 1989

So this happens with TkAgg and blitting.  Here is the sample script:

#!/usr/bin/env python
import matplotlib; matplotlib.use('TkAgg')
import pylab
from matplotlib.widgets import SpanSelector

fig =3D pylab.figure()
ax =3D fig.add_subplot(111)

ax.plot(pylab.rand(100))
def onselect(vmin, vmax):
    print vmin, vmax

span =3D SpanSelector(ax, onselect, 'horizontal', useblit=3DTrue,
                    rectprops=3Ddict(alpha=3D0.5, facecolor=3D'red') )

pylab.show()

Adjust the subplot params then you will see the distortion.  With 2
subplots the spanselector never visually appears, but the callback is
called.

Thanks,
     Charlie

On 11/9/05, Charlie Moad <cw...@gm...> wrote:
>      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 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