matplotlib-devel Mailing List for matplotlib (Page 530)

This is primarily a bug-fix release from 0.65, though a couple of
little features managed to sneak in

 - 4x image speedups for large images

 - figimage bug fixed

 - fixed some bugs which caused the colorbar not to update properly
   when changing colormap interactively

 - refactored axes management to support delaxes, which deletes, as
   opposed to clears, a specified axes.  Default to current axes

 - tkagg's classic and new-fangled toolbars are now embeddable.

 - extended the new set/get introspection features to more classes

 - fixed some tkagg flakiness on win32 regarding unusual uses of show.

 - new cross backend animation idiom in examples/anim.py - use
   interactive mode rather than timers/idle handlers.

 - deferred some initializations in dates and colors modules for
   faster load times.


http://sourceforge.net/projects/matplotlib

Enjoy!

JDH 

> As my Christmas present to the backend maintainers, I ported these
> changes to WX, GTK, Tk and FLTK.  I don't have FLTK on my system so
> Gregory please test.  I have run the other backends through
> backend_driver.py and have done some interactive testing as well and
> everything looks good.  But please update from CVS after giving the
> mirrors a few hours and test for yourself.

Hi John,

a quick interactive test and backend_driver both work for FltkAgg,
thanks for your Christmas present :-)
Merry Christmas and happy new year to all the list and matplotlib users,

Greg.

Fernando Perez wrote:
> hi all,
> 
> A few minor nits with mpl 0.65:
> 
> 1. I just tried to build an rpm for mpl via bdist_rpm, and it unfortunately
> fails.  The problem is the extra -debuginfo rpm which gets generated in the
> process, which then causes the setup.py process to abort.  It would be very
> nice to be able to use bdist_rpm to cleanly generate RPMs out of the sources,
> for handling installation via yum on multiple boxes.

OK, here's a quick and dirty fix I found.  In distutils/command/bdist_rpm.py, 
around line 309, use the following:

         if not self.dry_run:
             if not self.binary_only:
                 srpms = glob.glob(os.path.join(rpm_dir['SRPMS'], "*.rpm"))
                 #assert len(srpms) == 1, \
                 #       "unexpected number of SRPM files found: %s" % srpms
                 #self.move_file(srpms[0], self.dist_dir)
                 map(lambda f:self.move_file(f,self.dist_dir),srpms)

             if not self.source_only:
                 rpms = glob.glob(os.path.join(rpm_dir['RPMS'], "*/*.rpm"))
                 #assert len(rpms) == 1, \
                 #       "unexpected number of RPM files found: %s" % rpms
                 #self.move_file(rpms[0], self.dist_dir)
                 map(lambda f:self.move_file(f,self.dist_dir),rpms)


I commented out the asserts which cause the operation to fail, and replaced 
them with a brute-force map call.  I'll try to have some form of this change 
sent upstream to python-dev, b/c that stupid assert causes no end of grief for 
extension RPMs.

I guess this makes it a bit of a real Xmas gift :)

Cheers,

f

hi all,

A few minor nits with mpl 0.65:

1. I just tried to build an rpm for mpl via bdist_rpm, and it unfortunately
fails.  The problem is the extra -debuginfo rpm which gets generated in the
process, which then causes the setup.py process to abort.  It would be very
nice to be able to use bdist_rpm to cleanly generate RPMs out of the sources,
for handling installation via yum on multiple boxes.

2. I think there are some hardcoded paths in mpl which shouldn't.  I installed
   it (after the rpm failure) with 'install --prefix=/usr/local', and the date
demos fail:

planck[examples]> python date_demo1.py
Could not find bitmap file "/usr/share/matplotlib/home.xpm"; dying

Note that:

planck[examples]> d /usr/local/share/matplotlib/home.xpm
-rw-r--r--  1 root 5135 Jul 20 12:13 /usr/local/share/matplotlib/home.xpm

which is as it should, since I specified my prefix as /usr/local.  The runtime
code should not assume that the base prefix is necessarily /usr, since this
can be changed at installation time by the user.

3. The dates stuff also has problems when running in non-english locales:

In [1]: run date_demo2.py
---------------------------------------------------------------------------
exceptions.ValueError                                Traceback (most recent
call last)

/home/fperez/code/python/pylab/examples/date_demo2.py
       20
       21
---> 22 quotes = quotes_historical_yahoo('INTC', date1, date2)
       23 if not quotes:
       24     print 'Found no quotes'

