matplotlib-users Mailing List for matplotlib

the marker 'x' (ex: plot(a,b,'bx',markersize=5) are not working anymore 
(at least version 0.72.1 and cvs) with Agg backend and derived  (TkAgg 
and GTKAgg). With PS or PNG backends it's ok.

The error message is:

Traceback (most recent call last):
 File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", line 1345, in __call__
   return self.func(*args)
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 140, in resize
   self.show()
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 143, in draw
   FigureCanvasAgg.draw(self)
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 319, in draw
   self.figure.draw(self.renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/figure.py", 
line 338, in draw
   for a in self.axes: a.draw(renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py", line 
1296, in draw
   a.draw(renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", line 
294, in draw
   markerFunc(renderer, gc, xt, yt)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", line 
1044, in _draw_x
   renderer.draw_line(gc, x-offset, y-offset, x+offset, y+offset)
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 155, in draw_line
   self._renderer.draw_lines(gc, x, y)
IndexError: Unexpected SeqBase<T> length.


thanks.

Hi all,
I'm an absolutely matplotlib newbie, so I'm sorry if my question is 
trivial. Anyway I've read the user guide and looked at the examples 
without finding out a solution.

Here it is my problem. Suppose I have a 2-dimensional array containg my 
data, and I want to produce a surface or a contour plot with it. Now 
the  imshow() function seems the right way to go through. So far so 
good. Now suppose I want to draw the x,y axes for this plot, and 
suppose my axes are represented by **not-uniform** 1-dimensional array 
x[i], y[j]. How can I get the right ticks on the plot axes??

I hope to have been clear. Thanks in advance,
  Andrea.

the marker 'x' (ex: plot(a,b,'bx',markersize=5) are not working anymore 
(at least version 0.72.1 and cvs) with Agg backend (and TkAgg and 
GTKAgg). With PS backend it's ok.

The error message is:

Traceback (most recent call last):
  File "/astro/homes/gruel/usr/local//lib/python2.4/lib-tk/Tkinter.py", 
line 1345, in __call__
    return self.func(*args)
  File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 140, in resize
    self.show()
  File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 143, in draw
    FigureCanvasAgg.draw(self)
  File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 319, in draw
    self.figure.draw(self.renderer)
  File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/figure.py", 
line 338, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py", line 
1296, in draw
    a.draw(renderer)
  File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", 
line 294, in draw
    markerFunc(renderer, gc, xt, yt)
  File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", 
line 1044, in _draw_x
    renderer.draw_line(gc, x-offset, y-offset, x+offset, y+offset)
  File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 155, in draw_line
    self._renderer.draw_lines(gc, x, y)
IndexError: Unexpected SeqBase<T> length.


thanks.

This is somewhat off topic, but:  I've been trying to build matplotlib 
(and numarray and scipy for that matter) with 'python setup.py 
bdist_rpm'.  This works fine on a Fedora Core 3 system.  It does not 
work on FC1 with its default Python 2.2 installation, nor does it work 
if I install Python 2.3 from the FC1 RPMs at python.org and do 
'python2.3 setup.py bdist_rpm' on the FC1 system.  The version of 
distutils on the FC3 system and the FC1 Python 2.3 install seems to be 
the same. Since the FC1 system is supposed to be a stable server, I'm 
loathe at the moment to risk updating it to FC3.

Any help?

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:

    Malte> John, When do you expect this to be implemented?

    Malte> I'd like to roll out a package depending on matplotlib and
    Malte> have a request for this specific feature.

I took a look at implementing this last week and talked with Fernando
Perez who did the matplotlib pylab support for ipython, we came to the
conclusion, that this needs to be done at the interactive shell
level.  The basic problem is that although you are blocking, you need
to still share cpu time with the gui thread, so that you can continue
to interact with your plot and generate events.  What shell and
backend are you using?

In the meantime, you might want to suggest this idiom to your user who
is asking for a blocking event

class Catcher:
    event = None
    def __call__(self, event):
        self.event = event

plot([1,2,3])
c = Catcher()

connect('button_press_event', c)

# no go click on the axes
print c.event.xdata, c.event.ydata

# and click somewhere else
print c.event.xdata, c.event.ydata

So even though the call is not blocking you have ready access to the
event data in as way that doesn't feel like event driven programming
with callbacks.

I like this approach, actually.  I wonder if it would be useful to
assign some new pylab module variables

bp = Catcher()
connect('button_press_event', bp)

br = Catcher()
connect('button_release_event', br)

kp = Catcher()
connect(key_press_event', kp)

and so on.  Then in the pylab interface, w/o making any connections
yourself, you would always have access to the last keypress event as

kp.event

and so on.

Do people think this would be useful for interactive work?

JDH

Hi Hans,

Let me ask, what do you think would be the correct labels? As I remember, 
Matlab will go out to 4 decimal points, so your ticks would be labeled 
1,1.0000,1.0000.

I have been meaning to do some work with the tick formatters. It has been 
suggested here that all significant digits are preserved, so for example, 
your ticks would be 1,1,1 (If you want to go out to 9 sig digits, I think you 
would have to write your own custom formatter, which is discussed on this 
list and in the user's guide). If you ticks are 1,1.01,1.02, the labels would 
be 1.00,1.01,1.02. I think this results in the best looking result, but I'd 
like to know others opinions before I start. Also, for ticks like 
1e5,2e5,3e5, I am intending to make the ticks 1,2,3, and have a x10^5 just 
outside the axis or in the last label. Comments, suggestions?

Darren

On Thursday 24 February 2005 05:53 am, Hans Fangohr wrote:
> Dear Matplotlib developers,
>
> running the following program
>
> import pylab
>
> x=pylab.arange(0,1e-8,1e-9)+1.0
> pylab.plot(x)
> pylab.show()
>
> with matplotlib 0.70.1 results in a graph that shows:
>
> (i) correctly the linear increase of x
> (ii) but the labels on the y-axis of the plot all show "1e", apart from
> the lowest one, which shows (correctly) just "1".
>
> All works fine when I subtract the mean of x but there seems to be a
> problem with labelling axes for plotted data which is not close to zero
> but shows only small variations.
>
> By the way: thank you for providing matplotlib.
>
> Cheers,
>
> Hans
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 

Darren

Dear Matplotlib developers,

running the following program

import pylab

x=pylab.arange(0,1e-8,1e-9)+1.0
pylab.plot(x)
pylab.show()

with matplotlib 0.70.1 results in a graph that shows:

(i) correctly the linear increase of x
(ii) but the labels on the y-axis of the plot all show "1e", apart from 
the lowest one, which shows (correctly) just "1".

All works fine when I subtract the mean of x but there seems to be a 
problem with labelling axes for plotted data which is not close to zero 
but shows only small variations.

By the way: thank you for providing matplotlib.

Cheers,

Hans

Upfront disclaimer: like I said yesterday, I wrote those e-mails when
my frustration with a number of things completely boiled over.  Then I
just core dumped everything that was bothering me into the mails.
Probably the only thing that's useful beyond the scope of the specific
problems I was experiencing are my comments about unused keyword
arguments. 

* Perry Greenfield <pe...@st...> wrote:
>>Gripe #3 is related to interactive windows when Python and the X11
>>server are connected by a slow link.  
> This is a consequence of how most of the interactive backends are 
> implemented. 
> ...
> Implementing the backends using their built in plotting commands 
> may be a way around this, but it means having much higher maintenance 
> costs for backends and lots of annoying capability mismatches (some 
> backends don't support rotated text, alpha blending, etc.)

I figured it was something like this, and I can understand that the
benefits of a common rendering engine outweigh the admittedly small
benefit of fast remote X11 redraws.  Furthermore I've more or less
solved the problem for myself by using non-interactive backends with a
combination of scripts and ssh tunnels that watch for changes in a
file on the remote machine and, when it is modified, sends the file
over the link, where (similarly) a script is watching for changes in
the _local_ file and lauches a viewer.  Not sure why this seems to
make a difference (all the pixel data is going over the channel in
either case) but it seems to make a big difference.

* John Hunter <jdh...@ni...> wrote:
>   Greg> Gripe #2 is that it would be nice if the same word were
>   Greg> abbreviated the same way everywhere.  Ie, either cmap or cm,
>   Greg> not both.
> I don't think I agree with you here.  matplotlib.cm is a *module* and
> cm is a convenient reference to that module for pylab interactive
> users who want to save on keystrokes.  I think it would lead to
> confusion and hard to find bugs if a module name and a kwarg were the
> same.  

Not sure why this is the case.  I realize that they're different
entities in the language, but they both help you with the same task.
Context always (?) allows the Python interpreter to know the
difference, and the exceptions that are thrown by problems with each
are different.  As a user, the thought that goes through my head when
I'm using either one is "Something related to colormaps" and there's
an extra cognitive load associated with remembering that "Modules
related to colormaps" requires cm while "Arguments related to
colormaps" requires cmap.

> I don't see this as a huge problem since a simple pcolor?
> in ipython would have shown you the correct kwarg.  

True, but we're aiming high here.  If I didn't care about things like
this, I'd use Fortran or C because everyone else does and I certainly
wouldn't have taken an interest in Python.  If you can just guess
without referring to documentation and have software do what you want,
I think that's a sign of an elegant interface: it has anticipated my
desires.

> And if mpl had raised an exception on seeing cm as a kwarg as you
> suggest in gripe#1, it wouldn't have been a problem for you.

Quite true!  The extra cognitive load would still be there, but
addressing grip #1 effectively would make this into a very small
annoyance rather than something that can cause real frustration.

> So in the near future, we may have a GTK backend that uses native
> drawing and looks good too.  In which case you may get speed over an
> X11 connection as well as nice looking plots.

This sounds great.  :-)

>   Greg> Not everyone uses matplotlib inside of scripts!  Judging
>   Greg> from the manual, this is the only approved way to use the
>   Greg> library.
> If the manual gives a different impression, that is unintentional,
> and may result from selective reading.
> ...
> Basically, the claim that we only support a scripting interface is
> not true.

I didn't mean to imply that this was a policy decision, only that it
seems to be an assumption that's made often in the manual.
Specifically the thing that set me off was what I referred to here:

>   Greg> Looking through the manual, I
>   Greg> find that I can specify it on the command line, in
>   Greg> .matplotlibrc, or via matplotlib.use('..'), but only "before
>   Greg> you import matplotlib.pylab"

I couldn't figure out why matplotlib.use(...) didn't seem to be doing
anything, and then I found the bit about it only working before you
import matplotlib.pylab.  This is where my frustration boiled over,
and I dashed off the e-mail.  That probably wasn't a great idea
(writing while angry) but what can I say?  All of this together set me
off.

> matplotlib development usually happens when a developer needs a
> feature or one or more users make a case that a feature is important
> -- you are officially the second person to request the ability to
> switch backends interactively, if memory serves.

I'm certainly open to the idea of contributing code, but at this point
I'm obviously not in a position to do so since I'm still learning my
way around.  Also, I can see that interactively switching
backends will be a seldom used feature.  My desire for it (and
excessive frustration when I failed to find it) were due to an unhappy
confluence of events.

> that.  As you'll see in that thread, Fernando is looking into ways to
> include the backend switching functionality into ipython, eg so you
> can run a script with
>>> run -backend PS somefile.py

It's true that this is done from an interactive Python shell, but I
wouldn't call this switching backends interactively.  In general my
.py files contain only function definitions.  So I would envision
being able to do things like this:

>>> %run defs.py
>>> z = read_data()
>>> make_plot(z)
>>> switch_backend('PS')
>>> make_plot(z)

Now, please keep in mind my comments above: that once I use mpl a
little more and establish a regular pattern of use, I don't expect
to need this feature much, if at all.  I'm just commenting on the
example you gave.

> But even w/o this ease of use, in the current matplotlib release the
> pylab switch_backend function exists.  

Cool, I'll certainly give it a shot.

Thanks,
Greg

>>>>> "Tim" == Tim Leslie <ti...@cs...> writes:

    Tim> I'm working with data sampled at 500Hz but as you would know
    Tim> we're more interested in the 0-50Hz range. Is the some way to
    Tim> get the specgram() function to only show up a particular
    Tim> frequency range rather than downsampling the data to a lower
    Tim> sampling rate? I'm currently plotting with

    Tim>     specgram(data, Fs=500) colorbar() show()

Set the ylimits of the specgram axes to show only the frequency bad of
interest

  specgram(data, Fs=500)
  ylim(0, 40)
  colorbar()


    Tim> but I'm not too sure where to go from here to achieve my
    Tim> aims.

    Tim> Thanks in advance and for putting together an amazingly
    Tim> useful package.

Your welcome!  You may want to check out my eegview package at
http://pbrain.sf.net.  It's poorly documented and I don't have a lot
of time to support it currently, but there is already a lot there and
if you wanted to contribute some effort to that rather than starting
over, that would be great.  We are in the process of trying to hire
someone to help with the development, maintenance and documentation of
that package, so I suspect it will see some activity in the not too
distant future.

JDH

Hi John (and others),

I'm working with EEG data and want to use a specgram similar to what you
have in the example at the bottom of 

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

I'm working with data sampled at 500Hz but as you would know we're more
interested in the 0-50Hz range. Is the some way to get the specgram()
function to only show up a particular frequency range rather than
downsampling the data to a lower sampling rate? I'm currently plotting
with 

    specgram(data, Fs=500)
    colorbar()
    show()

but I'm not too sure where to go from here to achieve my aims.

Thanks in advance and for putting together an amazingly useful package.

Tim Leslie

John,

When do you expect this to be implemented?

I'd like to roll out a package depending on matplotlib and have a request for 
this specific feature.

Cheers,
Malte.