matplotlib-users Mailing List for matplotlib (Page 1370)

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.

Hello,

Is there a simple argument to pass to matshow so that it'll print 0 as 
white and 1 as black, and not the opposite as it defaults to ?

--
Yann Le Du

Darren,
All of the error handling code was recently reworked by John to make all of 
the front ends be consistent.  So, that line doesn't even exist in the CVS 
repository anymore.  If you sync to the latest CVS then you should be fine.

You can find the instructions for CVS access here: 
http://sourceforge.net/cvs/?group_id=80706

Ted


At 09:06 AM 2/23/2005, Darren Dale wrote:
>On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> >     Darren> backend_qt.py is present in my cvs directory, but it looks
> >     Darren> like it didnt make it into the MPL-0.72 tarball.
> >
> > This was a problem with the MANIFEST file in the 0.72 release.  I
> > should be fixed in the 0.72.1 bugfix release, which is up on the sf
> > site.
>
>Great! One bug to report. Line 262 of backend_qt.py should read:
>
>error_msg = error_msg_qt
>
>or I get an error:
>
>File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py",
>line 262, in ?
>     error_msg = error_msg
>NameError: name 'error_msg' is not defined
>
>--
>
>Darren
>
>
>-------------------------------------------------------
>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

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

>>>>> "Greg" == Greg Novak <no...@uc...> writes:

    Greg> This is gripe #1: weak typing only works when using
    Greg> undefined variables bites you on the nose.  Otherwise we're

This is a good point -- Norbert submitted a patch addressing this a
couple of months ago but it broke python2.2 so we unrolled it.  I've
added it to my list of things to do.  It's tricky to get right, but
it's manageable and important.

    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.  Now cm may not be the best module name, perhaps cmaps would be
better.  I don't see this as a huge problem since a simple 

  >>> pcolor?  

in ipython would have shown you the correct kwarg.  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.

BTW, do you know you can interactively change the colormap for an
existing plot with the jet, gray, hot, et al commands

  >>> pcolor(rand(12,12))  # use your default colormap
  >>> hot()     # colormap is now hot
  >>> summer()  # colormap is now summer

    Greg> Gripe #3 is related to interactive windows when Python and
    Greg> the X11 server are connected by a slow link.  All of the
    Greg> interactive backends I've used for matplotlib look great,
    Greg> but render very slowly in this situation b/c they're sending
    Greg> all the pixel data.  Since most plots consist of a few
    Greg> lines, a bit of text, and a few dots, it'd be nice if the
    Greg> windows rendered quickly over slow connections.  For
    Greg> example, Gnuplot runs very well in this configuration.  I
    Greg> realize that this doesn't invovle matplotlib per se, I just
    Greg> wanted to throw it out there as a concern.

Perry already addressed this -- basically because we have so many
python GUIs it becomes a maintenance nightmare to add new features if
we use native drawing.  Using agg to render to a bitmap which is then
transferred to a GUI canvas means we can add a feature in one place
and Tk, Wx, GTk, Fltk and QT users automagically get it with *no*
changes to the GUI backend.  It comes with a cost, as you observed.

You do have the option of using a GUI native drawing backend, eg GTK
instead of GTKAgg or WX instead of WXAgg.  Because we use double
buffering in GTK, it may not help (Steve -- would it be possible to
make double buffering optional?)  The native GTK drawing is inferior
to Agg, in my view, but you may be willing to trade quality for
speed.  

There is hope for you, however, that you can have the best of both
worlds.  Steve says that GTK is moving to a Cairo renderer for GTK
2.8, which does provide nice graphics.  And it is a happy confluence
of circumstances that 1) matplotlib has a Cairo backend, 2) the GTK
maintainer (Steve Chaplin) is also the author of the Cairo and
GTKCairo backends and 3) Steve is very good about keeping the GTK*
stuff up to the latest developments in the gtk world.  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.

    Greg> I apologize for the negative tone of this mail.  Don't get
    Greg> me wrong--I use matplotlib and I like it b/c it's the best
    Greg> thing I've found.  However, I just had one of those
    Greg> "GAAARGHGGHHHH!" moments and it's taking a little while to
    Greg> de-stress.