/usr/local/lib/python2.3/site-packages/matplotlib/finance.py in
quotes_historical_yahoo(ticker, date1, date2)
       61         if len(vals)!=7: continue
       62         datestr = vals[0]
---> 63         dt = datetime.date(*time.strptime(datestr, '%d-%b-%y')[:3])
       64         d = date2num(dt)
       65         open, high, low, close =  [float(val) for val in vals[1:5]]

/usr/src/build/394694-i386/install/usr/lib/python2.3/_strptime.py in
strptime(data_string, format)
      422     found = format_regex.match(data_string)
      423     if not found:
--> 424         raise ValueError("time data did not match format:  data=%s
fmt=%s" %
      425                          (data_string, format))
      426     if len(data_string) != found.end():

ValueError: time data did not match format:  data=1-Dec-03  fmt=%d-%b-%y
WARNING: Failure executing file: <date_demo2.py>

In [3]: !echo $$LANG
de_DE.UTF-8

If I switch to the US locale, the code runs (until the crash listed in #2
because of the path problem).

Anyway, this is _my_ Christmas gift to matplotlib ;)

Cheers,

f

In thinking about Michel Sanner's problem of removing subplots, I
decided to make some changes in the way axes and subplot management
was done by the backends and the pylab interface.  The problem was
that there was a chain of calls from the FigureManager for adding
subplots and axes to the Figure, and this was done so the
FigureManager could manage the current axes.  The other reason it was
designed this way is the figure manager need to be notified whenever
the number of axes changed, so it could update the classic toolbar
menu.

The problem with this design is that every time I wanted to add a new
kwarg or some other feature to add_axes or add_subplot in the Figure,
these changes had to be mirrored in the FigureManager, sometimes
across backends which had concrete implementations, which proved to be
a pain.  And when I wanted to think about deleting axes, I had to
worry about the FigureManager's information and the figure's
information, which was a bad design.

In its place, I added the management of the current axes to the Figure
class itself, and used an observer pattern so the backend
FigureManager could get notification when the number of axes changed.
So FigureManager add_subplot and add_axes methods no longer exist.
Note the Figure doesn't *do* anything with the current axes
information, it merely manages it.

As my Christmas present to the backend maintainers, I ported these
changes to WX, GTK, Tk and FLTK.  I don't have FLTK on my system so
Gregory please test.  I have run the other backends through
backend_driver.py and have done some interactive testing as well and
everything looks good.  But please update from CVS after giving the
mirrors a few hours and test for yourself.

Ted, please make sure your QT implementer is advised of these changes.

There is also a new method Figure.delaxes and a pylab interface
function delaxes to remove an axes from the Figure.  This is different
from merely clearing an axes with cla, and the Figure updates the
current axes after a call to delaxes using an axes stack so the
previously current axes becomes current after a deletion.  Eg,

    from pylab import *

    ax1 = subplot(211)
    plot([9,10,11])
    ylabel('y1')

    ax2 = subplot(212)
    scatter(rand(10), rand(10))
    ylabel('y2')

    subplot(211)  # make 211 current
    title('this is a title', color='r')
    grid()

    delaxes(ax1)  # now 212 is current again
    grid()

Thanks,
JDH

Here's something I find surprising (and disconcerting):

astraw@flygate:~$ python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> min(1,2)
1
 >>> from pylab import *
 >>> min(1,2)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File 
"/usr/lib/python2.3/site-packages/numarray/linear_algebra/mlab.py", 
line 149, in min
     return minimum.reduce(m,axis)
ValueError: Empty array in a ufunc that has no identity value.

So, it seems that the "min" function is overridden.  Digging deeper,

 >>> min.__module__
'numarray.linear_algebra.mlab'

OK, I see what's going on here: in an effort to achieve maximum matlab 
compatibility, pylab imports everything (or at least min) from 
numarray.linear_algebra.mlab.  The trouble with this is that a simple 
"from pylab import *" will break a script that uses min() on scalars.  
While numarray may have very good reasons for overriding builtins 
(although I admit that I cannot see what), I think causing normal 
Python scripts to break by simply importing pylab into their namespace 
is not the way to achieve total world domination. :)

This may be a numarray.linear_algebra.mlab bug/issue and I should go to 
their mailing list.  (Although here is probably as good a place to 
reach them :).   But, even if the good numarray folks did it this way 
for a reason (I'd love to know, but I should hunt on their FAQ before 
asking), I suggest than pylab seek to not (incompatibly) override 
builtins.

