matplotlib-users Mailing List for matplotlib (Page 14)

In article <SNT...@ph...>,
 Stephen T. <obs...@ho...> 
 wrote:

> Hi, I am having trouble installing matplotlib. I have OS X 10.5 with Python 
> 2.6
>  downloaded and installed from python.org.
>  (10.5 came with Apple
>  Python 2.5). I've also installed NumPy and SciPy for Python 2.6.

I encourage you to try the matplotlib 1.0.0 binary installer. It was 
built to use the python.org Python (versions are available for Python 
2.5 and 2.6; the latter did have a known problem with permissions on the 
icon files; you can fix that manually or a new installer with that 
problem fixed should be up now or shortly).

Another option is to wade through the build instructions. I've got some 
here:
<http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
l>

-- Russell

I'm trying to learn how to make a fairly efficient strip chart display 
and have run into a few glitches:

The example strip_chart_demo.py is not annotated but does refer to a 
page <http://www.scipy.org/wikis/topical_software/Animations>
Unfortunately that page does not exist. I suspect the desired page is:
<http://www.scipy.org/Cookbook/Matplotlib/Animations>

However, that page has its own issues: all the links to code that I have 
tried are broken, e.g.:
anim.py = <http://matplotlib.sf.net/examples/anim.py>
anim_tk.py = <http://matplotlib.sf.net/examples/anim_tk.py>
etc.

That page also says at one point:
"For backends that support the new API (GTKAgg) set useblit=True:"
and
"As noted above, only the GTKAgg supports the methods above to to the 
animations of selected actors."

However, it earlier claims:
"As of matplotlib-0.87, GTKAgg, TkAgg, WXAgg, and FLTKAgg support the 
methods discussed here."

If the first two quotes are needlessly restrictive then it would help to 
list the supported backends once and refer back to that if necessary.

These are minor complains. Having found this page it looks pretty 
straightforward to do what I want (especially since my data rate is slow 
enough that I can skip the fancy bit blitting).

One question: it appears that there is no way to append new data to the 
Line2D and occasionally flush the oldest data; instead I have to copy 
all data for every update. Is this so, or am I missing something?

-- Russell

Hi Friedrich,Thanks again for your response. I've been away traveling (with no internet connection) and just returned... hope you can help me troubleshoot this last bit (hopefully last bit)!> This is important. I recently had a similar issue (sort of). I think> the macports library is 32-bit only, and I know that at least for> building Python the build performs 64-bit only by default (this was my> issue) on a 64bit system. Of course, in case you want to make a 64bit> build against a 32bit library the error would be sensible.> > To check this, try to run:> $ file /opt/local/lib/libxml2.2.dylib> > When I run it on the Apple supplied file it gives:> > /usr/lib/libxml2.dylib: Mach-O universal binary with 3 architectures> /usr/lib/libxml2.dylib (for architecture x86_64):	Mach-O 64-bit> dynamically linked shared library x86_64> /usr/lib/libxml2.dylib (for architecture i386):	Mach-O dynamically> linked shared library i386> /usr/lib/libxml2.dylib (for architecture ppc7400):	Mach-O dynamically> linked shared library ppcmine gives only:/opt/local/lib/libxml2.2.dylib: Mach-O dynamically linked shared library i386Is this the problem?Thanks so much!Stephen
 		 	   		  

On 09:29 Sat 31.07.10, Friedrich Romstedt wrote:
> What you will want to use is .set_tick_params(top=True,
> labeltop=False, labelbottom=False)  .
That worked indeed but I have uncovered another problem.

It is about the positioning of the rotated labels.
The code is here:
http://paste.pocoo.org/show/246870/

Note that in line 36 I had already remarked about the hack I used. Now I
noticed that if the labels have different lengths rotating them gives
different positions. What I really want to do is rotate about the bottom
of the labels. Can that be done?

Regards
Simon

Hi,
Looking for a way to analyze a set of images I found waitforbuttonpress, which
basically does what I need: allows me to display a few plots/scatter/etc for as
long as I need; then when pressing a key move to the next image and redo all
plots/scatter/etc. 
Now my problem is that waitforbuttonpress (or the (mis)use I gave it) forces me
to close the ipython session frequently and start over again. This is at least
inconvenient, and a few times forced me to recalculate things that took some
time (and that I had forgot to save). 
I know this might be backend-related. I use GTKAgg, on ubuntu 10.04, mpl-1.0.0
(locally built). Below you'll find a script I created where I see this behavior,
the ipython console's output, and the steps I followed.

