matplotlib-users Mailing List for matplotlib (Page 1434)

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

    Andrew> Hi all, I'd like use matplotlib to draw shapes on a
    Andrew> transparent background using the Agg backend to save .png
    Andrew> files. Is this possible?

    Andrew> I've tried

    Andrew> fig._figurePatch.set_alpha(0)

There is a vestigial limitation from the bad old days when we didn't
have an alpha channel.  For polyons, there is no place holder for a
separate alpha channel for the edge and face.  The way to do this
right is to simply replace all rgb instances throughout the library
with rgba, but this is a fair amount of work that touches the entire
library.  What I am doing currently is sharing the alpha attribute
between edge and face for polygons.

So setting alpha=0 *should work. What backend and version are you
using?  Rectangle calls gc.set_alpha before calling draw_polygon in
patches.Patch.  In _backend_agg.RendererAgg.draw_polygon, the alpha
attribute for the face is taken from the edge which gets it from the
gc (around line 204 in _backend_agg).  I say all this just because
from my read of the code *it should* work, and indeed, in my tests

  f = figure(1, facecolor='r')
  f._figurePatch.set_alpha(0.0)

does work for me using Agg and the latest matplotlib.

What backend and version are you using?

That said, the best way to do this is to add a frameon attribute for
figures, because this will be respected across backends including
those who don't understand alpha.  This way you can say

f = figure(1, frameon=False)

I checked this into CVS.

JDH





    Andrew> This seems to get halfway, but there's still (opaque)
    Andrew> white drawn in the background.

    Andrew> Is there a "recommended way", and, if so, what is it?
    Andrew> Otherwise, can we improve matplotlib to allow drawing on
    Andrew> transparent backgrounds?

    Andrew> Cheers!  Andrew


    Andrew> -------------------------------------------------------
    Andrew> This SF.Net email is sponsored by: Oracle 10g Get
    Andrew> certified on the hottest thing ever to hit the
    Andrew> market... Oracle 10g. Take an Oracle 10g class now, and
    Andrew> we'll give you the exam FREE.
    Andrew> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
    Andrew> _______________________________________________
    Andrew> Matplotlib-users mailing list
    Andrew> Mat...@li...
    Andrew> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

>>>>> "MWallis" == MWallis  <mw...@sw...> writes:

    MWallis> I have 5 plots in one window that I am updating
    MWallis> dynamically and the GUI starts to freeze.  Each of the
    MWallis> plots has its own timeout.  Is there a better way of
    MWallis> doing this or can I put the plots on different threads?

    MWallis> Any suggestions would be appreciated.

Hi Melissa,

You may look into doing an idle_add instead of a timeout_add.  The
former only draws when the processor is idle.  Perhaps it is taking
you longer to draw than the frequency that you are calling the draw
functions with the timer, getting you into trouble.

Also, you had asked earlier about one canvas with many axes versus
many canvases embedded in GTK and my answer was it "it depends on
layout considerations".  Now that I see better what you are trying to
do, I'd like to add that it will likely be more efficient to
dynamically update several axes on the same canvas than to separately
update many canvases.

def myfunc(*args):
   # update all the figures and draw
   return gtk.TRUE     

idle_add(c.idle_function)

JDH

when running the following simple script:

from matplotlib.matlab import *
from numarray import *

theta = arange(0.0,8*pi,0.1)
a=1
b=.2

dt = 0.0
x = a*cos( theta )*exp(b*theta)
y = a*sin( theta )*exp(b*theta)

plot(x,y)
show()
#savefig('ss')

with the following combination of software:

matplotlib 0.54
numarray 0.9
python 2.2.1
windows XP

if I use WXAgg or Agg, I get this:

Traceback (most recent call last):
  File "simple_spiral.py", line 13, in ?
    show()
  File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_wx.py", line 
1124, in show
    figwin.canvas.draw()
  File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_wxagg.py", 
line 50, in draw
    agg.draw()
  File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_agg.py", line 
