matplotlib-users Mailing List for matplotlib

In article <row...@ne...>,
 "Russell E. Owen" <ro...@uw...> wrote:

> I am trying to make a legend for a stacked histogram using matplotlib 
> 1.0.1 and it's not working.
> 
> Here's what I've tried so far:
> 
>     count, bins, ignored = pyplot.hist(
>         (matchedStarPsfMags, unmatchedRefStarPsfMags,
>           unmatchedSourcePsfMags),
>         bins=30, histtype='barstacked', normed=True)
>     pyplot.legend(("matched stars", "unmatched stars", \
>       "false detections"), loc='upper left')
> 
> This produces a nice stacked histogram with red, green and blue. 
> Unfortunately the legend is blue for all three entries, so the legend is 
> useless!
> 
> I figured I could label the data instead. The documentation for hist 
> says:
> label:
> String, or sequence of strings to match multiple datasets. Bar charts 
> yield multiple patches per dataset, but only the first gets the label, 
> so that the legend command will work as expected:
> 
> That last sentence sounded really ominous in this context, but I figured 
> I would try it anyway. Unfortunately this code fails:
> 
>     count, bins, ignored = pyplot.hist(
>         (matchedStarPsfMags, unmatchedRefStarPsfMags,
>            unmatchedSourcePsfMags),
>         label = ("matched stars", "unmatched stars",
>             "false detections"),
>         bins=30, histtype='barstacked', normed=True)
>     pyplot.legend(loc='upper left')
> 
> with this error:
> 
> Traceback (most recent call last):
>   File "bin/measDepth.py", line 291, in <module>
>     pyplot.legend(loc='upper left')
>   File 
> "/lsst/DC3/stacks/gcc443/15oct2010/Linux64/external/matplotlib/0.98.5.2+1
> /lib/python/matplotlib/pyplot.py", line 2441, in legend
>     ret =  gca().legend(*args, **kwargs)
>   File 
> "/lsst/DC3/stacks/gcc443/15oct2010/Linux64/external/matplotlib/0.98.5.2+1
> /lib/python/matplotlib/axes.py", line 3777, in legend
>     label != '' and not label.startswith('_')):
> AttributeError: 'tuple' object has no attribute 'startswith'
> 
> In other words the documentation appears to be incorrect that a sequence 
> of strings is acceptable.
> 
> Any suggestions?

Oops. I was able to answer my own question.

It turns out I was using an ancient version of matplotlib (0.98.5.2) (I 
was using a remote server and forgot to check).

The second version does work with matplotlib 1.0.1 and produces a nice 
legend with the correct color for each entry. Yaay!

The first version produces a useless legend with all colors the same on 
both modern matplotlib and the ancient matplotlib. So use the second 
method of specifying label=(...) in the hist command.

-- Russell

I am trying to make a legend for a stacked histogram using matplotlib 
1.0.1 and it's not working.

Here's what I've tried so far:

    count, bins, ignored = pyplot.hist(
        (matchedStarPsfMags, unmatchedRefStarPsfMags,
          unmatchedSourcePsfMags),
        bins=30, histtype='barstacked', normed=True)
    pyplot.legend(("matched stars", "unmatched stars", \
      "false detections"), loc='upper left')

This produces a nice stacked histogram with red, green and blue. 
Unfortunately the legend is blue for all three entries, so the legend is 
useless!

I figured I could label the data instead. The documentation for hist 
says:
label:
String, or sequence of strings to match multiple datasets. Bar charts 
yield multiple patches per dataset, but only the first gets the label, 
so that the legend command will work as expected:

That last sentence sounded really ominous in this context, but I figured 
I would try it anyway. Unfortunately this code fails:

    count, bins, ignored = pyplot.hist(
        (matchedStarPsfMags, unmatchedRefStarPsfMags,
           unmatchedSourcePsfMags),
        label = ("matched stars", "unmatched stars",
            "false detections"),
        bins=30, histtype='barstacked', normed=True)
    pyplot.legend(loc='upper left')

with this error:

Traceback (most recent call last):
  File "bin/measDepth.py", line 291, in <module>
    pyplot.legend(loc='upper left')
  File 
"/lsst/DC3/stacks/gcc443/15oct2010/Linux64/external/matplotlib/0.98.5.2+1
/lib/python/matplotlib/pyplot.py", line 2441, in legend
    ret =  gca().legend(*args, **kwargs)
  File 