Steps followed and description:
1- Run script, click mouse a few times (plot is closed and redrawn), finally
press a key. The plot is closed, and the console returns to be active. This
corresponds to "In [1]" in the ipython console's output
2- Trying to run anything at the ipython console results in a looong delay and a
message like in "In [2]" at the console. The console works fine after this,
though, at least with non matplotlib-related stuff
3- Running the script again results in the output shown in "In [3]". The script
seems to runs fine, i.e. clicks cause the redrawing of the plot, though pressing
any key (which should break the loop and end the script) will end the script but
won't close the plot windows. The console works mostly ok, the only way to close
the plot window and ipython is by killing the ipython process.
4- In some other cases, I ended up with an unresponsive console that required
killing the ipython process as well.
This test case is not comprehensive of the things I've experienced, but it might
show a possible cause of this behavior.

Regards,

Jorge

------------------------
Ipython console's output:

In [1]: run doct/intrinsic-images/test_waitforbuttonpress.py
/home/jscandal/lib/python2.6/site-packages/matplotlib/backend_bases.py:2051:
DeprecationWarning: Using default event loop until function specific to this GUI
is implemented
  warnings.warn(str,DeprecationWarning)

In [2]: run doct/intrinsic-images/test_waitforbuttonpress.py
Warning: Timeout for mainloop thread exceeded
switching to nonthreaded mode (until mainloop wakes up again)

In [3]: run doct/intrinsic-images/test_waitforbuttonpress.py
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/usr/lib/pymodules/python2.6/IPython/Shell.pyc in on_timer(self)
    847 
    848         update_tk(self.tk)
--> 849         self.IP.runcode()
    850         time.sleep(0.01)
    851         return True

/usr/lib/pymodules/python2.6/IPython/Shell.pyc in runcode(self)
    455         # code modifies it, we restore our own handling.

    456         try:
--> 457             signal(SIGINT,sigint_handler)
    458         except SystemError:
    459             # This happens under Windows, which seems to have all sorts


ValueError: signal only works in main thread
-------------------------
 
script used in the test:
------------------------
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt

data = np.random.rand(10,2)

while True:
    fig, ax = plt.subplots(1,1)
    ax.scatter(data.T[0], data.T[1])
    plt.show()
    if fig.waitforbuttonpress(timeout=-1):
	plt.close('all')
	break
    plt.close('all')

Jae-Joon Lee <lee.j.joon@...> writes:

<snip>
> In recent versions, there is a separate parameter : scatterpoints. So
> check your document.
> 
>  ax.legend(sc, labels, scatterpoints=1)
> 
> Regards,
> 
> -JJ

Great! It works fine with 1.0.0

Jorge

On Thu, Aug 5, 2010 at 4:48 PM, Jorge Scandaliaris
<jor...@ya...> wrote:
> BTW, I think I've found another thing
> related to legend() and scatter plots: the 'numpoints' keyword argument to
> legend is not respected, as showed in the example pasted below,
>
> Jorge

In recent versions, there is a separate parameter : scatterpoints. So
check your document.

 ax.legend(sc, labels, scatterpoints=1)

Regards,

-JJ

On Thu, Aug 5, 2010 at 2:48 AM, Jorge Scandaliaris
<jor...@ya...>wrote:

> Benjamin Root <ben.root@...> writes:
> >
> <snip>
> > Probably not directly, but I hadn't thought about that before.  For a set
> of
> > scatter points that are colored by values, what should the legend show?
> In
> > other words, what does it *mean* for there to be a legend for points that
> are
> > colored in a potentially non-uniform manner?So, maybe this is desired
> behavior
> > (but possibly by accident)?
> > Thanks for your help,
> > Ben Root
>
> I thought for a moment that legend was using the color of the first point
> in the
> set, but a quick test reveals that no matter what colormap you specify, the
> marker color inside the legend is blue. BTW, I think I've found another
> thing
> related to legend() and scatter plots: the 'numpoints' keyword argument to
> legend is not respected, as showed in the example pasted below,
>
> Jorge
>
> -------
> import numpy as np
> import matplotlib as mpl
> import matplotlib.pyplot as plt
>
> data0 = np.random.rand(10,2)
> data1 = np.random.rand(10,2)
> data2 = np.random.rand(10,2)
> data = [data0, data1, data2]
>
> fig, ax = plt.subplots(1,1)
> norm = mpl.colors.Normalize(0,len(data))
> cmap = mpl.cm.afmhot
>
> sc = []
> labels = []
> for i,d in enumerate(data):
>     sc.append(ax.scatter(d.T[0], d.T[1], c=np.ones(d.shape[0])*i,
>            norm=norm, cmap=cmap))
>    labels.append('data set ' + str(i))
> ax.legend(sc, labels, numpoints=1)
> plt.show()
> -------
>
>
Yes, this was found a little while back and I believe it was fixed for v1.0.