299, in draw
    self.figure.draw(self.renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\figure.py", line 128, 
in draw
    for a in self.axes: a.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\axes.py", line 603, in draw
    self.xaxis.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 463, in draw
    tick.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 125, in draw
    if midPoint and self.tick1On: self.tick1line.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 193, in 
draw
    self._lineFunc(renderer, gc, xt, yt)
  File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 326, in 
_draw_solid
    renderer.draw_lines(gc, xt,yt)
TypeError: can't convert complex to float; use e.g. abs(z)

if I use PS, I get this:

Traceback (most recent call last):
  File "simple_spiral.py", line 14, in ?
    savefig('ss')
  File "C:\Python22\Lib\site-packages\matplotlib\matlab.py", line 1156, 
in savefig
    manager.canvas.print_figure(*args, **kwargs)
  File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
378, in print_figure
    self.figure.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\figure.py", line 128, 
in draw
    for a in self.axes: a.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\axes.py", line 603, in draw
    self.xaxis.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 463, in draw
    tick.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 125, in draw
    if midPoint and self.tick1On: self.tick1line.draw(renderer)
  File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 193, in 
draw
    self._lineFunc(renderer, gc, xt, yt)
  File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 326, in 
_draw_solid
    renderer.draw_lines(gc, xt,yt)
  File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
103, in draw_lines
    ps.append('newpath %s moveto' % _nums_to_str((x[0], y[0])))
  File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
36, in _nums_to_str
    return ' '.join([_int_or_float(val, fmt) for val in seq])
  File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
41, in _int_or_float
    ival = int(val)
TypeError: can't convert complex to int; use e.g. int(abs(z))

Hi all,

I'd like use matplotlib to draw shapes on a transparent background using 
the Agg backend to save .png files. Is this possible?

I've tried

fig._figurePatch.set_alpha(0)

This seems to get halfway, but there's still (opaque) white drawn in the 
background.

Is there a "recommended way", and, if so, what is it?  Otherwise, can we 
improve matplotlib to allow drawing on transparent backgrounds?

Cheers!
Andrew

>>>>> "MWallis" == MWallis  <mw...@sw...> writes:

    MWallis> I am trying to dynamically update some figures that I
    MWallis> have embedded in GTK.  The figures display fine and if I
    MWallis> minimize and then maximize the window the figures update
    MWallis> but I can't get the figures to update dynamically as you
    MWallis> watch the window.  To try and get this working I used the
    MWallis> code from one of the dynamic samples and just embedded it
    MWallis> in my application.

Hi Melissa,

You were using kind of a hybrid of what I call the matlab interface
and the application interface, so I rewrote your example in the way I
would do it if I were embedding the dynamic demo in a GTK
application.  The code is for the latest release (0.54) where some of
the API changed as discussed in the release notes, and would be
slightly different for earlier versions of matplotlib.

The major difference is that under the new API, you create axes and
subplots from a Figure instance with, for example,

  self.ax = self.figure.add_subplot(111)

Hope this helps,
John 

import pygtk
pygtk.require('2.0')
import gtk
import time
from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as FigureCanvas
from matplotlib.figure import Figure
from matplotlib.matlab import *



class C:
    def __init__(self):
        self.figure  = Figure( figsize=(8,6), dpi=72)
        self.canvas = FigureCanvas(self.figure)  # a gtk.DrawingArea

        self.ax = self.figure.add_subplot(111)

        self.win = gtk.Window()
        self.win.set_name("Embedding in GTK")
        self.win.connect("destroy", gtk.mainquit)
        self.win.set_border_width(5)

        self.win.add(self.canvas)

    def create_AntennaResponseDisplay (self, title):



        ind = arange(1,9)
        p1,p2,p3,p4,p5,p6,p7,p8 = self.ax.bar(ind, self.get_stats())
        centers = ind + 0.5*p1.get_width()
        p1.set_facecolor('b')
        p2.set_facecolor('b')
        p3.set_facecolor('b')
        p4.set_facecolor('b')
        p5.set_facecolor('b')
        p6.set_facecolor('b')
        p7.set_facecolor('b')
        p8.set_facecolor('b')

        self.ax.set_xlim([0.5,9])
        self.ax.set_xticks(centers)
        self.ax.set_ylim([0,100])
        self.ax.set_xticklabels(['1', '2', '3', '4', '5', '6', '7', '8'])
        t = self.figure.text(0.5, 0.95, title,
            horizontalalignment = 'center', fontsize = 10,)


        def updatefig(*args):
            e1, e2, e3, e4, e5, e6, e7, e8 = self.get_stats()

            p1.set_height(e1)
            p2.set_height(e2)
            p3.set_height(e3)
            p4.set_height(e4)
            p5.set_height(e5)
            p6.set_height(e6)
            p7.set_height(e7)
            p8.set_height(e8)

            self.ax.set_ylim([0,100])
            self.canvas.draw()

            return gtk.TRUE

        gtk.timeout_add(250, updatefig)
        self.canvas.show()
        self.win.show()
        gtk.mainloop()
        
    def get_memory(self):
        "Simulate a function that returns system memory"
        return 100*(0.5+0.5*sin(0.5*pi*time.time()))

    def get_cpu(self):
        "Simulate a function that returns cpu usage"
        return 100*(0.5+0.5*sin(0.2*pi*(time.time()-0.25)))


    def get_net(self):
        "Simulate a function that returns network bandwidth"
        return 100*(0.5+0.5*sin(0.7*pi*(time.time()-0.1)))



    def get_stats(self):
        return self.get_memory(), self.get_cpu(), self.get_net(), \
               self.get_memory(), self.get_cpu(), self.get_net(), \
               self.get_memory(), self.get_cpu()

c = C()
c.create_AntennaResponseDisplay('Test!')

What's new in matplotlib 0.54
=============================

I've done a lot of rewriting of the core of matplotlib to support some
new features - mainly fast handling of polygon collections (pcolor and
scatter) and since the changes were pervasive, I took to opportunity
to fix some things that were bugging me about the design of
matplotlib.  If you use the API, creating your own Axes, Subplots,
Lines, Rectangles, Texts, or working directly with transforms and
bboxes, you will need to upgrade your code, since the constructors of
all these objects have been simplified.  The major changes affecting
users of the matlab interface are for pcolor and scatter.  These
changes and others are detailed below and in
http://matplotlib.sf.net/API_CHANGES.  Sorry for the pain - in the
long run, the new design is much cleaner and easier to work with, and
as far as I can see, will be stable.

More general transformation architecture
----------------------------------------

Earlier versions of matplotlib handled transformation of x and y
separately (ie we assumed all transformations were separable) but this
makes is difficult to do rotations or polar transformations, for
example. The new transformation lays the framework for doing general
transformations; see the transforms module
http://matplotlib.sf.net/matplotlib.transforms.html.

More efficient pcolor
---------------------

pcolor is now implemented with matplotlib.collections.  polygon
collections which should provide significantly faster performance
across backends. The return value from pcolor is now a PolyColleciton
object rather than a list of patches, but the API is largely
compatible. See http://matplotlib.sf.net/API_CHANGES. The old function
pcolor_classic is retained for full backward compatibility.

New scatter plots
-----------------

The http://matplotlib.sf.net/matplotlib.matlab.html#-scatter command
is rewritten, and is implemented in the backend with a new polygon
collection class. For large scatter plots, the performance is 5 times
faster across all backends and 10 times faster for the *Agg
backends. Also, scatter works with many symbols: diamonds, sqaures,
oriented triangles, circles and more. As with pcolor, the scatter
command returns a collection instance rather than a list of patches as
before; see See http://matplotlib.sf.net/API_CHANGES


Also the size argument is now in points^2 (the area of the symbol in
points) and is not in data coords as before. This fixes a few
problems: symbols are not skewed by unequally shaped axes, scatter
works with log coords w/o distoring the symbol, and it is matlab
compatible.

The function scatter_classic is the old scatter function and will work
identically.

Enhanced mathtext
-----------------

A significant rewrite of the mathtext module provides much more
precise layout. The freetype component has been factored out of the
layout engine and replaced by an abstract class for font
handling. This lays the groundwork for ps mathtext. The text clipping
problems have been fixed. Added spacing commands '\/' (small space)
and '\ ' (regular space), and '\hspace{frac}' (space is fraction of
pointsize) as well as composite chars such as \angstrom. Fixed
over/under subscripts so you can say x_i^j and nested subscripts if
you do x_i_{j} (you need the curlys)

Many new plot symbols and markers
---------------------------------

Thanks Gary Ruben. See
http://matplotlib.sf.net/matplotlib.matlab.html#-plot

Font cacheing
-------------

Paul Barrett added caching support to the font manager to increase
performance. This and other changes have dramatically improved
postscript backend performance.

Newlines in text
----------------

After much encouragement from Al, I finally got around to supporting
newline separated text in the Text frontend, so this is no longer
backend dependent. As a bonus, it even works with arbitrary
rotations. There is an additional text attribute 'multialignment' that
specifies the alignment of the lines in multiline text. See
http://matplotlib.sf.net/examples/multiline.py and
http://matplotlib.sf.net/screenshots.html#align_text. Works with all
text instances except mathtext.

Axes hold
---------

matlab compatible hold command determines whether subsequent plot
commands overlay current plot or clear the axes by default. Default
setting is set in matplotlibrc and toggled by the hold command.

New rc file options
-------------------

You can control grid properties and tick padding (the space between
the axes and tick label) in matplotlibrc. The new options and defaults
are

axes.hold        :   True    # whether to clear the axes by default on
                             #  each plot command.  Toggle with hold command
grid.color       :   k       # grid color
grid.linestyle   :   :       # dotted
grid.linewidth   :   0.5     # in points            

tick.major.pad      : 4       # distance to major tick label in points
tick.minor.pad      : 4       # distance to the minor tick label in points


Full dash control
-----------------

You can precisely control the dashes with a sequence of on off ink in
points. See http://matplotlib.sf.net/examples/dash_control.py

Removed close buttons from GUI
------------------------------

Steve Chaplin persuasively argued these were a bad idea. It's taken me
a while not to instinctively try and click on the missing buttons, but
I'm used to it now.

Properly aligned text with arbitrary alignments
-----------------------------------------------

You can now expect horizontal and vertical alignment specifications to
work with text at an arbitrary angle, eg, 45 degrees. See
http://matplotlib.sf.net/examples/alignment_test.py

Added stem plotting command
---------------------------

See http://matplotlib.sf.net/matplotlib.matlab.html#-stem and
http://matplotlib.sf.net/examples/stem_plot.py

Bug fix roundup
---------------

Executive summary: fixed ps centering, errorbar autoscaling, constant
data plot, copy tick attribute, mathtext fontsizing in interactive
mode, missing draw if interactive, some numerix/numarray
incompatibilities in type handling, agg memory leak, wx tooltips and
close not returning interpreter.

See http://matplotlib.sf.net/CHANGELOG for details. 


Downloads at http://sourceforge.net/projects/matplotlib

has anyone come across this bug?

>>> from matplotlib.matlab import *

>>> a = arange(10)

>>> a.shape

(10,)

>>> plot(a)

[<matplotlib.lines.Line2D instance at 0x4147712c>]

>>> show()


this plot works ok but if we turn a into a one dimensional array then...

>>> a.shape=(10,1)

>>> a.shape

(10, 1)

>>> plot(a)

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

  File "/usr/lib/python2.3/site-packages/matplotlib/matlab.py", line 941, in plot

    try: lines =  gca().plot(*args, **kwargs)

  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1181, in plot

    self.yaxis.autoscale_view()

  File "/usr/lib/python2.3/site-packages/matplotlib/axis.py", line 405, in autoscale_view

    tup = self._majorTicker.locator.autoscale()

  File "/usr/lib/python2.3/site-packages/matplotlib/ticker.py", line 578, in autoscale

    self._locator = self.get_locator(d)

  File "/usr/lib/python2.3/site-packages/matplotlib/ticker.py", line 589, in get_locator

    fld = math.floor(ld)

TypeError: only rank-0 arrays can be converted to Python scalars.

>>>

>>>>> "Todd" == Todd Miller <jm...@st...> writes:

    Todd> (2) I could just build a numarray version of the matplotlob
    Todd> installer with each release.  That would offload the work
    Todd> from you and would keep the matplotlib code cleaner.

If you want to do that I have no objections - I like this better than
maintaining both in a single build.  I think we need to make the
matplotlib code work with either build (eg using the nx.Type scheme
you proposed) so that if the user switches their numerix setting with
a given build everything still works.  But if there is interest in a
numarray build for win32, I see no reason why not.  We should probably
be careful to coordinate so that the two releases are as similar as
possible, with the only difference being the default numerix setting
in the rc file.

JDH

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> I had looked at that. I'm a little confused by the
    Perry> terminology though.  This sounds like a prescription for
    Perry> changing the defaults for some parameters for a session
    Perry> rather than for a single figure. Do I misread that? (Also,
    Perry> on my browser these entries are much wider than the browser
    Perry> window for some reason; later in the faq that changes as do
    Perry> some of the fonts. I wonder if something is screwed up
    Perry> there).

You were rightfully confused.  It said figure when it should say
session.  I mainly work from scripts, with one figure per script, so I
was just munging them in my mind.  I made a brief update to the FAQ in
my own tree, but with the dynamic customization you discuss below,
this will need to be updated again.

As for the browser problem, I have the same.  I tried to spot an html
error that would explain it but haven't found it yet.

    Perry> Changing the use of the rcParams to be immediate rather
    Perry> than locked in at module initialization is more attractive
    Perry> to me (and may allow one to assign differnt rc sets to
    Perry> different backends by default as well; but that is not
    Perry> urgent). Do you mind changing when the parameters are
    Perry> picked up? (I'm asking that you do it now, just whether
    Perry> that is acceptable).

This seems like the way to go.  Nothing really speaks against it
except the slightly inelegant use of a bunch of Nones in the
constructors.  I'm happy to make the changes, or leave it to one of
you.

JDH

John Hunter wrote:
> >>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
> 
>     Perry> Is there a means of using alternate rcParams dictionaries
>     Perry> for use with different backends, say as a parameter to the
>     Perry> print_figure method? It doesn't look like it at the
>     Perry> moment. I'd guess to do that now means replacing rcParams
>     Perry> temporarily, rendering the plot to the file, and resetting
>     Perry> rcParams to what it was (I haven't actually tried it), but
>     Perry> that seems clumsier than it should be.
> 
> There are a few ways to go here.
> 
> Probably the best is based on the answer to "How do I customize the
> default behavior of a single figure?"
> http://matplotlib.sourceforge.net/faq.html#CUSTOM
> 
I had looked at that. I'm a little confused by the terminology though.
This sounds like a prescription for changing the defaults for some
parameters for a session rather than for a single figure. Do I
misread that? (Also, on my browser these entries are much wider
than the browser window for some reason; later in the faq that changes
as do some of the fonts. I wonder if something is screwed up there).

[details about setting up session context and object intialization
snipped]

I'm thinking of the case where someone tailors plots interactively
and then wants to render the same plot, but with different defaults
for a png file or postscript in the same session. In that case
a session change of default isn't very useful. They basically are
going to be force to write a script, and run it from a different
session to get a different version. So I think that is going
to be somewhat inconvenient for some users.

Changing the use of the rcParams to be immediate rather than locked
in at module initialization is more attractive to me (and may allow
one to assign differnt rc sets to different backends by default as
well; but that is not urgent). Do you mind changing when the 
parameters are picked up? (I'm asking that you do it now, just
whether that is acceptable).

Thanks, Perry

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> Is there a means of using alternate rcParams dictionaries
    Perry> for use with different backends, say as a parameter to the
    Perry> print_figure method? It doesn't look like it at the
    Perry> moment. I'd guess to do that now means replacing rcParams
    Perry> temporarily, rendering the plot to the file, and resetting
    Perry> rcParams to what it was (I haven't actually tried it), but
    Perry> that seems clumsier than it should be.

There are a few ways to go here.

Probably the best is based on the answer to "How do I customize the
default behavior of a single figure?"
http://matplotlib.sourceforge.net/faq.html#CUSTOM

Ie, you can set the rc params for a given session by updating the rc
dict before importing matplotlib.  You could set up a module like
plot_contexts 

plot_contexts.py::

from matplotlib import rcParams

def use(s):
    if s == 'powerpoint':
        rcParams['figure.facecolor']   = 'b'
        rcParams['text.fontname']   = 'cmr10'
        rcParams['lines.linewidth'] = 2.0
    elif s = 'some journal'
        and so on


And at the script level you could do

import plot_contexts
plot_contexts.use('powerpoint')
from matplotlib.matlab import *

The one down side of the rcParams approach is that currently all the
object defaults are evaluated at module load time, so you can only
switch at the start of your python session.  Eg, the current
constructors look like

class Line2D(Artist):
    def __init__(self, xdata, ydata,
                 linewidth=rcParams['lines.linewidth'],
                 linestyle=rcParams['lines.linestyle'],
                 )

By changing all the constructor defaults to 

    def __init__(self, xdata, ydata,
                 linewidth=None,
                 linestyle=None,
                 ):
                 if linewidth is None: linewidth = rcParams['lines.linewidth'],
                 if linestyle is None: linestyle = rcParams['lines.linestyle'],

we could defer those evaluations to construction time, so you could
switch contexts in the middle of an interactive session

  >>> plot_contexts.use('power point')
  >>> make_some_figs()
  >>> plot_contexts.use('some journal')
  >>> make_some_figs()  # again

I already did this for the FontProperties so you can have context
fonts, as in examples/font_properties_demo.py.  It wouldn't be much
work to do the same for the other properties controlled by rc.

As another approach, I have considered making the matplotlibrc finder
check the current dir first, and using that file if it finds one.
Then you could have dir based contexts.

JDH

I wonder what the recommended way of saving 
and using different plotting defaults is.

Let me give some background first. While many users 
like the current window color defaults (basically black
on white) some prefer white on black for interactive use
(for one thing, colors stand out more). And while they
may be morons for wanting to do so ;-), there is also
a very good reason to use such a color scheme for viewgraphs.
I don't know how many times I've suffered through a presentation
where the presenter showed the plots having a white background
and colored lines or symbols. In that setting, colors just don't
show well. ("well, you could see the yellow points in my version...")
On the other hand such color schemes don't print well (and
the current one does).

I could see someone wanting 2 or 3 different contexts. The 
current rcParams does allow for different save color faces, 
but that isn't quite enough for cases where text needs to be
white or something other than black to show up against black
bacgrounds.

Is there a means of using alternate rcParams dictionaries for 
use with different backends, say as a parameter to the print_figure
method? It doesn't look like it at the moment. I'd guess to do
that now means replacing rcParams temporarily, rendering the
plot to the file, and resetting rcParams to what it was (I haven't
actually tried it), but that seems clumsier than it should be.

Perry

On Fri, 2004-05-14 at 11:27, Perry Greenfield wrote:
> Todd Miller wrote:
> > 
> > So,  while this feels like walking backward,  you can say:
> > 
> >         y = int(self.height) - y.astype('s')
> > 
> > and expect it to work with either.
> > 
> If this is used as the workaround, perhaps local (to the module)
> versions of Int16 and such can be defined as 's' and so forth
> so that it will be easier to update code rather than litter
> it with such character codes.
> 
> Perry 

Good idea.  I'll see if I can get numerix to take care of it.

Todd

Todd Miller wrote:
> 
> So,  while this feels like walking backward,  you can say:
> 
>         y = int(self.height) - y.astype('s')
> 
> and expect it to work with either.
> 
If this is used as the workaround, perhaps local (to the module)
versions of Int16 and such can be defined as 's' and so forth
so that it will be easier to update code rather than litter
it with such character codes.

Perry 

On Fri, 2004-05-14 at 08:35, John Hunter wrote:
> The new transformation module I've been working on is implemented in
> extension code.  It offers a couple of important benefits, namely
> speed and generality (affines, nonseparable xy transformations).  It's
> not in CVS yet because I'm still ironing out the details.
> 
> I have two methods for operating over sequences of x and y, seq_x_y
> and numerix_x_y.  The first uses the python sequence API and the
> second uses the numerix api.  I expect the latter will be a good bit
> faster for long lines, since it doesn't have the python object type
> coercion to deal with, but I haven't profiled it.
> 
> But there is a gotcha.  When I compile the code, I use flag in
> setup.py to indicate whether to compile with Numeric or numarray.
> This sets a flag and that is used in the transforms module (and the
> image module) that will import arrayobject.h from either Numeric or
> numarray.
> 
> A problem can arise if someone compiles with one and uses a different
> setting in ~/.matplotlibrc.  I compiled the module with Numeric but
> used numarray in my matplotlibrc.  The transformation went fine,
> presumably thanks to the numarray compatibility layer.  I passed the
> transformed arrays off to one of the backends, which does
> 
> from matplotlib.numerix import Int16
> 
>         y = int(self.height) - y.astype(Int16)
> 
> and got a 
> 
>   ValueError: type must be either a 1-length string, or python type
>   object
> 
> clearly because of the difference between numpy and numarray type
> args.

Yeah.  numarray has full blown type objects which form a hierarchy which
can be used to test for type properties such as signed, integral, etc. 

numarray uses names for its type objects that were used by Numeric to
make 1 character typecodes clearer and easier to remember.  Thus, in
numarray Int16 is an object, but in Numeric Int16 is an alias for 's'.

Over time,  our compatibility ambitions have grown so now numarray
generally works with Numeric typecodes wherever a type object is
expected.  

So,  while this feels like walking backward,  you can say:

        y = int(self.height) - y.astype('s')

and expect it to work with either.

> Another question is win32, where the user doesn't have the choice at
> compile time.  If we compile in numpy for win32, the user's numarrays
> will be transformed into numpys at render time, but this won't affect
> the user arrays (unlike in scipy where the user is getting the return
> values) so I don't see it as a big deal.  I think trying to compile in
> both or supplying alternate binaries is doable but may not be worth
> the maintenance and complexity.
>
> In any case, there are a couple of readers here who know a bit more
> about numarray and numeric than I do <wink> ; any thoughts?

(1) One thought I've had for handling this has been to improve the basic
binary compatibility of numarray with Numeric to the point that numerix
can be extended to the C-level.  In this scheme,  an extension would be
compiled against neither numarray nor Numeric but against numerix; 
which array package was actually being used would be figured out at run
time much as it works at the Python level now.   I'm still exploring the
idea.

(2) I could just build a numarray version of the matplotlob installer
with each release.  That would offload the work from you and would keep
the matplotlib code cleaner.  

Todd

John Hunter wrote:

> Is there a clever workaround for this problem?  It doesn't affect any
> of the agg or PS backends.  GTK and GD both need to convert their
> arrays to ints before passing them on to their respective renderers.
> One solution is to do the conversion in list comps
[...]
> Another question is win32, where the user doesn't have the choice at
> compile time.  If we compile in numpy for win32, the user's numarrays
> will be transformed into numpys at render time, but this won't affect
> the user arrays (unlike in scipy where the user is getting the return
> values) so I don't see it as a big deal.  I think trying to compile in
> both or supplying alternate binaries is doable but may not be worth
> the maintenance and complexity.
[...]
> 
> In any case, there are a couple of readers here who know a bit more
> about numarray and numeric than I do <wink> ; any thoughts?
>
Perhaps there is a clever workaround, but I wonder if the best solution
isn't to build dual versions of the extensions, one for Numeric and one 
for numarray if both are present (and this would also solve the win32
issue by distributing both). I think setup.py could be setup to do this,
and a mechanism for a module that uses these to use whichever 
is selected by the user to pick up the right sharable
(e.g., _numarray_mycext.so vs _Numeric_mycext.so). It's not
elegant, but it should be robust. Todd and I did talk  about if
there was a way to make numarray arrays compatable at the binary 
level; perhaps, but I suspect it involves a lot work and I'm not
sure it will eliminate all issues. So do you want us to try to
come up with a an example setup.py to do this? Perhaps Todd will
have some other ideas.

Perry

The new transformation module I've been working on is implemented in
extension code.  It offers a couple of important benefits, namely
speed and generality (affines, nonseparable xy transformations).  It's
not in CVS yet because I'm still ironing out the details.

I have two methods for operating over sequences of x and y, seq_x_y
and numerix_x_y.  The first uses the python sequence API and the
second uses the numerix api.  I expect the latter will be a good bit
faster for long lines, since it doesn't have the python object type
coercion to deal with, but I haven't profiled it.

But there is a gotcha.  When I compile the code, I use flag in
setup.py to indicate whether to compile with Numeric or numarray.
This sets a flag and that is used in the transforms module (and the
image module) that will import arrayobject.h from either Numeric or
numarray.

A problem can arise if someone compiles with one and uses a different
setting in ~/.matplotlibrc.  I compiled the module with Numeric but
used numarray in my matplotlibrc.  The transformation went fine,
presumably thanks to the numarray compatibility layer.  I passed the
transformed arrays off to one of the backends, which does

from matplotlib.numerix import Int16

        y = int(self.height) - y.astype(Int16)

and got a 

  ValueError: type must be either a 1-length string, or python type
  object

clearly because of the difference between numpy and numarray type
args.

Is there a clever workaround for this problem?  It doesn't affect any
of the agg or PS backends.  GTK and GD both need to convert their
arrays to ints before passing them on to their respective renderers.
One solution is to do the conversion in list comps

 y = [ int(self.height-val) for val in y]

which obviously implies a performance hit but probably a bearable one
given the other speedups that the new transformation module implies
and that users have an option to use GTKAgg instead of GTK and Agg
instead of GD for optimal performance.

Another question is win32, where the user doesn't have the choice at
compile time.  If we compile in numpy for win32, the user's numarrays
will be transformed into numpys at render time, but this won't affect
the user arrays (unlike in scipy where the user is getting the return
values) so I don't see it as a big deal.  I think trying to compile in
both or supplying alternate binaries is doable but may not be worth
the maintenance and complexity.

In any case, there are a couple of readers here who know a bit more
about numarray and numeric than I do <wink> ; any thoughts?

JDH

Hi John,

thanks, it seems to work now atleast ..

warm regards
karthik



-----------------------------------------------------------------------
Karthikesh Raju,		    email: ka...@ja...
Researcher,			    http://www.cis.hut.fi/karthik
Helsinki University of Technology,  Tel: +358-9-451 5389
Laboratory of Comp. & Info. Sc.,    Fax: +358-9-451 3277
Department of Computer Sc.,
P.O Box 5400, FIN 02015 HUT,
Espoo, FINLAND
-----------------------------------------------------------------------

On Thu, 13 May 2004, John Hunter wrote:

> >>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes:
>
>     Karthikesh> Hi John, Looks like in the previous mail, i had set
>     Karthikesh> the build numarray on, now i removed that flag, and
>     Karthikesh> the installation went on smooth, and i could
>
>     Karthikesh> 1) pygtk, 2) gtk, and 3) matplotlib
>
>     Karthikesh> things went smooth so far, and i run most of the
>     Karthikesh> examples bearing some.  Now i will try to set things
>     Karthikesh> to auto slowly and try the rest.
>
>
> Great!  Start with agg, then image, then gtkagg, and that may be all
> you need.  Unless you want to use matplotlib interactively from the
> shell, in which case tkagg is your best bet.
>
>     Karthikesh> BTW: the following were the developmental packages
>     Karthikesh> that i needed here: (At work our sys's have not
>     Karthikesh> installed any of the developmental packages)
>
> Thanks for the list!  I'll put it on the web site.
>
> JDH
>
>

S=E6ll !


I was simply planning to be able to move between the default positions 'upp=
er right', 'upper left', etc
But I believe I can use _offset.

However it did not produce much effect

I have defined the legend the following way:
canvas.leg=3DFigure.legend(canvas.figure,tuple([i[1] for i in d]),tuple([i[=
0] for i in d]),'best')


And then when I toggle a button I apply the following move with the canvas =
object, which is just  a test offset

    def toggle_legend(self, event):
      """ Toggle the label in the legend button=20
          between Upper Right and Upper Left """
           =20
      if self.Legend_button.get_active()=3D=3D1:
         self.Legend_button.set_label("Upper Right")
      else:
         self.Legend_button.set_label("Upper Left")

      self.leg._offset(0.1,0.56)
      self.draw()
 =20
    return

When I toggle the button, the label changes, but the legend is unmoved.


Am I missing something ?=20

Takk

Jean-Baptiste



On Thu, 13 May 2004 05:20:28 -0500
John Hunter <jdh...@ni...> wrote:

> >>>>> "Jean-Baptiste" =3D=3D Jean-Baptiste Cazier <jc...@de...> wri=
tes:
>=20
>     Jean-Baptiste> S_ll !  I would like to be able to move my
>     Jean-Baptiste> Figure.legend Because the optimal position of the
>     Jean-Baptiste> legend on my figure is not always the same, I added
>     Jean-Baptiste> a button to the navigation toolbar to give the suer
>     Jean-Baptiste> a chance to choose the position of the legend I
>     Jean-Baptiste> knwo that I can get a handle on my first legend
>     Jean-Baptiste> drawing, but how can I just modify its location ?
>     Jean-Baptiste> Is there a move_location method for the
>     Jean-Baptiste> Figure.legend ?
>=20
> There is currently no "move to" location, but there is an offset
> method where you can supply a deltxa, deltay in relative sizes, in
> your case fractions of the figure width and height.   So if you wanted
> to move the legend 5% of the figure width to the right and 10% of the
> figure height up, you can call
>=20
>   leg._offset(0.05, 0.10)
>=20
> The leading underscore means that this method was intended for
> internal use, and may change in future releases, but you can try it
> and see if it works for you.  If it does, I can probably make it
> a public method for the next release.
>=20
> As always you'll need to call canvas.draw after setting the new legend
> location.
> =20
>=20
> JDH


--=20
-----------------------------
Jea...@de...

Department of Statistics
deCODE genetics     Sturlugata,8
570 2993          101 Reykjav=EDk

>>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes:

    Karthikesh> Hi John, Looks like in the previous mail, i had set
    Karthikesh> the build numarray on, now i removed that flag, and
    Karthikesh> the installation went on smooth, and i could

    Karthikesh> 1) pygtk, 2) gtk, and 3) matplotlib

    Karthikesh> things went smooth so far, and i run most of the
    Karthikesh> examples bearing some.  Now i will try to set things
    Karthikesh> to auto slowly and try the rest.


Great!  Start with agg, then image, then gtkagg, and that may be all
you need.  Unless you want to use matplotlib interactively from the
shell, in which case tkagg is your best bet.

    Karthikesh> BTW: the following were the developmental packages
    Karthikesh> that i needed here: (At work our sys's have not
    Karthikesh> installed any of the developmental packages)

Thanks for the list!  I'll put it on the web site.

JDH

Hi John,

Looks like in the previous mail, i had set the build numarray on, now i
removed that flag, and the installation went on smooth, and i could

1) pygtk,
2) gtk, and
3) matplotlib

things went smooth so far, and i run most  of the examples bearing some.
Now i will try to set things to auto slowly and try the rest.