"/lsst/DC3/stacks/gcc443/15oct2010/Linux64/external/matplotlib/0.98.5.2+1
/lib/python/matplotlib/axes.py", line 3777, in legend
    label != '' and not label.startswith('_')):
AttributeError: 'tuple' object has no attribute 'startswith'

In other words the documentation appears to be incorrect that a sequence 
of strings is acceptable.

Any suggestions?

-- Russell

Thanks, please check the git-hub issue.

On Thu, Jun 30, 2011 at 8:37 AM, Darren Dale <dsd...@gm...> wrote:

> > Hi,
> > I had problems to build the version 1.0.1-r1 in gentoo with
> linux-3.0.0-rcX.
> > As chromium, the matplotlib need fix the use of 'linux2' label. See
> chromium
> > thread:
> > http://code.google.com/p/chromium/issues/detail?id=85845
> > Is very simple fix. If you want, i can send one patch.
>
> Thank you. I've filed an issue at github and identified it as needing
> to be fixed in the next release. If you could submit a patch, that
> would be helpful.
>
> Darren
>



-- 
Tiago Rezende Campos Falcão
http://www.tiagofalcao.com
--
ProFUSION | embedded systems
Computer Systems Laboratory - IC - Unicamp
Grupo Pró Software Livre - Unicamp
Laboratory of Information Systems - IC - Unicamp

On 06/30/2011 01:10 PM, Michael Droettboom wrote:
> I'm surprised this bug (which really lies in Tkinter) isn't more widely
> known -- searching the Python bug tracker revealed nothing.  It would be
> great to follow-up there (with a standalone Tkinter-crashing example) if
> you're so inclined.
I did find this bug, which seems to be related.

http://bugs.python.org/issue10647

Mike

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

On 06/30/2011 01:10 PM, Michael Droettboom wrote:
> I'm surprised this bug (which really lies in Tkinter) isn't more widely
> known -- searching the Python bug tracker revealed nothing.  It would be
> great to follow-up there (with a standalone Tkinter-crashing example) if
> you're so inclined.
I did find this bug, which seems to be related.

Mike

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

Thanks for the report.  Indeed this is a problem.  I've filed a pull 
request with a fix here:

https://github.com/matplotlib/matplotlib/pull/387

There were a few other places where we weren't absolutely ensuring the 
passing of ints to Tkinter that I also fixed.

I'm surprised this bug (which really lies in Tkinter) isn't more widely 
known -- searching the Python bug tracker revealed nothing.  It would be 
great to follow-up there (with a standalone Tkinter-crashing example) if 
you're so inclined.

Cheers,
Mike