No problem.  With all the fan mail we're getting around here, we're
starting to get a little soft :-).  Some well placed criticism keeps
us on our toes.

Thanks,
JDH

>>>>> "Greg" == Greg Novak <no...@uc...> writes:

    Greg> Not everyone uses matplotlib inside of scripts!  Judging
    Greg> from the manual, this is the only approved way to use the
    Greg> library.

Hmm.  Not quite true.  I hear there is a fellow in Boulder who
sometimes uses matplotlib interactively <wink>.  If the manual gives a
different impression, that is unintentional, and may result from
selective reading.  Did you read section 1.5 with subheading
"Interactive"?  Eg,

   The recommended way to use matplotlib interactively from a shell is
   with ipython, which has an pylab mode that detects your matplotlib
   .matplotlibrc file and makes the right settings to run matplotlib
   with your GUI of choice in interactive mode using threading.  gtk
   users will need to make sure that they have compiled gtk with
   threading for this to work.  Using ipython in pylab mode is
   basically a nobrainer because it knows enough about matplotlib
   internals to make all the right settings for you internally.

Fernando and I have spent a lot of time and effort to make matplotlib
work seamlessly in interactive use.  The issues are non-trivial
because you have to handle threading to keep the GUI from stealing the
show.  Because threading is always involved when using most GUIs from
a python shell, we also provide an example in examples/interactive.py
which three mpl developers collaborated on to show people the
beginnings of how to roll their own custom interactive GTK shell.

I've also added a lot of short aliases for long keywords so you can
do, for example

 >>> plot([1,2,3], ls='--', c='red')

instead of

 >>> plot([1,2,3], linestyle='--', color='red')

Basically, the claim that we only support a scripting interface is not
true.  If you have specific things to suggest to further improve
interactive use, or documentation suggestions, fire away.

    Greg> There seems to be no way to change the backend in the middle
    Greg> of an interactive session.  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"

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.

The first person was Fernando Perez, who has driven many of the
improvements in interactive use because he makes lots of suggestions
and contributes code.  Recently on matplotlib-devel, we discussed the
importance of being able to switch backends interactively
http://sourceforge.net/mailarchive/message.php?msg_id=10724264 and I
provided a pylab_interface function switch_backend which does just
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

But even w/o this ease of use, in the current matplotlib release the
pylab switch_backend function exists.  It's not documented because we
are still exploring and testing it and it is experimental.  But I
added a docstring this morning which I'll paste in here

def switch_backend(newbackend):
    """
    Swtich the default backend to newbackend.  This feature is
    EXPERIMENTAL, and is only expected to work switching to an image
    backend.  Eg, if you have a bunch of PS scripts that you want to
    run from an interactive ipython session, yuo may want to switch to
    the PS backend before running them to avoid having a bunch of GUI
    windows popup.  If you try to interactively switch from one GUI
    backend to another, you will explode.

    Calling this command will close all open windows.
    """


    Greg> I would be extremely happy if there were a way to change
    Greg> backends midstream from an interactive shell (I use ipython,
    Greg> for example)

Good.  You should be extremely happy then.  As I suggested above, this
feature is lightly tested, so let us know what you find.

JDH

On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> backend_qt.py is present in my cvs directory, but it looks
>     Darren> like it didnt make it into the MPL-0.72 tarball.
>
> This was a problem with the MANIFEST file in the 0.72 release.  I
> should be fixed in the 0.72.1 bugfix release, which is up on the sf
> site.

Great! One bug to report. Line 262 of backend_qt.py should read:

error_msg = error_msg_qt

or I get an error:

File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", 
line 262, in ?
    error_msg = error_msg
NameError: name 'error_msg' is not defined

-- 

Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> backend_qt.py is present in my cvs directory, but it looks
    Darren> like it didnt make it into the MPL-0.72 tarball.

This was a problem with the MANIFEST file in the 0.72 release.  I
should be fixed in the 0.72.1 bugfix release, which is up on the sf
site.

JDH

Hi,

I got curious this morning and wanted to try out the QtAgg backend. I get the 
following error when I try to import pylab from a python interpreter:

File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qtagg.py", 
line 12, in ?
    from backend_qt import qt, FigureManagerQT, FigureCanvasQT,\
