matplotlib-devel Mailing List for matplotlib

On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
>> Also, everything should be numpy enabled,
>> and the sequence-of-python-tuples approach that many of the
>> collections take should be dropped.
>
> who hoo!
>
> However, numpy doesn't handle "ragged" arrays well. I wonder if 
> there's
> a good way to implement those, so that transforms can be done
> numpy-efficient.
Pad with NaNs?
>> = Chaco and Kiva =
>>
>> It is a good idea for an enterprising developer to take a careful 
>> look
>> at the current Chaco and Kiva
>
> OK. I have to ask -- why aren't we all just using Chaco? I know I'm 
> not
> because ??years ago, Enthought was not really supporting anything but
> Windows -- is that still true? Would it be a whole lot less work to
> support GTK, OS-X, ??? in Chaco than keep developing a separate lib?
Most of ETS is being developed, tested, and run on Windows, Mac, and 
Linux every day. We now have eggs for windows and mac and some 
flavors of linux (fedora, ubuntu). Long ago we factored out Chaco's 
underlying drawing layer into a package called Kiva. Kiva has Agg- 
based backends for wxWindows on X11 and Win32, and a native Quartz 
backend for wxWindows on OS X. There is also a PIL-based non- 
interactive raster backend. Kiva's PS, PDF, SVG, and GL backends 
could all use a little love, but they were functioning at one point 
in time.
-Peter