On 06/30/2011 11:48 AM, han...@ar... wrote:
> Hi,
>
> sorry if this has already been addressed. I did a search on the archives, but even though that turned up lots of hits, none of them seemed to be related to the issue.
>
> The following very simple example will reliably crash in Python 2.7.[0-2] with matplotlib 1.0.1 under a 64 bit German Windows (and probably also on other machines where you can set an equivalent locale):
>
> ---
>
> import matplotlib
>
> from pylab import arange,sin,pi
> t = arange(0.0, 2.0, 0.01)
> s = sin(2*pi*t)
>
> import locale
> # the locale setting in the next line makes pyplot.plot crash
> # have to use "deu_deu" instead of "de_DE" on German Windows
> locale.setlocale(locale.LC_ALL, 'deu_deu')
> print "locale =", locale.getlocale(locale.LC_NUMERIC)
>
> print "will plot ..."
> matplotlib.pyplot.plot(t, s, linewidth=1.0)
> # doesn't get this far with German locale
> print "will show ..."
> matplotlib.pyplot.show()
>
> ---
>
> The program crashes in pyplot.plot(). The stacktrace is:
>
> ---
>
> Traceback (most recent call last):
>    File "C:\[...]\badScreenSizeMPL.py", line 14, in<module>
>      matplotlib.pyplot.plot(t, s, linewidth=1.0)
>    File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 2279, in plot
>      ax = gca()
>    File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 593, in gca
>      ax =  gcf().gca(**kwargs)
>    File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 292, in gcf
>      return figure()
>    File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 270, in figure
>      **kwargs)
>    File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 82, in new_figure_manager
>      figManager = FigureManagerTkAgg(canvas, num, window)
>    File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 400, in __init__
>      self.toolbar = NavigationToolbar2TkAgg( canvas, self.window )
>    File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 667, in __init__
>      NavigationToolbar2.__init__(self, canvas)
>    File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line 2310, in __init__
>      self._init_toolbar()
>    File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 711, in _init_toolbar
>      borderwidth=2)
>    File "C:\Python27\lib\lib-tk\Tkinter.py", line 2466, in __init__
>      Widget.__init__(self, master, 'frame', cnf, {}, extra)
>    File "C:\Python27\lib\lib-tk\Tkinter.py", line 1977, in __init__
>      (widgetName, self._w) + extra + self._options(cnf))
> _tkinter.TclError: bad screen distance "640.0"
> Fatal Python error: PyEval_RestoreThread: NULL tstate
>
> ---
>
> The reason appears to be that at some point Tkinter tries to parse the string "640.0" as a number, which does not work in a locale where the decimal marker is, e.g., the comma (as in German). If you comment out the locale setting (or set it to "C"), the example works.
>
> The float value of 640.0 seems to emerge from the following piece of code in "backend_tkagg.py".
>
> ---
>
> class NavigationToolbar2TkAgg(NavigationToolbar2, Tk.Frame):
>
>     [...]
>
>      def _init_toolbar(self):
>          xmin, xmax = self.canvas.figure.bbox.intervalx
>          height, width = 50, xmax-xmin
>          Tk.Frame.__init__(self, master=self.window,
>                            width=width, height=height,
>                            borderwidth=2)
>
> ---
>
> Through the initialization by difference, "width" is a 'numpy.float64'; changing the assignment of "height, width" to
>
>     height, width = 50, int(xmax-xmin)
>
> makes the example program run through without problems.
>
> One the one hand, I guess this should be fixed in the depths of Tkinter (where apparently a number type gets stringified just to be parsed again as a number). One the other hand, it would be very simple fix in the TkAgg backend, and it seems sensible to make the width an int. (Perhaps even the intervals in intervalx should already be ints?)
>
> I would like to point out that, even though this might sound like a contrived problem, it can easily occur where machines are set up with different languages; we had a tool run on an English Windows, but we got the stack trace from above when we moved that tool to a German Windows which we believed to be set up in just the same way as the original Windows. It took us a day to figure out what the reason behind the cryptic Tkinter error was.
>
> Kind regards,
> H.
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users


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

Hi,

sorry if this has already been addressed. I did a search on the archives, but even though that turned up lots of hits, none of them seemed to be related to the issue.

The following very simple example will reliably crash in Python 2.7.[0-2] with matplotlib 1.0.1 under a 64 bit German Windows (and probably also on other machines where you can set an equivalent locale):

---

import matplotlib

from pylab import arange,sin,pi
t = arange(0.0, 2.0, 0.01)
s = sin(2*pi*t)

import locale
# the locale setting in the next line makes pyplot.plot crash
# have to use "deu_deu" instead of "de_DE" on German Windows 
locale.setlocale(locale.LC_ALL, 'deu_deu')
print "locale =", locale.getlocale(locale.LC_NUMERIC)

print "will plot ..."
matplotlib.pyplot.plot(t, s, linewidth=1.0)
# doesn't get this far with German locale
print "will show ..."
matplotlib.pyplot.show() 

---

The program crashes in pyplot.plot(). The stacktrace is:

---

Traceback (most recent call last):
  File "C:\[...]\badScreenSizeMPL.py", line 14, in <module>
    matplotlib.pyplot.plot(t, s, linewidth=1.0)
  File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 2279, in plot
    ax = gca()
  File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 593, in gca
    ax =  gcf().gca(**kwargs)
  File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 292, in gcf
    return figure()
  File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 270, in figure
    **kwargs)
  File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 82, in new_figure_manager
    figManager = FigureManagerTkAgg(canvas, num, window)
  File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 400, in __init__
    self.toolbar = NavigationToolbar2TkAgg( canvas, self.window )
  File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 667, in __init__
    NavigationToolbar2.__init__(self, canvas)
  File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line 2310, in __init__
    self._init_toolbar()
  File "C:\Python27\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 711, in _init_toolbar
    borderwidth=2)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2466, in __init__
    Widget.__init__(self, master, 'frame', cnf, {}, extra)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 1977, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: bad screen distance "640.0"
Fatal Python error: PyEval_RestoreThread: NULL tstate

---

The reason appears to be that at some point Tkinter tries to parse the string "640.0" as a number, which does not work in a locale where the decimal marker is, e.g., the comma (as in German). If you comment out the locale setting (or set it to "C"), the example works.

The float value of 640.0 seems to emerge from the following piece of code in "backend_tkagg.py".

---

class NavigationToolbar2TkAgg(NavigationToolbar2, Tk.Frame):

   [...]

    def _init_toolbar(self):
        xmin, xmax = self.canvas.figure.bbox.intervalx
        height, width = 50, xmax-xmin
        Tk.Frame.__init__(self, master=self.window,
                          width=width, height=height,
                          borderwidth=2)

---

Through the initialization by difference, "width" is a 'numpy.float64'; changing the assignment of "height, width" to

   height, width = 50, int(xmax-xmin)

makes the example program run through without problems.

One the one hand, I guess this should be fixed in the depths of Tkinter (where apparently a number type gets stringified just to be parsed again as a number). One the other hand, it would be very simple fix in the TkAgg backend, and it seems sensible to make the width an int. (Perhaps even the intervals in intervalx should already be ints?)

I would like to point out that, even though this might sound like a contrived problem, it can easily occur where machines are set up with different languages; we had a tool run on an English Windows, but we got the stack trace from above when we moved that tool to a German Windows which we believed to be set up in just the same way as the original Windows. It took us a day to figure out what the reason behind the cryptic Tkinter error was.

Kind regards,
H.

> Hi,
> I had problems to build the version 1.0.1-r1 in gentoo with linux-3.0.0-rcX.
> As chromium, the matplotlib need fix the use of 'linux2' label. See chromium
> thread:
> http://code.google.com/p/chromium/issues/detail?id=85845
> Is very simple fix. If you want, i can send one patch.

Thank you. I've filed an issue at github and identified it as needing
to be fixed in the next release. If you could submit a patch, that
would be helpful.

Darren

Hi,

I want to visualise a live data-stream by a number of plots (3d,
line drawings, scatter plots etc). I've been using the simpler
animation techniques (using gobject.idle_add and wx.EVT_IDLE to
redraw updates).

Some plots have static backgrounds that may benefit from the blit
techniques and I have been trying to get this approach to work in
GTKAgg and WXAgg. GTKAgg on linux seems to be coming along fine.
WXAgg on linux or macos, I'm not getting very far with.

So can anyone help with a few questions?

- can the native macos backend be used for animation? What's the
equivalent of gobject.idle_add or gobject.timeout_add? Anything
special needed for the blitting approach to work?

- What needs to be done to get WXAgg blitting? I have code like this:
...
matplotlib.use('WXAgg')
...
def update():
	...
	# restore, blit etc
	wx.WakeUpIdle()

...
wx.EVT_IDLE(wx.GetApp(), update)
...

On Linux this draws the first screen and pauses. If I move the mouse
around I see the updates. As soon as I stop, so do the updates. What
am I missing? (BTW I get the same behaviour from animation_blit_wx.py
from the examples page). This is 1.0.1 on Linux, although I'm still
using 0.99.1 as well.

thanks for any help,

cheers, chris





-- 
Chris Higgins, Omnisense Ltd, 3rd Floor, St. Andrews House,
59 St Andrews Street, Cambridge, CB2 3BZ
Office: +44 (0) 1223 651394
Mobile: +44 (0) 780 490 8562
Skype: chiggins99
http://www.omnisense.co.uk

Omnisense Ltd is a company registered in England and Wales. Registered number: 6779286.
Registered office: St. Andrews House, 59 St Andrews Street, Cambridge, CB2 3BZ

Hi,

I had problems to build the version 1.0.1-r1 in gentoo with linux-3.0.0-rcX.
As chromium, the matplotlib need fix the use of 'linux2' label. See chromium
thread:
http://code.google.com/p/chromium/issues/detail?id=85845

Is very simple fix. If you want, i can send one patch.

Thanks,

-- 
Tiago Rezende Campos Falcão
http://www.tiagofalcao.com
--
ProFUSION | embedded systems
Computer Systems Laboratory - IC - Unicamp
Grupo Pró Software Livre - Unicamp
Laboratory of Information Systems - IC - Unicamp

Hello,

I was trying to test out the Python 3 development version with the first
plot shown in the pyplot tutorial. Everything seems to work ok until I go

plt.show()

at which point nothing happens, I don't see a plot. Python accepts the
command and is waiting for a new command but I have no plot.

I've tried changing the backend in the matplotlibrc file to TkAgg, but I
still get nothing, in fact now when I try to import matplotlib I get a
traceback error that name -tkagg is not defined, seems like it might be
something in the module.

Can anyone lend a hand?

Thanks,

Jorge Garcia

> Yes, it is a known problem, and it is by design.  However, the OP has a good
> point that the gallary should have nice-looking plots.  Therefore, it would
> make sense to modify those really bad examples with subplot_adjust() to
> allow them to look better.

Very much agreed :)

On Tue, Jun 28, 2011 at 10:08 AM, Daniel Mader <
dan...@go...> wrote:

> Hi,
>
> this is a known problem when working with subplots, reducing the
> figure size or increasing the font size. It is like that by design but
> there are workarounds.
>
>
> http://old.nabble.com/Feature-request%3A-automatic-scaling-of-subplots,-margins,-etc-td31556961.html
>
> http://old.nabble.com/faq%3A-reducing-figure.figsize-cuts-off-labels-and-tick-marks-td30984092.html
>
> Hope this helps :)
>
>
Yes, it is a known problem, and it is by design.  However, the OP has a good
point that the gallary should have nice-looking plots.  Therefore, it would
make sense to modify those really bad examples with subplot_adjust() to
allow them to look better.

Ben Root

We started using Python 2.7.2 a week or two ago, and I'm now running into
this problem when attempting to build matplotlib 1.0.1 on several of our
machines:

basedirlist is: []
============================================================================
BUILDING MATPLOTLIB
            matplotlib: 1.0.1
                python: 2.7.2 (default_cci, Jun 28 2011, 12:34:28)  [GCC
                        4.0.1 (Apple Computer, Inc. build 5367)]
              platform: darwin

REQUIRED DEPENDENCIES
                 numpy: 1.5.1
             freetype2: found, but unknown version (no pkg-config)
                        * WARNING: Could not find 'freetype2' headers in any
                        * of '.', './freetype2'.

OPTIONAL BACKEND DEPENDENCIES
                libpng: found, but unknown version (no pkg-config)
                        * Could not find 'libpng' headers in any of '.'
Traceback (most recent call last):
  File "setup.py", line 162, in <module>
    if check_for_tk() or (options['build_tkagg'] is True):
  File
"/Volumes/Scratch1/nat/phenix_installer/build-source/mac-intel-osx/patchnose/tmp/matplotl
ib-1.0.1/setupext.py", line 832, in check_for_tk
    (Tkinter.__version__.split()[-2], Tkinter.TkVersion,
Tkinter.TclVersion))
IndexError: list index out of range

When I run the version of Python that I'm using to build matplotlib, this is
what I'm seeing:

>>> import Tkinter
>>> Tkinter.__version__
'$Revision$'

I don't need or want Tkinter support either in Python or in matplotlib, but
it appears to be impossible to disable Tkinter when compiling Python.  Is
there a way around this problem without patching the Python build, or
matplotlib, or both?

thanks,
Nat

Hi,

this is a known problem when working with subplots, reducing the
figure size or increasing the font size. It is like that by design but
there are workarounds.

http://old.nabble.com/Feature-request%3A-automatic-scaling-of-subplots,-margins,-etc-td31556961.html
http://old.nabble.com/faq%3A-reducing-figure.figsize-cuts-off-labels-and-tick-marks-td30984092.html

Hope this helps :)


2011/6/28 Randolf Ebelt <eb...@ie...>:
> Hi,
>
> the margins of all examples at
>
> http://matplotlib.sourceforge.net/gallery.html
>
> for example:
> http://matplotlib.sourceforge.net/examples/api/collections_demo.html
>
> seem to be way to small! For me as a potential user its bad advertising :)
>
> Regards,
> Randolf
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I'm using 0.99.3, which is from the ubuntu maverick repos.

This comes up mostly when I'm drawing plots interactively from ipython.

Cheers,
Alex



On Tue, Jun 28, 2011 at 10:44 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Mon, Jun 27, 2011 at 5:09 PM, Alex Flint <ale...@gm...> wrote:
>
>> Hi there,
>>
>> I'm wondering whether there is an easy way to append an additional subplot
>> to an existing figure without losing the subplots already drawn.
>>
>> Currently if I do something like
>> >>> subplot(211); plot(...); subplot(212); plot(...);
>>
>> Then I get inconsistent drawing results if I try something like:
>> >>> subplot(313); plot(...);
>>
>>  Cheers,
>> Alex
>>
>>
> Yes, it is "possible", but it can be messy to do so.  Also, which version
> of matplotlib are you using?  Is there a particular reason why you don't
> know the number of plots ahead of time?
>
> Ben Root
>
>

On Mon, Jun 27, 2011 at 5:09 PM, Alex Flint <ale...@gm...> wrote:

> Hi there,
>
> I'm wondering whether there is an easy way to append an additional subplot
> to an existing figure without losing the subplots already drawn.
>
> Currently if I do something like
> >>> subplot(211); plot(...); subplot(212); plot(...);
>
> Then I get inconsistent drawing results if I try something like:
> >>> subplot(313); plot(...);
>
>  Cheers,
> Alex
>
>
Yes, it is "possible", but it can be messy to do so.  Also, which version of
matplotlib are you using?  Is there a particular reason why you don't know
the number of plots ahead of time?

Ben Root

Hi,

the margins of all examples at

http://matplotlib.sourceforge.net/gallery.html

for example: 
http://matplotlib.sourceforge.net/examples/api/collections_demo.html

seem to be way to small! For me as a potential user its bad advertising :)

Regards,
Randolf

Hi there,

I'm wondering whether there is an easy way to append an additional subplot
to an existing figure without losing the subplots already drawn.

Currently if I do something like
>>> subplot(211); plot(...); subplot(212); plot(...);

Then I get inconsistent drawing results if I try something like:
>>> subplot(313); plot(...);

Cheers,
Alex

On 06/27/2011 03:38 AM, Jonathan Slavin wrote:
> I tried the suggested clean-up but saw no difference in performance.  I
> left out a crucial piece of information, I think, in my earlier message.
> The delay in drawing occurs when I'm running the code from within
> ipython, invoked with the -pylab flag.  When I run it directly from the
> command line, I get no such delay.  I presume this is backend dependent.
> For my current purposes, just running it directly from the command line
> (i.e. something like: % python do_fits.py) works for me.  The ability to
> interactively examine variables, as one can when running within ipython,
> would be nicer, however.
>
> Jon
>
>>          On 06/24/2011 04:03 AM, Jonathan Slavin wrote:
>>          >  import matplotlib.pyplot as plt
>>          >  plt.ion()
>>          >  fig = plt.gcf()
>>          >  for obsid in obsids:
>>          >       <do fitting>
>>          >       plt.cla()
>>          >       fig = plt.gcf()
>>          >       ax = fig.add_axes([0.15,0.1,0.8,0.6])
>>          >       ax.plot(x,y)
>>          >       plt.draw()
>>          >       ans = raw_input('continue? ')
>>          >       if ans == 'n':
>>          >           break
>>
>>          The behavior may depend on mpl version and backend, but with
>>          1.0.1 or
>>          later, I think something like what you have will work with a
>>          little
>>          cleanup, e.g.:
>>
>>          import matplotlib.pyplot as plt
>>          import numpy as np
>>
>>          plt.ion()
>>          fig = plt.gcf()
>>          ax = fig.add_axes([0.15,0.1,0.8,0.6])
>>          for i in range(3):
>>               ax.cla()
>>               ax.plot(np.random.rand(10))
>>               plt.draw()
>>               raw_input("hit a key to proceed")


What happens if you replace the raw_input with the figure method 
waitforbuttonpress?  (Also available as a pyplot function.)

Eric


>>
>>
>>          Eric
>

> I don't know for sure if this is matplotlib's fault. ipython's fault or Mac OS
> X, but I ever since I upgraded to matplotlib 1.0.1 I have this problem that
> ipython will exit with segfault after I close a figure.
>

 >> What version of ipython are you using?

Hi Eric,

Thanks for your response.

I'm indeed using 0.10

Good to know a new iPython will be out.

Best
-Kaushik

I tried the suggested clean-up but saw no difference in performance.  I
left out a crucial piece of information, I think, in my earlier message.
The delay in drawing occurs when I'm running the code from within
ipython, invoked with the -pylab flag.  When I run it directly from the
command line, I get no such delay.  I presume this is backend dependent.
For my current purposes, just running it directly from the command line
(i.e. something like: % python do_fits.py) works for me.  The ability to
interactively examine variables, as one can when running within ipython,
would be nicer, however.

Jon

>         On 06/24/2011 04:03 AM, Jonathan Slavin wrote:
>         > import matplotlib.pyplot as plt
>         > plt.ion()
>         > fig = plt.gcf()
>         > for obsid in obsids:
>         >      <do fitting>
>         >      plt.cla()
>         >      fig = plt.gcf()
>         >      ax = fig.add_axes([0.15,0.1,0.8,0.6])
>         >      ax.plot(x,y)
>         >      plt.draw()
>         >      ans = raw_input('continue? ')
>         >      if ans == 'n':
>         >          break
>         
>         The behavior may depend on mpl version and backend, but with
>         1.0.1 or 
>         later, I think something like what you have will work with a
>         little 
>         cleanup, e.g.:
>         
>         import matplotlib.pyplot as plt
>         import numpy as np
>         
>         plt.ion()
>         fig = plt.gcf()
>         ax = fig.add_axes([0.15,0.1,0.8,0.6])
>         for i in range(3):
>              ax.cla()
>              ax.plot(np.random.rand(10))
>              plt.draw()
>              raw_input("hit a key to proceed")
>         
>         
>         Eric

Hi

I've made a lib to replace the default Matplotlib toolbar, it looks like
this:
http://i256.photobucket.com/albums/hh163/_pelya/mpl-gui.png

It replaces the pan/zoom button with wheels and handles, using new
subplot2grid API of matplotlib 1.0.1.
The reason behind that change is that people I'm currently writing my
application for can hardly handle
anything that doesn't look like their 50-years-old potentiostat. Also, I
needed some custom event code to
interact with the figure (typically to mark a part of the graph), and
enabling/disabling pan/zoom mode
each time I need to make a change to the figure is not convenient.

Here's the sources:
http://elchemgraphview.svn.sourceforge.net/viewvc/elchemgraphview/

Currently it supports only subplot() API, similar to the Matplotlib API with
the same name,
also it requires quite a lot of a boilerplate code - see simpletest.py or
test.py for example.
As a bonus you can add your own buttons to that new toolbar, however my
designer skills
are rather poor, so it looks like MS Paint drawing.
If anyone is interested I can extend it to the point where you need only to
write
"import vintage" to get the new controls - it will replace several
matplotlib functions like pyplot.figure(),
pyplot.subplot() and pyplot.connect() with it's own handlers, right inside
pyplot module namespace.

On Sunday, June 26, 2011, Warren Weckesser
<war...@en...> wrote:
>
>
> On Sun, Jun 26, 2011 at 7:44 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Sunday, June 26, 2011, Carl Karsten <ca...@pe...> wrote:
>> http://matplotlib.sourceforge.net/examples/api/radar_chart.html
>>
>> "Exception occurred rendering plot."
>>
>
> Without more information, we can't help you.  What version of
> matplotlib are you using? On what OS?  How did you install it?  Do the
> tests pass?  And which backend?
>
>
> That error is what shows up on the web page when you follow the link.
>
> Warren
>
>

Ah, indeed it is.  I apologize for misunderstanding, what is odd is
that the demo didn't work, but the mpl logo rendered fine.

Who was it that uploaded the recent rebuild of the docs?

Ben Root

On Sun, Jun 26, 2011 at 7:44 PM, Benjamin Root <ben...@ou...> wrote:

> On Sunday, June 26, 2011, Carl Karsten <ca...@pe...> wrote:
> > http://matplotlib.sourceforge.net/examples/api/radar_chart.html
> >
> > "Exception occurred rendering plot."
> >
>
> Without more information, we can't help you.  What version of
> matplotlib are you using? On what OS?  How did you install it?  Do the
> tests pass?  And which backend?
>


That error is what shows up on the web page when you follow the link.

Warren



> Ben Root
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>