matplotlib-users Mailing List for matplotlib (Page 1430)

Kirill,
I've recently returned to Matplotlib and Scipy (and
happy to be back!!!).  I had the same problem and
solved it by putting the lines

import matplotlib
matplotlib.use('WXAgg')

before the usual import

from matplotlib.matlab import *

This worked for all of the example code.
If you don't have the examples, which are not included
in the Windows installer, go back to the download page
again and grab the .zip file.  This includes numerous
examples that you should be able to run with the two
lines mentioned above.

Hope this helps.
Barry Drake

--- Kirill Lapshin wrote:
> Hello,
> 
> I am a newbie to Matplotlib and all Python
numeric
> stuff, so sorry if it 
> is a FAQ.
> 
> I've installed NumPy 23.1, SciPy 0.3 and
Matplotlib
> 54.1. Python is 
> 2.3.4. The problem I have is that none of
backends
> works properly.
> 
> TkAgg -- works fine from console, but if ran from
> IDLE or PythonWin it 
> creates a window border only, does not populate
it
> with plot. If I try 
> to move the plot window whole python session
crashes
> with generic 
> runtime error message (windows error message box
> with a single Ok button).
> 
> WX/WXAgg -- both don't work from console -- show
> empty window, cursor 
> turns in hourglass when it is over plot window.
From
> GUI app 
> (IDLE/PythonWin) it seems to work at first glance
--
> plot gets created, 
> but the plot window can not be closed with either
> Alt-F4 or mouse. It 
> just does not react on close command. Moreover,
> python objects 
> corresponding to window seems to get destroyed
when
> I try to close 
> window, because if I do few plots commands
without
> trying to close the 
> window, new plots appear in first window, however
as
> soon as I try to 
> close the window (it won't close, remember?), new
> plots will open new 
> window. That second window can be closed, but
first
> one still remain 
> unclosable.
> 
> GTK/GTKAgg -- can't really try that one, because
it
> requires compiling 
> GTK, and we don't have compiler yet.
> 
> 
> Any ideas how that can be fixed, work arounded,
> debugged? I am pretty 
> comfortable with debugging Python code, but as I
> said I don't have C 
> compiler yet, so can't debug extensions.
> 
> This behavior observed on brand new computer with
> freshly installed Win 
> XP. The same behavior I am observing on my a bit
old
> Win XP laptop.
> 
> --Kirill
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: GNOME
Foundation
> Hackers Unite!  GUADEC: The world's #1 Open
Source
> Desktop Event.
> GNOME Users and Developers European Conference,
> 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
>
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello,

I am a newbie to Matplotlib and all Python numeric stuff, so sorry if it 
is a FAQ.

I've installed NumPy 23.1, SciPy 0.3 and Matplotlib 54.1. Python is 
2.3.4. The problem I have is that none of backends works properly.

TkAgg -- works fine from console, but if ran from IDLE or PythonWin it 
creates a window border only, does not populate it with plot. If I try 
to move the plot window whole python session crashes with generic 
runtime error message (windows error message box with a single Ok button).

WX/WXAgg -- both don't work from console -- show empty window, cursor 
turns in hourglass when it is over plot window. From GUI app 
(IDLE/PythonWin) it seems to work at first glance -- plot gets created, 
but the plot window can not be closed with either Alt-F4 or mouse. It 
just does not react on close command. Moreover, python objects 
corresponding to window seems to get destroyed when I try to close 
window, because if I do few plots commands without trying to close the 
window, new plots appear in first window, however as soon as I try to 
close the window (it won't close, remember?), new plots will open new 
window. That second window can be closed, but first one still remain 
unclosable.

GTK/GTKAgg -- can't really try that one, because it requires compiling 
GTK, and we don't have compiler yet.


Any ideas how that can be fixed, work arounded, debugged? I am pretty 
comfortable with debugging Python code, but as I said I don't have C 
compiler yet, so can't debug extensions.

This behavior observed on brand new computer with freshly installed Win 
XP. The same behavior I am observing on my a bit old Win XP laptop.

--Kirill

John,

I would like to use matplotlib in data acquisition and processing 
software for a shipboard acoustic Doppler current profiler (ADCP), and I 
am presently at sea on the University of Hawaii Research Vessel Kilo 
Moana (25S, 175W).  Until June 17 or 18, when I arrive in Honolulu, I 
will not have access to the mailing list via my normal email address, 
ef...@ha..., but mail sent to me on the ship, 
ef...@km..., will be transferred about 3 times per day.

I am working with a Linux machine, Mandrake 10.0, 2.6 kernel, pygtk 
2.2.  I suspect that the memory-monitoring parts of the scripts I have 
attached are Linux-specific.

The attached scripts illustrate what seem to be pervasive memory leaks 
when doing repeated plots, using GTK or GTKAgg to plot to the screen, or 
using Agg to make png files only.  I have tried several variations--all 
result in fairly steady increase in memory consumption. 

Memory usage increase can also be seen by running the pcolor_demo.py, 
and repeatedly raising and lowering the window, thereby forcing redraws.

Do you expect that such leakage is inevitable with matplotlib?  I hope 
not; matplotlib is by far the most promising plotting package I have 
found as a prospective Matlab replacement.

On another topic: I believe I saw in earlier mailing list correspondence 
a request for transparent plotting of data with NaNs in it--that is, a 
NaN in a line should cause the line to be broken and a symbol omitted, 
in pcolor should cause simply an empty (white, black, or transparent) 
cell, etc., as in Matlab.  I would like to second this request.  In 
physical oceanography, bad or missing measurements are ubiquitous, and 
Matlab's treatment of NaNs enormously reduces the pain of dealing with 
such glitches.  Ideally, this sort of thing would be done equivalently 
with NaNs in a numarray or with the mask in a masked array, so that one 
could use either approach.

Thanks for the excellent work you have already done.

Eric Firing
ef...@km... until June 17
ef...@ha... thereafter

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:

    Jin-chung> Hi: I encounter the following problems, most are
    Jin-chung> related to log plots.  I am using version 0.54.1 on
    Jin-chung> Solaris.  Did I miss something trivial?

Hi Jin-chung,

I think I have all these problems sorted out now.  If you would like
to test them, the latest snapshot is here

http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.2b.tar.gz

Thanks for the detailed examples!

JDH

>>>>> "Mark" == Mark Engelhardt <ma...@st...> writes:

    Mark> For me, the plot generated by x2 (the second call of show)
    Mark> is dense in the middle and fades out at the edges.  I assume
    Mark> this is somehow due to the line redrawing over itself as it
    Mark> moves from point to point.

    Mark> Is there a good way to clean it up, other than always
    Mark> sorting the x variable list?

Hi Mark,

The problem arises from a combination of when in the rendering
pipeline matplotlib does the transformation from data to display
coordinates, and how agg handles antialiasing with subpixel rendering.
The short answer is that matplotlib handles the transformation in the
front end and then passes the backend display coords to render.  This
doesn't play nicely with agg, which does different things depending on
the fractional value of the display coordinate (aka subpixel
rendering).  It's something I would like to change, but it is a fairly
substantial piece of work so I'm holding off on it for now.  Drawing
with

  plot(x, y, antialiased=False)

will improve the situation, but then you won't have anitaliasing, and
it still won't be perfect.

I posted a variant of your question to the antigrain mailing list (see
below) in hopes of understanding this issue better myself, and Maxim,
the antigrain author, was kind enough to write this web page in reply

  http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html

He also pointed out that SVG has the same behavior.  The best
solution, as noted above, is to render in the following order

  set the path
  apply the affine transformation
  rasterize

whereas I am doing

  apply the affine transformation
  set the path
  rasterize

and there is no way to change this w/o significant changes to al lthe
drawing functions in all the backends.

Note that the following simpler example exposes the problem

    from matplotlib.matlab import *
    x = array([2,5,3,1,4])
    plot(x, x)
    show()

If I come up with something better I'll let you know; even after
reading Maxim's webpage I'm still confused on a couple of issues so
I'll follow-up.  Note that this is a problem specific to the agg
backend, so if you need to produce something for distribution and want
to avoid this problem, you might be able to use another backend.

I'll include my post to the antigrain list below, where I have
translated your example into display coords, ie, what agg sees.

JDH


From: John Hunter <jdh...@ac...>
Subject: [AGG] line paths, subpixel, and aa
To: Vec...@li...
Date: Fri, 04 Jun 2004 15:39:44 -0500
Reply-To: vec...@li...


I develop a plotting library (matplotlib) that has an antigrain
backend.  The library is setup to do the transformations on the front
end and pass the backends drawing commands in display coordinates.
The library was designed before I started using antigrain as a
backend, and one unfortunate side-effect of this is that the backend
often gets coordinates with a variety of fractional values, eg 100.0,
100.25, 100.5.  The front end does not understand agg's subpixel
rendering.  

So occasionally we get "strange" results like uneven thickness of
lines.  I have a few hacks to deal with this in common use cases, but
it still is a lingering problem.  

Here is one particularly strange (to me) manifestation.  I don't fully
understand how agg handles line widths with antialiasing and subpixel
locations, so I'm hoping to use this example to enlighten me.

If a path is drawn as (canvas is 640x480 - all these points more or
less fall on the same line)

  path.move_to(204, 332.4);
  path.line_to(576, 48);
  path.line_to(328, 237.6);
  path.line_to(80, 427.2);
  path.line_to(452, 142.8);

There is a strong effect of line width.  For example, the line at (80,
427.2) is extremely (vanishingly) thin, but thick in the middle at
328, 237.6.  raw rgba pixel dump is at
http://nitace.bsd.uchicago.edu:8080/files/share/line_aa.raw.

If the order the line is drawn is changed to (points ordered by
increasing x,y)

  path.move_to(80, 427.2);
  path.line_to(204, 332.4);
  path.line_to(328, 237.6);
  path.line_to(452, 142.8);
  path.line_to(576, 48);

The line width is more or less uniform.

Can someone enlighten me here?  (Complete example below).

On another note, does anyone have advice on how to solve these kinds
of problems in general.  Another example is in drawing of horizontal
or vertical tick lines for graphs.  The tick locations are in data
coordinates and the front end transforms these into display coords as
above.  Depending on the data location, these might end up having any
fractional display value, and thus the thickness of these rendered
lines varies.  My solution for this case is to detect at the backend
(agg) whether the line is horizontal or vertical and "snap-to" the
nearest integer + 0.5 location.  This works OK for horiz and vertical
lines.

But for arbitrary line paths, eg, sine waves, snapping all points to
the same fractional value introduces other kinds of visual problems,
so I don't do this - but then I get the kinds of problems in the
example above.

General question: if the transformations were handled in agg, eg the
frontend passed data coords and I set the transformation matrices in
agg accordingly, would I still face these problems?

Sorry for the somewhat vague and meanering post - hopefully someone
can understand my problem and enlighten me!

John Hunter


#include <fstream>

#include "agg_path_storage.h"
#include "agg_pixfmt_rgb24.h"
#include "agg_pixfmt_rgba32.h"
#include "agg_rasterizer_scanline_aa.h"
#include "agg_renderer_scanline.h"
#include "agg_rendering_buffer.h"
#include "agg_scanline_bin.h"
#include "agg_scanline_p32.h"
#include "agg_conv_stroke.h"


typedef agg::pixel_formats_rgba32<agg::order_rgba32> pixfmt;
typedef agg::renderer_base<pixfmt> renderer_base;
typedef agg::rasterizer_scanline_aa<> rasterizer;

// antialiased
typedef agg::renderer_scanline_p_solid<renderer_base> renderer;
typedef agg::scanline_p8 scanline;

// aliased
//typedef agg::scanline_bin scanline;
//typedef agg::renderer_scanline_bin_solid<renderer_base> renderer;


int main(int argc, char* argv[]) {

  unsigned width(640), height(480);
  unsigned stride(width*4);

  size_t NUMBYTES(width*height*4);
  agg::int8u buffer[NUMBYTES];

  agg::rendering_buffer rbuf;
  rbuf.attach(buffer, width, height, stride);


  //draw_anti_aliased

  pixfmt pixf(rbuf);
  renderer_base rb(pixf);
  renderer ren(rb);
  rasterizer ras;
  scanline sline;


  agg::path_storage path;
  rb.clear(agg::rgba(1.0, 1.0, 1.0, 1.0));


  path.move_to(204, 332.4);
  path.line_to(576, 48);
  path.line_to(328, 237.6);
  path.line_to(80, 427.2);
  path.line_to(452, 142.8);
  /*
  path.move_to(80, 427.2);
  path.line_to(204, 332.4);
  path.line_to(328, 237.6);
  path.line_to(452, 142.8);
  path.line_to(576, 48);
  */


  agg::conv_stroke<agg::path_storage> stroke(path);
  stroke.width( 1);
  ras.add_path(stroke);


  ren.color(agg::rgba(0.0, 0.0, 0.0, 1.0));
  ras.render(sline, ren);

  size_t i;
  std::ofstream of2( "line_aa.raw", std::ios::binary|std::ios::out);
  for (i=0; i<NUMBYTES; ++i)
    of2.write((char*)&buffer[i], sizeof(char));
  
}

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:

    Jin-chung> Hi: I encounter the following problems, most are
    Jin-chung> related to log plots.  I am using version 0.54.1 on
    Jin-chung> Solaris.  Did I miss something trivial?

No, all your bugs are valid.  Several of them are trivial fixes.  One
of them (the 0.3 tick problem) is subtle and important.  I'm still
trying to figure it out.

I'll keep you posted.

Thanks for the examples,
JDH

Hi,

I've noticed that the line density seems to vary if the x-values in a 
2D plot are not ordered and the x,y pairs fall on the same line.

For example, compare these 2 plots:
def f(x):
	return x+1
x1 = arange(5)
x2 = array([2,5,3,1,4])
plot(x1, f(x1))
show()
plot(x2, f(x2))
show()

For me, the plot generated by x2 (the second call of show) is dense in 
the middle and fades out at the edges.  I assume this is somehow due to 
the line redrawing over itself as it moves from point to point.

Is there a good way to clean it up, other than always sorting the x 
variable list?

Thanks,
Mark

>>>>> "Nils" == Nils Wagner <nw...@me...> writes:

    Nils> Dear experts, I am interested in a plot of equipotential
    Nils> curves.  If desired, the regions between contours should be
    Nils> shaded or colored to indicate their magnitude.

    Nils> Is this feature already available in matplotlib ?  A small
    Nils> example will be appreciated.

There is no contour per se, but you can use imshow or pcolor with a
custom colormap that has only few levels to emulate one, as shown in
this screenshot and example below

  http://nitace.bsd.uchicago.edu:8080/files/share/poormans_contour.png

We are interested in developing a real contour function however, which
also provides contour lines, etc, as mentioned on
http://matplotlib.sourceforge.net/goals.html.

Cheers,
John Hunter

#!/usr/bin/env python
from matplotlib.matlab import *


def bivariate_normal(X, Y, sigmax=1.0, sigmay=1.0,
                     mux=0.0, muy=0.0, sigmaxy=0.0):
    """
    Bivariate gaussan distribution for equal shape X, Y

    http://mathworld.wolfram.com/BivariateNormalDistribution.html
    """
    Xmu = X-mux
    Ymu = Y-muy

    rho = sigmaxy/(sigmax*sigmay)
    z = Xmu**2/sigmax**2 + Ymu**2/sigmay - 2*rho*Xmu*Ymu/(sigmax*sigmay)
    return 1.0/(2*pi*sigmax*sigmay*(1-rho**2)) * exp( -z/(2*(1-rho**2)))


delta = 0.01
x = arange(-3.0, 3.0, delta)
y = arange(-3.0, 3.0, delta)
X,Y = meshgrid(x, y)
Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)

# difference of Gaussians
cmap = ColormapJet(10)  # only 10 levels for discrete color steps
im = imshow(Z2-Z1, cmap)

# set the interpolation method: 'nearest', 'bilinear', 'bicubic' and much more
im.set_interpolation('bilinear')

axis('off')
#savefig('test')
show()

Dear experts,

I am interested in a plot of equipotential curves.
If desired, the regions between contours should be shaded or colored to
indicate their magnitude.

Is this feature already available in matplotlib ?
A small example will be appreciated.

Thanks in advance.

Nils

Hi:

I encounter the following problems, most are related to log plots.  I am using
version 0.54.1 on Solaris.  Did I miss something trivial?


(1) No y tick labels when the range is less than 10, e.g.
>>> semilogy([8,5,6,4,5,6,7])

(2) The 0.3 tick mark is missing in this plot:
>>> semilogy([56,7,2,0.2,999])

(3) If we do the "linear" plot first and then overplot it with the (semi)log 
plot, the lowest Y label (1) is totally wrong and the lowest order of magnitude 
has no tick marks! e.g.
>>> plot([8,5,6,4,5,6,7])
>>> semilogy([56,7,2,0.2,999])

(4) When doing semilogx(), it is always necessary to issue the show() command 
afterwards, to see the plot.  Not so for plot() or semilogy().

JC Hsu

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:

    Flavio> John, I think it would be a good Idea to beef up the two
    Flavio> scales example by adding a second plot were the y axes
    Flavio> were independent while the x axis is shared. This is a
    Flavio> more common use of two scales.

Now you've confused me.  In two_scales.py, the x axis *is shared* and
there are two independent y axes.  I agree that this is the common use
case for multiple scales on the same axes, but that is what two_scales
already does.

Do you mean something like examples/ganged_plots.py by chance?

JDH

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:

    Flavio> Crystal! But then the legends second example(legend_demo2)
    Flavio> is a bit misleading since it uses the syntax I used
    Flavio> originally (without the subscripts). I am aware of the
    Flavio> difference between the two situations, but my general
    Flavio> point is that since the examples are one of the main
    Flavio> sources of instruction for users, they should be as
    Flavio> complete as possible, i.e. contain as many variations on
    Flavio> the theme as possible, don't you agree?  Of course they
    Flavio> should not substitute the prime directive: RTFM!, but they
    Flavio> are a powerful tool that should be explored.

Well, in this case it would be RTNYEFM (RT not-yet-existant FM) so I
would hesitate to advise it.  Yes, the difference in your example and
the one in legend_demo2.py is that in the latter the sequence of lines
returned by plot are length 1 whereas in hist they are longer.  The
legend code "flattens" the list of lines/patches and so consumes the
sequences in order until the list of labels is exhausted.  In your
original example, the patches from the first hist used up all your
labels.

I changed legend_demo2.py to read

l1, = plot(t2, exp(-t2))
l2, l3 = plot(t2, sin(2*pi*t2), '--go', t1, log(1+t1), '.')
l4, = plot(t2, exp(-t2)*sin(2*pi*t2), 'rs-.')


legend( (l2, l4), ('oscillatory', 'damped'), 'upper right')

Adding the commas after l1 and l4 unpack the sequence returned by
plot, so l1 and l4 are now Line2D instances, not a sequence of lines.

This whole business of return values being objects or sequences of
objects is obscured by the fact that 'set' will operate on either,
which is true for matlab, BTW.

JDH

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:

    Flavio> Hi, Is there a way to set the color of an histogram? what
    Flavio> about transparency ?

    Flavio> for example:

    Flavio> h=hist(x...  set(h,'alpha',0.75)

Of course, not all backends support the alpha channel (eg postscript),
but this is already possible with the agg backend

Here is some example code

    n, binsb, pb = hist(sb, 100,normed=True)
    set(pb, 'facecolor', 'r', 'alpha', 1.0)

Perhaps the problem with your test code above is that histogram
returns a tuple of (counts, bins, patches) and you need to set the
alpha on the patches only.

    Flavio> I would like to superimpose histograms on the same plot
    Flavio> but they would have to be of different colors and be
    Flavio> translucent.

    Flavio> I need to do this in using the matlab interface, not the
    Flavio> API.

Yep, I've done exactly this before using the code above; here's an
example image where one histogram is translucent gray superimposed
over a red histogram

http://nitace.bsd.uchicago.edu:8080/files/share/aptopower.png

JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:

    Peter> seems like axes.plot_date() does not return the lines it
    Peter> creates... by looking at matlab.plot_date(), and comparing
    Peter> those with the case for regular plot() I think it
    Peter> should.. so we have a missing return statement..

Duly noted, fixed.  Thanks.

JDH

seems like axes.plot_date() does not return the lines it creates... by 
looking at matlab.plot_date(),  and comparing those with the case for 
regular plot() I think it should.. so we have a missing return statement..

-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

>>>>> "Nils" == Nils Wagner <nw...@me...> writes:

    Nils> cvs -z3
    Nils> -d:pserver:ano...@cv...:/cvsroot/matplotlib
    Nils> co matplotlib cvs checkout: authorization failed: server
    Nils> cvs.sourceforge.net rejected access to /cvsroot/matplotlib
    Nils> for user anonymous

Hmm, I just tried anonymous access and got the same thing.
Sourceforge is flaky sometimes.  Let's give it a day and if the
problem persists I'll file a support request.

In the meantime, here's a link a current CVS snapshot:

http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.2a.tar.gz

JDH

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matplotlib co 
matplotlib
cvs checkout: authorization failed: server cvs.sourceforge.net rejected 
access to /cvsroot/matplotlib for user anonymous

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> Hi all, I'm trying to get some figures ready, but I've
    Andrew> encountered what may be a bug demonstrated by a trivial
    Andrew> program:


Yeah, it's a bug.  Replace the autoscale function in the Locator base
class, which currently raises the NotImplementedError, with

    def autoscale(self):
        'autoscale the view limits'
        self.verify_intervals()
        return self.dataInterval.get_bounds()

Should cure what ails you.

JDH

Hi all,

I'm trying to get some figures ready, but I've encountered what may be a 
bug demonstrated by a trivial program:

from matplotlib.matlab import *

set(gca(),'XTicks',[]) # fails
plot([1,2],[3,4])
#set(gca(),'XTicks',[]) # works
show()

The traceback is:

astraw@aspiring:~/src/py-play/matplotlib$ python no_ticks.py
Traceback (most recent call last):
  File "no_ticks.py", line 4, in ?
    plot([1,2],[3,4])
  File "/usr/lib/python2.3/site-packages/matplotlib/matlab.py", line 
1074, in plot
    try: lines =  gca().plot(*args, **kwargs)
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1361, 
in plot
    self.autoscale_view()
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 426, 
in autoscale_view
    tup = self.xaxis.get_major_locator().autoscale()
  File "/usr/lib/python2.3/site-packages/matplotlib/ticker.py", line 
321, in autoscale
    raise NotImplementedError('Derived must override')
NotImplementedError: Derived must override

This trivial example works if I call set() after plot() although this is 
sometimes inconvenient.  Is this a bug or are there some intricacies I'm 
not aware of?

Cheers!
Andrew

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:

    Flavio> Thanks John, with your patch, it is now possible to plot
    Flavio> vectors with shape(n,1)(column vector). However, vectors
    Flavio> of shape (1,n)(row vector) give the following error:

OK, thanks for the info.  I think I've got a working solution now, at
least as far as plot and friends (semilogx, semilogy, and loglog, all
of which use plot plus a scale change) are concerned.   There may
still be problems in the other plot commands (scatter, hist, bar, etc
since I haven't tested these yet).  I've added the following to my
unit test code

from matplotlib.matlab import *

y1 = arange(10)
y1.shape = 1,10

y2 = arange(10)
y2.shape = 10,1

subplot(411)
plot(y1)
subplot(412)
plot(y2)

subplot(413)
plot(y1, y2)

subplot(414)
X = rand(10,10)
plot(X[:,1], X[1,:], 'o')
savefig('shapes')

I'll try and write some test code for the other plot commands as time
permits.  In the meantime, if you know of any other failures, let me
know.

JDH     

> I agree.  The current design of matplotlib doesn't really support this
> kind of use because it redraws the entire figure every time and does
> too much duplicate work at the python level.  It shouldn't be too hard
> to add some specialized functions for agg that support strip charts.
> I've been planning to do it because we have a need for it here, and
> there is some general on c.l.python for this kind of plotting feature
> in python.
>
> So I can start mulling over the design, can you tell me what kinds of
> real time updates you need - only solid lines or arbitrary symbols
> like 'o' too?  Anything else besides line plots?
>
> I'm envisioning some extension code that talks directly to the data
> source and to the agg backend, updating only part of the canvas.  The
> blitting functions for GTK/WX/Tk Agg would have to be extended to blit
> only a region of the canvas.

We'd also be interested in updates to real-time graph capabilities. 
We've just started examining Python + wxPython as a platform for 
control of some of our robotic systems. I've gotten a real-time bar 
graph running now, but it's awfully inefficient. I modified the basic 
dynamic_demo_wx.py file to update regularly, and at a forced 10 FPS it 
locks out the wxPython interface on my dual 2 GHZ Mac G5. No way it 
should do that ...

We'd also be interested in strip charts, mostly line based. We'd want 
to do multiple lines per chart. A capability to move through time, or 
zooming, might be useful, but certainly not necessary in a first rev 
(just mentioning it for now).

For bar graphs, we have to update at a given rate (typically up to 
about 25Hz), with different colors per bar (I have yet to do this part 
in the example I'm working on - think of multilpe temperatures being 
displayed, and different colors indicating different zones, per bar; 
nominal, caution, danger).

Having said all that, we're currently  using wxPython, and I don't yet 
understand how AGG fits in the picture with matplotlib. :-(

TIA
Stephen

On Fri, 2004-05-28 at 10:56, John Hunter wrote:
> >>>>> "Gary" == Gary Pajer <pa...@in...> writes:
> 
>     Gary> I took out a wristwatch and timed it instead of guessing.  I
>     Gary> get three frames per second.  It's about 4x from where we
>     Gary> started, but still slow.  I guess I'm just underpowered,
>     Gary> although a couple of years ago this was a powerhouse.  It
>     Gary> seems that matplotlib may not be suited to this task.  I
>     Gary> don't think it should take 2 GHz just to power a stripchart.
> 
> One more comment here, mainly for Todd.  
> 
> Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
> anim_tk.py, where both scripts are doing the same thing.  The profiler
> reveals a good chunk of the time is in
> 
>       103    2.300    0.022    2.300    0.022 tkagg.py:4(blit)
> 
> This may be a tk limitation, but I just wanted to point it out to you
> in case there are any optimizations you can apply to that function.

I tried a few things,  but I didn't find anymore performance blunders 
so barring the kind of optimization Perry mentioned,  I think we're
stuck.   I think most of the time is going into Tk_PhotoPutBlock.

> I'll include the anim_tk.py I'm using for profiling below.

I only got 11-12 FPS (for tkagg) on a 1.7 Ghz Pentium-IV...

Todd

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:

    Flavio> Matplotlib 0.54.1 still has trouble plotting column or row
    Flavio> vectors:

Try replacing matplotlib.lines.set_data with the following and let me
know if it passes all your tests.  You will need to add ravel to the
list of functions imported from numerix at the top of the lines
module.

    def set_data(self, x, y):
        try: del self._xc, self._yc
        except AttributeError: pass

        self._x = asarray(x, Float)
        self._y = asarray(y, Float)

        if len(self._x.shape)>1: self._x = ravel(self._x)
        if len(self._y.shape)>1: self._y = ravel(self._y)

        if len(self._y)==1 and len(self._x)>1:
            self._y = self._y*ones(self._x.shape, Float)

        if self._useDataClipping: self._xsorted = self._is_sorted(self._x)

Thanks!
JDH

I'll get this one.  I also have some tkagg/setupext related changes for
Mac OS-X.

Todd

On Fri, 2004-05-28 at 12:55, Anthony Joseph Seward wrote:
> The default location for the tk include files is missing.  The attached
> patch fixes it.

The default location for the tk include files is missing.  The attached
patch fixes it.