ImportError: No module named backend_qt

backend_qt.py is present in my cvs directory, but it looks like it didnt make 
it into the MPL-0.72 tarball.

-- 

Darren

On Feb 23, 2005, at 1:28 AM, Greg Novak wrote:
> Gripe #3 is related to interactive windows when Python and the X11
> server are connected by a slow link.  All of the interactive backends
> I've used for matplotlib look great, but render very slowly in this
> situation b/c they're sending all the pixel data.  Since most plots
> consist of a few lines, a bit of text, and a few dots, it'd be nice if
> the windows rendered quickly over slow connections.  For example,
> Gnuplot runs very well in this configuration.  I realize that this
> doesn't invovle matplotlib per se, I just wanted to throw it out there
> as a concern.
>
This is a consequence of how most of the interactive backends are 
implemented. Since matplotlib is using agg to render graphics for them, 
all updates to graphs mean a new image must be transmitted to the 
window. If it is a remote window, that update is going to cost. There 
may be ways of improving the backends so that not the whole window 
needs to be updated, but I have a feeling that isn't going to yield a 
big improvement in many cases (a new plot of points means changes over 
most of the image even if it can be characterized by a relatively small 
number of points and labels). I don't see any great solution to this 
(maybe John has some good ideas). I pointed this out as a consequence 
of going this way before it was done (and I recommended going this way 
:-). 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.)

Perry

Ok, I was so rattled when I wrote the previous message that I forgot
to ask my actual question:

I was trying to change backends midstream because I was only getting
b/w plots when I used pcolor--I couldn't change the colormap.  At
first I thought that this was because I was using the Postscript
backend and for some reason it assumed I wanted b/w output for
printing.  After fooling around with some of the other imaging
backends, I used one of the interactive ones (this is a pain b/c I'm
running Python remotely and I'm sitting at the end of a slow internet
link.  Therefore interactive windows take forever to pop up.  More on
this later), and the plot was still b/w.

After significant frustration, I realized that my problem was that I
was specifying the color map as 'cm=' instead of 'cmap='; a reasonable
guess since the rest of the line is 'cm.hot'  The problem was that
matplotlib silently ignored my misspecified argument.

This is gripe #1: weak typing only works when using undefined
variables bites you on the nose.  Otherwise we're back to the bad old
days of fortran, when misspelling a variable name silently defined a
new variable.  It would be nice if somewhere in the heirarchy of
function calls within matplotlib someone checked to make sure there
were no lonely, unused keyword arguments sloshing around.  I realize
that this is hard to do robustly and with any generality, but there's
a lot at stake.  Python would be unusable if use-before-definition
didn't generate an exception.

Gripe #2 is that it would be nice if the same word were abbreviated
the same way everywhere.  Ie, either cmap or cm, not both.  

Gripe #3 is related to interactive windows when Python and the X11
server are connected by a slow link.  All of the interactive backends
I've used for matplotlib look great, but render very slowly in this
situation b/c they're sending all the pixel data.  Since most plots
consist of a few lines, a bit of text, and a few dots, it'd be nice if
the windows rendered quickly over slow connections.  For example,
Gnuplot runs very well in this configuration.  I realize that this
doesn't invovle matplotlib per se, I just wanted to throw it out there
as a concern.

I apologize for the negative tone of this mail.  Don't get me wrong--I
use matplotlib and I like it b/c it's the best thing I've found.
However, I just had one of those "GAAARGHGGHHHH!" moments and it's
taking a little while to de-stress.

Cheers,
Greg

Not everyone uses matplotlib inside of scripts!  Judging from the
manual, this is the only approved way to use the library.

There seems to be no way to change the backend in the middle of an
interactive session.  Looking through the manual, I find that I can
specify it on the command line, in .matplotlibrc, or via
matplotlib.use('..'), but only "before you import matplotlib.pylab"

I would be extremely happy if there were a way to change backends
midstream from an interactive shell (I use ipython, for example)

Thanks,
Greg

John,

Thanks for the reply. Sorry for the delay, I've been off line for a few 
days.

John Hunter wrote:
>>>>>>"Chris" == Chris Barker <Chr...@no...> writes:

>     Chris> Hi all, Is there a way to get the size of a text object?

> Do you mean the width and height
> in points?

At this point, points. The other option is figure coordinates. The 
problem at hand is that we're generating a figure that has some fairly 
large labels on the Y axis, so we're having to do the layout of subplots 
ourselves. We've got it looking OK with trial and error, but if we 
change a label, it might not layout right anymore, so I thought it would 
be helpful to be able to check the sizes of things to do it automagically.

Besides, aren't there methods to convert between the various coord. 
systems anyway?

> but could be screwed up by a figure resize.

Yeah, it would , but right now I'm working with the AGG backend, so I 
can stick with one figure size.

> FYI, this is an issue that crops up a lot and is vexing.  What one
> would like to be able to do is use a layout engine and say, place
> object one above and to the right of object 2 with a pad of 2 points.

Yes, that would be nice. In fact, I've been planning to do exactly that 
for my wxFloatCanvas. It's easier there because I've only got wx as a 
back end, but still a bit tricky. One thing I've done to help is simply 
declare that I'm always assuming 72dpi, rather than trying to use the 
system's idea of the display resolution. This has helped keep results 
consistent across systems. I have had to re-scale text, however.

> The text instance can give you its bounding box in display if you pass
> it the backend renderer -- this is required because the width and
> height can be backend dependent.  I suppose you are using OO agg based
> on your previous posts.

Mostly, it's a mix as I'm working with someone else and most of the 
examples are in the pylab interface.

> One problem with the current design that is
> that the agg canvas doesn't generate it's renderer until draw time
> (with caching), but you need access to the renderer before draw time
> for layout that depends on text.

Right. So, do any of the default layout's take text into account 
(subplot, for example?)

 > If we move this logic to a
> get_renderer method, you can use it at draw time.  I'll attach a
> replacement backend_agg.FigureCanvasAgg class to support this below
> 
>     from matplotlib.figure import Figure
>     from matplotlib.backends.backend_agg import FigureCanvasAgg
> 
>     fig = Figure()
>     canvas = FigureCanvasAgg(fig)

Didn't you add canvas as a Figure() attribute to support the new 
Figure.savefig() method? (added for me, such service!)

>     renderer = canvas.get_renderer()
>     ax = fig.add_subplot(111)
>     ax.plot([1,2,3])
>     t = ax.text(1,2,'hi mom')
>     bbox =  t.get_window_extent(renderer)
>     print 'display', bbox.get_bounds()  #l,b,w,h
> 
>     # get the axes data coords bbox of this display bounding box
>     from matplotlib.transforms import inverse_transform_bbox
>     axbox = inverse_transform_bbox(ax.transData, bbox)
> 
>     print 'data coords', axbox.get_bounds()
> 
>     fig.savefig('test')

Thanks for this example. I hope I"ll get a chance to play with this 
soon. My schedule is a nightmare for a while.

thanks,

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Tue, 2005-02-22 at 16:46, Perry Greenfield wrote:
> >   - Are Numeric and numarray MAs similar enough to be used at the
> >     C-API level, which is where agg would be checking the mask?  Does
> >     anyone know whether MAs will be part of the Numeric3 core?  I
> >     haven't seen any reference to them in the PEP.
> >
> We'll have to raise it. I imagine that they should be. As I mentioned, 
> NaNs don't solve all the problems that MA does. Since MA is layered on 
> Numeric/numarray it shouldn't be hard to do so. As far as C-API, since 
> it is a Python implementation, I presume it comes down to whether or 
> not the needed attributes are the same for the numeric and Numarray 
> variants. I'm not immediately familiar with that, but Todd should be 
> able to give a fairly quick answer on that (he did the port to 
> numarray)

As Perry said,  numarray.ma is a port of MA to numarray so they're
fairly close.  Both packages are pure Python layered over ordinary
numarray or Numeric numerical arrays.   Accessing from C,  both packages
should yield data or mask information via a method callback.  The
resulting arrays are PyArrayObjects which are source compatible only: 
extensions using MA component arrays will need to be compiled for either
Numeric or numarray as we do now for _image, _transforms, and _contour.

Todd

On Feb 22, 2005, at 4:21 PM, John Hunter wrote:

>>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
>
>     Perry> As far as keyword args go, it seems to me that they would
>     Perry> be more convenient in many cases, but as Stephen mentions,
>     Perry> may be a fair amount of work (and in essence, they are an
>     Perry> attribute of the data, so that may be where they belong).
>
> In the context of plotting, it isn't clear that NaNess is an attribute
> of the data.  If the data are y = sin(2*pi*t), then NaNess enters only

I meant masks were an attribute of the data, but not NaNs (in other 
words, the way MA handles it may be the most appropriate)

Perry

On Feb 22, 2005, at 4:21 PM, John Hunter wrote:

>>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
>
>     Perry> As far as keyword args go, it seems to me that they would
>     Perry> be more convenient in many cases, but as Stephen mentions,
>     Perry> may be a fair amount of work (and in essence, they are an
>     Perry> attribute of the data, so that may be where they belong).
>
> In the context of plotting, it isn't clear that NaNess is an attribute
> of the data.  If the data are y = sin(2*pi*t), then NaNess enters only
> under certain transformations (eg log) of the data.  From my
> perspective, or the perspective of a matplotlib Line, the data are
> intact, it is just that under certain transformations the data are
> invalid.  Thus the mask is only needed under certain views
> (transformations) which the Line class is mostly unaware of.  I think
> there are two cases to be distinguished: the case Eric mentioned where
> some data points are NaN or None because the measurements are missing
> or invalid, and the case where the data are valid but are nan under
> certain transformations.
>
Right.

> For the latter, it would be maximally useful to be able to do
>
>   #x,y,xt,yt are numerix arrays; transform puts in NaN on domain error
>   xt, yt = transform(x, y)
>
> and the drawing routine drops NaN points and handles the connecting
> segments properly.  That it only works for float arrays is not a
> problem since that is what we are using, eg in the line class
>
>         self._x = asarray(x, Float)
>         self._y = asarray(y, Float)
>
> but it is my current understanding that this ain't gonna happen in a
> consistent way for Numeric, Numeric3, and numarray across platforms,
> because my brief forays into researching this issue turned up posts by
> Tim Peters saying that there was no standard way of dealing with IEEE
> 754 special values across compilers.  If that's true, and we can't fix
> it or work around it, then I think boolean masks passed as a kwarg may
> be the easiest way to handle this across various numerix
> implementations, assuming that Numeric3 comes to fruition and assuming
> that there isn't a consistent MA approach that is accessible at the
> API level, which I don't know to be true but I get the feeling that
> this is a reasonable guess.
>
I think you may be over-extending what Tim was saying. I believe the 
issue is writing C code that handles things like tests against NaN 
values correctly. In that, Tim is right, there is a great deal of 
inconsistency in how C compilers handle ieee special values. But 
generally speaking, the computations *are* handled consistently by the 
floating point processors. numarray solved this problem by not relying 
on the C compiler to test or set NaN values (it tests raw bit patterns 
instead) and so should handle this issue properly. Numeric doesn't, but 
Numeric3 is planned to. So I think NaNs can't be handled right now 
because of Numeric, but I don't think the C compiler issue that Tim 
mentions is a roadblock (it is a nuisance for implementation though)..

> I'd be interested in getting feedback from those of you who have
> informed opinions on these matters:
>
>   - Is it possible to handle NaN in Numeric/numarray arrays across the
>
>   big three platforms?  I'm pretty sure the answer here is no.
>
No for Numeric, yes for numarray/Numeric3

>   - Are Numeric and numarray MAs similar enough to be used at the
>     C-API level, which is where agg would be checking the mask?  Does
>     anyone know whether MAs will be part of the Numeric3 core?  I
>     haven't seen any reference to them in the PEP.
>
We'll have to raise it. I imagine that they should be. As I mentioned, 
NaNs don't solve all the problems that MA does. Since MA is layered on 
Numeric/numarray it shouldn't be hard to do so. As far as C-API, since 
it is a Python implementation, I presume it comes down to whether or 
not the needed attributes are the same for the numeric and Numarray 
variants. I'm not immediately familiar with that, but Todd should be 
able to give a fairly quick answer on that (he did the port to 
numarray)

Perry