Again, "from pylab import *" is our plan for total world domination, 
and I suggest we not break  pure Python scripts.

The general problem does not appear serious:

 >>> from pylab import *
 >>>
 >>> for key in globals().keys():
...     if key in dir(__builtins__):
...         print "'%s' was overridden."%key
...
'round' was overridden.
'sum' was overridden.
'abs' was overridden.
'max' was overridden.
'min' was overridden.
'__doc__' was overridden.
'__name__' was overridden.

Cursory checks of the above functions indicate all except min(), max(), 
and round() are compatible with normal (non-exception raising) Python 
use. Even round() is apparently deprecated by numarray to around().

So, basically, I think we're just talking about min() and max().

What do folks think?

>>>>> "Jack" == Jack Diederich <jac...@ja...> writes:

    Jack> Hi, I just subscribed to the list and have been looking at
    Jack> the source.  I wrote a python graphing library so lots of
    Jack> the internals are familair (how many ways can you draw a
    Jack> line?) but spending a couple hours browsing the code I can't
    Jack> get a handle on how layout is done.  Are things generally at
    Jack> fixed positions?  Are there some things I can
    Jack> subclass/decorate to get a different look or feel?

Yes, things are placed in fixed positions.  Fixed here can mean
relative to something else, as in 20% from the left side of the axes,
but not free in the sense of a layout engine that tries to find
optimal placement.

For example, you can place axes with

  axes([left, bottom, width, height]) 

and these are expressed in fractions of the figure width and height.
Eg, http://matplotlib.sourceforge.net/screenshots.html#axes_demo.  Or
you can place a rectangle in relative axes coords (0,0) bottom left,
(1,1) top right with a custom transform

  Rectangle( xy=(0.25, 0.5), width=0.1, height=0.2,
             transform=ax.transAxes)

There has been a lot of clamoring for a layout engine, particularly
because when you have a number of subplots, the text labels from one
axes can overlap another as discussed here -
http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP .  In order to
incorporate a layout engine, you would need at a minimum to subclass
Figure and Axes. Most of the scene objects (matplotlib.artist.Artist)
can return their bounding box in window extent, and you could use this
information to help with layout.  The transforms module has a helper
function bbox_all which takes a sequence of bounding boxes
(transform.Bbox instances) and returns the box that bounds them all --
very useful when doing layout.  Basically, the Figure would want to
inspect it's axes and the axes in turn would inspect the bounding
boxes of the objects in contains.

The only catch is that in the current implementation, text instances
do not know their window extent until drawing time.  This is because
text sizes are backend dependent, and the class that knows how to size
text is the backend Renderer, which isn't known to the objects until
the call to Artist.draw(renderer).  This has proved to be a pain in
the ass since in some classes (eg legend, ticks, tables and text
itself) which need to do some layout involving text, the layout is
deferred until drawing time and then the information is sometimes
cached for efficiency.  Typically this leads to hairy, suboptimal, and
hard-to-maintain code, cf Legend._update_positions and
Text._get_layout.

One potential way out of this dilemma is to use the ft2font module
(matplotlib's freetype2 wrapper) to get the layout information
whenever you want it.  matplotlib's core backend agg uses this anyhow,
and postscript embeds freetype2 fonts and so uses it too.  It remains
to be seen how well this strategy would work on the SVG and Cairo
backends, which are the only other two renderers are actively
supported and used, as far as I know.  I know Steve has taken some
pains to get Cairo text sizing similar to Aggs/GTKs, so it may serve
as a good enough approximation for layout purposes for cairo as well.
We've been trying to push GD users -> Agg, and users who use native
GTK/WX drawing to GTKAgg/WXAgg, because this simplifies maintenance.

    Jack> I had a longstanding misimpression that matplotlib was a
    Jack> wrapper around matlab or I might have abandoned my custom

You're not the first to have this misperception.  I wonder how we can
combat it.  Perhaps renaming the main interface pylab will help.  Or a
blinking box on the homepage maybe - "matplotlib does not require
matlab!  That's the whole point!!'" :-)

    Jack> work and just thrown in here.  If I can get graphs that look
    Jack> like this[1] I'll do just that.

We'd love to have you on board - then we'd be collaborating on two
projects :-)

    Jack> Sorry for the vague questions, but I'll try to recompense by
    Jack> porting my PIL and ming backends over Christmas.  The
    Jack> unmodified backends are stupid similar to matplotlib (again,
    Jack> there aren't too many ways to spell 'line')

Right, the backends are dumb as bricks by design, because this lowers
the barrier of entry in writing a new backend.  Actually, they're too
dumb currently, because the frontend handles the transformation to
display coordinates, which isn't optimal for backends that have
transformations built in (eg PS, SVG) and leads to some problems with
subpixel antialiasing in agg.  Fixing this is on the list of things to
do.

    Jack> Ignore the "shape_*" methods, they just return a handle to
    Jack> paintable objects instead of doing the paint right away
    Jack> (required for doing hovers and sprites in ming/Flash).

As I mentioned to you earlier, I think the hover capabilities of
ming/Flash would be very appealing to webapp developers.  Actually, I
think these are great for all domains, because they let you pack so
much information into a figure. Could this be embedded in a GUI,
bychance?  

I've been meaning to make some alterations in the frontend to support
clickable elements, eg in SVG, and this wouldn't be hard.  The same
framework could be used for tagging hover elements.  If you want to
take the lead here, by all means.  Otherwise, when you get to this
point let me know and I can work with you on it.

    Jack> [1] I only need a few kinds of graphs but they are for
    Jack> marketing folks instead of tech folks so purtier is better.
    Jack> I put up some samples of our current output here (png &
    Jack> Flash) http://jackdied.com/jackdied/graph_sample.html

Everything except the 3D bar look is already supported.  We have major
and minor ticking, solid date support, legends, bar and line charts.
I'm personally not too interested in 3D bars because I don't think the
3D effect adds any information and arguably reduces it.  I would not
oppose a patch, though.  It would be fairly trivial to write, I
suspect.

See examples/major_minor_demo*.py, examples/date_demo*.py
examples/barchart_demo.py and examples/legend_demo*.py in the src
distro.

A few brief notes:

  - you can set the figure background color with the figure command
    and customize the default in the rc file

  - you can customize the default grid style (eg a solid gray line)
    using the rc file, the rc command, or directly setting the line
    properties on the result of, eg, ax.get_xgridlines()
 
      lines = ax.get_xgridlines() + ax.get_ygridlines()
      set(lines, linestyle='-', color='lightslategray', linewidth=1)
    
  - You have a "bar" and a "plot" overlayed.  Just make sure hold is
    set to True so that subsequent plots don't overwrite old plots.
    You can set the default state in rc, toggle it with the "hold
    command" or pass hold as a kwarg on a given plot command to
    temporarily override the hold state

  - To offset the major ticks ('Nov', 'Dec') below the minor ticks,
    you may want to simply prepend them with a newline ('\nNov',
    '\nDec').  You'll want to use custom date tick formatters as
    illustrated in the date demo files referenced above.  There are a
    number of other ways to control the vertical offset (see also the
    verticalalignment of the text instances) but the newline trick may
    be enough to get them into the position you want.

  - The legend doesn't have a shadow feature built in, though you
    could add one trivially and I would be happy to accept a patch.  
    This could be a general feature of patches, actually.

    JDH

Hi, I just subscribed to the list and have been looking at the source.
I wrote a python graphing library so lots of the internals are familair
(how many ways can you draw a line?) but spending a couple hours browsing
the code I can't get a handle on how layout is done.  Are things generally
at fixed positions?  Are there some things I can subclass/decorate to get
a different look or feel?

I had a longstanding misimpression that matplotlib was a wrapper around
matlab or I might have abandoned my custom work and just thrown in here.
If I can get graphs that look like this[1] I'll do just that.

Sorry for the vague questions, but I'll try to recompense by porting my PIL 
and ming backends over Christmas.  The unmodified backends are stupid similar
to matplotlib (again, there aren't too many ways to spell 'line')

Python 2.3.4 (#2, Dec  3 2004, 13:53:17) 
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Graph
>>> filter(lambda x:'__' not in x, dir(Graph.mingDraw))
['circle', 'clip', 'color', 'color_from_tup', 'line', 'pieslice', 'polygon', 
 'rectangle', 'shape_circle', 'shape_line', 'shape_pieslice', 
  'shape_rectangle', 'text', 'tup_from_color', 'write']

Ignore the "shape_*" methods, they just return a handle to paintable objects
instead of doing the paint right away (required for doing hovers and sprites
in ming/Flash).

-Jack

[1] I only need a few kinds of graphs but they are for marketing folks
    instead of tech folks so purtier is better.  I put up some samples of
    our current output here (png & Flash)
    http://jackdied.com/jackdied/graph_sample.html

These notes, with links, can be read at
http://matplotlib.sf.net/whats_new.html.

 - matlab namespace renamed pylab - see
   http://matplotlib.sf.net/matplotlib_to_pylab.py for details on
   conversion.  ipython pylab users should grab version 0.6.6.  You
   can import the matlab interface (now known as pylab interface) with

   from pylab import blah              # OK
   from matplotlib.pylab import blah   # OK
   from matplotlib.matlab import blah  # Deprecated

 - contouring with the contour function!!  Thanks to Nadia Dencheva.
   See examples/contour_demo.py

 - matlab compatible set and get introspection to determine settable
   properties and their values.  See examples/set_and_get.py.  Sample
   usage

   >>> lines = plot([1,2,3])  
   >>> set(lines)
       alpha: float
       antialiased or aa: [True | False]
       ...snip lots more...
   >>> get(lines)
       alpha = 1.0
       antialiased or aa = True
       ...snip lots more...

 - Added many new matlab compatible colormaps - autumn bone cool
   copper flag gray hot hsv jet pink prism spring summer winter -
   Thanks Perry!

 - zorder to artists to control drawing order of lines, patches and
   text in axes.  See examples/zorder_demo.py 

 - mathtext in cairo backend.  Also, printing now works to file
   object.  Thanks Steve Chaplin.


 - printing in WX - Matthew Newville contributed a print button and
   preview for the wx backends.  He also, who graciously volunteered
   to be the new wx backend maintainer.

 - matlab interface functions connect and disconnect replace
   mpl_connect and mpl_disconnect for event handling

 - Pass hold=True|False to any plotting command to override the
   current hold setting.  The original hold setting will be restored
   at the end of the plot function

 - all text instances now have a bbox property which is a dict of
   Rectangle properties.  If set, the text instance will display in a
   rectanglular bounding box.  Example usage
    
    title('hi mom', bbox={'facecolor':'r', 'alpha':0.5})

 - legend properties now exposed as kwargs.  See help(legend)

 - ishold to inspect the hold state

 - new plotting functions spy, spy2 for matrix sparsity visualization

 - pylab interface functions rgrids and thetagrids for customizing
   the grid locations and labels for polar plots - see
   examples/polar_demo.py.

 - add ion, ioff and isinteractive to pylab interface for control of
   interactive mode.  See updated discussion at
   http://matplotlib.sf.net/interactive.html

Bugs fixed - 

  - Fixed colorbar bug with scatter - JDH

  - SVG clipping problem - Thanks Norm Peterson

  - numerous small legend bugs fixed

  - zoom to rect works with reversed axis limits - thanks Gregory

  - fontsizing problem fixes, ps plots correctly sized, landscape
    support for ps output

  - smaller, leaner, meaner PS output - Thanks Jochen

  - make the Gtk backends build without an X-server connection -
    Thanks Jochen

 
Downloads at http://matplotlib.sf.net

JDH

Hello,

I will be on Christmas vacation until January 6.
Unfortunately I won't have time to fix the square-root
positioning problem for the PostScript backend before
I leave.

All the best and a merry Christmas,
Jochen
--=20
http://seehuhn.de/

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> Out of these timezones in dates.py UTC = timezone('UTC')
    Steve> Eastern = timezone('US/Eastern') Central =
    Steve> timezone('US/Central') Mountain = timezone('US/Mountain')
    Steve> Pacific = timezone('US/Pacific') London =
    Steve> timezone('Europe/London') Paris = timezone('Europe/Paris')
    Steve> Berlin = timezone('Europe/Berlin') Moscow =
    Steve> timezone('Europe/Moscow')

    Steve> As far as I can see the only timezones actually used are
    Steve> UTC - as a function default value, and Pacific - used in
    Steve> __main__ Is it OK to remove all the unused ones, or is
    Steve> there something that relies on them?

Well, I provided these for convenience for people to import from the
dates module.  It never occurred to me that simply instantiating 7
objects would carry such a performance hit.  However, it doesn't
appear that I documented this anywhere, so it should be safe to remove
them - just make a note in the API_CHANGES file that they are gone and
I'll mention it in the release notes.

JDH

On Sun, 2004-12-12 at 15:09 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> I suggest - for optional modules (like dates), only import
>     Steve> them when they are required (when the plot actually has a
>     Steve> date) - for all modules try to minimise the amount of code
>     Steve> that will execute upon import, especially function calls.
> 
>     Steve> What do you think?
> 
> Sounds great.  Thanks for tracking this one down.  A 10% speedup is
> well worth it.  It sounds like the dates module should also cache the
> timezone info.  Do you want to take the lead on this one?  
> 
> JDH
Out of these timezones in dates.py
UTC      = timezone('UTC')
Eastern  = timezone('US/Eastern')
Central  = timezone('US/Central')
Mountain = timezone('US/Mountain')
Pacific  = timezone('US/Pacific')
London   = timezone('Europe/London')
Paris    = timezone('Europe/Paris')
Berlin   = timezone('Europe/Berlin')
Moscow   = timezone('Europe/Moscow')

As far as I can see the only timezones actually used are
UTC - as a function default value, and Pacific - used in __main__
Is it OK to remove all the unused ones, or is there something that
relies on them?

Steve

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:

    Norbert> Doing the commands: ------------------------------ from
    Norbert> matplotlib.matlab import * plot((1,2),(3,4))
    Norbert> figtext(0.5,0.5,"$\sqrt 2$") savefig("tryout.eps")
    Norbert> ------------------------------

    Norbert> diplays the sqrt sign shifted upwards against the regular
    Norbert> text.

Looks like the dreaded cmex bug.  Paul, any ideas?

JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I suggest - for optional modules (like dates), only import
    Steve> them when they are required (when the plot actually has a
    Steve> date) - for all modules try to minimise the amount of code
    Steve> that will execute upon import, especially function calls.

    Steve> What do you think?

Sounds great.  Thanks for tracking this one down.  A 10% speedup is
well worth it.  It sounds like the dates module should also cache the
timezone info.  Do you want to take the lead on this one?  

JDH

I've been doing some profiling using
'hotshotmain.py simple_plot.py -dAgg >/tmp/hs-out 2>&1'
(with the Tools/scripts/hotshotmain.py script from the Python src
distribution)

I looked at the output and noticed that the pytz module takes up a fair
amount of the time. Which is a bit unexpected for simple_plot.py which
does not have any dates!
I commented out the 'dates' imports in pylab.py and axes.py and
performance increased 13%. It seemed strange for an import to have such
a large effect, but when I looked at dates.py I saw that it executes
code - it calls timezone() 9 times - a function which does further
imports which read in a lot of data.
If I restore the 'dates' imports and just comment out the 9 timezone()
calls in dates.py the speedup is 11% and it saves around 3,000 function
calls!

I suggest
- for optional modules (like dates), only import them when they are
required (when the plot actually has a date)
- for all modules try to minimise the amount of code that will execute
upon import, especially function calls.

What do you think?

Steve

>>>>> "Jody" == Jody Winston <jos...@ma...> writes:

    Jody> The real reason that I am working on Cairo and matplotlib is
    Jody> that I want a portable way to display output from ATT's
    Jody> graphviz.  From my quick look through matplotlib's code, it
    Jody> looks like this may be hard to do.  So, if I continue this
    Jody> project, I'll also be asking how to render ploygons,
    Jody> ellipses, and text.  Do you think that matplotlib is a good
    Jody> fit given my requirements?

Without commenting on goodness of fit, I'll add that matplotlib has
fundamental elements for polygons (matplotlib.patches.Polygon) and
text (matplotlib.text.Text) and it would be straightforward to add a
dedicated ellipse class (currently we just use polygons for ellipses)
and Ted also has an interest in creating an ellipse class for scale
free renderering, eg in the postscript backend.

JDH

Jody,
I have someone working on a Qt front end (using Agg for rendering).  He's 
only able to put in roughly 1 day/week and with the holidays coming up I'm 
not sure when it's going to be finished.  We're looking in to the 
possibility of being able to contribute this back to matplotlib (if John 
wants it) but there are legal issues on my end that need to get resolved 
before I'll know if it's possible.

FYI: If you want to render the output from graphviz, have you looked at 
dot?  The C/C++ tool doxygen uses graphviz/dot to render inheritance 
diagrams and place them in web pages (with click-able boxes no less).

Ted

At 11:15 AM 12/9/2004, Jody Winston wrote:
>John Hunter writes:
>  > >>>>> "Jody" == Jody Winston <jos...@ma...> writes:
>  >
>  >     Jody> Any pointers on either finding a Qt backend or writing one?
>  >     Jody> Thanks,
>  >
>  > Hi Jody,
>  >
>  > Sorry for the delay in getting back to you - I've been out of town for
>  > a week.
>  >
>  > There have been several people who have expressed interest in A QT
>  > backend - most recently Ted Drain at the JPL.  Perhaps you two could
>  > coordinate your efforts?
>
>I'd be happy to work with Ted.
>
>  > The first place to start is in the file
>  > matplotlib/backends/backend_template.py, which serves as a template
>  > for backend writers and gives some instructions.  I would follow the
>  > model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
>  > WXAgg, which use Agg to render the image and place it in the GUI
>  > canvas.  This is a lot less work and you automiatically get the latest
>  > matplotlib feature set for free.  The basic idea is to use a GUI
>  > independent image library that can then be reused across GUIs.
>  >
>  > The backends have to implement concrete versions of several interface
>  > classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
>  > FigureManagerBase, NavigationToolbar2.  If you opt to use Agg (or
>  > Cairo) to do the drawing for you, you can leave out RendererBase and
>  > GraphicsContextBase, which are the two that require the most work.
>
>I've also built a SWIG interface for Cairo so that I can embed it in a
>Qt application.
>
>The real reason that I am working on Cairo and matplotlib is that I
>want a portable way to display output from ATT's graphviz.  From my
>quick look through matplotlib's code, it looks like this may be hard
>to do.  So, if I continue this project, I'll also be asking how to
>render ploygons, ellipses, and text.  Do you think that matplotlib is
>a good fit given my requirements?
>
>
>
>
>-------------------------------------------------------
>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://productguide.itmanagersjournal.com/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

On Thu, 2004-12-09 at 13:15 -0600, Jody Winston wrote:
> I've also built a SWIG interface for Cairo so that I can embed it in a
> Qt application.
Matplotlib already supports Cairo rendering - it uses the Python Cairo
bindings PyCairo. For Qt to work with PyCairo I think you would just
need to write one function that connects an xlib target surface to Qt,
and then you would get all the matplotlib Cairo rendering done for free.

Steve

John Hunter writes:
 > >>>>> "Jody" == Jody Winston <jos...@ma...> writes:
 > 
 >     Jody> Any pointers on either finding a Qt backend or writing one?
 >     Jody> Thanks,
 > 
 > Hi Jody,
 > 
 > Sorry for the delay in getting back to you - I've been out of town for
 > a week.
 > 
 > There have been several people who have expressed interest in A QT
 > backend - most recently Ted Drain at the JPL.  Perhaps you two could
 > coordinate your efforts?

I'd be happy to work with Ted.

 > The first place to start is in the file
 > matplotlib/backends/backend_template.py, which serves as a template
 > for backend writers and gives some instructions.  I would follow the
 > model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
 > WXAgg, which use Agg to render the image and place it in the GUI
 > canvas.  This is a lot less work and you automiatically get the latest
 > matplotlib feature set for free.  The basic idea is to use a GUI
 > independent image library that can then be reused across GUIs.  
 > 
 > The backends have to implement concrete versions of several interface
 > classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
 > FigureManagerBase, NavigationToolbar2.  If you opt to use Agg (or
 > Cairo) to do the drawing for you, you can leave out RendererBase and
 > GraphicsContextBase, which are the two that require the most work.

I've also built a SWIG interface for Cairo so that I can embed it in a
Qt application.

The real reason that I am working on Cairo and matplotlib is that I
want a portable way to display output from ATT's graphviz.  From my
quick look through matplotlib's code, it looks like this may be hard
to do.  So, if I continue this project, I'll also be asking how to
render ploygons, ellipses, and text.  Do you think that matplotlib is
a good fit given my requirements?

>>>>> "Jody" == Jody Winston <jos...@ma...> writes:

    Jody> Any pointers on either finding a Qt backend or writing one?
    Jody> Thanks,

Hi Jody,

Sorry for the delay in getting back to you - I've been out of town for
a week.

There have been several people who have expressed interest in A QT
backend - most recently Ted Drain at the JPL.  Perhaps you two could
coordinate your efforts?

The first place to start is in the file
matplotlib/backends/backend_template.py, which serves as a template
for backend writers and gives some instructions.  I would follow the
model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
WXAgg, which use Agg to render the image and place it in the GUI
canvas.  This is a lot less work and you automiatically get the latest
matplotlib feature set for free.  The basic idea is to use a GUI
independent image library that can then be reused across GUIs.  

The backends have to implement concrete versions of several interface
classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
FigureManagerBase, NavigationToolbar2.  If you opt to use Agg (or
Cairo) to do the drawing for you, you can leave out RendererBase and
GraphicsContextBase, which are the two that require the most work.

JDH

On the users list, I recently discussed renaming the matlab namespace
to pylab out of trademark concerns

  http://sourceforge.net/mailarchive/message.php?msg_id=10174321

This change is now in CVS.  For the next few releases, importing
matplotlib.matlab will work but issue a deprecation warning.  I also
added pylab.py to site-packages, and the suggested way of importing
the pylab namespace is

  from pylab import blah, blah

which is a wrapper around

  from matplotlib.pylab import blah, blah

There is a script at http://matplotlib.sf.net/matplotlib_to_pylab.py
to recursively convert names files and directories to the new naming
convention.  Read the header to see which cases it handles and which
it does not.

Please update your repositories and test the new changes and
conversion script, which will go into the 0.65 release.

JDH

I've split backend_gtk.py into two parts:
backend_gdk.py - an image backend, like Agg and Cairo.
backend_gtk.py - an GUI backend, that uses gdk rendering

I don't think that a gdk backend is that much use by itself (since Agg
is probably better for most people to use), but I think it has these
benefits:
- the split is more consistent with the way Agg/GTKAgg and
Cairo/GTKCairo are written - the rendering (image backend) is separated
from the GUI.

- it allows me to run examples/backend_driver.py on gdk (without having
gtk widgets popup on screen) and compare performance etc to Agg and
Cairo.

- it makes it easier to delete GDK rendering (while keeping the GTK GUI)
at a later date, if it is no longer required.

Here's the backend_driver results I got for some of the backends,
fastest first:

Backend Template took 0.89 minutes to complete
        template ratio 1.000, template residual 0.000
Backend SVG took 1.06 minutes to complete
        template ratio 1.185, template residual 0.166
Backend PS took 1.32 minutes to complete
        template ratio 1.480, template residual 0.429
Backend Agg took 1.36 minutes to complete
        template ratio 1.519, template residual 0.464
Backend GDK took 1.88 minutes to complete
        template ratio 2.101, template residual 0.984
Backend Cairo took 2.11 minutes to complete
        template ratio 2.358, template residual 1.214

Cairo is slow compared to Agg, but has similar performance to GDK.
This makes sense since GDK and Cairo are both written in Python, 
which much of Agg is written in C++.

Steve

Doing the commands:
------------------------------
from matplotlib.matlab import *
plot((1,2),(3,4))
figtext(0.5,0.5,"$\sqrt 2$")
savefig("tryout.eps")
------------------------------

diplays the sqrt sign shifted upwards against the regular text.

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

On Dec 7, 2004, at 2:07 AM, Andrew Straw wrote:

> On Dec 6, 2004, at 6:52 PM, Steve Chaplin wrote:
>
>> On Mon, 2004-12-06 at 15:34 -0500, Perry Greenfield wrote:
>>> I really appreciate Andrew's diagnosing the original problem and
>>> particularly in recognizing it as possibility here. This is a nasty
>>> kind of bug to figure out.
>> The original bug was reported to numarray developers
>
> Probably by the too-modest Steve Chaplin, I suspect.  I forgot in my 
> previous email that a significant component of my late-phase debugging 
> consisted of emailing the numarray list, and getting an email from 
> Steven Chaplin, who had independently diagnosed the problem. He had 
> already gone much further than I -- he's the one who submitted the bug 
> report and patch to the glibc itself:

Sorry about that. I should have also thanked Steve for doing the hard 
part.

Hello,

I can confirm that the numarray version of matplotlib
(http://matplotlib.sourceforge.net/) crashes for me without this
patch, and does not crash any more after I applied the patch.

My setup: libc6 version 2.3.2.ds1-18, a Pentium 4 processor (has SSE)
and the atlas3-sse2 library installed.

references:

1) a test program and the patch is at
    http://sources.redhat.com/bugzilla/show_bug.cgi?id=3D10

2) the problem in the context of numarray is described at
    http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D870660&gro=
up_id=3D1369&atid=3D450446

I hope this helps,
Jochen
--=20
http://seehuhn.de/