On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
> = Data copying =
>
> Push the data to the backend only once, or only when required. Update
> the transforms in the backend, but do not push transformed data on
> every draw. This is potentially a major win, because we currently
> move the data around on every draw.
Does the backend keep a copy of the untransformed data around, so 
that it can easily create new transformed data when its transform is 
updated? If so, is there a coherent mechanism for invalidating a 
piece of data that is being graphed in multiple plots? If not, then 
how does hittesting determine the correct index into the data (since, 
presumably, hittesting will require the exact transform in the backend)?
> = Transformations =
>
> Support a normal transformation architecture. The current draft
> implementation assumes one nonlinear transformation, which happens at
> a high layer, and all transformations after that are affines. In the
> mpl1 draft, there are three affines: the transformation from view
> limits -> axes units (AxesCoords.affineview), the transformation from
> axes units to normalized figure units (AxesCoords.affineaxes), and the
> transformation from normalized figure units to display
> (Renderer.affinerenderer)
>
> Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
I admit the temptation of having basic 3D support, but the problem is 
that it really doesn't scale well in software. Even the simple blits 
that we do in Chaco start to hit their limits on big, high-res LCDs 
that are getting cheaper every day. The approach that I think we're 
going to have to take in Chaco is to only let 3D be available when 
using the OpenGL backend, and to restrict the Agg-based backends to 
be 2D only.
Of course, I'm thinking about all this from an interactive 
standpoint, so if speed is not a concern, then there's no reason not 
to build in 3D support from the get-go.
> How do transformations (linear and nonlinear) play with Axis features
> (ticking and gridding). The ideal is a framework in which ticking,
> gridding and labeling work intelligently with arbitrary, user
> supplied, transformations. What is the proper transformation API?
This is something we've been puzzling over for Chaco as well. Dave 
Kammeyer pointed out long ago that the problem with trying to write a 
generic axis/grid renderer while supporting arbitrary transformations 
is that straight lines become curves under arbitrary transforms. The 
basic idea is that the backend (or GraphicsContext, in the Chaco 
world) needs to provide transformation-aware implementations of 
line_to() that automatically convert line segments into bezier curves 
while at the same time providing drawing methods that are guaranteed 
to be "straight" or aligned with screen coordinates. This way, you 
can get curved axes in a hyperbolic space "for free", while your 
ticks stay perfectly straight and the label text is screen-aligned. 
(Of course, to be perfectly accurate, you would need to handle polar 
coordinates in a special way anyway.)
> = Objects that talk to the backend "primitives" =
>
> Have just a few, fairly rich obects, that the backends need to
> understand. Clear candidates are a Path, Text and Image, but despite
> their names, don't confuse these with the eponymous matplotlib
> matplotlib Artists, which are higher level than what I'm thinking of
> here (eg matplotlib.text.Text does *a lot* of layout, and this would
> be offloaded ot the backend in this conception of the Text primitive).
> Each of these will carry their metadata, eg a path will carry its
> stroke color, facecolor, linewidth, etc..., and Text will carry its
> font size, color, etc.... We may need some optimizations down the
> road, but we should start small. For now, let's call these objects
> "primitives".
>
> = How much of an intermediate artist layer do we need? =
>
> Do we want to create high level objects like Circle, Rectangle and
> Line, each of which manage a Path object under the hood? Probably,
> for user convenience and general compability with matplotlib. By
> using traits properly here, many current matplotlib Arists will be
> thin interfaces around one or more primitives.
I included these two together because I think they both concern a 
very fundamental matter, which is the drawing model. If you are 
going to create higher-level "primitives" which encapsulate state 
(e.g. color, dash style, line width), then you are moving 
significantly away from the model of a Canvas as just a place to dump 
pixels/vector drawing commands, and more towards the model of Canvas 
as a container of stateful objects. But as soon as you do this, a 
whole host of questions pop up... Are the Circle, Rectangle, etc. in 
the "intermediate artist layer" objects in their own right, with 
parameters like 'radius', 'position', etc., or are they just 
convenience functions to create more low-level primitives on the 
Canvas? If the former, then you have suddenly have a hierarchical 
Canvas. If the latter, then is there any structure to how these 
primitives are held in the Canvas? Even if they are just held in a 
simple list, are they drawn in the same order as they appear in that 
list? If they were inserted by a single Circle or Rectangle 
intermediate artist, is there any way to ensure that they maintain 
coherency when re-ordering that draw order?
Also, if you have a list of these primitives, it seems natural to 
hittest against them for picking and interaction. Does this also 
happen in the same order that they appear in the list? Is there a 
straightforward way to make them process events in a different 
order? If you have lots of these little primitives, are there 
optimizations you can design in so that you don't have to hittest 
thousands of little primitives on each mouse_move event?
> = Where do the plot functions live? =
>
> In matplotlib, the plot functions are matplotlib.axes.Axes methods and
> I think there is consensus that this is a poor design. Where should
> these live, what should they create, etc?
Well, you can probably guess my answer to this question. :) It seems 
to me that if you're going to have a drawing model that supports 
stateful graphics on a canvas, plot renderers should just be 
glorified graphics that live on the canvas, no different from a 
Circle or a Rectangle or whatnot. In this case, the plot functions 
then just become convenience functions that create these graphics and 
stick them on a canvas.
> I think the whole matplotlib.collections module is poorly designed,
> and should be chucked wholesale, in favor of faster, more elegant,
> optimizations and special cases. Just having the right Path object
> will reduce the need for many of these, eg LineCollection,
> PolygonCollection, etc... Also, everything should be numpy enabled,
> and the sequence-of-python-tuples approach that many of the
> collections take should be dropped. Obviously some of the more useful
> things there, like quad meshes, need to be ported and retained.
In Chaco we can get interactive speeds just by having a few fast 
drawing calls at the Kiva layer: lines(), line_set(), 
draw_marker_at_points(). These were quite easy to implement in both 
the Agg and Quartz backends. We've talked about introducing another 
set of drawing commands that allow passing in a "style index" with 
every point, so that we can speed up our colormapped scatter plots 
and eventually do colormapped lines and such.
> = Z-ordering, containers, etc =
>
> Peter has been doing a lot of nice work on z-order and layers for
> chaco, stuff that looks really useful for picking, interaction, etc...
> We should look at this approach, and think carefully about how this
> should be handled. Paul may be a good candidate for this, since he
> has been working recently on the picking API.
I think that you should really consider integrating the event 
propagation model with the drawing model. The Chaco model of 
"containers of graphical components" is pretty straightforward and 
even though we've implemented it in pure python, it is responsive 
enough for interactivity. The nice thing about it is that there's 
nothing in the container/component model that is intrinsically 
related to plotting, so you can use it to build simple widgets that 
play nicely with the rest of your plot because they use the same 
event propagation and component drawing model. I can put together 
some more thorough documentation on all this, if folks are interested.
> I also plan to use the SWIG
> agg wrapper, so this gets rid of _backend_agg. If we can enhance the
> SWIG agg wrapper, we can also do images through there, getting rid of
> _image.cpp. Having a fully featured, python-exposed agg wrapper will
> be a plus in mpl and beyond. But with the agg license change, I'm
> open to discussion of other approaches.
How exactly are you guys wrapping Agg? I guess I need to take a look 
at that stuff in more detail... Kiva has been fairly stable, even 
though we don't do much maintenance on it, and the DisplayPDF drawing 
model has worked out fairly well. After Robert put together the 
Quartz backend for it, we can nicely verify that our Agg-based 
implementation of DisplayPDF is fairly good, since our plots render 
the same on Windows and Mac. If we had just put in a little more 
effort on optimization for Linux and cleaning up some outdated cruft, 
I think it would be in really good shape. Additionally, Phil 
Thompson is going to be working on porting Kiva and Enable to Qt. 
Kiva's Agg backend is based on Agg 2.4, which is still BSD.
> The major missing piece in ft2font, which is a pretty elaborate CXX
> module. Michael may want to consider alternatives, including looking
> at the agg support for freetype, and the kiva/chaco approach.
Unfortunately, Chaco's font handling isn't anything to write home 
about.. I think the world is crying out for a nice Python library for 
font lookup and font metrics.
> = Traits =
>
> I think we should make a major committment to traits and use them from
> the ground up. Even without the UI stuff, they add plenty to make
> them worthwhile, especially the validation and notification features.
> With the UI (wx only) , they are a major win for many GUI developers.
> Compare the logic for sharing an x-axis using matplotlib transforms
> with Axes.sharex with the approach used in mpl1.py with sync_trait-ed
> affines.
Once you start using trait events and notifications extensively, you 
won't want to go back. :) It encourages a very componentized model 
of development that is both a world apart from normal OOP while at 
the same time feeling very natural.
> = Axis handling =
>
> The whole concept of the Axes object needs to be rethought, in light
> of the fact that we need to support multiple axis objects on one Axes.
> The matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes,
> and we hack two y-axis support (examples/two_scales.py) with some
> transform shenanigans via twinx and multiple Axes where one is hidden,
> but the approach is not scalable and is unwieldy.
>
> This will require a fair amount of thought, but we should aim for
> supporting an arbitrary number of axis obects, presumably associated
> with individual artists or primitives.
> ...
> The other important featiure for axis support is that, for the most
> part, they should be arbitrarily placeable (eg a "detached" axis).
I think you should consider separating the two concerns that are 
being overloaded onto the Axis object: (1) an axis represents a range 
in data space that controls the transforms/mappings between data and 
screen space, and (2) an axis is a visual component that needs to be 
rendered at a particular place on the screen and receives events from 
the user (e.g. double-clicking to set its parameters).
If you create a separate DataRange object, then you can use it to 
drive one or more Transforms as well as multiple Axis objects. This 
is basically how Chaco gets synchronized axes for "free". The actual 
graphical Axis objects can render themselves however they want to, 
and their actual layout on the screen (on opposite sides of a plot, 
piled up in a stack on the left or right, etc.) is determined by a 
layout mechanism that is completely orthogonal to the issues of 
mapping. This also allows for "detached" axes and such.
> = Chaco and Kiva =
>
> It is a good idea for an enterprising developer to take a careful look
> at the current Chaco and Kiva to see if we can further integrate with
> them. I am gun shy because they seem formiddable and complex, and one
> of my major goals here is to streamline and simplify, but they are
> incredible pieces of work and we need to carefully consider them,
> especially as we integrate other parts of the enthought suite into our
> core, eg traits, increasing the possibility of synergies.
I really glad to read this, because I think there are clearly a lot 
of common problems that we all have to solve. At its core, Chaco is 
not *that* complex - it's just rather poorly documented, and that is 
no one's fault but mine. The structure, however, is really pretty 
straightforward. Its container/component model is not much more 
complicated than what a minimal solution to some of the problems I've 
outlined in previous paragraphs would entail.
I guess the key question I would ask is this: What is the vision, or 
driving purpose, behind mpl1? Is it to develop a better backend 
architecture for pylab, or something more? I ask this because some 
of the designs you have proposed for various pieces of mpl1 look very 
much like they are trying to solve the same problems that we're 
trying to solve in Chaco; if you really are quite prepared to "break 
the hell out of matplotlib", I think that now would be a really good 
time for collaboration. :)
-Peter

