Scatter behavior for color field

Development matplotlib-devel
1

Hi,

I’m trying to display a scatter plot in 3D, and it calls the 2D scatter plot, in axes.py. This method tests for validity of the color argument in line 3777 :

    if not is_string_like(c) and iterable(c) and len(c)==len(x):

        colors = None
    else:
        colors = ( colorConverter.to_rgba(c, alpha), )

The trick is that if c is a numpy array, it passes the test, and thus no color is selected. If I get rid of the test and use a Nx3 array, the plot is correctly displayed.

I suppose that we could make it :

    if not (is_string_like(c) or is_numlike(c)) and iterable(c) and len(c)==len(x):
        colors = None
    else:
        colors = ( colorConverter.to_rgba(c, alpha), )

?

I found a little error in a docstring, if this proposal is OK, I’ll send a diff patch to the list.

Matthieu

2

Matthieu Brucher wrote:

Hi,

I'm trying to display a scatter plot in 3D, and it calls the 2D scatter plot, in axes.py. This method tests for validity of the color argument in line 3777 :

        if not is_string_like(c) and iterable(c) and len(c)==len(x):
            colors = None
        else:
            colors = ( colorConverter.to_rgba(c, alpha), )

The trick is that if c is a numpy array, it passes the test, and thus no color is selected. If I get rid of the test and use a Nx3 array, the plot is correctly displayed.

I suppose that we could make it :

        if not (is_string_like(c) or is_numlike(c)) and iterable(c) and len(c)==len(x):
            colors = None
        else:
            colors = ( colorConverter.to_rgba(c, alpha), )

?

I don't quite understand: what kind of "c" are you passing in, what is the original code doing with it, and what should it do with it? (I find both the original and the suggested code hard to understand, which makes me think that neither is actually what we want.)

I think that what we want may be the following:

try:
     colors = colorConverter.to_rgba_list(c, alpha)
except TypeError:
     colors = None # generate colors later by applying a colormap to c

Part of what makes all this hard to understand is that in the None case, colors are generated from c far down in the code, out of sight of this initial processing. Hence the comment.

OK, now I see that what I proposed won't work until I rip out the long-deprecated float-as-grey option. Looks like a good time for me to do it.

Eric

···

I found a little error in a docstring, if this proposal is OK, I'll send a diff patch to the list.

Matthieu

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

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

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

3

I don’t quite understand: what kind of “c” are you passing in, what is

the original code doing with it, and what should it do with it? (I find
both the original and the suggested code hard to understand, which makes
me think that neither is actually what we want.)

c is a named argument of the scatter method for the colors, but it is modified to get the real “colors” argument.

I think that what we want may be the following:

try:
colors = colorConverter.to_rgba_list(c, alpha)
except TypeError:
colors = None # generate colors later by applying a colormap to c

Part of what makes all this hard to understand is that in the None case,

colors are generated from c far down in the code, out of sight of this
initial processing. Hence the comment.

OK, now I see that what I proposed won’t work until I rip out the
long-deprecated float-as-grey option. Looks like a good time for me to

do it.

Eric

If you say so :slight_smile:

Matthieu

4

Matthieu Brucher wrote:

    I don't quite understand: what kind of "c" are you passing in, what is
    the original code doing with it, and what should it do with it? (I find
    both the original and the suggested code hard to understand, which makes
    me think that neither is actually what we want.)

c is a named argument of the scatter method for the colors, but it is modified to get the real "colors" argument.

    I think that what we want may be the following:

    try:
         colors = colorConverter.to_rgba_list(c, alpha)
    except TypeError:
         colors = None # generate colors later by applying a colormap to c

    Part of what makes all this hard to understand is that in the None
    case,
    colors are generated from c far down in the code, out of sight of this
    initial processing. Hence the comment.

Now I don't think that the above is what we really want; see below.

    OK, now I see that what I proposed won't work until I rip out the
    long-deprecated float-as-grey option. Looks like a good time for me to
    do it.

