Help with scatter

_Andrew_Stock · November 10, 2008, 3:38pm

Hi,

I'm trying to specify the colours for markers in a call to scatter.
I've read this information in the documentation:

c:
a color. c can be a single color format string, or a sequence of
color specifications of length N, or a sequence of N numbers to be
mapped to colors using the cmap and norm specified via kwargs (see
below). Note that c should not be a single numeric RGB or RGBA
sequence because that is indistinguishable from an array of values to
be colormapped. c can be a 2-D array in which the rows are RGB or
RGBA, however.

My interpretation of this is that either of the three values attempted
in the code example should work. However, all of these fail.

from pylab import *

x = [1,2,3]
y = [2,4,6]
c = ['#ff0000', '#00ff00', '#0000ff']
c = ['b','r', 'g']
c = [(1,0,0), (0,1,0), (0,0,1)]

scatter(x, y, c=c)

show()

If I change the call to scatter() to a call to bar() as so:

bar(x, y, color = c)

then each of the three examples work as I would expect.

Am I missing something in my interpretation of the documentation for
scatter? Can anyone point out what I've missed?

Thanks

Andrew

_Ryan_May · November 10, 2008, 4:51pm

Andrew Stock wrote:

My interpretation of this is that either of the three values attempted
in the code example should work. However, all of these fail.

from pylab import *

x = [1,2,3]
y = [2,4,6]
c = ['#ff0000', '#00ff00', '#0000ff']
c = ['b','r', 'g']
c = [(1,0,0), (0,1,0), (0,0,1)]

scatter(x, y, c=c)

show()

If I change the call to scatter() to a call to bar() as so:

bar(x, y, color = c)

then each of the three examples work as I would expect.

Am I missing something in my interpretation of the documentation for
scatter? Can anyone point out what I've missed?

Well, I can get the last one to work with SVN HEAD. The others don't
work for me either, though I agree they probably should.

It looks like any 1D sequence will trigger colormapping instead of
strings being mapped to rgba arrays. I'll keep digging to see what
changed. (Unless someone beats me to it.)

Ryan

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

_Ryan_May · November 10, 2008, 7:55pm

Andrew Stock wrote:

My interpretation of this is that either of the three values attempted
in the code example should work. However, all of these fail.

from pylab import *

x = [1,2,3]
y = [2,4,6]
c = ['#ff0000', '#00ff00', '#0000ff']
c = ['b','r', 'g']
c = [(1,0,0), (0,1,0), (0,0,1)]

scatter(x, y, c=c)

show()

I'm working on a better fix right now, but can you try making sure you
have more (or less) colors specified than needed? I think that should
work around (or it seems to on SVN HEAD).

Ryan

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

_Ryan_May · November 10, 2008, 8:14pm

Ryan May wrote:

Well, I can get the last one to work with SVN HEAD. The others don't
work for me either, though I agree they probably should.

It looks like any 1D sequence will trigger colormapping instead of
strings being mapped to rgba arrays. I'll keep digging to see what
changed. (Unless someone beats me to it.)

Ok, here's a patch that fixes the problem for me, as well as a test
script that tests a bunch of the color options along with having more,
the same, and less than the number of points passed in.

This is triggered by passing in a sequence of strings of the same length
as x, which matplotlib interprets as needing colormapping. Colormapping
an array of strings explodes nicely. I've fixed this issue by:

1) Make scatter() check if c is a sequence of strings. If it is, use
the colorConverter as expected.

2) This requires changing is_string_like() to recognize elements from
numpy string arrays (type numpy.string_) as strings. These elements are
actually instances of a subclass of python strings
(isinstance(<element>, str is True), but fail because they have a shape
attribute (which is explicitly checked).

3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
containing strings. Currently, there is an explicit check for a 2D
array, and if it is not, and exception is thrown.

Since this is my first mucking around in internals with which I am not
familiar, I'd like someone to double check me. It's only a 3 line diff,
but each line is in a different file, so it's got a pretty wide (though
thin) footprint.

Ryan

test.py (724 Bytes)

fix_scatter.diff (1.63 KB)

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

_Ryan_May · November 10, 2008, 8:17pm

Ryan May wrote:

Well, I can get the last one to work with SVN HEAD. The others don't
work for me either, though I agree they probably should.

It looks like any 1D sequence will trigger colormapping instead of
strings being mapped to rgba arrays. I'll keep digging to see what
changed. (Unless someone beats me to it.)

Ok, here's a patch that fixes the problem for me, as well as a test
script that tests a bunch of the color options along with having more,
the same, and less than the number of points passed in.

This is triggered by passing in a sequence of strings of the same length
as x, which matplotlib interprets as needing colormapping. Colormapping
an array of strings explodes nicely. I've fixed this issue by:

1) Make scatter() check if c is a sequence of strings. If it is, use
the colorConverter as expected.

2) This requires changing is_string_like() to recognize elements from
numpy string arrays (type numpy.string_) as strings. These elements are
actually instances of a subclass of python strings
(isinstance(<element>, str is True), but fail because they have a shape
attribute (which is explicitly checked).

3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
containing strings. Currently, there is an explicit check for a 2D
array, and if it is not, and exception is thrown.

Since this is my first mucking around in internals with which I am not
familiar, I'd like someone to double check me. It's only a 3 line diff,
but each line is in a different file, so it's got a pretty wide (though
thin) footprint.