On 7/21/07, Darren Dale <dd...@co...> wrote:
> On Saturday 21 July 2007 3:12:44 pm Fernando Perez wrote:
> > On 7/21/07, Darren Dale <dd...@co...> wrote:
> > > I'm working on converting our existing rc code to tconfig this weekend.
> > > So far so good. I just wanted to let people know to avoid duplicating
> > > effort.
> >
> > Excellent! Ping me if you have any problems.
>
> Im attaching a patch, it includes lots of changes to mplconfig.py, a realistic
> mplrc.conf file (feel free to rename it to mpl.conf or matplotlib.conf or
> whatever seems standard), and a backup of that .conf file. The mpltest lets
> me try your trick of modifying a well formatted file in place. Very nice!
Thanks, I added your more recent version. I also changed the base
class to HasStrictTraits, so that junk can't be added to the instance
post-creation via rc.junk='foo'.
There is also more support for recursive inclusion. Unfortunately I
didn't finish everything (I took a break on Sunday) and right now I
can't work on this, so it may not quite do everything you want it to.
But let's try to pinpoint what's still missing, and I'll find some
time this week in the evenings to finish it up while the logic is
still in my head.
cheers,
f

Paul Kienzle wrote:
> Let me rephrase: Can we have a function sqrt(x) which returns real if x is
> nonnegative, and complex if it is negative? Similarly for other math functions
> such as log which produce complex values for negative numbers?
standard python is
>>> import cmath
>>> cmath.sqrt(-1)
1j

On Mon, Jul 23, 2007 at 08:48:35AM -1000, Eric Firing wrote:
> Maybe the solution is to not use checkinstall?
Yes, I would:
 * Not use checkinstall
 * prefix to /usr/local
HTH,
Gaël

Maybe the solution is to not use checkinstall?
Eric
Xuedong Zhang wrote:
> I use the command as follows:
> sudo checkinstall python setup.py install --prefix /usr/local
> 
> But the problem is the same.
> It seems during the python install, python access the tk module, but the 
> checkinstall
> seems think it is modified so should be included in the package?
> 
> Michael Droettboom 写道:
>> Gael Varoquaux wrote:
>>> On Sat, Jul 21, 2007 at 05:50:19PM -0400, Xuedong Zhang wrote:
>>> 
>>>> What I am trying to run is the following command:
>>>> 
>>> 
>>>> sudo checkinstall python setup.py install
>>>> 
>>> 
>>>> I guess this maybe the problem between checkinstall and matplotlib
>>>> 
>>> OK, now it's more clear.
>>>
>>> I suggest you install to /usr/local. That way you will get rid of this
>>> conflict. You should be able to do it this way:
>>>
>>> sudo checkinstall python setup.py install --prefix /usr/local
>>> 
>> I agree with this advice. I wonder if you are running into this 
>> problem because you already have matplotlib installed as a Debian 
>> package. I'm mostly just curious as to the underlying cause...
>>
>> Cheers,
>> Mike
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I use the command as follows:
sudo checkinstall python setup.py install --prefix /usr/local
But the problem is the same.
It seems during the python install, python access the tk module, but the 
checkinstall
seems think it is modified so should be included in the package?
Michael Droettboom 写道:
> Gael Varoquaux wrote:
>> On Sat, Jul 21, 2007 at 05:50:19PM -0400, Xuedong Zhang wrote:
>> 
>>> What I am trying to run is the following command:
>>> 
>>
>> 
>>> sudo checkinstall python setup.py install
>>> 
>>
>> 
>>> I guess this maybe the problem between checkinstall and matplotlib
>>> 
>>
>> OK, now it's more clear.
>>
>> I suggest you install to /usr/local. That way you will get rid of this
>> conflict. You should be able to do it this way:
>>
>> sudo checkinstall python setup.py install --prefix /usr/local
>> 
> I agree with this advice. I wonder if you are running into this 
> problem because you already have matplotlib installed as a Debian 
> package. I'm mostly just curious as to the underlying cause...
>
> Cheers,
> Mike

On Sunday 22 July 2007 02:10:50 pm John Hunter wrote:
> On 7/22/07, Dave Peterson <dpe...@en...> wrote:
> > Just uploaded a new source tarball that I believe should have this fixed
> > so that you don't need to install enthought.resource. Basically, I
>
> Bingo, I am now getting a working install with
>
> sudo easy_install -f
> http://code.enthought.com/enstaller/eggs/source/unstable
> "enthought.traits < 3.0a"
>
> which brings in only etsconfig, util and traits. Thanks for tracking this
> down.
I just ran that command myself (9:45 EST, July 23), and it installed:
enthought.debug-2.0b2.dev_r12984-py2.5.egg/
enthought.developer-2.0b2.dev_r12984-py2.5.egg/
enthought.envisage-2.0b2.dev_r12984-py2.5.egg/
enthought.etsconfig-2.0b1.dev_r12883-py2.5.egg/
enthought.help-2.0b2.dev_r12984-py2.5.egg/
enthought.io-2.0b1.dev_r12810-py2.5.egg/
enthought.logger-2.0b2.dev_r12984-py2.5.egg/
enthought.naming-2.0b2.dev_r12810-py2.5.egg/
enthought.plugins.text_editor-2.0b2.dev_r12984-py2.5.egg/
enthought.pyface-2.0b2.dev_r12984-py2.5.egg/
enthought.resource-2.0b1.dev_r12810-py2.5.egg/
enthought.sweet_pickle-2.0b2.dev_r12810-py2.5.egg/
enthought.traits-2.0b2.dev_r12984-py2.5-linux-x86_64.egg/
enthought.traits.ui.wx-2.0b2.dev_r12984-py2.5.egg/
enthought.type_manager-2.0b1.dev_r12810-py2.5.egg/
enthought.units-2.0b2.dev_r12984-py2.5.egg/
enthought.util-2.0b2.dev_r12981-py2.5.egg/
Darren

I suspect my recent mathtext changes will help with Paul's problem.
I should probably give a quick update -- I've been coding pretty 
experimentally lately and didn't want to report on too much if I was 
likely to back it out later.
I've implemented a fairly direct Python translation of the TeX box 
layout model, which replaces the directional references used for layout 
in trunk. My main motivation was to help in the recursive layout of 
fractions (particularly in the vertical alignment) and the wandering 
baseline issue. Of course, this will only solve the baseline problem 
for mathtext (not other text), but I see the argument now for fixing 
that at a lower level. Both of these problems probably could have been 
solved within the existing framework, but I felt in the long run it 
would be useful to use the framework where so many math layout problems 
have already been solved. I'm still deciding whether to parse like TeX 
does (which uses two parsing phases and therefore makes some things a 
little easier/more efficient) or continue with the existing mpl parser. 
I suspect the existing mpl parser will result in more legible code at 
the expense of running some layout operations more times than strictly 
necessary. I'm not terribly concerned about performance -- TeX was 
designed for much weaker machines, and for much larger documents.
I expect to have the old parser up and running with the new box model in 
the next couple of days. It may be most expeditious to just wait for that.
Cheers,
Mike
John Hunter wrote:
> On 7/21/07, Paul Kienzle <pki...@ni...> wrote:
> 
>> Hi,
>>
>> I really love mathtext! I wrote a simple formula parser
>> and now I can label my graphs with easy to read chemical
>> names (I've attached it below for the curious).
>>
>> The problem is that the baseline is wandering. On my machine
>> the following has the 'h' too low and the 'io' too high:
>> 
>
> Just guessing, but...
>
> There is a problem we have with text alignment in the ft2font module.
> We can either align to top, bottom or center, but we need an option to
> align to the glyph baseline. Michael is currently working on mathtext
> and is now our resident font guru. Michael, can you take a look at
> this. This would be an important enhancement for mathtext, multiline
> text, and a text entry widget.
>
> Thanks,
> JDH
>
> 
>> import pylab
>> ax = pylab.subplot(111)
>> pylab.text(0.5,0.5,r'$\rm{Thiol}$', va='bottom')
>> pylab.show()
>>
>> I'm using wxAgg on OS X. I know I've installed freetype, but
>> beyond that I have no idea what font it is using.
>>
>> Do others experience the same problem?
>>
>> Any idea where I can start when debugging this?
>>
>> - Paul
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Gael Varoquaux wrote:
> On Sat, Jul 21, 2007 at 05:50:19PM -0400, Xuedong Zhang wrote:
> 
>> What I am trying to run is the following command:
>> 
>
> 
>> sudo checkinstall python setup.py install
>> 
>
> 
>> I guess this maybe the problem between checkinstall and matplotlib
>> 
>
> OK, now it's more clear.
>
> I suggest you install to /usr/local. That way you will get rid of this
> conflict. You should be able to do it this way:
>
> sudo checkinstall python setup.py install --prefix /usr/local
> 
I agree with this advice. I wonder if you are running into this problem 
because you already have matplotlib installed as a Debian package. I'm 
mostly just curious as to the underlying cause...
Cheers,
Mike