This is done (with corresponding simplification of the code and improved error checking and reporting), and I have made slight changes to scatter, but there is still an ambiguity in scatter's argument handling. It was and is resolved in favor of treating the c argument as an array rather than an rgb or rgba sequence in any case where it could be either. (To be safe, if you want c to be an mpl color, use a string form of colorspec as specified in the scatter docstring.) I don't know whether this ambiguity, or possibly a bug in its resolution, was what prompted your original message. In any case, please try the svn version and see if it does what you want. If it does not, then please say exactly what c you are passing in to scatter, what scatter is doing, and what you think it should do instead. I never understood that from your previous messages.

Eric

5

This is done (with corresponding simplification of the code and improved
error checking and reporting), and I have made slight changes to

scatter, but there is still an ambiguity in scatter’s argument handling.
It was and is resolved in favor of treating the c argument as an array
rather than an rgb or rgba sequence in any case where it could be

either. (To be safe, if you want c to be an mpl color, use a string
form of colorspec as specified in the scatter docstring.) I don’t know
whether this ambiguity, or possibly a bug in its resolution, was what

prompted your original message. In any case, please try the svn version
and see if it does what you want. If it does not, then please say
exactly what c you are passing in to scatter, what scatter is doing, and

what you think it should do instead. I never understood that from your
previous messages.

Eric

Thanks for the update, I’ll try it tuesday from work, but I don’t think it will change anything. I’ll post some pictures/data if you want.

What I’m passing as argument for c is a numpy array of dimension (N, 3) with floats between 0 and 1. When I get rid of the check at line 3777, I can have a good scatter plot with the correct colors.

This is why I proposed to check that the argument was string like or num like, because my argument for c is not string-like.

One question that may arise is why do I use such colors and not mpl colors. The doc says that I can have color given by a tuple. In fact, the code can handle color in an array, and as the colors for each point in the scatter plot is generated by the coordinates of the point, the colors are stored in a numpy array. I do not want to transform them into strings or tuples if the code can handle numpy arrays. And it is more simple to officially allow the use of such color array for an average user.

I hope you understand my point a little better now :expressionless:

Matthieu

6

Matthieu Brucher wrote:

    This is done (with corresponding simplification of the code and improved
    error checking and reporting), and I have made slight changes to
    scatter, but there is still an ambiguity in scatter's argument handling.
      It was and is resolved in favor of treating the c argument as an array
    rather than an rgb or rgba sequence in any case where it could be
    either. (To be safe, if you want c to be an mpl color, use a string
    form of colorspec as specified in the scatter docstring.) I don't know
    whether this ambiguity, or possibly a bug in its resolution, was what
    prompted your original message. In any case, please try the svn version
    and see if it does what you want. If it does not, then please say
    exactly what c you are passing in to scatter, what scatter is doing,
    and
    what you think it should do instead. I never understood that from your
    previous messages.

    Eric

Thanks for the update, I'll try it tuesday from work, but I don't think it will change anything. I'll post some pictures/data if you want.
What I'm passing as argument for c is a numpy array of dimension (N, 3) with floats between 0 and 1. When I get rid of the check at line 3777, I can have a good scatter plot with the correct colors.

OK, I thought that might be the case. The behavior you want was not actually supported by scatter--at least it was contrary to the docstring--but it is reasonable, so I have made changes that I think will do what you want. I also changed the docstring to reflect this.

Eric

7

Thanks for the update, I’ll try it tuesday from work, but I don’t think

it will change anything. I’ll post some pictures/data if you want.
What I’m passing as argument for c is a numpy array of dimension (N, 3)
with floats between 0 and 1. When I get rid of the check at line 3777, I

can have a good scatter plot with the correct colors.

OK, I thought that might be the case. The behavior you want was not
actually supported by scatter–at least it was contrary to the
docstring–but it is reasonable, so I have made changes that I think

will do what you want. I also changed the docstring to reflect this.

Eric

Thanks a lot for the update, I appreciate the patience you had to understand what I wanted.

Matthieu