matplotlib-devel Mailing List for matplotlib

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

> 
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Version: matplotlib 0.98.3

I get no markers inside of the figure legend (using figlegend).  Using "legend" shows the markers.

Try the following:

from pylab import *
lines = plot([1, 2, 3, 4], [2, 4, 7, 8], 'ro')
legend(lines, ["foo"])
figlegend(lines, ["foo"], "upper right")
show()

If I use 'r-' for the marker instead of 'ro', the figlegend() output matches the legend() output.

I believe this worked okay in version 0.82.

Great package.  Thanks to the developers.

Rick

p.s. I did not file a bug on this.  I would guess one may already exist, but a quick query of the mailing lists did not show anything that was obviously a similar posting.

Note that the weight argument was added to histogram in Numpy 1.1.

David

2008/10/29 Olle Engdegård <ol...@fy...>

>
> Hi,
>
> I attach a trivial patch to pass a weight argument through hist() to
> histogram().
>
> Cheers,
> Olle
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Mon, Nov 10, 2008 at 1:59 PM, Ryan May <rm...@gm...> wrote:

>> I am not even sure if the above is the fix we want, but having numpy
>> string array elements fail "is_string_like" seems like a fundamentally
>> bad thing.

we definitely want numpy strings, eg in a record array, to return True here.

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

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

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

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

Eric Firing wrote:
> The fix is:
> 
> def is_string_like(obj):
>     """
>     Return True if *obj* looks like a string
> 
>     Such objects should include Python strings, unicode
>     strings, and numpy string array scalars.
>     """
>     #if hasattr(obj, 'shape'): return 0
>     # I think the above is a legacy of Numeric...
>     try:
>         if str(obj) + '' == obj:
>             return True
>     except (TypeError, ValueError):
>         return False
>     return True
> 
> I am not even sure if the above is the fix we want, but having numpy
> string array elements fail "is_string_like" seems like a fundamentally
> bad thing.

I agree.  It's even more egregious when you consider that:

>>>s = numpy.string_('Foo')
>>>isinstance(s, str)
True

I think a nicer workaround at the moment might be to just see if the
passed in object *is* indeed a string instance, and if so, return True.
 I can't imagine that breaking anything.  Figuring out why font
dictionary handling breaks would be good to do however.

Ryan

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

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 wrote:
> Eric Firing wrote:
>> ry...@us... wrote:
>>> Revision: 6385
>>>           http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
>>> Author:   ryanmay
>>> Date:     2008-11-10 18:59:18 +0000 (Mon, 10 Nov 2008)
>>>
>>> Log Message:
>>> -----------
>>> Make iterable() and is_string_like() return True/False instead of 1/0.
>> Agreed--good cleanup.
>>
>> A larger problem is that if you index out an element from a numpy array 
>> of strings, it is a numpy string array scalar, and it is not recognized 
>>   by is_string_like.  I have a fix for that (not committed), but it 
>> causes breakage elsewhere.  All this is an example of the perils of 
>> duck-typing; it has its advantages, but also its pitfalls.
> 
> What's your fix, and, more importantly, what breakage does it cause?
> I've added a fix locally to just check to see if the string is an
> instance of np.string_.  It works, along with a few other things, to fix
> the scatter() problem.  I was just getting ready to start running this
> stuff by the list...

The fix is:

def is_string_like(obj):
     """
     Return True if *obj* looks like a string

     Such objects should include Python strings, unicode
     strings, and numpy string array scalars.
     """
     #if hasattr(obj, 'shape'): return 0
     # I think the above is a legacy of Numeric...
     try:
         if str(obj) + '' == obj:
             return True
     except (TypeError, ValueError):
         return False
     return True

I am not even sure if the above is the fix we want, but having numpy 
string array elements fail "is_string_like" seems like a fundamentally 
bad thing.

Breakage is in font dictionary handling.

I don't have the whole problem solved, and I need to move on to other 
things right now.

Eric

> 
> Ryan
> 

Eric Firing wrote:
> ry...@us... wrote:
>> Revision: 6385
>>           http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
>> Author:   ryanmay
>> Date:     2008-11-10 18:59:18 +0000 (Mon, 10 Nov 2008)
>>
>> Log Message:
>> -----------
>> Make iterable() and is_string_like() return True/False instead of 1/0.
> 
> Agreed--good cleanup.
> 
> A larger problem is that if you index out an element from a numpy array 
> of strings, it is a numpy string array scalar, and it is not recognized 
>   by is_string_like.  I have a fix for that (not committed), but it 
> causes breakage elsewhere.  All this is an example of the perils of 
> duck-typing; it has its advantages, but also its pitfalls.

What's your fix, and, more importantly, what breakage does it cause?
I've added a fix locally to just check to see if the string is an
instance of np.string_.  It works, along with a few other things, to fix
the scatter() problem.  I was just getting ready to start running this
stuff by the list...

Ryan

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

ry...@us... wrote:
> Revision: 6385
>           http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
> Author:   ryanmay
> Date:     2008-11-10 18:59:18 +0000 (Mon, 10 Nov 2008)
> 
> Log Message:
> -----------
> Make iterable() and is_string_like() return True/False instead of 1/0.

Agreed--good cleanup.

A larger problem is that if you index out an element from a numpy array 
of strings, it is a numpy string array scalar, and it is not recognized 
  by is_string_like.  I have a fix for that (not committed), but it 
causes breakage elsewhere.  All this is an example of the perils of 
duck-typing; it has its advantages, but also its pitfalls.

Eric

> 
> Modified Paths:
> --------------
>     trunk/matplotlib/lib/matplotlib/cbook.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/cbook.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/cbook.py	2008-11-09 14:11:16 UTC (rev 6384)
> +++ trunk/matplotlib/lib/matplotlib/cbook.py	2008-11-10 18:59:18 UTC (rev 6385)
> @@ -261,16 +261,16 @@
>  def iterable(obj):
>      'return true if *obj* is iterable'
>      try: len(obj)
> -    except: return 0
> -    return 1
> +    except: return False
> +    return True
>  
>  
>  def is_string_like(obj):
>      'return true if *obj* looks like a string'
> -    if hasattr(obj, 'shape'): return 0
> +    if hasattr(obj, 'shape'): return False
>      try: obj + ''
> -    except (TypeError, ValueError): return 0
> -    return 1
> +    except (TypeError, ValueError): return False
> +    return True
>  
>  def is_sequence_of_strings(obj):
>      """
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> 
> -------------------------------------------------------------------------
> 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-checkins mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins

Just a note -- my recent changes to the font cache were drastic enough 
that I changed the file name (a cheap form of versioning...).  It is now 
fontList.cache -- I was hoping that would avoid this, but apparently 
not... :(

Mike

John Hunter wrote:
> On Sat, Nov 8, 2008 at 5:53 PM, Jae-Joon Lee <lee...@gm...> wrote:
>   
>> Yes, the script also works for me.
>> It seems that the version on the web is picking up a wrong font file.
>>     
>
> I flushed my font caches and rebuilt and the text is looking OK now.
> It may be that some combination of old font caches with Michael's
> recent changes to the font finder caused some grief, so everyone
> working from svn may want to flush the cache.  Perhaps we should
> introduce version tagging on the caches, so these get flushed
> periodically on upgrades.
>
> I pushed the new docs up to the site - thanks for letting me know...
>
> Now I really better get back to the wife and kids :-)
>
>
> JDH
>
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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

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