BTW: the following were the developmental packages that i needed here:
(At work our sys's have not installed any of the developmental packages)

audiofile-devel-0.2.3-6.i386.rpm         gtk2-devel-2.2.1-4.i386.rpm
esound-devel-0.2.28-4.i386.rpm           gtk+-devel-1.2.10-25.i386.rpm
freetype-2.1.3-6.i386.rpm                imlib-devel-1.9.13-12.i386.rpm
freetype-devel-2.1.3-6.i386.rpm          ORBit-devel-0.5.17-7.i386.rpm
freetype-utils-2.1.3-6.i386.rpm          pygtk2-1.99.16-8rh9.i386.rpm
glib-devel-1.2.10-10.i386.rpm
pygtk2-devel-1.99.16-8rh9.i386.rpm
gnome-libs-devel-1.4.1.2.90-32.i386.rpm
pygtk2-libglade-1.99.16-8rh9.i386.rpm

Many had circular dependences, and hence the requirement.

Thankx,

warm regards
karthik







-----------------------------------------------------------------------
Karthikesh Raju,		    email: ka...@ja...
Researcher,			    http://www.cis.hut.fi/karthik
Helsinki University of Technology,  Tel: +358-9-451 5389
Laboratory of Comp. & Info. Sc.,    Fax: +358-9-451 3277
Department of Computer Sc.,
P.O Box 5400, FIN 02015 HUT,
Espoo, FINLAND
-----------------------------------------------------------------------

On Thu, 13 May 2004, John Hunter wrote:

> >>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes:
>
> Since you are facing multiple issues, let's try and get the simplest
> build working and then add stuff in.  First though, it would be
> helpful if you told me what devel rpms you needed to install so I
> recommend  these on the web page to other users.  BTW, the two pages
> most relevant for you with installation information are
> http://matplotlib.sf.net/installing.html and
> http://matplotlib.sf.net/backends.html.  Make sure you give these a
> good read.
>
> From reading your email, I see that you are installing everything to
> your home dir, is that right?
>
> Step 1: start with a clean matplotlib src tree.  I don't want to try
>   and work with the one where you have hardcoded information in the
>   code because then I don't know what is going on.  Just untar the
>   tar.gz file in a new dir and start cleanly
>
> Step 2: Edit setup.py and turn all the BUILD flags off, except for
>   BUILD_FT2FONT.  Let's try and get a working base install and then deal
>   with getting the extension code compiled.
>
> Step 3: Edit setupext.py and add any non-standard base dirs in which
>   you have installed stuff (eg /home/you/usr, /home/you/usr/local') to
>   the basedirs dictionary at the top of that file.  Your platform is
>   linux2.
>
> Step 4: Install matplotlib with > python setup.py install
>
> Step 5: If the build doesn't finish cleanly (the only reason I can
>   think it would fail is if you don't get ft2font built properly.
>   This package requires lib freetype so make you have the freetype and
>   freetype-devel libs installed.  It also requires libz so make sure
>   you have zlib and zlib-devel installed.  If you have installed these
>   to a nonstandard place, make sure you add the basedir to setupext
>   basedirs.
>
> Step 6: OK, I'm assuming you have a clean install at this point.  If
>   you installed with a non-standard prefix, you need to set your
>   MATPLOTLIBDATA environment variable.  This data should point to the
>   dir that contains, for example, all the Vera*.ttf files.  Eg,
>   /your/install/prefix/share/matplotlib.  If you add this to your rc
>   file, make sure you resource your rc or open a new shell.
>
> Step 7: At this point, if you have numarray and pygtk installed
> (1.99.16 or later), you should be able to import matplotlib.  Open up
> python shell and make sure you can do
>
>    >>> import pygtk
>    >>> pygtk.require('2.0')
>    >>> import gtk
>    >>> import numarray
>    >>> import matplotlib
>
>   If not, let us know what error you are getting.  You should now be
>   able to run python simple_plot.py -dGTK
>
>
> Step 8: Edit setup.py and add the other build flags back in.  You can
>   set the ones you want to build to 'auto', which will try and build
>   an extension if the python dependencies are found.  If you still
>   have problems with arrayobject.h, let me know.  You can add the
>   include path to that file in the build_image method in setupext.py
>   by doing
>
>       module.include_dirs.append('/your/path/to/numerix/headers')
>
>   ie, /home/karthik/usr/include/python/numarray
>
>
> We do want to improve the build process for people who have stuff in
> non-default locations, and it would be very helpful for us if you tell
> us explicitly what you had to add and change in the steps above so we
> can incorporate as much as possible into the default.
>
> Good luck!
> JDH
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

>>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes:

    Karthikesh> Ofcourse, numarray/arrayobject.h is at
    Karthikesh> /home/karthik/usr/include/python/numarray

    Karthikesh> What should i do next ?

Well it looks like you did not turn off the BUILD_IMAGE flag - set
BUILD_IMAGE = 0 and all the other BUILD_* flags except FT2FONT to 0.
The instructions for how to handle arrayobject are included later in
my instructions, but let's stay on target!

Note that I did give you the wrong path for arrayobject in my previous
email.  When you get to step 8, I'm fairly certain you will need

  module.include_dirs.append('/home/karthik/usr/include/python')

JDH

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

    Nils> Now python setup.py build works fine.  However

    Nils> python setup.py install

    Nils> as root failed with the following messages

    Nils> Xlib: connection to ":0.0" refused by server Xlib: No
    Nils> protocol specified

    Nils> Traceback (most recent call last): File "setup.py", line 75,
    Nils> in ?  try: import gtk File
    Nils> "/usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py",
    Nils> line 43, in ?  from _gtk import * RuntimeError: could not
    Nils> open display

    Nils> Any hint is appreciated

A couple of areas in the build process currently require an X
connection.  This should probably be fixed.  Are you building on a
local or remote machine?

  * If you are building on a remote machine, you need to set the
    display or use automatic X forwarding with ssh -X.

  * If you are building on a local machine, I think the problem is
    that when you go to install you are root and root doesn't have
    access to the display.  You can verify this by trying to do

     root> xterm&

    and see if you can get a window to pop up.  If not, you need to
    tell the windowing system to allow connections from root.  

Unix gurus please advise here.  Something like

    user> python setup.py build
    user> xhost +
    user> su
    root> python setup.py install
    root> exit 
    user> xhost -

Let me know!

JDH

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

    Nils> /home/nwagner> pkg-config --libs pygtk-2.0 -L/opt/gnome/lib
    Nils> -lgobject-2.0 -lglib-2.0

    Nils> /home/nwagner> pkg-config --libs gtk+-2.0
    Nils> -Wl,--export-dynamic -L/opt/gnome/lib -lgtk-x11-2.0
    Nils> -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0
    Nils> -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl
    Nils> -lglib-2.0

Well that's interesting because pkg-config is doing it's job and
finding -L/opt/gnome/lib.  You should verify that that flag is indeed
being added on the compile line that is failing but it should be so I
don't think this is your problem.  In and case, could you post that
line and the first couple of error messages you get. 

Can anyone think of any reason why you would get a linker failure to
find -lgobject-2.0 if the compiler gets -L/opt/gnome/lib and the
following exist

  /opt/gnome/lib/libgobject-2.0.a
  /opt/gnome/lib/libgobject-2.0.la
  /opt/gnome/lib/libgobject-2.0.so

Is this some sun os weirdness?

JDH

Dear experts,

I have added the following entries in setupext.py  (i.e. '/opt/gnome'

basedir = {

     'win32'  : ['win32_static',],
     'linux2' : ['/usr','/opt/gnome',],
     'linux'  : ['/usr','/opt/gnome',],
     'darwin' : ['/usr/local', '/sw'],
     'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
}

Now python setup.py build works fine.
However

python setup.py install

as root failed with the following messages

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Traceback (most recent call last):
   File "setup.py", line 75, in ?
     try: import gtk
   File "/usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py", line 
43, in ?
     from _gtk import *
RuntimeError: could not open display

Any hint is appreciated

Nils