Ben Root

It looks like you're configured for the STIX fonts (the rcParam 
mathtext.fontset = stix), but they are not installed on your system.

Do you have the file "STIXGeneral.ttf" on your system?  Perhaps you need 
to install an additional package.

Mike

On 08/04/2010 03:18 PM, Michael Hannon wrote:
>> Which backend are you using?
>>
>> Can you set the  rcParam "verbose.level" to "debug-annoying" and then
>> send us the output  produced when running a plot?  This will include a
>> number of lines  about font lookup that may help us diagnose the problem.
>>      
>
> Hi, Mike.  I'm currently doing this interactively on a Gnome, X-windows desktop.
>
> The default backend for this is evidently:
>
>      TkAgg
>
> I've appended the debug-annoying output, but it may be, as Ben Root has
> observed,
> that I just need a newer version of matplotlib.
>
> Thanks for your help.
>
> -- Mike
>
>
>
>
>
> backend TkAgg version 8.5
>    
>>>> figure()
>>>>          
> <matplotlib.figure.Figure object at 0x18e6bd0>
>    
>>>> text(0.5, 0.5, r'$\pi$')
>>>>          
> <matplotlib.text.Text object at 0x1a1dbd0>
>    
>>>> show()
>>>>          
> FigureCanvasAgg.draw
> RendererAgg.__init__
> RendererAgg.__init__ width=650.0, height=490.0
> RendererAgg.__init__ _RendererAgg done
> RendererAgg.__init__ done
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> findfont: Matching
> :family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=medium
>   to DejaVu Sans (/usr/share/fonts/dejavu/DejaVuSans.ttf) with score of 0.100000
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg.points_to_pixels
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> RendererAgg.draw_text
> RendererAgg._get_agg_font
> RendererAgg._get_agg_font
> findfont: Matching
> :family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0
>   to DejaVu Sans (/usr/share/fonts/dejavu/DejaVuSans.ttf) with score of 0.100000
> findfont: Matching
> :family=STIXGeneral:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0
>   to STIXGeneral (/usr/share/fonts/stix/STIXGeneral.otf) with score of 0.000000
> findfont: Could not match
> :family=STIXSize1:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Matching
> :family=STIXGeneral:style=normal:variant=normal:weight=bold:stretch=normal:size=12.0
>   to STIXGeneral (/usr/share/fonts/stix/STIXGeneralBol.otf) with score of
> 0.000000
> findfont: Could not match
> :family=STIXSize3:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=STIXSize4:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=STIXSize5:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=STIXSize2:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Matching
> :family=STIXGeneral:style=italic:variant=normal:weight=normal:stretch=normal:size=12.0
>   to STIXGeneral (/usr/share/fonts/stix/STIXGeneralItalic.otf) with score of
> 0.000000
> findfont: Could not match
> :family=STIXNonUnicode:style=italic:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=STIXNonUnicode:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=STIXNonUnicode:style=normal:variant=normal:weight=bold:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=cmb10:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=cmtt10:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=cmmi10:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=cmex10:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=cmsy10:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=cmr10:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> findfont: Could not match
> :family=cmss10:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
>   Returning /usr/share/fonts/un-core/UnDotum.ttf
> RendererAgg.draw_text
> RendererAgg.draw_mathtext
>    
>>>>          
>
>
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Benjamin Root <ben.root@...> writes:
> 
<snip>
> Probably not directly, but I hadn't thought about that before.  For a set of 
> scatter points that are colored by values, what should the legend show?  In 
> other words, what does it *mean* for there to be a legend for points that are 
> colored in a potentially non-uniform manner?So, maybe this is desired behavior 
> (but possibly by accident)?
> Thanks for your help,
> Ben Root