Ryan

test.py (724 Bytes)

fix_scatter.diff (1.63 KB)

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Eric_Firing2 · November 10, 2008, 11:54pm

Ryan May wrote:

Ryan May wrote:

Well, I can get the last one to work with SVN HEAD. The others don't
work for me either, though I agree they probably should.

It looks like any 1D sequence will trigger colormapping instead of
strings being mapped to rgba arrays. I'll keep digging to see what
changed. (Unless someone beats me to it.)

Ok, here's a patch that fixes the problem for me, as well as a test
script that tests a bunch of the color options along with having more,
the same, and less than the number of points passed in.

This is triggered by passing in a sequence of strings of the same length
as x, which matplotlib interprets as needing colormapping. Colormapping
an array of strings explodes nicely. I've fixed this issue by:

1) Make scatter() check if c is a sequence of strings. If it is, use
the colorConverter as expected.

2) This requires changing is_string_like() to recognize elements from
numpy string arrays (type numpy.string_) as strings. These elements are
actually instances of a subclass of python strings
(isinstance(<element>, str is True), but fail because they have a shape
attribute (which is explicitly checked).

3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
containing strings. Currently, there is an explicit check for a 2D
array, and if it is not, and exception is thrown.

Since this is my first mucking around in internals with which I am not
familiar, I'd like someone to double check me. It's only a 3 line diff,
but each line is in a different file, so it's got a pretty wide (though
thin) footprint.

Ryan,

Here is a modification of your patch that I think will be very slightly more efficient and general.

Eric

scattercolor.diff (2.51 KB)

···

Ryan

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

_Ryan_May · November 11, 2008, 1:49am

Thanks. That does look a lot more clean. It would have helped if I had known about dtype.kind for ease of testing for arrays of strings and numpy string scalars.

Anyone else?

Ryan

···

On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <efiring@…229…> wrote:

Ryan May wrote:

Ok, here’s a patch that fixes the problem for me, as well as a test

script that tests a bunch of the color options along with having more,

the same, and less than the number of points passed in.

This is triggered by passing in a sequence of strings of the same length

as x, which matplotlib interprets as needing colormapping. Colormapping

an array of strings explodes nicely. I’ve fixed this issue by:

Make scatter() check if c is a sequence of strings. If it is, use

the colorConverter as expected.

This requires changing is_string_like() to recognize elements from

numpy string arrays (type numpy.string_) as strings. These elements are

actually instances of a subclass of python strings

(isinstance(, str is True), but fail because they have a shape

attribute (which is explicitly checked).

Changing colorConverter.to_rgba_array() to accept a 1D numpy array

containing strings. Currently, there is an explicit check for a 2D

array, and if it is not, and exception is thrown.

Since this is my first mucking around in internals with which I am not

familiar, I’d like someone to double check me. It’s only a 3 line diff,

but each line is in a different file, so it’s got a pretty wide (though

thin) footprint.

Ryan,

Here is a modification of your patch that I think will be very slightly more efficient and general.

–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Eric_Firing2 · November 11, 2008, 6:55am

Ryan May wrote:

    Ryan May wrote:

        Ok, here's a patch that fixes the problem for me, as well as a test
        script that tests a bunch of the color options along with having
        more,
        the same, and less than the number of points passed in.

        This is triggered by passing in a sequence of strings of the
        same length
        as x, which matplotlib interprets as needing colormapping.
         Colormapping
        an array of strings explodes nicely. I've fixed this issue by:

        1) Make scatter() check if c is a sequence of strings. If it
        is, use
        the colorConverter as expected.

        2) This requires changing is_string_like() to recognize elements
        from
        numpy string arrays (type numpy.string_) as strings. These
        elements are
        actually instances of a subclass of python strings
        (isinstance(<element>, str is True), but fail because they have
        a shape
        attribute (which is explicitly checked).

        3) Changing colorConverter.to_rgba_array() to accept a 1D numpy
        array
        containing strings. Currently, there is an explicit check for a 2D
        array, and if it is not, and exception is thrown.

        Since this is my first mucking around in internals with which I
        am not
        familiar, I'd like someone to double check me. It's only a 3
        line diff,
        but each line is in a different file, so it's got a pretty wide
        (though
        thin) footprint.

    Ryan,

    Here is a modification of your patch that I think will be very
    slightly more efficient and general.

Thanks. That does look a lot more clean. It would have helped if I had known about dtype.kind for ease of testing for arrays of strings and numpy string scalars.

Anyone else?

Ryan,

I hope you don't mind--I took care of the "FIXME" that I had put in, and committed the whole thing. Your test passes, and the backend_driver.py seems happy, so it should be OK.

Eric

···

On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <efiring@…229… > <mailto:efiring@…229…>> wrote:

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

_Ryan_May · November 11, 2008, 2:59pm

Eric Firing wrote:

Ryan,

I hope you don't mind--I took care of the "FIXME" that I had put in, and
committed the whole thing. Your test passes, and the backend_driver.py
seems happy, so it should be OK.

You have stolen my glory! Actually, I was thinking at this point it
was more your patch anyways, and I had just done the work of tracking
down all the problem spots. Saves me the effort of doing the checkin.

Ryan

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma