matplotlib-users Mailing List for matplotlib

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
>     Fernando> Oh, I don't think it's necessarily a leak.  Simply a ton
>     Fernando> of unreachable stuff lying around, which a call to
>     Fernando> gc.collect() may help with.
> 
> I hope you're right -- matplotlib uses a lot of cyclic references.
> But if he's using the pylab interface to manage the figure windows,
> the destroy event of the window manager already triggers a call to
> gc.collect in the _pylab_helpers module.

Never mind then.  If gc.collect is already called reasonably often, an extra 
manual call will do zilch.  Sorry.

Best,

f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
    Fernando> Oh, I don't think it's necessarily a leak.  Simply a ton
    Fernando> of unreachable stuff lying around, which a call to
    Fernando> gc.collect() may help with.

I hope you're right -- matplotlib uses a lot of cyclic references.
But if he's using the pylab interface to manage the figure windows,
the destroy event of the window manager already triggers a call to
gc.collect in the _pylab_helpers module.

JDH

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
>     Fernando> You can try to do:
> 
>     Fernando> import gc gc.collect()
> 
>     Fernando> This will force the garbage collector to kick in, which
>     Fernando> sometimes may help.
> 
> I'm not seeing any leak on linux with my standard memory leak test, eg
> 
>   unit/memleak_hawaii3.py
> 
> in CVS.

Oh, I don't think it's necessarily a leak.  Simply a ton of unreachable stuff 
lying around, which a call to gc.collect() may help with.

Best,

f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> You can try to do:

    Fernando> import gc gc.collect()

    Fernando> This will force the garbage collector to kick in, which
    Fernando> sometimes may help.

I'm not seeing any leak on linux with my standard memory leak test, eg

  unit/memleak_hawaii3.py

in CVS.

Have you read over

  http://matplotlib.sourceforge.net/faq.html#LEAKS

Unfortunately, the standard idiom I use for testing memory usage is
platform specific.

A complete script which exposes the leak would help...

JDH

D Brown wrote:
> I'm writing batch plotting code in the "traditional" sloppy
> way by typing scripts from the command line in ipython
> until I get what I want and then stringing the lines
> together in a file.  Then I put the whole thing in a loop
> and use run from ipython.  Now I can batch process a bunch
> of .cvs files into nice plots.
> 
> I have two problems though:
> 
> 1. The memory use in python increases about 5-10MB /sec
> during processing. I have pylab.ioff() in the loop and put
> a pylab.close('all') in the loop to try to close the figure
> and release memory. Now 24 files processed results in
> ~190MB memory use.  When I run again it keeps increasing. 
> I'm basically drawing the fig with several subplots and
> labels and then using savefig() to save it to a .png file. 
> Is there some way to release memory explicity?  I'm using
> WinXP and tkAgg backend.  I've tried things like gca() and
> clf() at the beginning of the script to try to reuse the
> canvas but It's not clear it it helps.  Sometimes if I wait
> long enough the memory use goes down so I don't suspect
> it's not a memory leak, but garbage collection problem. 
> Unfortunately the wait can be very long.  General as well
> as specific tips are wellcome.

You can try to do:

import gc
gc.collect()

This will force the garbage collector to kick in, which sometimes may help.

Best,

f

I'm writing batch plotting code in the "traditional" sloppy
way by typing scripts from the command line in ipython
until I get what I want and then stringing the lines
together in a file.  Then I put the whole thing in a loop
and use run from ipython.  Now I can batch process a bunch
of .cvs files into nice plots.

I have two problems though:

1. The memory use in python increases about 5-10MB /sec
during processing. I have pylab.ioff() in the loop and put
a pylab.close('all') in the loop to try to close the figure
and release memory. Now 24 files processed results in
~190MB memory use.  When I run again it keeps increasing. 
I'm basically drawing the fig with several subplots and
labels and then using savefig() to save it to a .png file. 
Is there some way to release memory explicity?  I'm using
WinXP and tkAgg backend.  I've tried things like gca() and
clf() at the beginning of the script to try to reuse the
canvas but It's not clear it it helps.  Sometimes if I wait
long enough the memory use goes down so I don't suspect
it's not a memory leak, but garbage collection problem. 
Unfortunately the wait can be very long.  General as well
as specific tips are wellcome.

2. If I use show() or ion() the new plot window pops up
where it likes, usually on top of my other windows.  Is
there a way to control this better? This may be a FAQ but I
didn't see it. In enviroments like IDL there is a "window"
command for this.  Curious what Matlab does and if there is
a platform independent pylab equivalent.

-- David


+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Personals - Better first dates. More second dates. 
http://personals.yahoo.com

>>>>> "Daisy" == Daisy Fuentes <eli...@ya...> writes:

    Daisy> John, Thank you for your reply.  A couple of issues though.
    Daisy> I looked at the documentation and saw the alpha
    Daisy> transperancy parameter, but for some reason I was still
    Daisy> getting the same results.  Maybe I am missing something
    Daisy> very fundamental.  If alpha is not provided then the
    Daisy> default is for the candlestick box not to be transperant,
    Daisy> correct?  Even changing the alpha value wouldn't produced
    Daisy> desired results, I can increase transperancy, but not
    Daisy> eliminate it.  I wasn't seeing that since I can still see
    Daisy> the lines (wicks) go through the boxes that's why I asked
    Daisy> here.  Also, this may be another foolish oversight on my

OK, I see what is going on.  The lines are being plotted over the
rectangles, so even if the rectangles are transparent, you still see
the lines.  There are two candlestick functions in matplotlib
candlestick and candlestick2.  They have slightly different call
signatures and a different implementation under the hood.  candlestick
creates a bunch of separate lines and rectangles, candlestick2 uses
collections (see the help for the matplotlib.collections module).

You can control the z-ordering on the plot by setting the zorder
property (see examples/zorder_demo.py).  For candlestick (see
examples/candlestick_demo.py) you would do

  lines, patches = candlestick(ax, quotes, width=0.6)
  set(lines, zorder=0.9*patches[0].zorder)

for candlestick2 you would do (untested)
  
 linecol, rectcol = candlestick2(blah) 
 z = rectcol.get_zorder()
 linecol.set_zorder(0.9*z)


    Daisy> part, but how come when I have candlestick2(axMiddle,
    Daisy> opens, closes, highs, lows, width=4, colorup='k',
    Daisy> colordown='r') instead of getting a bar colored black when
    Daisy> it closes above the open price I get the opposite --- red?
    Daisy> It seems colorup should be black, colordown -- red as in
    Daisy> colorup : the color of the lines where close >= open
    Daisy> colordown : the color of the lines where close < open

Argg, that's embarrassing.  Good thing mpl is distributed with no
warranties....  No telling how many billions this bug has cost the
wall street barons already!

In matplotlib/finance.py in the candlestick2 function, find this code

    colord = { True : colorup,
               False : colordown,
               }
    colors = [colord[open>=close] for open, close in zip(opens, closes) if open!=-1 and close !=-1]


That should read

    colors = [colord[close>=open] for open, close in zip(opens, closes) if open!=-1 and close !=-1]


right?  I believe this is already correct in candlestick, so this is a
candlestick2 specific bug.


    Daisy> As far as the moving average calculation, I did see the
    Daisy> disclaimer and didn't mean to be a stickler, it just seem a
    Daisy> bit misleading to me as I was trying to do the Exponential
    Daisy> Moving Average calculation and compare the results to the
    Daisy> actual financial charts.  They didn't match and I thought I
    Daisy> would point that out.

OK, if you submit a replacement function that better matches actual
plots, I will be happy to include it.

Thanks for the report!
JDH

>>>>> "Sascha" == Sascha Schnepp <sc...@te...> writes:

    Sascha> Hi everybody, I'm new to this list, so please don't be too
    Sascha> impatient...

    Sascha> I would like to know which possibilities I have to
    Sascha> customize the legend. I already found how to change the
    Sascha> font size using font_manager and FontProperties. What I'd
    Sascha> like to have is a slight gray legend background. Is this
    Sascha> possible?

Hi Sascha,

The way to customize the legend is to get the legend instance back
from the legend command.  Then you can call any of the methods
available for the legend.  You can read about these by doing from the
python shell

 >>> leg = legend(blha, blah)
 >>> help(leg)

or reading the site documentation at
http://matplotlib.sourceforge.net/matplotlib.legend.html#Legend .  To
customize the rectangular box around the legend, use

  >>> rect = leg.get_frame()

rect is a Rectangle instance, documented at
http://matplotlib.sourceforge.net/matplotlib.patches.html#Rectangle . 

To change the facecolor to gray, you need to call

  >>> rect.set_facecolor(0.8)  # a grayscale intensity

or

  >>> rect.set_facecolor('gray')

There are many wanys to set colors in matplotlib, these are discussed
at http://matplotlib.sourceforge.net/matplotlib.pylab.html#-colors

In particular, see examples/legend_demo.py that comes with the
matplotlib source distribution (and is also available here
http://matplotlib.sourceforge.net/matplotlib_examples_0.74.zip ).
This example shows you how to set the background color and more.

Hope this helps,
JDH

jdh...@ac... a écrit :
> While I was at it, I also implemented unicode support for the *Agg and
> PS backends :-)  If you have access to CVS, you may want to give it a
> test drive.  See examples/unicode_demo.py.  CVS mirrors may lag.

Wonderful! Unfortunately I don't have enough room on my disk for a 
compilation from CVS sources and the Debian package isn't out yet... So 
I'll try next time I boot on Windows!

> If they are looking for someone to pay.... :-)
> 
> JDH

It would really be a good idea. One never knows, maybe one day?


JM. Philippe