I thought for a moment that legend was using the color of the first point in the
set, but a quick test reveals that no matter what colormap you specify, the
marker color inside the legend is blue. BTW, I think I've found another thing
related to legend() and scatter plots: the 'numpoints' keyword argument to
legend is not respected, as showed in the example pasted below,

Jorge

-------
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt

data0 = np.random.rand(10,2)
data1 = np.random.rand(10,2)
data2 = np.random.rand(10,2)
data = [data0, data1, data2]

fig, ax = plt.subplots(1,1)
norm = mpl.colors.Normalize(0,len(data))
cmap = mpl.cm.afmhot

sc = []
labels = []
for i,d in enumerate(data):
    sc.append(ax.scatter(d.T[0], d.T[1], c=np.ones(d.shape[0])*i,
            norm=norm, cmap=cmap))
    labels.append('data set ' + str(i))
ax.legend(sc, labels, numpoints=1)
plt.show()
-------

On Wed, Aug 4, 2010 at 8:05 PM, Michael Hannon <jm_...@ya...> wrote:

> > Wow, I hadn't realized that Fedora 13 is carrying a rather old version of
> > matplotlib (~2 years old).  I should double-check what version is in
> rawhide
> > and possibly prod some people to get them to choose a more recent
> version...
>
> Hi, Ben.  I think it would be a good idea to give the Fedora people some
> feedback on this.  I thought that one of the main points of Fedora was to
> explore bleeding-edge software.
>
>
Maybe, way in the future there will be source-based custom Fedora builds
where all the OS code and the packages will be build from their repositories
according to one's need. For the time being I like following these three
easy steps on my FC12 for the latest matplotlib:

svn co
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlibmatplotlib
python setupegg.py develop (one time only)

svn up

It's good to see some other fellow Fedora users around in these lists. It
will somewhat off-the-topic but what are your impressions of Python and FC13
combination?


>
> > I am not exactly sure what the cause of your problem is, but you could
> try
> > uninstalling the Fedora packages of matplotlib and install the latest
> > version from source.  Unless someone else has a better idea about what
> the
> > cause of the problem is?
>
> I'm usually reluctant to do this, as the packages installed from source
> don't
> automatically get security updates, etc., but I tried your suggestion and
> found the exercise painless.  And with the new version I DO get math
> symbols
> on my plots.
>
> Thanks for your help with this.
>
> -- Mike
>
>
> For the mathtext problem for inclusion of simple math texts you could
easily construct your formulas or units using unicode text. Adding # -*-
coding: utf-8 -*- on top of your scripts and then: plt.ylabel(u"π") will do
the trick.


>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>


-- 
Gökhan

> Wow, I hadn't realized that Fedora 13 is carrying a rather old version of
> matplotlib (~2 years old).  I should double-check what version is in rawhide
> and possibly prod some people to get them to choose a more recent version...
 
Hi, Ben.  I think it would be a good idea to give the Fedora people some
feedback on this.  I thought that one of the main points of Fedora was to
explore bleeding-edge software.

> I am not exactly sure what the cause of your problem is, but you could try
> uninstalling the Fedora packages of matplotlib and install the latest
> version from source.  Unless someone else has a better idea about what the
> cause of the problem is?

I'm usually reluctant to do this, as the packages installed from source don't
automatically get security updates, etc., but I tried your suggestion and
found the exercise painless.  And with the new version I DO get math symbols
on my plots.

Thanks for your help with this.

-- Mike


      

ׁHi,
Sorry for the late reply.
Yes the solution suggested in reply to my bug report was indeed helpful !

Thanks for the help !

Oz

On Wed, Aug 4, 2010 at 5:01 PM, Benjamin Root <ben...@ou...> wrote:

> On Wed, Aug 4, 2010 at 12:26 AM, Oz Nahum <na...@gm...> wrote:
>
>> Hi Everyone  !
>> This is urgent, I have to finish some plots by tomorrow, and I totally
>> lost the ability to work with python matplotlib -
>> "import pylab"
>> "from pylab import *"
>>
>> all yield the following error:
>>
>> [code]Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "/usr/lib/pymodules/python2.6/pylab.py", line 1, in <module>
>>     from matplotlib.pylab import *
>>   File "/usr/lib/pymodules/python2.6/matplotlib/pylab.py", line 206, in
>> <module>
>>     from matplotlib import mpl  # pulls in most modules
>>   File "/usr/lib/pymodules/python2.6/matplotlib/mpl.py", line 3, in
>> <module>
>>     from matplotlib import axes
>>   File "/usr/lib/pymodules/python2.6/matplotlib/axes.py", line 17, in
>> <module>
>>     import matplotlib.dates as mdates
>>   File "/usr/lib/pymodules/python2.6/matplotlib/dates.py", line 87, in
>> <module>
>>     import pytz
>>   File "/usr/lib/python2.6/dist-packages/pytz/__init__.py", line 32, in
>> <module>
>>     from pkg_resources import resource_stream
>> ValueError: bad marshal data
>> [/code]
>>
>>
>> I am using python-matplotlib on Debian Squeeze.
>>
>> Any help would be appreciated !
>> Thanks,
>>
>>
> Oz,
>
> I see you have filed a bug with the Debian people and have gotten a
> response.  Did their suggestion help you?
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591606
>
> Ben Root
>



-- 
Oz Nahum
Graduate Student
Zentrum für Angewandte Geologie
Universität Tübingen

---

Imagine there's no countries
it isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace

On Wed, Aug 4, 2010 at 3:52 PM, Jorge Scandaliaris
<jor...@ya...>wrote:

> Benjamin Root <ben.root@...> writes:
>
> <snip>
> >
> > Yes, please do, and then mention which bug report you filed to this
> thread.
> Ben Root
>
> Done. Bug number is 3039678
>
> Could this behavior be due to the fact that scatter() accepts sequences for
> setting the color of each point individually? Maybe I am way off, but who
> knows...
>
> Jorge
>
>
>
Probably not directly, but I hadn't thought about that before.  For a set of
scatter points that are colored by values, what should the legend show?  In
other words, what does it *mean* for there to be a legend for points that
are colored in a potentially non-uniform manner?

So, maybe this is desired behavior (but possibly by accident)?

Thanks for your help,
Ben Root

Benjamin Root <ben.root@...> writes:

<snip>
> 
> Yes, please do, and then mention which bug report you filed to this thread.
Ben Root

Done. Bug number is 3039678 

Could this behavior be due to the fact that scatter() accepts sequences for
setting the color of each point individually? Maybe I am way off, but who 
knows...

Jorge

On Wed, Aug 4, 2010 at 3:01 PM, Jorge Scandaliaris
<jor...@ya...>wrote:

> Benjamin Root <ben.root@...> writes:
>
> <snip>
> > Hmm, this definitely looks like a bug.
>
> Should I fill a bug report about this?
>
> Jorge
>
>
Yes, please do, and then mention which bug report you filed to this thread.

Ben Root

Benjamin Root <ben.root@...> writes:

<snip>
> Hmm, this definitely looks like a bug. 

Should I fill a bug report about this?

Jorge

Benjamin Root <ben.root@...> writes:

<snip>
> Hmm, this definitely looks like a bug.  If I explicitly state what color I want
> using the "color" keyword instead of using 'c' and 'norm', then everything
> works properly.

I can't tell if this is a bug or not, but the trick of using a color directly is
an even simpler workaround than the one I used. Thanks.

Jorge

On 08/04/2010 06:19 AM, John Hunter wrote:
> On Wed, Aug 4, 2010 at 11:07 AM, Tommy Grav<tg...@ma...>  wrote:
>> A rather simple question, but I could not find the
>> answer while rummaging around on the matplotlib
>> webpages. Is there a way to increase the size of
>> the tick label sizes from say fontsize 9 to 12?
>
> for label in ax.get_xticklabels() + ax.get_yticklabels():
>      labe.set_fontsize(12)
>
> You may want to take a look at the artist tutorial, which gives an
> overview of all the objects in the matplotlib figure, how to get at
> them and modify them, etc.
>
> http://matplotlib.sourceforge.net/users/artists.html
>
> JDH

Also, if you are running mpl 1.0, you can use the tick_params Axes 
method or pyplot function. E.g.,

ax.tick_params(labelsize=12)

Eric

So I switched to axes_grid1 and got things working.  Thanks.
-- 

R. Padraic Springuel
Research Assistant
Department of Physics and Astronomy
University of Maine
Bennett 309
Office Hours: By Appointment Only

>> Is there a cleaner way to do this?
>
> Use a LineCollection:
>
> http://matplotlib.sourceforge.net/search.html?q=codex+linecollection
>
> JDH

Exactly what I was looking for. Thank you.

/Ulf Larsson
 		 	   		  

On Wed, Aug 4, 2010 at 11:07 AM, Tommy Grav <tg...@ma...> wrote:
> A rather simple question, but I could not find the
> answer while rummaging around on the matplotlib
> webpages. Is there a way to increase the size of
> the tick label sizes from say fontsize 9 to 12?

for label in ax.get_xticklabels() + ax.get_yticklabels():
    labe.set_fontsize(12)

You may want to take a look at the artist tutorial, which gives an
overview of all the objects in the matplotlib figure, how to get at
them and modify them, etc.

http://matplotlib.sourceforge.net/users/artists.html

JDH

A rather simple question, but I could not find the
answer while rummaging around on the matplotlib
webpages. Is there a way to increase the size of
the tick label sizes from say fontsize 9 to 12?

Tommy

On Wed, Aug 4, 2010 at 10:00 AM, Jorge Scandaliaris
<jor...@ya...>wrote:

> Jorge Scandaliaris <jorgesmbox-ml@...> writes:
> >
> > Hi,
> > I am adding several scatter plots to the same axis, each having a
> specific
> > color. When I call legend on the axis it correctly picks all scatter
> plots with
> > their symbols and labels, but it doesn't pick up the color. The example
> below
> > demonstrates this. What I would like to do is to have in the legend the
> marker
> > its color matching that of the set it represents. How would I do this?
>
> Answering my own question, I found a way to achieve what I wanted by using
> a
> proxy artist as suggested in this thread:
>
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20995/focus=20999
>
> Maybe there's a better approach. I certainly would love legend to pick up
> on the
> color used in the scatter plot by its own.
>
> Jorge
>
>
>
Hmm, this definitely looks like a bug.  If I explicitly state what color I
want using the "color" keyword instead of using 'c' and 'norm', then
everything works properly.

Digging through the code, 'color' gets used right after the creation of the
collection object by calling the .update() function, which in turn calls the
.set_color() function which calls the set_facecolor() and set_edgecolor()
functions.  However, when using 'c' and 'norm', and having 'c' contain an
array that is the same length as the data, causes colors to be set to None
during the creation of the polygon collection.  After the collection
creation, set_array(), set_cmap() and set_norm() are called, which allows
for the scatter graph to be colored correctly upon draw.

However, I suspect that when the legend is being created, the legend uses
whatever the face/edge color that was set for the collection, which probably
isn't set yet and won't be until a draw is performed.

Ben Root

On Wed, Aug 4, 2010 at 9:42 AM, Ulf Larsson <ulf...@ho...> wrote:
>
>
> Hi,
>
> I have some performance problems when plotting several lines and would
> appreciate some comments. My application plots lots of lines (~5000)
> of different sizes. The performance bottleneck lies in the following
> code snippet:
>
> for s in data.layout.segment:
>    x = []
>    y = []
>    for p in s.part:
>        for px, py in p.curve_points():
>            x.append(px)
>            y.append(py)
>    axes.plot(x, y, 'g', label = '_nolegend_')
>
> Profiling showed that half of the time was spent in parsing the plot
> arguments and most of the other half was spent in
> Axes._set_artist_props.
>
> I could speed up the application by using Line2D and
> Axes.add_lines. But the only way to come around the time spent in
> Axes._set_artist_props that I could come up with is this ugly hack
> where I only call Axes.add_line for the first line and after that use
> copies that are added directly to Axes.lines.
>
> org_line = None
> for s in data.layout.segment:
>    x = []
>    y = []
>    for p in s.part:
>        for px, py in p.curve_points():
>            x.append(px)
>            y.append(py)
>    if not org_line:
>        org_line = matplotlib.lines.Line2D(numpy.array(x), numpy.array(y),
>                                           color='green', label = '_nolegend_')
>        axis.add_line(org_line)
>    else:
>        line = copy.copy(org_line)
>        line.set_xdata(numpy.array(x))
>        line.set_ydata(numpy.array(y))
>        axis.lines.append(line)
>
> Is there a cleaner way to do this?

Use a LineCollection:

http://matplotlib.sourceforge.net/search.html?q=codex+linecollection

JDH