Re: [matplotlib-devel] spy: ignore zero values in sparse matrix

[Eric Firing]

Tony S Yu wrote:
> 
> On Sep 26, 2008, at 5:01 PM, Eric Firing wrote:
>> Also, if an image cannot be resolved by the output device, info is 
>> lost--one might not see anything at a location where there actually is 
>> a value--whereas with markers, a marker will always show up, and the 
>> only problem is that one can't necessarily distinguish a single point 
>> from a cluster.
>>
>> The real problem with all-zero values is that plot can't handle 
>> "plot([],[])".  One can work around this by putting in bogus values to 
>> plot a single point, saving the line, and then setting the line data 
>> to empty; or, better, by not using the high-level plot command, but by 
>> generating the Line2D object and adding it to the axes.  The Line2D 
>> initializer is happy with empty x and y sequences. I think if you use 
>> this approach it will kill two bugs (failure on all-zeros with sparse 
>> and full arrays) with one very simple stone.
>>
>> Eric
> 
> 
> Thanks for the tip Eric. Below is a patch for spy that implements Eric's 
> suggestion. This patch seems to work for a couple simple tests on my 
> end: sparse and dense arrays with non-zero and all-zero values.
> 
> A couple of notes:
> 
> * the call to `add_artist` isn't needed to show the correct plot, but it 
> may be helpful for debugging.
> 
> * the docstring for `spy` suggests that a Line2D instance is returned, 
> but `spy` currently returns a list with a Line2D instance. I set 
> all-zero arrays to return a list also, for consistency.

Tony,

Changes to spy and a few other things are in svn 6127.

Regarding your last point, the docstring made more sense than the 
original implementation, so I changed the implementation to correspond 
to it.  I hope this does not cause more trouble than it is worth; if it 
looks like it will, then I can easily change the behavior back and 
modify the docstring.  It seems silly to always return a list with a 
single item, though, and I doubt that many people are making heavy use 
of the return value of the spy method anyway.

Regarding your original idea, that sparse arrays should be handled like 
ordinary arrays, with only nonzero values plotted:  I think this is 
going too far, and not far enough, so I did the following:

1) If "precision" is None or a non-zero value, the behavior for sparse 
and ordinary arrays is identical.  Previously, the precision kwarg was 
silently ignored for sparse arrays.  Now it is used.

2) If "precision" is 0, then one gets the old behavior: all locations 
with data are shown, regardless of value.  It seems to me that one 
really wants to have this behavior available, to see how much of a 
sparse array is filled in.

I am not entirely comfortable with the way the "precision" kwarg is 
being used to control this, but it seemed preferable to adding another 
kwarg.  Alternatives could include swapping the roles of 0 and None, or 
letting precision take a string value to specify the old behavior.

Actually, I think the most logical thing would be to let the default 
None give the old behavior, and require precision=0 to get the new 
behavior.  What do you think?  Is it OK if I make this change?  It is 
more consistent with the old behavior.

I also changed the behavior so that if a sparse array is input, with no 
marker specifications, it simply makes a default marker plot instead of 
raising an exception.

Eric

> 
> 
> -Tony
> 
> 
> 
> Index: matplotlib/lib/matplotlib/axes.py
> ===
> --- matplotlib/lib/matplotlib/axes.py(revision 6123)
> +++ matplotlib/lib/matplotlib/axes.py(working copy)
> @@ -6723,9 +6723,9 @@
>  else:
>  if hasattr(Z, 'tocoo'):
>  c = Z.tocoo()
> -y = c.row
> -x = c.col
> -z = c.data
> +nonzero = c.data != 0.
> +y = c.row[nonzero]
> +x = c.col[nonzero]
>  else:
>  Z = np.asarray(Z)
>  if precision is None: mask = Z!=0.
> @@ -6733,8 +6733,12 @@
>  y,x,z = mlab.get_xyz_where(mask, mask)
>  if marker is None: marker = 's'
>  if markersize is None: markersize = 10
> -lines = self.plot(x, y, linestyle='None',
> - marker=marker, markersize=markersize, **kwargs)
> +if len(x) == 0:
> +lines = [mlines.Line2D([], [])]
> +self.add_artist(lines[0])
> +else:
> +lines = self.plot(x, y, linestyle='None',
> + marker=ma

Re: [matplotlib-devel] memory leak: gtk.gdk.Pixbuf and gtk.gdk.GCX11 with gtkagg backend

[Eric Firing]

Mátyás János wrote:
> Hi,
> 
> I'm looking for memory leaks in a python application and found leaks in
> matplotlib. The application is graphic intensive. Each time it updates
> the screen, matplotlib allocates another 5-10 megabytes memory for the
> new gtk.gdk.Pixbuf and gtk.gdk.GCX11 while does not free up the buffers
> allocated for the previous content.
> 

This sounds to me like a pygtk bug, not a matplotlib bug; a gtk object 
is hanging around after its reference has been deleted. What versions of 
gtk and pygtk are you using?  This sounds dimly familiar.  I don't know 
enough about gtk and pygtk to help, but I am sure the people who do know 
more will want to know the version.

Eric

> I switched on garbage collection debugging with:
> 
> import gc
> gc.enable()
> gc.set_debug(gc.DEBUG_LEAK)
> 
> and tried to delete the leaking objects:
> 
> --- ./lib/matplotlib/backends/backend_gtkagg.py 2008-06-23
> 04:09:29.0 +0200 ++
> + 
> /usr/lib/python2.4/site-packages/matplotlib-0.91.4-py2.4-linux-i686.egg/matplotlib/backends/backend_gtkagg.py
> 2008-10-02 00:05:32.0 +0200 @@ -3,6 +3,7 @@ """
>  from __future__ import division
>  import os
> +import gc
> 
>  import matplotlib
>  from matplotlib.figure import Figure
> @@ -82,8 +83,17 @@
>  h = int(ren.height)
>  pixbuf = gtk.gdk.pixbuf_new_from_data(
>  buf, gtk.gdk.COLORSPACE_RGB,  True, 8, w, h, w*4)
> -pixmap.draw_pixbuf(pixmap.new_gc(), pixbuf, 0, 0, 0, 0, w, h,
> +   g = pixmap.new_gc()
> +pixmap.draw_pixbuf(g, pixbuf, 0, 0, 0, 0, w, h,
> gtk.gdk.RGB_DITHER_NONE, 0, 0)
> +
> +   print "XX", pixbuf,
> g,pixbuf.__grefcount__,g.__grefcount__
> +   print gc.get_referrers(pixbuf)
> +   print gc.get_referrers(g)
> +   del pixbuf
> +   del g
> +   gc.collect()
> +
>  if DEBUG: print 'FigureCanvasGTKAgg.render_figure done'
> 
>  def blit(self, bbox=None):
> 
> 
> The __grefcount__ values are 1 but the memory is not freed up even after
> gc.collect().
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] spy: ignore zero values in sparse matrix

[Eric Firing]

Tony S Yu wrote:
> Hi Eric,
> 
> Sorry for the late reply.
> 
> On Sep 27, 2008, at 8:56 PM, Eric Firing wrote:
> 
>> Actually, I think the most logical thing would be to let the default  
>> None give the old behavior, and require precision=0 to get the new  
>> behavior.  What do you think?  Is it OK if I make this change?  It  
>> is more consistent with the old behavior.
> 
> I'm ambivalent about this change. On one hand, I think it makes a lot  
> more sense to have None give the old behavior and precision=0 to  
> ignore zero values in the sparse array (then precision would be  
> consistent for finite values and for zero).
> 
> On the other hand, I think ignoring zero values should be the default  
> behavior for sparse arrays (although, I definitely agree there should  
> be the option to plot all assigned values).
> 
> Would it be possible to make the change you suggest and also change  
> the default precision value to 0? (see diff below) This change would  
> also allow you to remove a lot of the special handling for  
> precision=None, since precision=0 gives the same result (I didn't go  
> this far in the diff below).

Good point.  I made that change, but then made precision='present' be 
the value for sparse arrays to show all filled cells.  precision=None is 
deprecated, but converted to 0.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Axes.add_line() is oddly slow?

[Eric Firing]

I am getting very inconsistent timings when looking into plotting a line 
with a very large number of points.  Axes.add_line() is very slow, and 
the time is taken by Axes._update_line_limits().  But when I simply run 
the latter, on a Line2D of the same dimensions, it can be fast.

import matplotlib
matplotlib.use('template')
import numpy as np
import matplotlib.lines as mlines
import matplotlib.pyplot as plt
ax = plt.gca()
LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
from time import time
t = time(); ax.add_line(LL); time()-t
###16.621543884277344
LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
t = time(); ax.add_line(LL); time()-t
###16.579419136047363
## We added two identical lines, each took 16 seconds.

LL = mlines.Line2D(np.arange(1.5e6), np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.1733548641204834
## But when we made another identical line, updating the limits was
## fast.

# Below are similar experiments:
LL = mlines.Line2D(np.arange(1.5e6), 2*np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.18362092971801758

## with a fresh axes:
plt.clf()
ax = plt.gca()
LL = mlines.Line2D(np.arange(1.5e6), 2*np.sin(np.arange(1.5e6)))
t = time(); ax._update_line_limits(LL); time()-t
###0.22244811058044434

t = time(); ax.add_line(LL); time()-t
###16.724560976028442

What is going on?  I used print statements inside add_line() to verify 
that all the time is in _update_line_limits(), which runs one or two 
orders of magnitude slower when run inside of add_line than when run 
outside--even if I run the preceding parts of add_line first.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] path simplification with nan (or move_to)

[Eric Firing]

Mike, John,

Because path simplification does not work with anything but a continuous 
line, it is turned off if there are any nans in the path.  The result is 
that if one does this:

import numpy as np
xx = np.arange(20)
yy = np.random.rand(20)
#plot(xx, yy)
yy[1000] = np.nan
plot(xx, yy)

the plot fails with an incomplete rendering and general 
unresponsiveness; apparently some mysterious agg limit is quietly 
exceeded.  With or without the nan, this test case also shows the 
bizarre slowness of add_line that I asked about in a message yesterday, 
and that has me completely baffled.

Both of these are major problems for real-world use.

Do you have any thoughts on timing and strategy for solving this 
problem?  A few weeks ago, when the problem with nans and path 
simplification turned up, I tried to figure out what was going on and 
how to fix it, but I did not get very far.  I could try again, but as 
you know I don't get along well with C++.

I am also wondering whether more than straightforward path 
simplification with nan/moveto might be needed.  Suppose there is a 
nightmarish time series with every third point being bad, so it is 
essentially a sequence of 2-point line segments.  The simplest form of 
path simplification fix might be to reset the calculation whenever a 
moveto is encountered, but this would yield no simplification in this 
case.  I assume Agg would still choke. Is there a need for some sort of 
automatic chunking of the rendering operation in addition to path 
simplification?

Thanks.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Eric Firing]

Michael Droettboom wrote:

Eric Firing wrote:

Mike, John,

Because path simplification does not work with anything but a 
continuous line, it is turned off if there are any nans in the path.  
The result is that if one does this:


import numpy as np
xx = np.arange(20)
yy = np.random.rand(20)
#plot(xx, yy)
yy[1000] = np.nan
plot(xx, yy)

the plot fails with an incomplete rendering and general 
unresponsiveness; apparently some mysterious agg limit is quietly 
exceeded.
The limit in question is "cell_block_limit" in 
agg_rasterizer_cells_aa.h.  The relationship between the number vertices 
and the number of rasterization cells I suspect depends on the nature of 
the values.
However, if we want to increase the limit, each "cell_block" is 4096 
cells, each with 16 bytes, and currently it maxes out at 1024 cell 
blocks, for a total of 67,108,864 bytes.  So, the question is, how much 
memory should be devoted to rasterization, when the data set is large 
like this?  I think we could safely quadruple this number for a lot of 
modern machines, and this maximum won't affect people plotting smaller 
data sets, since the memory is dynamically allocated anyway.  It works 
for me, but I have 4GB RAM here at work.


It sounds like we have little to lose by increasing the limit as you 
suggest here.  In addition, it would be nice if hitting that limit 
triggered an informative exception instead of a puzzling and quiet 
failure, but maybe that would be hard to arrange.  I have no idea how to 
approach it.


With or without the nan, this test case also shows the bizarre 
slowness of add_line that I asked about in a message yesterday, and 
that has me completely baffled.

lsprofcalltree is my friend!


Thank you very much for finding that!



Both of these are major problems for real-world use.

Do you have any thoughts on timing and strategy for solving this 
problem?  A few weeks ago, when the problem with nans and path 
simplification turned up, I tried to figure out what was going on and 
how to fix it, but I did not get very far.  I could try again, but as 
you know I don't get along well with C++.
That simplification code is pretty hairy, particularly because it tries 
to avoid a copy by doing everything in an iterator/generator way.  I 
think even just supporting MOVETOs there would be tricky, but probably 
the easiest first thing.


The attached patch seems to work, based on cursory testing.  I can make 
an array of 1M points, salt it with nans, and plot it, complete with 
gaps, and all in a reasonably snappy fashion, thanks to your units fix.


I will hold off on committing it until I hear from you or John; or if 
either of you want to polish and commit it (or an alternative), that's 
even better.


Eric



I am also wondering whether more than straightforward path 
simplification with nan/moveto might be needed.  Suppose there is a 
nightmarish time series with every third point being bad, so it is 
essentially a sequence of 2-point line segments.  The simplest form of 
path simplification fix might be to reset the calculation whenever a 
moveto is encountered, but this would yield no simplification in this 
case.  I assume Agg would still choke. Is there a need for some sort 
of automatic chunking of the rendering operation in addition to path 
simplification?


Chunking is probably something worth looking into (for lines, at least), 
as it might also reduce memory usage vs. the "increase the 
cell_block_limit" scenario.


I also think for the special case of high-resolution time series data, 
where x if uniform, there is an opportunity to do something completely 
different that should be far faster.  Audio editors (such as Audacity), 
draw each column of pixels based on the min/max and/or mean and/or RMS 
of the values within that column.  This makes the rendering extremely 
fast and simple.  See:


http://audacity.sourceforge.net/about/images/audacity-macosx.png

Of course, that would mean writing a bunch of new code, but it shouldn't 
be incredibly tricky new code.  It could convert the time series data to 
an image and plot that, or to a filled polygon whose vertices are 
downsampled from the original data.  The latter may be nicer for Ps/Pdf 
output.


Cheers,
Mike



Index: src/agg_py_path_iterator.h
===
--- src/agg_py_path_iterator.h	(revision 6166)
+++ src/agg_py_path_iterator.h	(working copy)
@@ -137,7 +137,8 @@
  double width = 0.0, double height = 0.0) :
 m_source(&source), m_quantize(quantize), m_simplify(simplify),
 m_width(width + 1.0), m_height(height + 1.0), m_queue_read(0), m_queue_write(0),
-m_moveto(true), m_lastx(0.0), m_lasty(0.0), m_clipped(false),
+m_moveto(true), m_after_moveto(false),
+m_lastx(0.0), m_lasty(0.0), m_clipped(false),
 m_do_clipping(width > 0.0 &

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Eric Firing]

The patch in that last message of mine was clearly not quite right.  I 
have gone through several iterations, and have seemed tantalizingly 
close, but I still don't have it right yet.  I need to leave it alone 
for a while, but I do think it is important to get this working 
correctly ASAP--certainly it is for my own work, at least.

What happens with a nan should be somewhat similar to what happens with 
clipping, so perhaps one could take advantage of part of the clipping 
logic, but I have not looked at this approach closely.

Eric


Eric Firing wrote:
> Michael Droettboom wrote:
>> Eric Firing wrote:
>>> Mike, John,
>>>
>>> Because path simplification does not work with anything but a 
>>> continuous line, it is turned off if there are any nans in the path.  
>>> The result is that if one does this:
>>>
>>> import numpy as np
>>> xx = np.arange(20)
>>> yy = np.random.rand(20)
>>> #plot(xx, yy)
>>> yy[1000] = np.nan
>>> plot(xx, yy)
>>>
>>> the plot fails with an incomplete rendering and general 
>>> unresponsiveness; apparently some mysterious agg limit is quietly 
>>> exceeded.
>> The limit in question is "cell_block_limit" in 
>> agg_rasterizer_cells_aa.h.  The relationship between the number 
>> vertices and the number of rasterization cells I suspect depends on 
>> the nature of the values.
>> However, if we want to increase the limit, each "cell_block" is 4096 
>> cells, each with 16 bytes, and currently it maxes out at 1024 cell 
>> blocks, for a total of 67,108,864 bytes.  So, the question is, how 
>> much memory should be devoted to rasterization, when the data set is 
>> large like this?  I think we could safely quadruple this number for a 
>> lot of modern machines, and this maximum won't affect people plotting 
>> smaller data sets, since the memory is dynamically allocated anyway.  
>> It works for me, but I have 4GB RAM here at work.
> 
> It sounds like we have little to lose by increasing the limit as you 
> suggest here.  In addition, it would be nice if hitting that limit 
> triggered an informative exception instead of a puzzling and quiet 
> failure, but maybe that would be hard to arrange.  I have no idea how to 
> approach it.
> 
>>> With or without the nan, this test case also shows the bizarre 
>>> slowness of add_line that I asked about in a message yesterday, and 
>>> that has me completely baffled.
>> lsprofcalltree is my friend!
> 
> Thank you very much for finding that!
> 
>>>
>>> Both of these are major problems for real-world use.
>>>
>>> Do you have any thoughts on timing and strategy for solving this 
>>> problem?  A few weeks ago, when the problem with nans and path 
>>> simplification turned up, I tried to figure out what was going on and 
>>> how to fix it, but I did not get very far.  I could try again, but as 
>>> you know I don't get along well with C++.
>> That simplification code is pretty hairy, particularly because it 
>> tries to avoid a copy by doing everything in an iterator/generator 
>> way.  I think even just supporting MOVETOs there would be tricky, but 
>> probably the easiest first thing.
> 
> The attached patch seems to work, based on cursory testing.  I can make 
> an array of 1M points, salt it with nans, and plot it, complete with 
> gaps, and all in a reasonably snappy fashion, thanks to your units fix.
> 
> I will hold off on committing it until I hear from you or John; or if 
> either of you want to polish and commit it (or an alternative), that's 
> even better.
> 
> Eric
> 
>>>
>>> I am also wondering whether more than straightforward path 
>>> simplification with nan/moveto might be needed.  Suppose there is a 
>>> nightmarish time series with every third point being bad, so it is 
>>> essentially a sequence of 2-point line segments.  The simplest form 
>>> of path simplification fix might be to reset the calculation whenever 
>>> a moveto is encountered, but this would yield no simplification in 
>>> this case.  I assume Agg would still choke. Is there a need for some 
>>> sort of automatic chunking of the rendering operation in addition to 
>>> path simplification?
>>>
>> Chunking is probably something worth looking into (for lines, at 
>> least), as it might also reduce memory usage vs. the "increase the 
>> cell_block_limit" scenario.
>>
>> I also think for the special case of high-resolution time series data, 
>> where x if uniform, t

Re: [matplotlib-devel] path simplification with nan (or move_to)

[Eric Firing]

Michael Droettboom wrote:
> John Hunter wrote:
>> On Wed, Oct 8, 2008 at 11:37 AM, Michael Droettboom <[EMAIL PROTECTED]> 
>> wrote:
>>
>>   
>>> I figured this out.  When this happens, a RuntimeError("Agg rendering
>>> complexity exceeded") is thrown.
>>> 
>> Do you think it is a good idea to put a little helper note in the
>> exception along the lines of
>>
>>   throw "Agg rendering complexity exceeded; you may want to increase
>> the cell_block_size in agg_rasterizer_cells_aa.h"
>>
>> in case someone gets this exception two years from now and none of us
>> can remember this brilliant fix :-)
>>   
> We can suggest that, or suggest that the size of the data is too large 
> (which is easier for most users to fix, I would suspect).  What about:
> 
> "Agg rendering complexity exceeded.  Consider downsampling or decimating 
> your data."
> 
> along with a comment (not thrown), saying
> 
> /* If this is thrown too often, increase cell_block_limit. */
> 
> Mike
> 

Mike,

Thanks for doing this--it has already helped me in my testing of the 
gappy-path simplification support, which I have now committed.  As you 
suggested earlier, I included in path.py a check for a compatible codes 
array.

The agg limit still can be a problem.  It looks like chunking could be 
added easily by making the backend_agg draw_path a python method calling 
the renderer method; if the path length exceeds some threshold, then 
subpaths would be generated and passed to the renderer method.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] scatter and alpha settings

[Eric Firing]

Gregor Thalhammer wrote:
> Dear developers,
> 
> in matplotlib 0.98.3 I discoverd that in scatter individual alpha 
> settings (by giving a list of rgba values) are ignered. Here an example 
> that show this behaviour: All points show the same alpha value as given 
> by the alpha keyword argument. (Omitting it equals to the setting alpha=1).
> 
> 
> from pylab import *
> 
> x = [1,2,3]
> y = [1,2,3]
> 
> c = [[1,0,0, 0.0],
>  [1,0,0, 0.5],
>  [1,0,0, 1.0]]
> 
> gca()
> cla()
> scatter(x,y, c=c, s = 200, alpha = 0.5)
> draw()
> show()
> 
> 
> I had a look at the sources. In axes.py/scatter I simply removed the line
> 
> collection.set_alpha(alpha)

You are correct that there is a bug, in that the alpha in rgba arrays is 
  always overridden, but removing that line is not the solution.  I will 
try to fix it in the next few days.  I think the intention was that 
alpha=None would be used to mean "don't disturb existing alpha in an 
rgba array; but use alpha=1 if color comes in as other than rgba", but 
this has not been propagated uniformly.  Small changes in quite a few 
places may be needed.

Eric

> 
> The recent svn version also contains this line.
> With this change it worked as expected, also e.g. for the case of a 
> single color for all points,
> 
> scatter(x,y, c = 'r', alpha = 0.5)
> 
> Gregor

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Line Integral Convolution

[Eric Firing]

Anne Archibald wrote:
> Hi,
> 
> First of all, matplotlib is a very nice piece of software - I use it
> all the time for interactive data analysis, for posters, and for
> published papers.
> 
> For visualizing low-resolution vector fields, quiver() is quite nice.
> But for high-resolution vector fields there is a technique called
> "line integral convolution" that can be quite effective. Matplotlib
> doesn't seem to implement it, but I have written a simple line
> integral convolution operator I'd be happy to contribute. It's written
> in cython, and is quite fast and fairly general. There is no
> high-level interface like quiver() yet, in part because of the many
> ways you might want to use the operator. In fact I don't know for sure
> that it belongs here rather than (say) scipy.
> 
> Are you interested in including this in matplotlib?

Possibly.  As you note, the question may be whether this belongs in 
scipy, or in an mpl toolkit, or in mpl itself.  I had to google to find 
out what "line integral convolution" is.  It does look like it would be 
a nice thing to offer.  I presume the actual plot would be via image (or 
maybe pcolorfast if anything but a uniform rectangular grid is used). 
Is that correct, or are there other ways the output of the operator 
would be displayed?

So far, mpl has not had pyrex or cython as a build dependency, but 
cython is used in the basemap toolkit.  Personally, I like pyrex/cython 
very much and would be happy to see one of them--presumably cython--used
in mpl.  Others may disagree.

Based on what you say above, my guess is that scipy might be the most 
natural home for your code, in which case we would want to have an 
example of its use for generating an image in the set of mpl examples. 
But if something more elaborate is needed in the way of a high-level 
interface, then either putting it in mpl directly, or in a toolkit, 
would be good.

Eric

> 
> Anne
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] suggestion for the interpolation in imshow()

[Eric Firing]

Andrew Hawryluk wrote:
> The interpolation algorithm used in imshow() can produce spurious 
> results, as has been noted before:
> 
> _http://article.gmane.org/gmane.comp.python.matplotlib.general/12062_
> 
> This happens because the data is converted to RGB before the 
> interpolation/resampling, rather than after. How hard would it be to 
> reverse this so that the data array is first interpolated & resampled 
> and then converted by cmap to RGB?

To me, it looks very hard.  The color mapping is done first, in python, 
and not repeated with every draw.  The interpolation is done by agg at 
rendering time.  Logically, I don't know any reason why agg shouldn't do 
what you suggest: interpolate the scalar field and then convert to rgb. 
  Maybe agg can do it this way.  If so, it would still take quite a bit 
of work by someone comfortable with agg (i.e., not me) to make the change.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6217] trunk/matplotlib/lib/matplotlib/axes.py

[Eric Firing]

Manuel,

Although it doesn't hurt, I don't think it is worthwhile changing range 
to xrange.  From the 2.5 docs:

xrange(  [start,] stop[, step])
  This function is very similar to range(), but returns an ``xrange 
object'' instead of a list. This is an opaque sequence type which yields 
the same values as the corresponding list, without actually storing them 
all simultaneously. The advantage of xrange() over range() is minimal 
(since xrange() still has to create the values when asked for them) 
except when a very large range is used on a memory-starved machine or 
when all of the range's elements are never used (such as when the loop 
is usually terminated with break).

Note "minimal" advantage.  xrange was intended for special-case use, not 
general use.

And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html

xrange() renamed to range(), so range() will no longer produce a list 
but an iterable yielding integers when iterated over.

This implies to me that range is the preferred form, and xrange is 
intended to go away.

Eric

[EMAIL PROTECTED] wrote:
> Revision: 6217
>   http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6217&view=rev
> Author:   mmetz_bn
> Date: 2008-10-16 11:15:25 + (Thu, 16 Oct 2008)
> 
> Log Message:
> ---
> minor optimizations: replacing range by xrange in for loops
> 
> Modified Paths:
> --
> trunk/matplotlib/lib/matplotlib/axes.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/axes.py
> ===
> --- trunk/matplotlib/lib/matplotlib/axes.py   2008-10-15 20:53:09 UTC (rev 
> 6216)
> +++ trunk/matplotlib/lib/matplotlib/axes.py   2008-10-16 11:15:25 UTC (rev 
> 6217)
> @@ -243,7 +243,7 @@
>  x, y, multicol = self._xy_from_y(y)
>  
>  if multicol:
> -for j in range(y.shape[1]):
> +for j in xrange(y.shape[1]):
>  color = self._get_next_cycle_color()
>  seg = mlines.Line2D(x, y[:,j],
>   color = color,
> @@ -285,7 +285,7 @@
>  ret.append(seg)
>  
>  if multicol:
> -for j in range(y.shape[1]):
> +for j in xrange(y.shape[1]):
>  makeline(x[:,j], y[:,j])
>  else:
>  makeline(x, y)
> @@ -324,7 +324,7 @@
>  closed = kwargs.get('closed', True)
>  func = makefill
>  if multicol:
> -for j in range(y.shape[1]):
> +for j in xrange(y.shape[1]):
>  func(x[:,j], y[:,j])
>  else:
>  func(x, y)
> @@ -372,7 +372,7 @@
>  func = makefill
>  
>  if multicol:
> -for j in range(y.shape[1]):
> +for j in xrange(y.shape[1]):
>  func(x[:,j], y[:,j])
>  else:
>  func(x, y)
> @@ -3897,9 +3897,9 @@
>  pass
>  elif align == 'center':
>  if orientation == 'vertical':
> -left = [left[i] - width[i]/2. for i in range(len(left))]
> +left = [left[i] - width[i]/2. for i in xrange(len(left))]
>  elif orientation == 'horizontal':
> -bottom = [bottom[i] - height[i]/2. for i in 
> range(len(bottom))]
> +bottom = [bottom[i] - height[i]/2. for i in 
> xrange(len(bottom))]
>  
>  else:
>  raise ValueError, 'invalid alignment: %s' % align
> @@ -4571,7 +4571,7 @@
>  elif nc == 1:
>  x = [x.ravel()]
>  else:
> -x = [x[:,i] for i in range(nc)]
> +x = [x[:,i] for i in xrange(nc)]
>  else:
>  raise ValueError, "input x can have no more than 2 
> dimensions"
>  if not hasattr(x[0], '__len__'):
> @@ -4665,7 +4665,7 @@
>  else:
>  def doplot(*args):
>  shuffled = []
> -for i in range(0, len(args), 3):
> +for i in xrange(0, len(args), 3):
>  shuffled.extend([args[i+1], args[i], args[i+2]])
>  return self.plot(*shuffled)
>  
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the 
> world's largest Open Source development site.
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-checkins mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins

Re: [matplotlib-devel] [Re]: kwarg "range" in hist

[Eric Firing]

Manuel Metz wrote:
> Please see the end of the mail for the important point !!!

Thank you--I see you are way ahead of me on this.  See comments below.
> 
> Eric Firing wrote:
>> Manuel,
>>
>> Although it doesn't hurt, I don't think it is worthwhile changing range 
>> to xrange.  From the 2.5 docs:
> [...snip...]
>> Note "minimal" advantage.  xrange was intended for special-case use, not 
>> general use.
> 
> Eric,
> 
> yes, I absolutely agree with you that this is only a small (minimal)
> advantage, probably not worth to worry about. Nevertheless ...
> 
>> And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
>> xrange() renamed to range(), so range() will no longer produce a list 
>> but an iterable yielding integers when iterated over.
> 
> Python 3.0 will use xrange() by default, but it is then named range(),
> so from that _I_ conclude that xrange() should be used by default. You
> can also see the difference by using 2to3:
> 
> """
> for i in range(10): print i
> for i in xrange(10): print i
> """
> 
> gets converted to:
> 
> """
> for i in range(10): print i
> for i in range(10): print i
> """
> 
> That is, because 2to3 is a clever program. But:
> 
> """
> a = range(10)
> b = xrange(10)
> for i in a: print i
> for i in b: print i
> """
> 
> gets converted to
> 
> """
> a = list(range(10))
> b = range(10)
> for i in a: print(i)
> for i in b: print(i)
> """
> 
> ;-)
> 
> As you said, it's only a minimal advantage and 2to3 is a clever code!!!
> 

I am glad you brought the above to my attention--it completely changes 
my point of view.  It does appear that changing to xrange now, whenever 
it will work (that is, when one does not *need* a list) will make the 
transition to Python 3 more efficient and has no disadvantage with 
present code.

> 
> (THE IMPORTANT POINT)
> 
> But this brings me to another, more important point: In the axes hist()
> method, a keyword named "range" is used that is passed to the numpy
> histogram() function, which has the kwarg 'range'. Now, this is not a
> problem as long as the range() builtin function is not used in the
> hist() method. But there are a few loops in this method that use
> xrange(), so this code will be translated to range() in py3 -- and that
> will be a problem. A basic example with a pseudo-code:
> 
> """
> def foo(x, range=(1,10)):
> print range
> for i in xrange(x): print i
> foo(10)
> """
> 
> with 2to3 -->
> 
> """
> def foo(x, range=(1,10)):
> print(range)
> for i in range(x): print(i)
> foo(10)
> """
> which then fails.
> 
> One solution would be to use a different keyword argument, maybe
> "binrange" instead of "range" and to throw a deprecated warning for the
> old keyword ???
> 

Yes, I think the use of any builtin as a kwarg is a bug that should be 
squashed via a new kwarg with a deprecation.  Similarly, use of any 
builtin as in internal variable should be considered a latent bug and fixed.

Unfortunately, in this case, the badly-named kwarg is in numpy.histogram 
as well.  The best thing would be to try to get the same change made in 
numpy so that mpl hist and numpy.histogram kwargs would stay in sync.

To make matters worse, histogram has evolved in such a way that its 
kwargs are a confusing mess.  It is too bad that when the "new" syntax 
was developed, the "range" kwarg was not changed at the same time. I 
don't know whether any more changes would be accepted now.

If there is to be a new kwarg, I think I would call it "cliprange", 
since it is essentially used to clip the input--unless "new" is not 
True.  It is not really a "bin range", because it can be set 
independently of the bins.  (I have not traced the code; I am basing my 
statement on the docstring, so I could be wrong about what the code 
actually does.)

Eric

> Manuel
> 
>> This implies to me that range is the preferred form, and xrange is 
>> intended to go away.
>>
>> Eric
>>
> [...snip...]
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
&g

Re: [matplotlib-devel] colormap clipping for large numbers (small vmax - vmin)

[Eric Firing]

Tony S Yu wrote:
> I was using pcolor with very large numbers and a small vrange (vmax - 
> vmin), and ran into a float to integer conversion problem. Large numbers 
> get converted to *negative* integers by astype (see numpy thread 
> )
>  in 
> colors.Colormap.__call__.
> 
> I'm not sure if this is even worth fixing since almost no one would run 
> into this problem (unless you were doing something stupid, like trying 
> to use pcolor as a 2D zero finder :). For the error to occur, you have 
> to set vmin/vmax values (otherwise, the data is properly normalized 
> before converting to integers), and your data has to greatly exceed 
> these limits.

Tony,

Thank you.

I committed the change; it looks like the cost of the extra clip is 
negligible, and it is nice to make the behavior correct even under 
extreme conditions.

Eric

> 
> Cheers,
> -Tony
> 
> 
> 
> 
> 
> Example of the problem:
> #~
> import matplotlib.pyplot as plt
> import numpy as np
> 
> cmap = plt.cm.gray
> cmap.set_over('r', 1.0)
> cmap.set_under('g', 1.0)
> cmap.set_bad('b', 1.0)
> 
> eps = 1E-8
> 
> A = np.arange(100).reshape(10, 10)
> plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)
> # the plot should be about half red and half green (plus a black square)
> # without patch, some of the red squares are filled green
> plt.show()
> #~
> 
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> 
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6288] trunk/matplotlib

[Eric Firing]

[EMAIL PROTECTED] wrote:
> Revision: 6288
>   http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6288&view=rev
> Author:   jdh2358
> Date: 2008-10-21 15:26:22 + (Tue, 21 Oct 2008)
> 
> Log Message:
> ---
> restored the support for multiple pyplots that I broke earlier
>


>  def set_xlim(self, xmin=None, xmax=None, emit=True, **kwargs):
>  """
> @@ -1944,7 +1944,7 @@
>  """
>  Get the y-axis range [*ymin*, *ymax*]
>  """
> -return self.viewLim.intervaly
> +return tuple(self.viewLim.intervaly)

John,

It might be worth adding a comment in the code as to why a tuple is 
needed here.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] doc build failure?

[Eric Firing]

I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the 
docs.  The Latex is failing with output ending in

) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
(/etc/texmf/tex/latex/config/graphics.cfg)))
(/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
! Extra \fi.
l.62 \fi\fi


Is anyone else getting this?  Is there something else I need to clean 
out in order to make it work now?

Thanks.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] doc build failure?

[Eric Firing]

John Hunter wrote:
> On Tue, Oct 21, 2008 at 12:52 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
>> I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the
>> docs.  The Latex is failing with output ending in
>>
>> ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
>> (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
>> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
>> (/etc/texmf/tex/latex/config/graphics.cfg)))
>> (/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
>> ! Extra \fi.
>> l.62 \fi\fi
>>
>>
>> Is anyone else getting this?  Is there something else I need to clean
>> out in order to make it work now?
> 
> Try again, and make sure you reinstall mpl from HEAD? There were a
> couple of bugs in the matplotlib.mlab.cohere math string that was
> causing an error on my box
> 
>   C_{xy} = \\frac{|P_{xy}|^2}{P_{xx}P_{yy}}
> 
>  It looks like I forgot to commit the change (now in r6289).

I did a build and install of mpl from a clean checkout, went to the doc 
subdir, and ran "python make.py".  It failed in exactly the same place 
as before (but took quite a while to get there).

Sphinx is installed as Sphinx-0.5dev_20081020-py2.5.egg.

The line Latex is complaining about is in sphinx.sty.  I found that by 
typing "E" after the Latex "?" output; I could never have figured it out 
from the actual Latex output preceding the "?".

Changing the \fi\fi to \fi fixes it, at least with respect to building 
mpl docs.

I filed it as bug 4166.

Eric


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Eric Firing]

Mark Bakker wrote:
> Hello list (especially Erik, who can fix this I hope) -
> 
> I have had problems with shared axes, especially when one of the axis 
> has an aspect ratio that is set 'equal'. It has been discussed on the 
> list before (mostly with Erik Firing), but it hasn't been fixed yet. 
> What I want to do is have two plots. The top plot has an aspect ratio 
> that is 'equal'. The idea is to have a contour plot in the top figure, 
> while the bottom figure gives a cross-sectional picture of what I am 
> plotting. This used to work well (quite some time ago), including 
> zooming and such. But now I cannot plot it at all, let alone zoom.
> 
> My first problem is when I add a subplot with a shared x-axis, it 
> changes the limits on the original x-axis. That seems to be a bug:
> ax1 = subplot(211)
> plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
> subplot(212,sharex=ax1)  # Now the limits of both x-axis go from 0 to 1.
> 
> After all, the new subplot shares the axis with the existing subplot, so 
> why doesn't it copy the axis limits from that subplot?

I may have the fix for this, but I need more time to check and refine 
it--and try to make sure that I don't break anything else in the process.

> 
> But the bigger problem occurs when I want the aspect ratio of one of the 
> first axis to be 'equal'.
> 
> ax1 = subplot(211,aspect='equal')
> plot([1,2,3]) 
> subplot(212,sharex=ax1)
> 
> The second subplot is added, but the length of the graph is not the same 
> as for the first subplot. It also resets the xlimits to go from 0 to 1, 
> as before, which means the first subplot becomes unreadable (it still 
> enforces 'equal' in the first subplot by changing the limits of the 
> y-axis). When I now change the limits on the x-axis, the aspect ratio is 
> not equal anymore
> 

I will see what I can do.  There are definitely some bugs that need to 
be squashed.

Eric

> ax1.set_xlim(0,2)
> draw()
> 
> Thanks for your help. I am willing to help in testing any changes.
> 
> Best regards, Mark

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Eric Firing]

David Trem wrote:
> Hi,
> 
>  Eric, I will be happy to test your possible fix too. I have similar
> problem with autoscaling shared axes like you Mark.
> 
> David

I have committed to svn some changes to support autoscaling with shared 
axes, so please test.  I have done only very simple and cursory 
checking.  You might try reversed axes, log axes, etc.

I have not yet addressed the aspect ratio part of Mark's original post, 
below, but I think my changes have fixed the first of the two problems, 
in addition to adding autoscaling support, which I don't think we ever 
had before.

At present, autoscaling does not work with shared axes if an aspect 
ratio is specified.

Eric

> 
> Mark Bakker a écrit :
>> Thanks Eric.
>>
>> You know that this has been on my wish list for a long time.
>>
>> Let me know if I can test anything or help in any other way,
>>
>> Mark
>>
>> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>> wrote:
>>
>> Mark Bakker wrote:
>>
>> Hello list (especially Erik, who can fix this I hope) -
>>
>> I have had problems with shared axes, especially when one of the
>> axis has an aspect ratio that is set 'equal'. It has been
>> discussed on the list before (mostly with Erik Firing), but it
>> hasn't been fixed yet. What I want to do is have two plots. The
>> top plot has an aspect ratio that is 'equal'. The idea is to
>> have a contour plot in the top figure, while the bottom figure
>> gives a cross-sectional picture of what I am plotting. This used
>> to work well (quite some time ago), including zooming and such.
>> But now I cannot plot it at all, let alone zoom.
>>
>> My first problem is when I add a subplot with a shared x-axis,
>> it changes the limits on the original x-axis. That seems to be a
>> bug:
>> ax1 = subplot(211)
>> plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
>> subplot(212,sharex=ax1)  # Now the limits of both x-axis go from
>> 0 to 1.
>>
>> After all, the new subplot shares the axis with the existing
>> subplot, so why doesn't it copy the axis limits from that subplot?
>>
>>
>> I may have the fix for this, but I need more time to check and
>> refine it--and try to make sure that I don't break anything else in
>> the process.
>>
>>
>>
>> But the bigger problem occurs when I want the aspect ratio of
>> one of the first axis to be 'equal'.
>>
>> ax1 = subplot(211,aspect='equal')
>> plot([1,2,3]) subplot(212,sharex=ax1)
>>
>> The second subplot is added, but the length of the graph is not
>> the same as for the first subplot. It also resets the xlimits to
>> go from 0 to 1, as before, which means the first subplot becomes
>> unreadable (it still enforces 'equal' in the first subplot by
>> changing the limits of the y-axis). When I now change the limits
>> on the x-axis, the aspect ratio is not equal anymore
>>
>>
>> I will see what I can do.  There are definitely some bugs that need
>> to be squashed.
>>
>> Eric
>>
>>
>> ax1.set_xlim(0,2)
>> draw()
>>
>> Thanks for your help. I am willing to help in testing any changes.
>>
>> Best regards, Mark
>>
>>
>>
>> 
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>> 
>>
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applicati

Re: [matplotlib-devel] problems with shared axis

[Eric Firing]

Mark Bakker wrote:
> Hello list (especially Erik, who can fix this I hope) -
> 
> I have had problems with shared axes, especially when one of the axis 
> has an aspect ratio that is set 'equal'. It has been discussed on the 
> list before (mostly with Erik Firing), but it hasn't been fixed yet. 
> What I want to do is have two plots. The top plot has an aspect ratio 
> that is 'equal'. The idea is to have a contour plot in the top figure, 
> while the bottom figure gives a cross-sectional picture of what I am 
> plotting. This used to work well (quite some time ago), including 
> zooming and such. But now I cannot plot it at all, let alone zoom.
> 
> My first problem is when I add a subplot with a shared x-axis, it 
> changes the limits on the original x-axis. That seems to be a bug:
> ax1 = subplot(211)
> plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
> subplot(212,sharex=ax1)  # Now the limits of both x-axis go from 0 to 1.
> 
> After all, the new subplot shares the axis with the existing subplot, so 
> why doesn't it copy the axis limits from that subplot?
> 
> But the bigger problem occurs when I want the aspect ratio of one of the 
> first axis to be 'equal'.
> 
> ax1 = subplot(211,aspect='equal')
> plot([1,2,3]) 
> subplot(212,sharex=ax1)

Mark,

I made some more changes so that the above works by changing the 
adjustable to 'datalim'.  Have I broken anything?  Does this work for 
your applications?

Eric

> 
> The second subplot is added, but the length of the graph is not the same 
> as for the first subplot. It also resets the xlimits to go from 0 to 1, 
> as before, which means the first subplot becomes unreadable (it still 
> enforces 'equal' in the first subplot by changing the limits of the 
> y-axis). When I now change the limits on the x-axis, the aspect ratio is 
> not equal anymore
> 
> ax1.set_xlim(0,2)
> draw()
> 
> Thanks for your help. I am willing to help in testing any changes.
> 
> Best regards, Mark
> 
> 
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> 
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Eric Firing]

David Trem wrote:
> Thank you very much Eric !
> 
>  It basically works for me but I think there is still a small bug
> related to sharing y axes. I attach a small script that reproduce the
> problem.
> The end of the related error message is the following:
> 
>   File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
> __init__
> if sharex._adjustable == 'box':
> AttributeError: 'NoneType' object has no attribute '_adjustable'
> 
> Hope it could help.

It certainly does, thank you.  In a cut'n'paste operation, I had 
neglected to change a couple of 'x's to 'y's.  Fixed in svn.

Thanks again, and keep testing!

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Eric Firing]

Mark Bakker wrote:
> I was gone for the weekend (sorry, but that 'life' thing gets in the way 
> of getting things done sometimes). I don't have a way to build stuff at 
> the moment. Can I just check out the axes.py and replace my current one, 
> or are there too many changes?

The changes were in ticker.py and axes.py.  Whether plugging in the 
current versions would work depends on the age of the other files you 
have.  If you have a fairly recent svn build, then updating those two 
files probably would work.  You could use svn to get the diffs 
specifically for my changes related to shared axes.

Eric

> 
> Mark
> 
> On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> Mark Bakker wrote:
> 
> Hello list (especially Erik, who can fix this I hope) -
> 
> I have had problems with shared axes, especially when one of the
> axis has an aspect ratio that is set 'equal'. It has been
> discussed on the list before (mostly with Erik Firing), but it
> hasn't been fixed yet. What I want to do is have two plots. The
> top plot has an aspect ratio that is 'equal'. The idea is to
> have a contour plot in the top figure, while the bottom figure
> gives a cross-sectional picture of what I am plotting. This used
> to work well (quite some time ago), including zooming and such.
> But now I cannot plot it at all, let alone zoom.
> 
> My first problem is when I add a subplot with a shared x-axis,
> it changes the limits on the original x-axis. That seems to be a
> bug:
> ax1 = subplot(211)
> plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
> subplot(212,sharex=ax1)  # Now the limits of both x-axis go from
> 0 to 1.
> 
> After all, the new subplot shares the axis with the existing
> subplot, so why doesn't it copy the axis limits from that subplot?
> 
> But the bigger problem occurs when I want the aspect ratio of
> one of the first axis to be 'equal'.
> 
> ax1 = subplot(211,aspect='equal')
> plot([1,2,3]) subplot(212,sharex=ax1)
> 
> 
> Mark,
> 
> I made some more changes so that the above works by changing the
> adjustable to 'datalim'.  Have I broken anything?  Does this work
> for your applications?
> 
> Eric
> 
> 
> The second subplot is added, but the length of the graph is not
> the same as for the first subplot. It also resets the xlimits to
> go from 0 to 1, as before, which means the first subplot becomes
> unreadable (it still enforces 'equal' in the first subplot by
> changing the limits of the y-axis). When I now change the limits
> on the x-axis, the aspect ratio is not equal anymore
> 
> ax1.set_xlim(0,2)
> draw()
> 
> Thanks for your help. I am willing to help in testing any changes.
> 
> Best regards, Mark
> 
> 
> 
> 
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere
> in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> 
> 
> 
> 
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> <mailto:Matplotlib-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Eric Firing]

Mark Bakker wrote:
> Dang, I looked at it, but so much has changed since 0.98.3 release that 
> I have little chance of getting any changes implemented.
> Any plans for a new release that you know of?
> Thanks, Mark

None that I know of.  It would certainly be nice if we had the release 
package-building completely automated; or automated daily svn builds of 
the Win and OSX packages. Since I don't work with either Win or OSX, I 
don't know how hard this would be to set up.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems with shared axis

[Eric Firing]

Michael Droettboom wrote:
> This may not be necessary if we can get a Windows box, but I thought I'd 
> mention it.
> 
> I wrote a distutils extension a couple of years ago to build Windows 
> installers on a Linux box with Mingw32.  This has been working perfectly 
> for nightly builds on my home machine since around September 2007 for a 
> project with much the same build requirements as matplotlib.  It's 
> really easy to install Mingw32 on Debian derivatives (maybe other dists 
> as well.)

Mike,

Thank you!  I had no idea that mingw32 was available as an ubuntu 
package, for example, and never would have thought to look for it.  Now 
I will have to try it out.  Do you know if there is an scons builder 
that uses it?  That might be the sticking point for my non-mpl C code, 
which is now all built with scons.

I think that if your distutils extension works for building mpl for Win 
on a Linux box, then we should use it.  Anything that reduces dependence 
o having an actual Windows machine around is a win.

On second thought, there is one disadvantage: an automated build on a 
Win box could also run an automated test.

I have some dim impression of having seen a caution regarding 
compatibility between mingw extensions and present or future official 
python.org Python builds.  Does this ring any bells?

Eric

> 
> See here:
> 
> http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup
>  
> 
> 
> Mike
> 
> John Hunter wrote:
>> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
>>
>>  
>>> None that I know of.  It would certainly be nice if we had the release
>>> package-building completely automated; or automated daily svn builds 
>>> of the
>>> Win and OSX packages. Since I don't work with either Win or OSX, I don't
>>> know how hard this would be to set up.
>>> 
>>
>> Nightly builds would be excellent -- Charlie, to what extent do you
>> think this is feasible from a scripting perspective?  Ie, ignoring the
>> hardware side for a minute, and assuming we had access to a build farm
>> with OS X and win32, how hard would it be to setup a build bot for
>> nightly builds?
>>
>> JDH
>>
>> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>   
> 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] legend class with paddings in canvas unit

[Eric Firing]

Jae-Joon Lee wrote:
> John,
> 
> The current legend class has following options given in axes units.
> 
>   pad, labelsep, handlelen, hadletextsep, axespad
> 
> Eric introduced borderpad (given as a fraction of the font size),
> which replaces "pad".
> One way is to introduce new names for all of above options. Eric's
> suggestion was (in my understanding) to use same names, but have a
> some way to select between the old behavior and the new one.
> And my inclination was to go with Eric's suggestion instead of
> inventing new names. Anyhow, I'm happy with either approach.
> If we're inventing new option names, I guess there would be no problem
> I mentioned in the previous mail.

Assuming good, descriptive names can be found--whether recycling the old 
ones or choosing new ones--the larger question is what the preferred 
units should be for which options.  I think it makes sense for axespad 
to remain in axes units, but all the others seem most natural to me in 
fraction of the font size, not in points.  With the former, it is like 
specifying "doublespace" in a document; the whole legend, and everything 
in it, should have proportions that are scale-independent and font-size 
independent.  With points, you have to adjust 4 options if you change 
your font size.  I think that *all* pads involving text placement should 
  scale with the corresponding font size.  This applies to tick label 
pads, axis label pads also.  That way, if you need to make a figure for 
publication or beamer display, with extra-large text, it will look right 
when you merely change the font sizes--you won't have to adjust all the 
pads at the same time.

Eric

> 
> Regards,
> 
> -JJ
> 
> 
> On Thu, Oct 30, 2008 at 7:15 AM, John Hunter <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>>> Basic idea is to create a new version of the Legend class with a same
>>> interface to the current one.
>>> Eric's original suggestion was to use some optional kwarg to choose the 
>>> version.
>>> But I found this approach does not work well unless we also set the
>>> meaningful default values in the rc file. For example, the current
>>> "legend.axespad" in rcsetup.py is 0.02 which is in axes unit. But this
>>> need to be ~10 (if given in points) or ~0.5 (if given in fraction of
>>> the font size) in the new class.
>> I think we should deprectate the axes pad kwarg. If you see it coming
>> in (not None), make a reasonable points approximation to a pad using
>> the figure dimensions and axes dimensions and dpi, and issue a warning
>>
>>padpoints = # compute something here from figsize, axes rect and axespad
>>warnings.warn("axespad is a deprecated argument to legend.  The
>> new argument is "padpoints" and is in points.  Assuming %1.1f
>> ponts"%padpoints)
>>
>> That way we won't go crazy supporting 2 versions of something, users'
>> code won't break initially or fail silently, nd users will have a
>> clear migration path.
>>
>> Does that work?  Anyone who is using axespad is something of a power
>> user and will have no problem fixing up their code.
>>
>> JDH
>>
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] logo example plots are wrong

[Eric Firing]

John,

Something really went haywire on this example:

http://matplotlib.sourceforge.net/examples/pylab_examples/logo.html

It works on my machine, so I don't know why the version on the web site 
is wrong.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py

[Eric Firing]

[EMAIL PROTECTED] wrote:
> Revision: 6385
>   http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
> Author:   ryanmay
> Date: 2008-11-10 18:59:18 + (Mon, 10 Nov 2008)
> 
> Log Message:
> ---
> Make iterable() and is_string_like() return True/False instead of 1/0.

Agreed--good cleanup.

A larger problem is that if you index out an element from a numpy array 
of strings, it is a numpy string array scalar, and it is not recognized 
  by is_string_like.  I have a fix for that (not committed), but it 
causes breakage elsewhere.  All this is an example of the perils of 
duck-typing; it has its advantages, but also its pitfalls.

Eric

> 
> Modified Paths:
> --
> trunk/matplotlib/lib/matplotlib/cbook.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/cbook.py
> ===
> --- trunk/matplotlib/lib/matplotlib/cbook.py  2008-11-09 14:11:16 UTC (rev 
> 6384)
> +++ trunk/matplotlib/lib/matplotlib/cbook.py  2008-11-10 18:59:18 UTC (rev 
> 6385)
> @@ -261,16 +261,16 @@
>  def iterable(obj):
>  'return true if *obj* is iterable'
>  try: len(obj)
> -except: return 0
> -return 1
> +except: return False
> +return True
>  
>  
>  def is_string_like(obj):
>  'return true if *obj* looks like a string'
> -if hasattr(obj, 'shape'): return 0
> +if hasattr(obj, 'shape'): return False
>  try: obj + ''
> -except (TypeError, ValueError): return 0
> -return 1
> +except (TypeError, ValueError): return False
> +return True
>  
>  def is_sequence_of_strings(obj):
>  """
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the 
> world's largest Open Source development site.
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-checkins mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py

[Eric Firing]

Ryan May wrote:
> Eric Firing wrote:
>> [EMAIL PROTECTED] wrote:
>>> Revision: 6385
>>>   
>>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
>>> Author:   ryanmay
>>> Date: 2008-11-10 18:59:18 + (Mon, 10 Nov 2008)
>>>
>>> Log Message:
>>> ---
>>> Make iterable() and is_string_like() return True/False instead of 1/0.
>> Agreed--good cleanup.
>>
>> A larger problem is that if you index out an element from a numpy array 
>> of strings, it is a numpy string array scalar, and it is not recognized 
>>   by is_string_like.  I have a fix for that (not committed), but it 
>> causes breakage elsewhere.  All this is an example of the perils of 
>> duck-typing; it has its advantages, but also its pitfalls.
> 
> What's your fix, and, more importantly, what breakage does it cause?
> I've added a fix locally to just check to see if the string is an
> instance of np.string_.  It works, along with a few other things, to fix
> the scatter() problem.  I was just getting ready to start running this
> stuff by the list...

The fix is:

def is_string_like(obj):
 """
 Return True if *obj* looks like a string

 Such objects should include Python strings, unicode
 strings, and numpy string array scalars.
 """
 #if hasattr(obj, 'shape'): return 0
 # I think the above is a legacy of Numeric...
 try:
 if str(obj) + '' == obj:
 return True
 except (TypeError, ValueError):
 return False
 return True

I am not even sure if the above is the fix we want, but having numpy 
string array elements fail "is_string_like" seems like a fundamentally 
bad thing.

Breakage is in font dictionary handling.

I don't have the whole problem solved, and I need to move on to other 
things right now.

Eric

> 
> Ryan
> 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Help with scatter

[Eric Firing]

Ryan May wrote:

Ryan May wrote:

Well, I can get the last one to work with SVN HEAD.  The others don't
work for me either, though I agree they probably should.

It looks like any 1D sequence will trigger colormapping instead of
strings being mapped to rgba arrays.  I'll keep digging to see what
changed. (Unless someone beats me to it.)


Ok, here's a patch that fixes the problem for me, as well as a test
script that tests a bunch of the color options along with having more,
the same, and less than the number of points passed in.

This is triggered by passing in a sequence of strings of the same length
as x, which matplotlib interprets as needing colormapping.  Colormapping
an array of strings explodes nicely.  I've fixed this issue by:

1) Make scatter() check if c is a sequence of strings.  If it is, use
the colorConverter as expected.

2) This requires changing is_string_like() to recognize elements from
numpy string arrays (type numpy.string_) as strings.  These elements are
actually instances of a subclass of python strings
(isinstance(, str is True), but fail because they have a shape
attribute (which is explicitly checked).

3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
containing strings.  Currently, there is an explicit check for a 2D
array, and if it is not, and exception is thrown.

Since this is my first mucking around in internals with which I am not
familiar, I'd like someone to double check me.  It's only a 3 line diff,
but each line is in a different file, so it's got a pretty wide (though
thin) footprint.


Ryan,

Here is a modification of your patch that I think will be very slightly 
more efficient and general.


Eric



Ryan





-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/




___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Index: lib/matplotlib/cbook.py
===
--- lib/matplotlib/cbook.py	(revision 6385)
+++ lib/matplotlib/cbook.py	(working copy)
@@ -266,8 +266,14 @@
 
 
 def is_string_like(obj):
-'return true if *obj* looks like a string'
-if hasattr(obj, 'shape'): return False
+'Return True if *obj* looks like a string'
+if isinstance(obj, (str, unicode)): return True
+# numpy strings are subclass of str, ma strings are not
+if ma.isMaskedArray(obj):
+if obj.ndim == 0 and obj.dtype.kind in 'SU':
+return True
+else:
+return False
 try: obj + ''
 except (TypeError, ValueError): return False
 return True
Index: lib/matplotlib/colors.py
===
--- lib/matplotlib/colors.py	(revision 6385)
+++ lib/matplotlib/colors.py	(working copy)
@@ -342,8 +342,9 @@
 # If c is a list it must be maintained as the same list
 # with modified items so that items can be appended to
 # it. This is needed for examples/dynamic_collections.py.
+# FIXME: comment above does not appear correct.
 if isinstance(c, np.ndarray):
-if len(c.shape) != 2:
+if c.ndim != 2 and c.dtype.kind not in 'SU':
 raise ValueError("Color array must be two-dimensional")
 
 result = np.zeros((len(c), 4))
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py	(revision 6385)
+++ lib/matplotlib/axes.py	(working copy)
@@ -4927,17 +4927,17 @@
 
 x, y, s, c = cbook.delete_masked_points(x, y, s, c)
 
-# The inherent ambiguity is resolved in favor of color
-# mapping, not interpretation as rgb or rgba.
 
-if not is_string_like(c):
+if is_string_like(c) or cbook.is_sequence_of_strings(c):
+colors = mcolors.colorConverter.to_rgba_array(c, alpha)
+else:
 sh = np.shape(c)
+# The inherent ambiguity is resolved in favor of color
+# mapping, not interpretation as rgb or rgba:
 if len(sh) == 1 and sh[0] == len(x):
 colors = None  # use cmap, norm after collection is created
 else:
 colors = mcolors.colorConverter.to_rgba_array(c, alpha)
-else:
-colors = mcolors.colorConverter.to_rgba_array(c, alpha)
 
 if not iterable(s):
 scales = (s,)
--

Re: [matplotlib-devel] Help with scatter

[Eric Firing]

Ryan May wrote:
> On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> Ryan May wrote:
> 
> Ok, here's a patch that fixes the problem for me, as well as a test
> script that tests a bunch of the color options along with having
> more,
> the same, and less than the number of points passed in.
> 
> This is triggered by passing in a sequence of strings of the
> same length
> as x, which matplotlib interprets as needing colormapping.
>  Colormapping
> an array of strings explodes nicely.  I've fixed this issue by:
> 
> 1) Make scatter() check if c is a sequence of strings.  If it
> is, use
> the colorConverter as expected.
> 
> 2) This requires changing is_string_like() to recognize elements
> from
> numpy string arrays (type numpy.string_) as strings.  These
> elements are
> actually instances of a subclass of python strings
> (isinstance(, str is True), but fail because they have
> a shape
> attribute (which is explicitly checked).
> 
> 3) Changing colorConverter.to_rgba_array() to accept a 1D numpy
> array
> containing strings.  Currently, there is an explicit check for a 2D
> array, and if it is not, and exception is thrown.
> 
> Since this is my first mucking around in internals with which I
> am not
> familiar, I'd like someone to double check me.  It's only a 3
> line diff,
> but each line is in a different file, so it's got a pretty wide
> (though
> thin) footprint.
> 
> 
> Ryan,
> 
> Here is a modification of your patch that I think will be very
> slightly more efficient and general.
> 
> 
> Thanks.  That does look a lot more clean.  It would have helped if I had 
> known about dtype.kind for ease of testing for arrays of strings and 
> numpy string scalars.
> 
> Anyone else?

Ryan,

I hope you don't mind--I took care of the "FIXME" that I had put in, and 
committed the whole thing.  Your test passes, and the backend_driver.py 
seems happy, so it should be OK.

Eric

> 
> Ryan
> 
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] modification of update_path_extents?

[Eric Firing]

Mike,

A bug was recently pointed out: axhline, axvline, axhspan, axvspan mess 
up the ax.dataLim.  I committed a quick fix for axhline and axvline, but 
I don't think that what I did is a good solution, so before doing 
anything for axhspan and axvspan I want to arrive at a better strategy.

What is needed is a clean way to specify that only the x or the y part 
of ax.dataLim be updated when a line or patch (or potentially anything 
else) is added.  This is specifically for the case, as in *line, where 
one axis is in data coordinates and the other is in normalized 
coordinates--we don't want the latter to have any effect on the dataLim.

This could be done in python in any of a variety of ways, but I suspect 
that to be most consistent with the way the transforms code is now 
written, relying on update_path_extends from _path.cpp, it might make 
sense to append two boolean arguments to that cpp function, "update_x" 
and "update_y", and use kwargs in Bbox.update_from_path and siblings to 
set these, with default values of True.

What do you think?  If you agree to the _path.cpp change strategy, do 
you prefer to do that yourself, or would you rather that I try it first?

Any suggestions and/or contributions are welcome.

Thanks.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] modification of update_path_extents?

[Eric Firing]

Michael Droettboom wrote:
> 
> Eric Firing wrote:
>> Mike,
>>
>> A bug was recently pointed out: axhline, axvline, axhspan, axvspan 
>> mess up the ax.dataLim.  I committed a quick fix for axhline and 
>> axvline, but I don't think that what I did is a good solution, so 
>> before doing anything for axhspan and axvspan I want to arrive at a 
>> better strategy.
>>
>> What is needed is a clean way to specify that only the x or the y part 
>> of ax.dataLim be updated when a line or patch (or potentially anything 
>> else) is added.  This is specifically for the case, as in *line, where 
>> one axis is in data coordinates and the other is in normalized 
>> coordinates--we don't want the latter to have any effect on the dataLim.
>>
>> This could be done in python in any of a variety of ways, but I 
>> suspect that to be most consistent with the way the transforms code is 
>> now written, relying on update_path_extends from _path.cpp, it might 
>> make sense to append two boolean arguments to that cpp function, 
>> "update_x" and "update_y", and use kwargs in Bbox.update_from_path and 
>> siblings to set these, with default values of True.
> It seems we could do this without touching C at all.  Just change 
> update_from_path so it only updates certain coordinates in the bounding 
> box based on the kwargs you propose.  Sure, the C side will be keeping 
> track of y bounds even when it doesn't have to, but I doubt that matters 
> much compared to checking a flag in the inner loop.  It will compute the 
> bezier curves for both x and y anyway (without digging into Agg).  It's 
> hard to really estimate the performance impact, so I'm necessarily 
> pushing for either option, but it may save having to update the C.

Mike,

I was somehow thinking that update_path_extents was changing things in 
place--completely wrong.  So yes, it is trivial to make the change at 
the python level, and that is definitely the place to do it.  I will try 
to take care of it this evening.

In poking around, however, I came up with a couple of questions. 
Neither is a blocker for what I need to do, but each might deserve a 
comment in the code, if nothing else.

1) in _path.cpp:

void get_path_extents(PathIterator& path, const agg::trans_affine& trans,
   double* x0, double* y0, double* x1, double* y1,
   double* xm, double* ym)
{
 typedef agg::conv_transform transformed_path_t;
 typedef agg::conv_curve curve_t;
 double x, y;
 unsigned code;

 transformed_path_t tpath(path, trans);
 curve_t curved_path(tpath);

 curved_path.rewind(0);

 while ((code = curved_path.vertex(&x, &y)) != agg::path_cmd_stop)
 {
 if ((code & agg::path_cmd_end_poly) == agg::path_cmd_end_poly)
 continue;
 /* if (MPL_notisfinite64(x) || MPL_notisfinite64(y))
 continue;
We should not need the above, because the path iterator
should already be filtering out invalid values.
 */
 if (x < *x0) *x0 = x;
 if (y < *y0) *y0 = y;
 if (x > *x1) *x1 = x;
 if (y > *y1) *y1 = y;
 if (x > 0.0 && x < *xm) *xm = x;
 if (y > 0.0 && y < *ym) *ym = y;
 }
}


In the last 2 lines, why are xm and ym being clipped at 0, when x0 and 
y0 are not?

2) It looks like update_path_extents throws away orientation by always 
returning x0 and y0 as the minima.  Bbox.update_from_path is therefore 
doing the same.  This doesn't hurt in present usage, since orientation 
is not needed for dataLim, but it seems a bit surprising, and worth a 
comment at least.  Am I again missing something obvious?

Eric


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] modification of update_path_extents?

[Eric Firing]

>> if (x > 0.0 && x < *xm) *xm = x;
>> if (y > 0.0 && y < *ym) *ym = y;
>> }
>> }
>>
>>
>> In the last 2 lines, why are xm and ym being clipped at 0, when x0 and 
>> y0 are not?
> xm and ym are the minimum positive values, used for log scales. 
> Definitely worth a comment.

I will add one.

>>
>> 2) It looks like update_path_extents throws away orientation by always 
>> returning x0 and y0 as the minima.  Bbox.update_from_path is therefore 
>> doing the same.  This doesn't hurt in present usage, since orientation 
>> is not needed for dataLim, but it seems a bit surprising, and worth a 
>> comment at least.  Am I again missing something obvious?
>>
> I think I'm missing something.  (Choices in my code are always obvious 
> to *me*, and any mistakes are invisible... ;)  Are you suggesting that 
> if a line has x decreasing then x0 > x1?  What if it boomerangs?  I 
> think it's simplest to keep data limits in a consistent order.  View 
> limits are another issue, of course.

I think I will add a comment.  The only "problem" at present is that 
update_from_path, taken as a perfectly general Bbox method, is doing a 
bit more than is obvious from its name or even from the code, and this 
places at least a theoretical restriction on its potential use.  For 
example, if someone looked at the method and thought he or she could use 
it to directly update a viewLim, the result would not be as expected.

Eric

> 
> Mike
> 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svg.image_noscale and others

[Eric Firing]

Jozef Vesely wrote:
> Hello matplotlib developers,
> 
> I have implemented "svg.image_noscale" feature for ps and pdf backends. I 
> think
> that resampling/scaling should be avoided, when vector format can scale image
> itself.

It seems to me best if there is an option to scale or not; depending on 
the situation, one might want to generate a file with images downscaled.

> 
> One advantage is that original image can be recovered from final file. 
> Moreover
> as it is vector format it should be dpi independent and always provide maximum
> possible quality - that's original data.
> 
> As for svg backend I have commented some transformation changes which 
> I don't understand and which result in misaligned image and axes. 
> Without it the misalignment is still there but smaller.
> I have also removed MixedModeRenderer from svg as it conflicts with 
> "svg.image_noscale"
> and does not seem to be used.
> 

I think having the option of using the MixedModeRenderer is important in 
the long run for the vector backends; without it, one can end up with 
completely unwieldy and potentially unrenderable files.  I'm not sure 
what its status is at present; I think Mike got it working to a 
considerable extent, but didn't quite finish, and therefore left it 
temporarily disabled.

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in pylab.date2num

[Eric Firing]

vschmidt wrote:
> I'm hoping you can help me confirm/deny a bug in pylab's date2num() function. 
> 
> My assumption (this may be wrong) is that this function is meant to be
> compatible with the MATLAB function date2num(). However, in ipython I can
> execute:
> 
> -
> import datetime
> import pylab as p
> 
> dts = datetime.datetime.now()
> serialts = p.date2num(dts)
> 
> print dts
> 2008-11-16 12:03:20.914480
> 
> print serialts
> 733362.502325
> 
> 
> If I then copy this serialts value into MATLAB I get:
> 
> --
> datestr(733362.502325)
> 16-Nov-2007 12:03:20
> --
> 
> Note that the year is off by one.

Evidently date2num was designed to be similar, but not identical, to 
Matlab's datenum. (The difference might have been inadvertent.) Matlab's 
documentation says,

A serial date number represents the whole and fractional number of days 
from a specific date and time, where datenum('Jan-1- 00:00:00') 
returns the number 1. (The year  is merely a reference point and is 
not intended to be interpreted as a real year in time.)

And mpl's says,


 return value is a floating point number (or sequence of floats)
 which gives number of days (fraction part represents hours,
 minutes, seconds) since 0001-01-01 00:00:00 UTC

So they simply have a different origin.  I find calendars endlessly 
confusing, and I make no attempt to delve into them; but I dimly recall 
that there is a year 1, but there is no year 0, so perhaps that is an 
advantage of the mpl version--not that it should matter in practice.

I think the conclusion is that this sort of date number should be 
considered suitable for internal use only, and not used as an 
interchange format; for going from one software system to another, one 
must use a genuine standard supported by both.

Eric

> 
> 


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] transforms bug: axhline with log y scale

[Eric Firing]

Mike (or other transforms afficionados),

The thread "[Matplotlib-users] Bug saving semilogy plots with a axvline" 
started by [EMAIL PROTECTED] pointed to a bug that appears to be deep in 
the transforms code.  My head is spinning.  The problem seems to be 
related to the propagation of the _invalid attribute in transforms, in 
the case of a mixed data/axes transform such as ashline uses.  The 
following one-line change in TransformNode, second line from the bottom, 
works:

 def invalidate(self):
 """
 Invalidate this :class:`TransformNode` and all of its
 ancestors.  Should be called any time the transform changes.
 """
 # If we are an affine transform being changed, we can set the
 # flag to INVALID_AFFINE_ONLY
 value = (self.is_affine) and self.INVALID_AFFINE or self.INVALID

 # Shortcut: If self is already invalid, that means its parents
 # are as well, so we don't need to do anything.
 if self._invalid == value:
 return

 if not len(self._parents):
 self._invalid = value
 return

 # Invalidate all ancestors of self using pseudo-recursion.
 parent = None
 stack = [self]
 while len(stack):
 root = stack.pop()
 # Stop at subtrees that have already been invalidated
 if root._invalid != value or root.pass_through:
 root._invalid = self.INVALID # value  <===
 stack.extend(root._parents.keys())

Now, I know this is the wrong solution, because it defeats all the 
cleverness with the _invalid values; but perhaps it will save you a few 
minutes in finding the right solution.

To reproduce the problem, do this in ipython -pylab:

axhline(5)
yscale('log')
ylim(0.5,30)

Eric

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Eric Firing]

Mike,

This is a gentle check--I suspect my original message, below, may have 
slipped under the radar.

Eric

Eric Firing wrote:
> Mike (or other transforms afficionados),
> 
> The thread "[Matplotlib-users] Bug saving semilogy plots with a axvline" 
> started by [EMAIL PROTECTED] pointed to a bug that appears to be deep in 
> the transforms code.  My head is spinning.  The problem seems to be 
> related to the propagation of the _invalid attribute in transforms, in 
> the case of a mixed data/axes transform such as ashline uses.  The 
> following one-line change in TransformNode, second line from the bottom, 
> works:
> 
>  def invalidate(self):
>  """
>  Invalidate this :class:`TransformNode` and all of its
>  ancestors.  Should be called any time the transform changes.
>  """
>  # If we are an affine transform being changed, we can set the
>  # flag to INVALID_AFFINE_ONLY
>  value = (self.is_affine) and self.INVALID_AFFINE or self.INVALID
> 
>  # Shortcut: If self is already invalid, that means its parents
>  # are as well, so we don't need to do anything.
>  if self._invalid == value:
>  return
> 
>  if not len(self._parents):
>  self._invalid = value
>  return
> 
>  # Invalidate all ancestors of self using pseudo-recursion.
>  parent = None
>  stack = [self]
>  while len(stack):
>  root = stack.pop()
>  # Stop at subtrees that have already been invalidated
>  if root._invalid != value or root.pass_through:
>  root._invalid = self.INVALID # value  <===
>  stack.extend(root._parents.keys())
> 
> Now, I know this is the wrong solution, because it defeats all the 
> cleverness with the _invalid values; but perhaps it will save you a few 
> minutes in finding the right solution.
> 
> To reproduce the problem, do this in ipython -pylab:
> 
> axhline(5)
> yscale('log')
> ylim(0.5,30)
> 
> Eric
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Eric Firing]

Michael Droettboom wrote:
> Thanks for the reminder.  It wasn't propagating the "non-affine" 
> invalidation correctly.  I think I have a fix in r6465, but please let 
> me know if you see anything else funny.
> 
> Cheers,
> Mike

Mike,

It looks like that helps, fixing the window resize behavior, but zooming 
and panning still do not work in the original example given by João Silva:

import matplotlib.pyplot as pl
import numpy as np

x = np.linspace(0.0,1.0,100)

pl.semilogy(x,x**2)
pl.axvline(x=0.5,ls='--',color='k')
pl.show()

Eric


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Eric Firing]

Michael Droettboom wrote:
> Hmm...  works fine for me here, both with the zoom/pan tool and zoom to 
> rect.  Can you describe a particular action that isn't working?  I'm at 
> a loss otherwise...

Mike,

When I run João's commands in ipython -pylab and click the pan/zoom 
button, panning or zooming moves the plotted curve, but the axvline 
stays in the middle of the picture instead of moving with the x=0.5 
point.  Same with zoom-to-rect: the axvline stays in the middle of the 
window, not at x=0.5.

Eric

> 
> Mike
> 
> Eric Firing wrote:
>> Michael Droettboom wrote:
>>> Thanks for the reminder.  It wasn't propagating the "non-affine" 
>>> invalidation correctly.  I think I have a fix in r6465, but please 
>>> let me know if you see anything else funny.
>>>
>>> Cheers,
>>> Mike
>>
>> Mike,
>>
>> It looks like that helps, fixing the window resize behavior, but 
>> zooming and panning still do not work in the original example given by 
>> João Silva:
>>
>> import matplotlib.pyplot as pl
>> import numpy as np
>>
>> x = np.linspace(0.0,1.0,100)
>>
>> pl.semilogy(x,x**2)
>> pl.axvline(x=0.5,ls='--',color='k')
>> pl.show()
>>
>> Eric
> 



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transforms bug: axhline with log y scale

[Eric Firing]

Michael Droettboom wrote:
> Sorry -- I neglected to commit some changes.  (Playing around with bzr 
> and still getting used to it, I guess.)

Very good, thank you!

OT: I'm glad you are taking a look at bzr; personally, I chose hg quite 
some time ago (when bzr was not mature enough to use), and I have no 
regrets.  It is very small, quick, and uncluttered--a beautiful piece of 
work.  (The code base is *much* smaller than bzr--I like that.) The one 
area in which hg is a bit behind now is svn interoperability,
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion,
which doesn't matter at all for the uses to which I put it.  Possibly it 
will catch up soon: 
http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion
http://blog.red-bean.com/sussman/?p=116

Eric

> 
> Mike
> 
> Eric Firing wrote:
>> Michael Droettboom wrote:
>>> Hmm...  works fine for me here, both with the zoom/pan tool and zoom 
>>> to rect.  Can you describe a particular action that isn't working?  
>>> I'm at a loss otherwise...
>>
>> Mike,
>>
>> When I run João's commands in ipython -pylab and click the pan/zoom 
>> button, panning or zooming moves the plotted curve, but the axvline 
>> stays in the middle of the picture instead of moving with the x=0.5 
>> point.  Same with zoom-to-rect: the axvline stays in the middle of the 
>> window, not at x=0.5.
>>
>> Eric
>>
>>>
>>> Mike
>>>
>>> Eric Firing wrote:
>>>> Michael Droettboom wrote:
>>>>> Thanks for the reminder.  It wasn't propagating the "non-affine" 
>>>>> invalidation correctly.  I think I have a fix in r6465, but please 
>>>>> let me know if you see anything else funny.
>>>>>
>>>>> Cheers,
>>>>> Mike
>>>>
>>>> Mike,
>>>>
>>>> It looks like that helps, fixing the window resize behavior, but 
>>>> zooming and panning still do not work in the original example given 
>>>> by João Silva:
>>>>
>>>> import matplotlib.pyplot as pl
>>>> import numpy as np
>>>>
>>>> x = np.linspace(0.0,1.0,100)
>>>>
>>>> pl.semilogy(x,x**2)
>>>> pl.axvline(x=0.5,ls='--',color='k')
>>>> pl.show()
>>>>
>>>> Eric
>>>
>>
> 



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot.fill() and masked arrays

[Eric Firing]

Ryan May wrote:
> Hi,
> 
> Is there any reason pyplot.fill() doesn't support masked arrays?  Or was it 
> just 
> overlooked?
> 

I think the reason is that it is not obvious what any filled region with 
masked vertices should look like.

Eric

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot.fill() and masked arrays

[Eric Firing]

Ryan May wrote:
> Ryan May wrote:
>> Hi,
>>
>> Is there any reason pyplot.fill() doesn't support masked arrays?  Or was 
>> it just overlooked?
> 
> Looks like this is better handled by fill_between, nevermind.
> 
> Now, what about dates?  I'm having problems using dates for the x-axis for 
> fill_between.  I know I can use date2num on my array, but I was wonder if 
> there 
> was some magic I could add to the fill_between code.

Magic is the operative word.  It is sprinkled like pixie dust throughout 
mpl.  You may be able to figure it out by looking at the code for other 
functions that do support units.  You could look for recent commits by 
Ted Drain, if I remember correctly, and by John, both of whom fill gaps 
in units handling every now and then.

For example, note this line at the top of scatter:

 self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs)


Eric

> 
> Ryan
> 


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] CHANGELOG tabs

[Eric Firing]

Ryan May wrote:
> Hi,
> 
> It looks like some tabs have crept into the CHANGELOG file.  Is anyone 
> opposed to 
> me changing them to the equivalent (8) spaces?  It messes up my editor, which 
> is 
> set to display them as 4 spaces, and makes it think that tabs are the proper 
> way 
> to indent.
> 
> Ryan
> 

By all means, tabs are bugs, kill them dead!

Eric

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Loss of filled vs. stroked distinction by Collections

[Eric Firing]

Eric Bruning wrote:
> I think of artists as having visual properties that persist (e.g.,
> filled vs. outlined, a colormap with min and max values) even as data
> associated with the artist is changed. In the edge case described
> below, this doesn't seem to hold true.
> 
> I have code that animates a scatter plot by sub-selecting the data
> stored in a collection artist. In cases where some frames contain no
> data, the scatter artist's data is temporarily empty. On subsequent
> frames (once there is data again) some of the visual properties my
> filled point becomes an outlined point, as in the code below.
> 
> # Filled single point with no outline
> sc = scatter([1],[1],c=[1], edgecolors='none')
> 
> # Cache the data
> xy=sc.get_offsets()
> s=sc.get_array()
> 
> sel=s<0
> sc.set_offsets(xy[sel,:])
> sc.set_array(s[sel])
> 
> # No data, so nothing shown. No problem.
> sc.figure.canvas.draw()
> 
> # Now restore the original data
> sc.set_offsets(xy)
> sc.set_array(s)
> 
> # Outlined single point with no fill
> sc.figure.canvas.draw()
> sc.get_edgecolors()
> sc.get_facecolors()
> sc.get_array()
> 
> The fix probably has to do with Collection.update_scalarmappable.
> When set_array([ ]) happens,
> len(self._facecolors) > 0, therefore
> self._facecolors = to_rgba([  ]),
> When set_array([1]) restores data,
> len(self._facecolors) == 0, therefore
> self._edgecolors = self.to_rgba([1])
> 
> Should is_filled vs. is_stroked be preserved in this case? If so, is
> there a more elegant fix than to add is_filled and is_stroked
> properties that are checked by update_scalarmappable?

I don't see a better way, so I implemented your suggestion.

Eric

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] polar plotting and theta wrapping

[Eric Firing]

Mike, Jan,

The thread
http://www.mail-archive.com/matplotlib-us...@lists.sourceforge.net/msg08342.html

culminated in changeset r6106, which seemed to fix the immediate 
problem, but in fact introduced a major bug: polar plotting was broken 
for lines or patches with angles crossing zero.

The real solution to the original problem is not a change to mpl, but to 
user code.  In the example from the thread,

r = np.transpose(.1+np.arange ( 0 , 0.7 , 0.001))
theta = -4.5 * np.pi *r
freq = r*10e9
data = np.multiply(r,np.exp(1j*theta))
ax.plot(np.unwrap(angle(data)),abs(data))  # note added call to unwrap

the original problem was that the angle was jumping from near minus pi 
to near plus pi, and the solution is to use the unwrap function, or 
equivalent, to make the angle vary smoothly from start to finish, with 
no jumps.

Any attempt to normalize the angles to a fixed range of length 2 pi 
inside of mpl is sure to wreck valid user code; it merely moves the 
trouble spot to a different angle.

In 6731 I reverted the normalization change from 6106, and also improved 
the r-tick locations in cases where the actual r-data range is small.

Mike, of course I realized too late that I should have made the change 
in the maintenance branch and used svnmerge to propagate it to the 
trunk; should I just make the change manually in the branch?

Polar plotting could still use more work, but I doubt I will be able to 
do much any time soon.

Eric

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] polar plotting and theta wrapping

[Eric Firing]

Michael Droettboom wrote:
> Eric Firing wrote:
>> Mike, Jan,
>>
>> Any attempt to normalize the angles to a fixed range of length 2 pi 
>> inside of mpl is sure to wreck valid user code; it merely moves the 
>> trouble spot to a different angle.
> Thanks for catching this.  Clearly that was a bone-headed fix on my 
> part... :(
>>
>> In 6731 I reverted the normalization change from 6106, and also 
>> improved the r-tick locations in cases where the actual r-data range 
>> is small.
>>
>> Mike, of course I realized too late that I should have made the change 
>> in the maintenance branch and used svnmerge to propagate it to the 
>> trunk; should I just make the change manually in the branch?
> That should work fine.  Then run "svnmerge merge ; svn commit" back on 
> the trunk to mark it as merged.

Mike,

The following is the result of svnmerge merge and svn status; I have not 
yet run svn commit because the status output suggests to me that things 
are getting merged that perhaps should not, since I don't know anything 
about them.  Advice?

Eric

efir...@manini:~/programs/py/mpl/mpl_trunk$ svnmerge merge -S 
v0_98_5_maintproperty 'svnmerge-integrated' set on '.'

property 'svnmerge-blocked' deleted from '.'.

--- Merging r6717 through r6732 into '.':
Ulib/matplotlib/path.py

property 'svnmerge-integrated' set on '.'

property 'svnmerge-blocked' deleted from '.'.

efir...@manini:~/programs/py/mpl/mpl_trunk$ svn status
  M .
?  svnmerge-commit-message.txt
?  doc/build
?  doc/examples
?  doc/_static/inheritance0ca9968ee0.pdf
?  doc/_static/inheritance1bda3e63b5.pdf
?  doc/_static/inheritance829eaf436e.pdf
?  doc/_static/inheritance47732b7b79.pdf
?  doc/_static/inheritance0ca9968ee0.png
?  doc/_static/inheritancecbc02086c0.pdf
?  doc/_static/inheritance1bda3e63b5.png
?  doc/_static/inheritance829eaf436e.png
?  doc/_static/inheritance47732b7b79.png
?  doc/_static/mathmpl
?  doc/_static/inheritancecbc02086c0.png
?  doc/_static/plot_directive
?  doc/_static/examples
  M doc/sphinxext/gen_gallery.py
  M doc/sphinxext/gen_rst.py
  M doc/pyplots/README
?  lib/matplotlib/cbook0.py
?  lib/matplotlib/colors0.py
?  lib/matplotlib/transform.py
?  lib/matplotlib/axes0.py
M  lib/matplotlib/path.py
?  examples/tests/ps
?  examples/tests/agg
?  examples/tests/svg
?  examples/tests/pdf
?  examples/tests/template

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] contour plots & linestyles

[Eric Firing]

Manuel Metz wrote:
> Hi,
>   I just noted a strange behavior of contour(). When a contour plot is
> created with negative values and using a single color instead of a cmap,
> contour _always_ uses the contour.negative_linestyle, even if linestyles
> are specifically provided:
> 
>   x = linspace(-pi,pi,100)
>   X,Y = meshgrid(x,x)
>   Z = cos(X) + 0.5*cos(Y)
> 
>   contour(X,Y,Z, colors='k', linestyles='solid')
> 
> I would expect the contour.negative_linestyle to be used when
> linestyles=None, but not if it is explicitly specified. More serious,
> even in the following case the effect takes place.
> 
>   contour_ls = ['solid']*9
>   contour(X,Y,Z,10, colors='k', linestyles=contour_ls)
> 
> 
> Should we consider this as a bug and fix it ???

Fixed.  Thank you.  Oh, rats. I forgot again--I need to put this in the 
maintenance branch, and your immediately preceding change probably 
should go there, too, so I will take care of both now.

Eric

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Problem with pan/ZOOM on semilog plot

[Eric Firing]

John Hunter wrote:
> On Sat, Jan 10, 2009 at 12:28 PM, David Trem  wrote:
>> Hi,
>>
>>  I've just discover a problem with the pan/zoom tool.
>> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
>> zoom does not work correctly.
>> To visualize the problem launch the small script in attachment press the
>> pan/zoom button and use the zoom on the x axis direction -> you will see
>> the button part of the curve directly jumping at the bottom of the graph
>>  whereas you would expected it not to move...
>> I evidence this problem using GTKAgg but also with the OSX backend (did
>> not try other backend).
>> Matplotlib version is the latest svn on a MacOS X platform.
> 
> I don't think I see this -- if you hold down the 'x' while you are
> panning, the zoom will be constrained in the x direction and I see no
> unusual movement.  If I release the 'x' but still zoom horizontally,
> there is some motion in the vertical direction, but that is because I
> cannot move precisely horizontally.  Could you be more precise about
> the artifact you are seeing. For me, the bottom part of the curve is
> at (0, 10^0) and and I do not see any unusual behavior there

John,

I reproduced the problem (jumpy boundary with log scale and zoom) and 
fixed it in my last two commits (6773 to maint and 6775 merging to trunk).

Eric


> 
> --
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] pruning the codebase

[Eric Firing]

While trying to track down the zoom bug reported by David Trem, I got 
all tangled up in what appear to be completely obsolete and unneeded 
"zoom" etc. methods.  These are left over from the original 
NavigationToolbar and the pre-transforms code.  I would like to see all 
of this, including the entire original NavigationToolbar, deprecated and 
then removed.  My guess is that no one is actually using any of it.

Comments?  Does anyone know of other cruft that we might be able to 
clean out?

Eric

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] refactoring for units; was Re: John: Thoughts on a standard test system

[Eric Firing]

John Hunter wrote:

> On the issue of units (not unit testing but unit support which is
> motivating your writing of unit test) I think we may need a new
> approach.  The current approach is to put unitized data into the
> artists, and update the converted data at the artist layer.  I don't
> know that this is the proper design.  For this approach to work, every
> scalar and array quantity must support units at the artist layer, and
> all the calculations that are done at the plotting layer (eg error
> bar) to setup these artists must be careful to preserve unitized data
> throughout.  So it is burdensome on the artist layer and on the
> plotting function layer.
> 
> The problem is compounded because most of the other developers are not
> really aware of how to use the units interface, which I take
> responsibility for because they have oft asked for a design document,
> which I have yet to provide because I am unhappy with the design.  So
> new code tends to break functions that once had unit support.  Which
> is why we need unit tests 
> 
> I think everything might be  easier if mpl had an intermediate class
> layer PlotItem for plot types, eg XYPlot, BarChart, ErrorBar as we
> already do for Legend.  The plotting functions would instantiate these
> objects with the input arguments and track unit data through the
> reference to the axis.  These plot objects would contain all the
> artist primitives which would store their data in native floating
> point, which would remove the burden on the artists from handling
> units and put it all in the plot creation/update logic.  The objects
> would store references to all of the original inputs, and would update
> the primitive artists on unit changes.  The basic problem is that the
> unitized data must live somewhere, and I am not sure that the low
> level primitive artists are the best place for that -- it may be a
> better idea to keep this data at the level of a PlotItem and let the
> primitive artists handle already converted floating point data.  This
> is analogous to the current approach of passing transformed data to
> the backends to make it easier to write new backends.  I need to chew
> on this some more.

John,

I think that getting unit support out of the basic artists, and keeping 
it at a higher level, is an excellent idea.  Right now, unit support is 
sprinkled all over, and one never knows exactly where it will be or what 
to expect.  Most of it works, but some doesn't.  (I just fixed a part 
that didn't.)

One could go a little farther with this and require that more of the 
argument checking and regularization be done above the artist level as 
well; so that the artists could count on arrays of coordinates being 
ndarrays or masked arrays, for example.  Whether the resulting code 
simplification would be worth the extra care required in using the 
artists, I don't know.

I also like the PlotItem concept as a way to get Axes under control and 
slimmed down.  It is the approach taken with Quiver, Contour, and 
Colorbar, so there is more precedent than just Legend.

I'm not sure that a complete PlotItem-ization is required for localizing 
the unit support at a higher level than the basic artists; maybe it can 
be done piecemeal.  A complete one-shot reworking would be a big job, 
requiring a lot of testing.

Eric

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [SciPy-user] recursion limit in plot

[Eric Firing]

Ryan May wrote:

> Ok, my debugging tells me the problem comes down to the units support,
> specifically this code starting at line 130 in units.py:
> 
> if converter is None and iterable(x):
> # if this is anything but an object array, we'll assume
> # there are no custom units
> if isinstance(x, np.ndarray) and x.dtype != np.object:
> return None
> 
> for thisx in x:
> converter = self.get_converter( thisx )
> return converter
> 
> Because a string is iterable, and even a single character is considered 
> iterable,
> this code recurses forever.  I can think this can be solved by, in addition to
> the iterable() check, make sure that x is not string like.  If it is, this 
> will
Doing this check makes sense.
> return None as the converter.  Somehow, this actually will then plot properly.
> I'm still trying to run down why this works, but I'm running out of time for 
> the
> day.  I will say that the data set for the line2D object is indeed a masked 
> array
>  of dtype ('|S4').
> 
> Anyone object to adding the check?
> 
> In addition, why are we looping over thisx in x but returning inside the loop?
> Wouldn't this *always* be the same as x[0]?
> 

The idea is to base the converter selection on the first item instead of 
checking every item, which would be very slow.



> Ryan
> 


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] units/ example scripts

[Eric Firing]

John Hunter wrote:
[...]
> 
> The code is trying to add a non-unitized quantity (eg an errorbar
> width but just guessing) of int type with a unitized quantity
> TaggedValue (this is from the mockup basic_units testing package).
> You'd have to dig a little bit to find out where the non-unitized
> quantity is entering.  errorbar is a complex example that was once
> (and I think still is) working on the 91 branch.  You may want to
> compare the errorbar function on the branch vs the trunk and see what
> new feature and code change broke the units support.  Again, it might
> be cleaner to have an ErrorbarItem that stores the errorbar function
> inputs and updates artist primitives on unit change rather than try
> and propagate the original unitized data down to the artist layer.  As
> Eric suggested, doing these one at a time is probably a good idea, and
> errorbar is a good test case because it is so damned hairy :-)

One of the reasons for doing all the conversions at the higher level 
than the primitive artist is that often one *has* to do the conversion 
at that higher level in order to do the calculations required to draw 
the item; so a consequence of putting the conversion in the primitive 
artists is that the conversion facilities have to live at *both* levels, 
which makes the code harder to understand and maintain.  The only 
penalty in taking the conversion out of the primitive artists is that a 
user who wants to support units in a custom plot type, using primitive 
artists, must include the unit conversion etc.  I don't think this is a 
big problem for new code, though, because if the conversion is at that 
higher level only, then it is easy to show how to do it (there will be 
plenty of examples), and to ensure that there are enough helper 
functions to make it easy to code.  Maybe there already are.  Or maybe 
deriving from a PlotItem base class would make it easier.  (Or maybe 
this is a place where decorators would simplify things?  Just a random 
idea, not thought out.)

Eric


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svnmerge broken?

[Eric Firing]

John Hunter wrote:
> After reading in a separate thread that Eric was having trouble with
> svnmerge, I gave it a try and got
> 
>   jdhun...@uqbar:mpl> svnmerge.py merge v0_98_5_maint
>   svnmerge: "v0_98_5_maint" is not a subversion working directory
> 
> Maybe our svn merge guru (MD) could take a look and see if anything
> looks out of whack?

John,

I don't understand exactly what was going on, but I suspect there may 
have been two or more problems--especially since you seem to have run 
into the same error message that I was getting.

One problem, I think, is that I was trying to run svnmerge from a 
subdirectory instead of from the root of my checkout.  I simply did not 
notice that I was in the wrong directory until I had thrashed around for 
a while.

There may be, or have been, a larger problem as well--maybe caused by 
me, maybe not.  In any case, to get things working, I reran

svnmerge init 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_5_maint

but it looks like I was still in the wrong directory when I did that, so 
I don't know if it had any useful effect.

After getting into the right directory, some combination of svn up and 
svnmerge merge seemed to get everything straightened out, with a little 
editing to resolve conflicts along the way.

That was last night, in the misty past.  Now it looks like I am back 
with the original problem I started with last night, and which you also 
reported:

efir...@manini:~/programs/py/mpl/mpl_trunk$ svnmerge avail 
/branches/v0_98_5_maint
svnmerge: "/branches/v0_98_5_maint" is not a subversion working directory

So, I'm baffled again.  It is as if Jae-Joon's commit since mine of last 
night, and my corresponding "svn up" this morning, wiped out the 
svnmerge tracking info.

I suspect a brief wave of Mike's magic wand tomorrow morning will clear 
away the fog.

Eric

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svnmerge broken?

[Eric Firing]

Michael Droettboom wrote:
> You need the '-S' parameter to specify a branch.  Otherwise, any 
> arguments after the command name are just paths within the working copy, 
> just like most other svn commands.
> 
> So you need to do:
> 
>> svnmerge.py merge -S v0_98_5_maint
> 
> I just tested a change to the branch followed by a merge and everything 
> seems to be working fine here.
> 
> Eric Firing wrote:
>> John Hunter wrote:
>>   svnmerge init 
>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_5_maint
>>  
>>
>>   
> That would have no effect without a following commit anyway... but 
> please don't do that if you're not sure what you're doing.  That command 
> really should only ever be needed once.  It's pretty hard to get into a 
> state where it would ever need to be done again for a particular branch.
>> but it looks like I was still in the wrong directory when I did that, 
>> so I don't know if it had any useful effect.
>>
>> After getting into the right directory, some combination of svn up and 
>> svnmerge merge seemed to get everything straightened out, with a 
>> little editing to resolve conflicts along the way.
>>   
> You can do merges from within subdirectories, and it works just like 
> most other svn commands when run from a subdirectory.  Generally, 
> though, I like to catch all available merges and run from the root of 
> the source tree.
>> That was last night, in the misty past.  Now it looks like I am back 
>> with the original problem I started with last night, and which you 
>> also reported:
>>
>> efir...@manini:~/programs/py/mpl/mpl_trunk$ svnmerge avail 
>> /branches/v0_98_5_maint
>> svnmerge: "/branches/v0_98_5_maint" is not a subversion working directory
>>   
> Again, you're specifying a path that doesn't exist within the source 
> tree.  There is no need to specify a path (generally) with the "svnmerge 
> avail" command.
>> So, I'm baffled again.  It is as if Jae-Joon's commit since mine of 
>> last night, and my corresponding "svn up" this morning, wiped out the 
>> svnmerge tracking info.
>>
>> I suspect a brief wave of Mike's magic wand tomorrow morning will 
>> clear away the fog.
>>   
> I think this all comes down to missing the '-S'.  I didn't need to get 
> out my wand for this one... ;)

Well, looking back at the command history in the terminal window I was 
using, I was using the -S last night when things first started going 
haywire; but one way or another, or many ways, I was getting confused.

Thanks for the clarifications and testing.

Eric

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] set_aspect with shared axes

[Eric Firing]

Ryan May wrote:
> Hi,
> 
> Does anyone know why set_aspect('equal', 'box') isn't accepted on shared axes?
> I'm trying to make the following type of scenario work:

Ryan,

Mark Bakker keeps asking about this, too.

I have never been able to figure out an algorithm, consistent with the 
present mpl architecture, that would cleanly handle shared axes with 
fixed aspect ratio when the box is adjustable.  If you can specify 
exactly what should happen under all such conditions that might 
arise--including single or dual shared axes, and fixed aspect ratio on 
one or more of the plots with shared axes, and any kind of zooming or 
panning--then we should be able to come up with the logic to implement it.

Maybe the problem is not that there is no such specification or 
algorithm, but that it requires a global solution, involving figuring 
out the dimensions of all the boxes at the same time, whereas with 
adjustable datalim the calculation can be done on any subplot 
individually--hence it can be in Axes.draw, as at present.  I suspect 
this is the crux of it--fixed aspect ratio, shared axes, adjustable box 
would require a level of code that does not exist at present; a method 
invoked at the Figure.draw() level that would calculate and freeze all 
of the axes positions in one whack before any of them are drawn.

Actually, even this is not right, because IIRC axes can be shared across 
figures, so this calculation would need to be done at the highest 
level--before the Figure.draw() method.

If we go this route--which sounds like going to full-fledged sizer/pack 
type algorithms--we need to be sure it does not slow down interactive 
responsiveness.  Or burden us with bugs and unmaintainable code. 
Sometimes it is worthwhile to accept some limitations and keep things 
simple.

Note that the present implementation of shared axes, unlike an earlier 
implementation, has no notion of master and slaves; all are equivalent, 
and can be calculated and drawn in any order.

Eric


> 
> import numpy as np
> from matplotlib.pyplot import figure, show
> 
> fig1 = figure()
> fig2 = figure()
> 
> ax1 = fig1.add_subplot(1, 1, 1)
> ax1.set_aspect('equal', 'datalim')
> 
> ax2 = fig2.add_subplot(1, 2, 1, sharex=ax1, sharey=ax1)
> ax2.set_aspect('equal', 'datalim')
> ax3 = fig2.add_subplot(1, 2, 2, sharex=ax2, sharey=ax2)
> 
> data = np.random.rand(50,50)
> ax1.pcolormesh(data)
> ax2.pcolormesh(data)
> ax3.pcolormesh(data)
> 
> show()
> 
> Basically, I have multiple figures with multiple subplots, all of which 
> should be
> displaying the same range.  However, the different figures have different 
> numbers
> of subplots.  The example above doesn't work, because once you zoom into one 
> of
> the figures, it iteratively zooms out, adjusting data limits until both 
> figures
> have their aspect ratio properly set again.  I thought using 'box' might
> alleviate the problem, but that's throwing an exception.
> 
> I realize making the figures have the same layout would solve the problem, I 
> just
> wasn't sure if there was another way.
> 
> Ryan


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Line2D.set_pickradius missing in svn

[Eric Firing]

Martin Spacek wrote:
> Hi,
> 
> I just updated my checkout to rev 6829, and it seems 
> lines.Line2D.set_pickradius 
> has been renamed to setpickradius. Is this a typo? get_pickradius still 
> exists. 
> This is on line 318 in lines.py. Renaming it back to set_pickradius seems 
> make 
> it work the way it used to.
> 

John, you made the change on Dec. 10:

http://currents.soest.hawaii.edu/hg/hgwebdir.cgi/matplotlib_mirror/diff/0a8f5203a8fd/matplotlib/lib/matplotlib/lines.py

Looks accidental to me.

Eric

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] gtk backend silently ignores all exceptions

[Eric Firing]

John Hunter wrote:
> On Mon, Jan 26, 2009 at 6:02 PM, Jae-Joon Lee  wrote:
>> Michael,
>>
>> It seems that the gtk backend in the current svn silently ignores ALL
>> exceptions raised during the drawing.
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/backends/backend_gtk.py?r1=6696&r2=6793
>>
>> Is this necessary? I don't think we want to do this.
> 
> No, it is a bug.  Catching blanket exceptions and ignoring them is
> never OK -- we need to add a section to the coding guide to this
> effect.  If absolutely necessary, one can catch blanket exceptions and
> log them, eg using cbook.exception_to_str, but they must be reported.
> Michael has already fixed this (perhaps it was some detritus left in
> from a debugging session?) and I'll make a note in the developer docs
> coding guide.

John,

Not quite "always": I think that for something like cbook.is_string_like 
we actually *do* want to silently catch all exceptions.  The problem is 
that if you know nothing about the type of object that you might have to 
deal with, you have no way of knowing what exception it might raise.  We 
ran into an example of this recently.

Eric

> 
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updated units.ConversionInterface

[Eric Firing]

James Evans wrote:
> All,
> 
> I have just submitted an updated units.ConversionInterface.  For each of the 
> static methods it now takes the invoking Axis instance
> as a parameter.  I have updated the appropriate calling functions.  This 
> allows the DateConverter to now guarantee that the default
> axes no longer attempts to convert a value of zero to a date (ie. The 
> 'ordinal <= 0' datetime conversion error is now a lot more
> difficult to invoke).  Additionally I have modified the DateConverter class 
> to make use of any specified units, such that the
> timezone is used for the units value.
> 

James,

I have not thought all this through, but a quick look at your changeset 
raises the question:

Why are you making such a complete change in the API?  In every 
instance, you are changing the method signature so that the new arg, 
"axis", is the first.  This seems particularly odd for the "convert" 
method--the new signature, convert(axis, value, unit), gives the 
arguments in what seems to be an unintuitive order.  Why not have 
something like convert(value, unit, axis=None), so that convert can be 
called without specifying an axis, and so that the argument order is 
still natural: "convert the value with unit, taking advantage of the 
axis if specified"?

Is there some compelling logic to having the "axis" argument now at the 
head of the list?

Eric

> --James Evans
> 
> PS: I expect to be submitting a fully functioning test harness by the end of 
> this week.
> 
> 
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] broken examples/units/*

[Eric Firing]

James,

The scripts in examples/units (and run by backend_driver.py) are broken; 
they have not been updated to match your addition of the new mandatory 
axis argument to convert() and default_units().  Would you fix them, 
please?  (While you are in the neighborhood, you might also update the 
methods by switching to the @staticmethod decorator.)

The argument was also missing from the units.py docstring, but I have 
fixed that.

Thank you.

Eric

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Can we retire numerix?

[Eric Firing]

Chris Barker wrote:
> Hi all,
> 
> I just ran into an issue with py2exe -- my app failed because various 
> numpy sub-packages weren't included. However, I wasn't using them. But 
> it failed because numerix imports them, and they weren't included 
> because it imports them with __import__
> 
> Anyway, I can work around this, but it made me wonder: is it time to 
> retire numerix? We all should be using numpy anyway.

Why was numerix getting imported?  Is this inherent in py2exe--that it 
imports all subpackages of a base, if you use that base (matplotlib)?

Numerix is there only for the convenience of anyone who has code that 
depends on it; it is completely unused in matplotlib itself.  I would be 
happy get it out of matplotlib, or phase it out if necessary.  I don't 
think it should be left there forever.

Eric

> 
> note that the docstring is out of date, too:
> 
> """
> 1. The value of numerix in matplotlibrc: either Numeric or numarray
> 
> 2. If none of the above is done, the default array package is Numeric.
> Because the matplotlibrc always provides *some* value for numerix
> (it has it's own system of default values), this default is most
> likely never used.
> 
> To summarize: the  commandline is examined first, the  rc file second,
> and the default array package is Numeric.
> """
> 
> -Chris
> 
> 
> 
> 


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Can we retire numerix?

[Eric Firing]

John Hunter wrote:
> On Tue, Feb 24, 2009 at 1:44 PM, Christopher Barker
>  wrote:
> 
>>> happy get it out of matplotlib, or phase it out if necessary.  I don't
>>> think it should be left there forever.
> 
> I think it can be removed.  It lives on the maintenance branch 0.91.

Good point.  I am in the process of removing it from the trunk.  I 
should be doing this slightly differently, with a single commit, but I 
got ahead of myself, so it will take more than one.  Sorry.

Eric

> 
> JDH
> 
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Can we retire numerix?

[Eric Firing]

Christopher Barker wrote:
> Eric Firing wrote:
>> It has been purged from the svn trunk.
> 
> Thanks. Has it been deprecated somehow? I don't want folks' code to 
> break too fast!

No, I guess I was in a dangerous mood--I just ripped it out.  I could 
put it back with a deprecation if necessary--is it? The only nod to 
deprecation at present is that a matplotlibrc file with a numerix entry 
will trigger a warning instead of bombing.

It is still in the 0.98.5 maintenance branch, which I presume will be 
the source of the next release.  One option would be to put a 
deprecation warning there, but leave the trunk as-is.

What we probably *should* have done was to put a deprecation warning in 
back when 0.98 was first released.

Eric

> 
> 
>>  Now, if you can run your app after building from svn,
> 
> Well, I'm not set up to build on Windows...
> 
>> it should become obvious where the numerix import was coming from
> 
> Found it: it was wxmpl. I'm going to send a patch to Ken.
> 
> -Chris
> 
> 
> 
> 


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Can we retire numerix?

[Eric Firing]

Chris Barker wrote:
> Hi all,
> 
> I just ran into an issue with py2exe -- my app failed because various 
> numpy sub-packages weren't included. However, I wasn't using them. But 
> it failed because numerix imports them, and they weren't included 
> because it imports them with __import__
> 
> Anyway, I can work around this, but it made me wonder: is it time to 
> retire numerix? We all should be using numpy anyway.

It has been purged from the svn trunk.  Now, if you can run your app 
after building from svn, it should become obvious where the numerix 
import was coming from, assuming it was in your app or in some package 
it imports.

Eric

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Can we retire numerix?

[Eric Firing]

Christopher Barker wrote:
> Eric Firing wrote:
>> It has been purged from the svn trunk.
> 
> Thanks. Has it been deprecated somehow? I don't want folks' code to 
> break too fast!

I have restored a stripped-down numpy-only version of numerix, with a 
prominent deprecation warning.

Eric

> 
> 
>>  Now, if you can run your app after building from svn,
> 
> Well, I'm not set up to build on Windows...
> 
>> it should become obvious where the numerix import was coming from
> 
> Found it: it was wxmpl. I'm going to send a patch to Ken.
> 
> -Chris
> 
> 
> 
> 


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] File format for plots

[Eric Firing]

Sandro Tosi wrote:
> Hi Sam,
> 
> On Wed, Feb 25, 2009 at 09:35, sam tygier  wrote:
>> I think this topic has come up before, but i don't think anything has
>> resulted from it.
>>
Correct, because the capability would require a *lot* of work to 
implement, and most of us don't see a compelling need; we believe that a 
better practice is to structure one's work so that plotting is separated 
from data (result) generation in any cases where the latter is highly 
time-consuming.

>> I'd like a way for saving a plot from from matplotlib, so that it can be
>> re-rendered later, possibly with a different backend, maybe to a different
>> size, and maybe with changes to the labels. This would save me having to
>> rerun the simulation that generated the plot.
>>
>> Ideally this would work by having a save_plot() function, that would save
>> all state of the current plot into a file. This could then be loaded by a
>> program to regenerate that plot.
> 
> Can't this be achieved by pickling/unpickling the mpl objects? Didn't
> manage to test it, but it should work.

No, this has been discussed several times.  Quite a bit of work would be 
required to make all the extension code compatible with pickling.  More 
work, more complexity, more difficult code maintenance and testing. 
It's not worth it, given the developer resources available for mpl.

> 
> Of course, it might fall in uncompatibility from source (pickling)
> environment and the destination (unpickling) one.

Yes, pickling is fundamentally unreliable, and should be used only under 
controlled, non-critical circumstances, such as for caching.

Eric

> 
> Regards,


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] File format for plots

[Eric Firing]

sam tygier wrote:
> Eric Firing wrote:
>> Sandro Tosi wrote:
>>> Hi Sam,
>>>
>>> On Wed, Feb 25, 2009 at 09:35, sam tygier  wrote:
>>>> I think this topic has come up before, but i don't think anything has
>>>> resulted from it.
>>>>
>> Correct, because the capability would require a *lot* of work to 
>> implement,
> 
> Would i be right in assuming that it would take roughly the same amount of 
> effort as writing a new backend? ie for each motplotlib action it would need 
> a function to store that action and a function to call that action again.

It is much more than that; it would take a backend to write out the new 
format, and an interpreter to turn that format back into mpl objects or 
API calls.

One of the mpl backends is svg; can you use something like Inkscape to 
make the plot adjustments you are talking about?

Eric

> 
>> and most of us don't see a compelling need; we believe that a 
>> better practice is to structure one's work so that plotting is separated 
>> from data (result) generation in any cases where the latter is highly 
>> time-consuming.
> 
> It might not be essential, but it would offer an additional work flow, that a 
> few people seem to like.
> 
> I think it would be especially useful when it comes to putting plots into 
> papers. I often find that i want to tweak something like the font size or 
> labels. having a modifiable plot format seems the easiest way to achieve 
> that. maybe the could even be some integration into latex so that if you were 
> to resize your plot in your paper, it would be re-rendered with the fonts 
> adjusted.
> 
>>>> I'd like a way for saving a plot from from matplotlib, so that it can be
>>>> re-rendered later, possibly with a different backend, maybe to a different
>>>> size, and maybe with changes to the labels. This would save me having to
>>>> rerun the simulation that generated the plot.
>>>>
>>>> Ideally this would work by having a save_plot() function, that would save
>>>> all state of the current plot into a file. This could then be loaded by a
>>>> program to regenerate that plot.
>>> Can't this be achieved by pickling/unpickling the mpl objects? Didn't
>>> manage to test it, but it should work.
>> No, this has been discussed several times.  Quite a bit of work would be 
>> required to make all the extension code compatible with pickling.  More 
>> work, more complexity, more difficult code maintenance and testing. 
>> It's not worth it, given the developer resources available for mpl.
> 
> a file format avoids all the issues that pickling causes.
> 
> thanks for all the comments
> 
> sam tygier
> 
> 
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Selecting WX2.8 in examples

[Eric Firing]

Sandro Tosi wrote:
> On Fri, Mar 6, 2009 at 22:12, Sandro Tosi  wrote:
> import wxversion
> wxversion.select('2.8')
> from wx import *
> wx.__version__
>> '2.8.7.1'
>>
>> That solves the problem of multi-wx on a system.
>>
>> What do you think about adding those 2 line into wx examples?
> 
> Moreover, I will provide a patch to move from
> 
 from wx import *
> 
> to
> 
 import wx
> 
> that's much more clear. Just let me know if in the patch I will add
> the wxversion.select or no.
> 
> Regards,

Sounds good to me, but I am not a wx user, so I might be missing 
something.  The only reservation that occurs to me is this:  suppose 
version 2.10 comes out, and someone has only that installed.  Is there a 
way to select 2.8 or higher, instead of requiring 2.8?

Eric


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Selecting WX2.8 in examples

[Eric Firing]

Sandro Tosi wrote:
> On Fri, Mar 6, 2009 at 22:24, Sandro Tosi  wrote:
>> On Fri, Mar 6, 2009 at 22:12, Sandro Tosi  wrote:
>> import wxversion
>> wxversion.select('2.8')
>> from wx import *
>> wx.__version__
>>> '2.8.7.1'
>>>
>>> That solves the problem of multi-wx on a system.
>>>
>>> What do you think about adding those 2 line into wx examples?
>> Moreover, I will provide a patch to move from
> 
> Here it is the promised patch (sorry for the late, that proves how
> busy I am these days).
> 
> It uses the 'wxversion.ensureMinimal' function as Chris pointed out,
> and move from "from wx import *" to "import wx".
> 
> I tested them on a sys (Debian sid) with both wx2.6 and wx2.8: before
> the patch the examples goes in abort, after they select wx2.8 and uses
> it displaying the windows (even though ex2 and 3 seems a little "too
> compress" do not know if it's due to code or patch ;) ).

Sandro,

I have applied your patch, plus related changes to backend_wx and 
backend_wxagg as suggested by Chris, to the 0.98.5 maintenance branch, 
and then used svnmerge to propagate the changes to the trunk.  (In other 
words, I judged the changes to be a bug fix rather than a new feature.)

Eric

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Polar Plot

[Eric Firing]

Sherif Ahmed wrote:
> Hello Mike,
> 
> Thanks for your advice. I think this is exactly what I need. I am not sure
> how to use this option, might you help me?
> 
> I use simply the following lines in my code:
> 
> self.figure.clf()
> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
 resolution=1,
> aspect='equal')
> 
> and later:
> self.axes.plot(angle(data),abs(data),label=title,linewidth = 2,zorder=10)
> 
> Where should I change the resolution feature? With each plot or with figure
> object?

Put the resolution kwarg in the call to the add_axes method.  The way 
the line is drawn between points--whether as a straight line on the plot 
or by interpolating in the data coordinates--is controlled on a per-axes 
basis by this kwarg when the axes are created.

Eric

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Polar Plot

[Eric Firing]

Sherif Ahmed wrote:
> Hello Eric,
> 
> I am afraid this does not work. I get error saying that :
> AttributeError: 'PolarAxes' object has no attribute 'set_resolution'


It looks like support for the resolution kwarg was added late in 
January, so you need either a more recent version, or an older version. 
  Unfortunately, it also looks like the latest release was before this 
change.

Maybe it is time for another release, either 0.98.5 maintenance or 
trunk. Or both. Releases are not my area, though.

Eric

> 
> The full error text is:
> -
> Traceback (most recent call last):
>   File "D:\EmGine
> Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 287, in 
> PlotSmith.plot_dummy()
>   File "D:\EmGine
> Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 241, in plot_dummy
> self.plot_data(data1.real, data1.imag,freq1,'my first data')
>   File "D:\EmGine
> Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 144, in plot_data
> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
> resolution = 1, aspect='equal')
>   File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\figure.py", line 615, in add_axes
> a = projection_factory(projection, self, rect, **kwargs)
>   File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\projections\__init__.py", line 44, in projection_factory
> return get_projection_class(projection)(figure, rect, **kwargs)
>   File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\projections\polar.py", line 171, in __init__
> Axes.__init__(self, *args, **kwargs)
>   File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\axes.py", line 537, in __init__
> if len(kwargs): martist.setp(self, **kwargs)
>   File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\artist.py", line 894, in setp
> func = getattr(o,funcName)
> AttributeError: 'PolarAxes' object has no attribute 'set_resolution'
> 
> 
> -
> 
> Do you know what is the reason behind this?
> 
> Thanks,
> Sherif
> 
> -Original Message-
> From: Eric Firing [mailto:efir...@hawaii.edu] 
> Sent: Thursday, March 19, 2009 11:39 PM
> To: Sherif Ahmed
> Cc: 'Michael Droettboom'; matplotlib-devel@lists.sourceforge.net
> Subject: Re: [matplotlib-devel] Polar Plot
> 
> Sherif Ahmed wrote:
>> Hello Mike,
>>
>> Thanks for your advice. I think this is exactly what I need. I am not sure
>> how to use this option, might you help me?
>>
>> I use simply the following lines in my code:
>>
>> self.figure.clf()
>> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
>  resolution=1,
>> aspect='equal')
>>
>> and later:
>> self.axes.plot(angle(data),abs(data),label=title,linewidth = 2,zorder=10)
>>
>> Where should I change the resolution feature? With each plot or with
> figure
>> object?
> 
> Put the resolution kwarg in the call to the add_axes method.  The way 
> the line is drawn between points--whether as a straight line on the plot 
> or by interpolating in the data coordinates--is controlled on a per-axes 
> basis by this kwarg when the axes are created.
> 
> Eric
> 


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Polar Plot

[Eric Firing]

Sherif Ahmed wrote:
> Hi Eric,
> 
> Thanks agaon. Now it works after updating to matplotlib 98.5.
> 
> Well I also attach the code. I find it good if we can publish it to other
> interested users. May be some one needs it or likes to upgrade it. I made
> already the basic work. How does this work? Should I distribute it via the
> list here or somewhere else?
> 
> I am not expert in this stuff :)
> 
> Nice wishes,
> Sherif

Thank you.

Let's see if someone wants to adapt it for direct inclusion in mpl, or 
as an example.  I'm not going to volunteer, since it is far from my area 
of expertise, and I am short of time anyway.

Eric

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] patches have incorrect alpha values

[Eric Firing]

Jae-Joon Lee wrote:
> Hi,
> 
> When drawing a patch, the alpha value of its edgeolor is ignored. The
> following command draw a circle whose edgecolor has alpha=1, instead
> of 0.1.
> 
> 
> gca().add_patch(Circle((0.5, 0.5), 0.3,
>ec=(1,0,0,0.1), fc="none"))
> 
> 
> Attached is a little test script and its output.
> It seems that the edgecolor always has an alpha value of the face color.
> I'm not sure if this behavior is intended, but I personally think this
> is a bug.

Jae-Joon,

I can't look at this specifically now, but I suspect it is a side effect 
of the way that alpha support has evolved, resulting in a confusing 
mess.  Some things are RGB, others are RGBA; alpha defaults get set in 
various places, and there is no clear way of keeping track of what is 
just a default and should be overridden, versus what has been set 
deliberately and should *not* be overridden. I dimly remember looking 
into it a few months ago, thinking that it could be cleaned up with some 
simple changes, but failing.  I really wish we could make some sweeps 
through the mpl code base and systematically clean up some of these 
messes.  I don't know how many there are, but certainly more than one. 
Dpi is another area of perennial confusion, for example.

Eric




--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] patches have incorrect alpha values

[Eric Firing]

Jae-Joon Lee wrote:

> 
> Thanks for the explanation.
> I personally think that the default behavior for setting alpha is
> better to be multiplying with the previous one, instead of overriding.

This was causing havoc in contourf; I don't see the logic of multiplying 
a previous alpha by a new one.

> We may introduce override keyword in set_alpha method to to force the
> override. I think it should be considered a bug If there are more than
> one alpha defaults involved. Just a thought.

Yes, it is a bug, but I don't think another kwarg in set_alpha will 
necessarily solve it.

Eric


> And, yes, dealing with the dpi is always confusing!
> 
> -JJ
> 
> 
> 
> 


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] patches have incorrect alpha values

[Eric Firing]

John Hunter wrote:
> 
> 
> On Mon, Mar 23, 2009 at 3:24 PM, Jae-Joon Lee  > wrote:
> 
> The example (e) in my previous script have a code and a text label
> mismatched.
> I'm attaching the corrected one.
> 
> I took a more look on how a patch is drawn.
> the draw() method of a patch calls draw_path method of the renderer,
> which seems to be responsible for both "fill", and "stroke". But there
> is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b
> and does not have a alpha value.
> 
>renderer.draw_path(gc, tpath, affine, rgbFace)
> 
> Thus, it seems that is is not possible to have different alpha for
> "fill" and "stroke".
> One of the easiest solution would be call the draw_path twice, each
> for fill and stroke.
> 
> 
> I think we would pay a significant performance hit in some cases to make 
> the call twice.  Perhaps this is a good time to rethink the draw_path 
> and gc signature, since as Eric notes these have evolved over time from 
> the early days when mpl didn't have alpha at all.  One possibility would 
> be to have a facecolor/edgecolor property on the gc itself, which would 
> be rgba tuples.  Since the gc is almost entirely internal, we can revamp 
> it w/o affecting userland code, though it would be nice to support 
> legacy methods (eg gc.set_alpha could warn and then proceed to set the 
> edge and face alpha channel).  Then we would drop the rgbFace argument 
> entirely.  Obviously this would require hacking through a bunch of 
> backend code to fix, but the changes would be fairly straightforward and 
> of the busy-work variety.
> 
> JDH

It may be nearly orthogonal to the lower-level changes you are 
suggesting, John, but before I completely forget about it I would like 
to toss out a very vague idea about reform at a higher level, with 
apologies that I have not thought it through:

Maybe we need an MplColorSpec class.  At present, functions and methods 
typically accept colors and/or color arrays in a wide variety of forms. 
  This is good.  My thought is that these should then be converted by 
the accepting function or method to instances of the new class, and that 
instances of the new class should be accepted as color inputs along with 
all the old forms.  I suspect that this refactoring might, without loss 
of backwards compatibility, make it possible to considerably simplify, 
clarify, and generalize the handling of colors (again, both single 
values and arrays), and provide a less-confusing framework for setting 
and overriding defaults.  I think that as things are now, color spec 
checking and/or conversion are often done repeatedly in a single 
pipeline.  With the class, all this would happen only the first time a 
color spec is encountered.

The class might include mapping, or the present color mapping might 
yield an instance of the class; I have not thought about this aspect.

Eric

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] patches have incorrect alpha values

[Eric Firing]

Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
>> Eric Firing  writes:
>>   
>>> John Hunter wrote:
>>> 
>>>> One possibility would be to have a facecolor/edgecolor property on
>>>> the gc itself, which would be rgba tuples. Since the gc is almost
>>>> entirely internal, we can revamp it w/o affecting userland code,
>>>> though it would be nice to support legacy methods (eg gc.set_alpha
>>>> could warn and then proceed to set the edge and face alpha channel).
>>>> Then we would drop the rgbFace argument entirely. Obviously this
>>>> would require hacking through a bunch of backend code to fix, but the
>>>> changes would be fairly straightforward and of the busy-work variety.
>>>>   
>>   
> One open question is whether set_alpha (even if deprecated) should set 
> or multiply the alpha of the fill and edge color.  But I think I'm in 
> favor of creating "one way to do it", which would be to have alpha as 
> the fourth component of any color -- that option also scales well to 
> individual colors in a collection, in a way that any of the more global 
> options don't.

I agree.  To the extent that we retain alpha= kwargs and set_alpha, it 
seems to me they should have the obvious meaning: "set_x" means *set*, 
not multiply; if you want to multiply, use "scale_alpha", or "fade", or 
something like that.  These sorts of operations could be done naturally 
as ColorSpec methods.

> 
> It strikes me that if none of us find the time for this, this task would 
> be a good initial GSoC task...  it's not enough work for an entire 
> summer by any means, but it's "busy work" that touches a lot of parts of 
> the code, and therefore a good introduction to the code base.  The other 
> related task is to create a gc-like object for collections so that the 
> arguments to draw_collection don't have to change in every backend every 
> time a new feature is added.
> 
>> This sounds like a good idea. In the pdf backend, GraphicsContextPdf
>> already defines a _fillcolor attribute, and for example draw_path does
>>
>> def draw_path(self, gc, path, transform, rgbFace=None):
>> self.check_gc(gc, rgbFace)
>> # ...
>>
>> where check_gc just temporarily sets gc._fillcolor to the value of
>> rgbFace and issues the pdf commands to change the graphics state to
>> reflect gc. If rgbFace is absorbed into gc, at least the pdf backend
>> should be easy to change accordingly, and should become less complex in
>> the process. Currently the same alpha value (gc._alpha) is used for both
>> strokes and painting operations, but this too should be easy to change
>> if we decide to drop the _alpha attribute from GraphicsContext and use
>> the fourth component of the stroke and fill colors for alpha.
>>
>> By the way, the PDF imaging model has much richer support for
>> transparency than just specifying an alpha value for each operation; the
>> Transparency chapter takes up 64 pages in the PDF spec¹. One thing that
>> I imagine somebody just might want to have support for in matplotlib are
>> transparency groups², i.e., blending some objects together and then
>> blending the group with the background. But I wonder if that's possible
>> in Agg - I guess we will want to stay pretty close to the greatest
>> common denominator of Agg, SVG and PDF, and let people with special
>> needs use other software such as Illustrator to postprocess the files.
>>
>> ¹ http://www.adobe.com/devnet/pdf/pdf_reference_archive.html
>> ² 
>> http://itext.ugent.be/library/com/lowagie/examples/directcontent/colors/transparency.pdf
>>
>>   
>>> Maybe we need an MplColorSpec class.  At present, functions and methods 
>>> typically accept colors and/or color arrays in a wide variety of forms. 
>>>   This is good.  My thought is that these should then be converted by 
>>> the accepting function or method to instances of the new class, and that 
>>> instances of the new class should be accepted as color inputs along with 
>>> all the old forms.
>>> 
>> replacing the current hack, neat
>> as it is, where a string representation of a decimal number means a
>> grayscale color, a string beginning with # means a hexadecimal color,
>> etc. The pyplot API should of course continue to work as it does now.
>>
>>   
> I really like Eric's suggestion here, as it fits in well with my desire 
> to verify arguments early and consistently.  But I don't think we need 
> to throw out the con

Re: [matplotlib-devel] question about imshow's support for masked arrays

[Eric Firing]

Darren Dale wrote:
> I am experimenting with numpy masked arrays, and have a question about 
> how imshow handles them:
> 
> from numpy import ma
> from pylab import colorbar, imshow, show
> 
> a=ma.array([[1,2,3],[4,5,6]],mask=[[0,0,1],[0,0,0]], fill_value=0)
> imshow(a, interpolation='nearest')
> colorbar()
> show()
> 
> With svn matplotlib, the missing value is treated as if identical to the 
> maximum value. I thought imshow would instead respect the masked array's 
I don't see this with my installation from svn.
> fill_value property by calling fix_invalid, and perhaps defaulting to 
> the min() or max() if fill_value is the default 99. What is the 
> intended behavior?

What I see with your example is a white square for the masked value; 
actually, it is transparent, with alpha = 0.  This is the intended 
default; if it is masked, don't paint anything.  It is set in 
Colormap.__init__ and can be overridden by Colormap.set_bad().

There is no intention to use the masked array fill value.

> 
> Relatedly, it looks like imshow and other functions like contour are 
> badly confused by NaNs, I thought they were supported?

I suspect we really should run the Z inputs through masked_invalid, 
especially for contour.  The performance hit is minimal as a fraction of 
the total time.  I will do this for contour.  imshow has to be handled 
more carefully, so I don't want to do it in a hurry.

One of the general cleanups needed in mpl is clarity and consistency in 
argument validation.  Part of this is a matter of clarity about API 
levels; we don't want to have to do full validation and acceptance of 
all possible input variations at every level.

Eric

> 
> Thanks,
> Darren

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Multithreading problem with print_png and font object?

[Eric Firing]

Karen Tracey wrote:
> I originally posted this to the user's list but got no response there.  
> As I think there's a bug in matplotlib here, I'm re-trying on the 
> development list.  Here's what I sent to -users back on Mar 13:



Karen,

(I saw your question to the users group, and was hoping someone more 
knowledgeable than myself about threading problems would reply to you.)

http://www.mail-archive.com/matplotlib-us...@lists.sourceforge.net/msg06152.html

I don't think there has been any progress on this question since it came 
up a year ago in the above thread.  Evidently it is something that needs 
more attention.  I would say that you have found a bug, and there are 
probably many more.  There are global objects outside the pyplot 
interface; maybe they provide opportunities for threads to trip over 
each other. A reasonable goal would be to have matplotlib be thread-safe 
at least when the pure OO interface is used, and possibly with some 
additional restrictions such as "don't mess with rcParams when more than 
one thread might be running".  I suspect this will take some time and 
effort to achieve--and I don't know who might be able to put in that 
time and effort.  What might help would be a simple but brutal testing 
framework, independent of web servers etc., that would be likely to make 
mpl fail quickly unless it really is thread-safe.  Maybe you can provide 
such a test program?  And if you are willing to dive into mpl internals 
and come up with solutions for thread problems, that's even better.

For your immediate needs, I suggest that you use only the OO interface 
(which means that you won't import pylab or pyplot, and so won't use the 
figure() function), and/or use a mutex as you describe below. (I don't 
think that dumping "figure" in itself will help with the problem you 
have run into so far; you will still need the mutex. And if the mutex 
locks all your plotting, then you probably won't hit any other mpl 
threading problems.)

If you do keep using the figure() function (or any related aspect of the 
pyplot interface) then be sure to explicitly close each figure. 
Otherwise your process will chew up all available memory.

Eric

> 
> I am using matplotlib's object-oriented API to dynamically generate some 
> graphs served by a web site.  The web site is built with Django and I 
> have generally followed the cookbook example I found here: 
> http://www.scipy.org/Cookbook/Matplotlib/Django for serving matplotlib 
> figures under Django.  Specifically my code looks like this:
> 
> from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
> from matplotlib.figure import Figure
> 
> def generate_png(request, f, year, cid, pid, ic):
> 
> # ...snipped code that generates the data to graph...
> 
> fig = Figure()
> ax = fig.add_subplot(111)
> ax.set_title(fig_title)
> ax.set_xlabel("Score")
> ax.set_ylabel("Frequency")
> n, bins2, patches = ax.hist(vals, bins, facecolor='blue', 
> edgecolor='blue')
> if x is not None:
> patches[x].set_facecolor('red')
> patches[x].set_edgecolor('red')
> fig.legend((patches[x],), ('%s (%d)' % (cname, cval),), 'lower 
> left')
> canvas = FigureCanvas(fig)
> canvas.print_png(f)
> 
> # ... snip remainder ...
> 
> This works fine, except when I run it under a multi-threaded web server 
> (Apache with mod_wsgi in daemon mode with multi-threaded processes) it 
> sometimes (not always) fails with this traceback:
> 
>  File 
> "/home/kmt/django/Django-1.1-alpha-1/django/core/handlers/base.py", line 
> 86, in get_response
>response = callback(request, *callback_args, **callback_kwargs)
>  File "/home/kmt/software/web/xword/acpt/views.py", line 321, in get_png
>response = generate_png(request, f, year, cid, pid, ic)
>  File "/home/kmt/software/web/xword/acpt/views.py", line 308, in 
> generate_png
>canvas.print_png(f)
>  File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 305, in print_png
>FigureCanvasAgg.draw(self)
>  File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 261, in draw
>self.figure.draw(self.renderer)
>  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 765, 
> in draw
>legend.draw(renderer)
>  File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 215, 
> in draw
>t.draw(renderer)
>  File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 329, 
> in draw
>ismath=self.is_math_text(line))
>  File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 113, in draw_text
>self._renderer.draw_text_image(font.get_image(), int(x), int(y) + 1, 
> angle, gc)
> RuntimeError: You must call .set_text() before .get_image()
> 
> I'm not at all familiar with the internals (truly I'm barely familiar 
> with the public APIs) of matplotlib but it appears from this exception 
> that internally there's a 'font' object 

Re: [matplotlib-devel] Multithreading problem with print_png and font object?

[Eric Firing]

Karen Tracey wrote:

> Hmm, the Ubuntu packaging for matplotlib seems to put a copy of 
> matplotlibrc only in /etc, where, I gather, it will not ever be used by 
> matplotlib?  I guess one is supposed to copy it to one's home directory 
> and do per-user customization there.  For my case, where the code is 
> running under Apache, I'd guess no matplotlibrc is being found so all 
> defaults are being used.   

Karen,

That seems a little odd; matplotlib doesn't look in /etc by default. 
Although I run ubuntu, I have never used the ubuntu package, so I have 
not run into this.

The default matplotlibrc has been stripped down to a bare minimum: 
everything but the default backend selection is commented out.

You may have already discovered this, but in case you haven't, you can 
find out where the active matplotlibrc is being found by using 
matplotlib_fname():

In [1]:import matplotlib

In [2]:matplotlib.matplotlib_fname()
Out[2]:'/usr/local/lib/python2.5/site-packages/matplotlib/mpl-data/matplotlibrc'

The docstring explains the search order:

 Return the path to the rc file

 Search order:

  * current working dir
  * environ var MATPLOTLIBRC
  * HOME/.matplotlib/matplotlibrc
  * MATPLOTLIBDATA/matplotlibrc

Thank you for the test script.  I have added it to the "unit" 
subdirectory of matplotlib, after adding a short docstring.  JDH may 
want to modify or move it.

Eric

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] And the winner is...

[Eric Firing]

http://thread.gmane.org/gmane.comp.python.devel/102706

http://article.gmane.org/gmane.comp.python.devel/102742

The above two posts are worth reading for any among us who are 
interested in an eventual migration to a DVCS.

Eric (happy hg user)


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SF.net SVN: matplotlib:[7016] branches/v0_98_5_maint/lib/matplotlib

[Eric Firing]

mdb...@users.sourceforge.net wrote:
> Revision: 7016
>   http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7016&view=rev
> Author:   mdboom
> Date: 2009-03-31 15:22:06 + (Tue, 31 Mar 2009)
> 

...

> Modified: branches/v0_98_5_maint/lib/matplotlib/transforms.py
> ===
> --- branches/v0_98_5_maint/lib/matplotlib/transforms.py   2009-03-31 
> 15:13:24 UTC (rev 7015)
> +++ branches/v0_98_5_maint/lib/matplotlib/transforms.py   2009-03-31 
> 15:22:06 UTC (rev 7016)
> @@ -975,8 +975,7 @@
>  if self._invalid:
>  points = self._transform.transform(self._bbox.get_points())
>  if ma.isMaskedArray(points):
> -points.putmask(0.0)
> -points = np.asarray(points)
> +np.putmask(points, points.mask, 0.0)
>  self._points = points
>  self._invalid = 0
>  return self._points

Mike,

A cleaner version is this:

points = points.filled(0.0)

Or you can replace the conditional and the assignment with the single line:

points = np.ma.filled(points, 0.0)

Example:

In [6]:np.ma.filled([1,2,3], 0.0)
Out[6]:array([1, 2, 3])

In [7]:np.ma.filled(np.ma.array([1,2,3], mask=[False,True,False]), 0.0)
Out[7]:array([1, 0, 3])

The version you have actually can fail:

In [10]:zz = np.ma.ones(5)

In [11]:zz
Out[11]:
masked_array(data = [ 1.  1.  1.  1.  1.],
  mask = False,
fill_value = 1e+20)


In [12]:np.putmask(zz, zz.mask, 0)
---
ValueErrorTraceback (most recent call last)

/home/efiring/ in ()

ValueError: putmask: mask and data must be the same size



Eric

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] [Fwd: [Matplotlib-users] imshow without resampling]

[Eric Firing]

Jouni, Darren,

I'm not sure who the SVG expert is, and I presume the attached message 
applies to pdf as well as ps.  I'm bringing it to your attention because 
it is suggesting what would seem to be significant improvements in some 
backends by taking better advantage of their native image support.  I 
know nothing about this; would either of you (or anyone else) like to 
comment?


Eric
--- Begin Message ---
Hello,

I am using matplotlib to create postscript and SVG files. I am  
currently using imshow to show the contents of an array, but this  
means that when saving vector graphics files, matplotlib resamples the  
image/array onto a finer grid. What I would like, is for code such as  
this:

import matplotlib
matplotlib.use('PS')
from matplotlib.pyplot import *

import numpy as np

image = np.random.random((10,10))

fig = figure(figsize=(4,4))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example1.ps')

fig = figure(figsize=(8,8))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example2.ps')

to produce files that are the roughly the same size, rather than  
different by a factor of 4. In addition, both files should be very  
small since they should only contain a 10x10 bitmap in addition to the  
axes+labels. Postscript and SVG (as languages) both allow a bitmap of  
an arbitrary resolution to be scaled, translated, and rotated without  
resampling.

I have come across the figimage method which is meant to place an  
array in a plot without resampling, but I cannot figure out how to use  
it like imshow, i.e. to show the image inside the axes as before. I've  
also tried the pcolor functions, but it seems like they define each  
pixel as an individual polygon, which is inefficient.

I was wondering if anyone had a solution to this, or if there are  
plans to make matplotlib behave like this in future?

Thanks,

Thomas

--
___
Matplotlib-users mailing list
matplotlib-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
--- End Message ---
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] release strategy, and the role of v0_98_5_maint

[Eric Firing]

It is not always clear what should go in the 0.98.5 maintenance branch. 
  For example, is the _png.cpp patch by Tobias, committed by Andrew, a 
bug fix or a new feature?  I would have said the latter, but I can see 
arguments either way.

More generally, how long do we need to keep updating this maintenance 
branch?

And is there a release schedule in mind?  Any prospect of more 
thoroughly automating official releases and of adding svn snapshot 
releases? And of following numpy's buildbot example?

I don't think I can help with any of this; I am just casting about to 
see if there might be someone on the list who is interested and can 
break loose some time.

Eric



--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

[Eric Firing]

John Hunter wrote:
[...]
>> And is there a release schedule in mind?  Any prospect of more
>> thoroughly automating official releases and of adding svn snapshot
>> releases? And of following numpy's buildbot example?
>>
>> I don't think I can help with any of this; I am just casting about to
>> see if there might be someone on the list who is interested and can
>> break loose some time.
> 
> We are not that far away, at least for src snapshots, os x binaries,
> and the docs.  The windows binary would take some work, as would a
> linux binary, eg a debian package.  I am definitely for it, but one or
> more of us will have to step up and push it through.

For snapshots, I think that packages are needed only for OS X and 
Windows.  Anyone who is going to be running snapshots on linux should be 
able to build from a tarball or svn. (And they should be installing in 
/usr/local or a private location.) The only step that might be nice to 
make that easier would be to list the package dependencies for common 
distros--that is, not just in generic form, but the actual names.

Eric

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

[Eric Firing]

Charlie Moad wrote:
> I might be able to squeeze some time in this weekend.  I am not
> thrilled about the new visual studio requirements, nor do I have
> access to it.  I know John started a build script for OSX and I have
> been meaning to try something similar for mingw.  Is anyone opposed to
> creating the official releases with mingw?

As long as it works, I would greatly prefer it.  A build script would be 
  great.

Eric

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Rasterized artists have wrong transform

[Eric Firing]

Jae-Joon Lee wrote:
> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning  wrote:
>> I like that this solution doesn't litter every call to draw with
>> rasterize checks. But it means that the rasterization support had
>> better be robust, since Artist authors might not know they're
>> interacting with the rasterization code. It has the downside of being
>> implicit rather than explicit.
> 
> Eric,
> I think we'd better stick to your decorator solution.
> 
> Anyhow, I thought you had a svn commit permission but it seems not. Do
> you (and other dwevelopers) mind if I commit this patch to the trunk?

It would be especially good for John and Mike to have a look.

As a matter of style, I suggest a name change. 
"@hook_before_after_draw" is too generic, and brings to mind discussions 
a long time ago about possibly adding a general hook mechanism; even 
before rasterization, and before decorators were available, there were 
thoughts that we might need this.  (Now I don't remember what the 
motivation was, but I think it had to do with coordinating different 
elements of a plot.)  In any case, the decorator is actually very 
specific to rasterization, so maybe call it "@with_rasterization"  or 
"@allow_rasterization".

I am very anxious to see rasterization support in place; let's just be 
sure we have a good API and mechanism.  The patch looks reasonable to 
me, but I have no experience in writing decorators, and have not had 
time to really think about the rasterization API problem.

Eric

> 
> One I thing I want to add your patch is to warn users when they set
> "rasterized" attribute of the artists whose draw method is not
> decorated. I'll think about it later but feel free to propose any.
> 
> Thanks,
> 
> -JJ
> 
> --
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] DeprecationWarning message fix for polyfit

[Eric Firing]

Aleksandar Veselinovic wrote:
> Correcting function spelling (poyfit->polyfit) error in depreciation
> warning.

Fixed in 7088.  Thank you.

Eric

> 
> 
> Index: trunk/matplotlib/lib/matplotlib/mlab.py
> ===
> --- trunk/matplotlib/lib/matplotlib/mlab.py (revision 7087)
> +++ trunk/matplotlib/lib/matplotlib/mlab.py (working copy)
> @@ -617,7 +617,7 @@
>  :func:`polyval`
> polyval function
>  """
> -warnings.warn("use numpy.poyfit", DeprecationWarning)
> +warnings.warn("use numpy.polyfit", DeprecationWarning)
>  return np.polyfit(*args, **kwargs)
> --
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] clabel and rotation

[Eric Firing]

Evan Mason wrote:
> Hi, would it be possible to add a keyword to clabel to optionally switch 
> off the angle fix in contour.py lines 384+?

Evan,

Done in r7097.  I called the kwarg "rightside_up", defaulting to True.

You have come up with a novel use for clabel. Longer-term, we should be 
able to support streamline plotting more directly by using the contour 
line data to place arrowhead markers at roughly uniform intervals.

Eric

> 
> # Fix angle so text is never upside-down
> if rotation > 90:
> rotation = rotation - 180.0
> if rotation < -90:
> rotation = 180.0 + rotation
> 
> Something like "clabel(CS, upsidedown=True)" with the default as False 
> would do it.
> 
> I am using clabel to put directional arrows on a streamline contour 
> plot, and this rotation causes some of the arrows to point the wrong 
> way.  I'm willing to try to do it myself if somebody could tell me which 
> files I would need to edit in addition to contour.py?
> 
> Many thanks,
> 
> Evan
> 
> 
> 
> 
> --
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> 
> 
> 
> 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo Backend and Subpixel Rendering

[Eric Firing]

John Hunter wrote:
> On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden  
> wrote:
>> Hi all,
>>
>> As some of you probably know I am working on the GSoC project to
>> externalise the Mathtex engine from Matplotlib. Today I have been
>> toying around with the renderer using various backends.
>>
>> One of the interesting things that I discovered was that the Cairo
>> backend was making use of subpixel rendering. (Or 'ClearType' as
>> Microsoft call it.) This is not surprising -- by default Cairo will
>> respect a users fontconfig settings when rendering text. Since I have
>> subpixel rendering enabled all text rendered by Cairo is subpixel
>> rendered.
>>
>> While this is fantastic for on screen text -- being significantly more
>> pleasing to look at that the text produced by the AGG backend -- it is
>> unsuitable for print. Now it is not too difficult to disable this,
>> Cairo has an API call: cairo_font_options_set_antialias to deal with
>> this.
>>
>> While I could write a quick patch to always disable subpixel rendering
>> it would be something off a loss to those who either view their graphs
>> onscreen or export them for the web -- where using subpixel rendering
>> is now surprisingly common.
>>
>> Is it worth looking into adding subpixel rendering as a configuration
>> option?
> 
> The matplotlib.lines.Line2D objects has an antialiased property -- we
> could add the same property to matplotlib.text.Text to turn on/off
> subpixel rendering (which could also be supported as an rc param)

I haven't poked around, so this may be a stupid question, but: for 
cairo, can subpixel rendering simply be left on for screen display and 
automatically turned off when writing to a file via savefig?  If this 
can be done, it seems like a better solution than requiring to the user 
to turn the parameter on and off manually, depending on whether show() 
or savefig() is being called.

Eric

> 
> JDH

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] time series zoom/pan speedup

[Eric Firing]

Please check and try out revision 7100.  For example, with ipython -pylab:


x = np.arange(100, dtype=float) * 0.2
y = np.sin(x)
plot(x,y)
xlim(10,20)

Then play around with panning and zooming.

To see what the behavior is like without the changes, just reverse the 
sign of x, since at present only monotonically increasing x is supported:

plot(-x, y)
xlim(-20,-10)

Notice that in the latter case, panning and zooming is jerky.

Thanks.

Eric

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Selecting WX2.8 causes problems on wx 2.8.4

[Eric Firing]

Tony Yu wrote:
> I hope you don't mind if I bump this.
> 
> I'm curious if Eric, or any others from the following thread had a 
> comment on this issue:
> http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
> 
> I don't mind upgrading if that's what's required, but I was just 
> wondering if this issue was an intended result of the patch.

Tony,

No, it certainly wasn't.

As for upgrading, it looks to me like you don't need to upgrade 
wxpython, just wxversion, which is a single independent file.

I don't know whether wxversion is always packaged with a wxpython 
itself, or whether it is distributed separately.

I don't see any decent workaround.  We can't just catch VersionError 
instead of AlreadyImportedError because that would defeat the purpose. 
It looks to me like upgrading wxversion is the only option, unless 
someone with wx expertise wants to plunge in and figure out a better 
solution.  The only other thing I can think of would be for mpl to 
include its own copy of wxversion.  I would prefer not to clutter mpl 
that way--it would be just one more obscure thing to maintain.

Eric

> 
> Best,
> -Tony
> 
> 
> On May 8, 2009, at 8:46 PM, Tony S Yu wrote:
> 
>> I'm running into the following error with the wx backend
>>
>> import wx
>> import matplotlib.backends.backend_wxagg
>>> Traceback (most recent call last):
>>>  File "", line 1, in 
>>>  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>>> matplotlib/backends/backend_wxagg.py", line 23, in 
>>>import backend_wx# already uses wxversion.ensureMinimal('2.8')
>>>  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>>> matplotlib/backends/backend_wx.py", line 120, in 
>>>except wxversion.AlreadyImportedError:
>>> AttributeError: 'module' object has no attribute  
>>> 'AlreadyImportedError'
>>
>> This problem seems to be related to additions made here:
>> http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
>>
>> The problem is that my version of wxversion raises 'VersionError'  
>> instead of 'AlreadyImportedError'.
>>
>> I'm running wxPython 2.8.4.0 while people in the above thread seem to  
>> be using at least 2.8.7.1. Do I need to upgrade, or is this a bug?
>>
>> Thanks,
>> -Tony
>>
>> --
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW 
>> KODAK i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> 
> 
> 


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Units issue

[Eric Firing]

John Hunter wrote:


> The fundamental problem here is that some artists (Line2D) have
> support for storing original unitized  data (_xorig, _yorig) and
> handling the conversion on unit change internally with the callback,
> and some artists (eg Patches) do not .  axes._process_plot_var_arg
> subserves both plot (Line2D) and fill (Polygon), one of which is
> expecting possibly unitized data and one which is only capable of
> handling already converted data.  Hence the fix one problem, create
> another bind we are now in.
> 
> So yes, we need a standard.

John,

As you know, I agree.  This has been a frustrating problem for a long 
time.

> 
> I think the resolution might be in having intermediate higher level
> container plot item objects (an ErrorBar, LintPlot, FilledRegion)
> which store the original data, manage the units, and pass converted
> data back to the primitives.  This is obviously a major refactoring,
> and would require some thought, but may be the best way to go.
> Handling the conversions in the plotting functions (eg fill, errorbar)
> is probably not the right way because there is no obvious way to
> support unit changes (eg inches to cm) since the data is already
> converted, the artists already created.

I'm not sure I understand the use case for unit *changes*, as opposed to 
initial unit specification.

> 
> Having the artist primitives store the original, possibly unitized
> data, and register callbacks for unit changes can work, but the
> problem is how to create the artist primitives in such a way the unit
> data is passed through correctly.  The problem here is that some
> operations don't make sense for certain unit types -- think addition
> with datetimes.  Some functions, eg bar or errorbar, which need to do
> a lot of arithmetic on the input arrays, may want to do:
> 
>   xmid = 0.5*(x[1:] + x[:-1])
> 
> which would not work for x if x is datetime (can't add two dates).
> distance and scaling should always be well defined, so one should be
> able to do:
> 
>   xmid = x[1:] + 0.5*(x[1:]-x[:-1])
> 
> So one solution is to require all plotting functions to respect the
> "no addition" rule, ie define the set of operations that are allowed
> for plotting functions, and all artists to handle original unitized
> data with internal conversion.  This is a fair amount of work at the
> plotting function layer, is invasive to the artist primitives, and
> requires the extra storage at the artist layer, but could work.

Sounds horrible to me.  I would really like to see clear stratification, 
with all complicated and flexible argument handling restricted to some 
not-too-low level.

> 
> The other solution, what I referred to as the intermediate plot item
> container, is to have a class ErrorBar, eg, which is like the errorbar
> method, but has an API like
> 
>   class ErrorBar:
> def __init__(self, all the errorbar args, possibly unitized):
>   self.store_all_original_data_here()
>   self.store_all_primitives_from_converted_data_here()
> 
>   def callback():
>   self.update_all_stored_primitives_newly_converted_original_data()
>   self.connect_callback_to_unit_change(callback)
> 
> 
> This has the advantage that the plot item container class can always
> work with arrays of floats (removing the onerous restriction on what
> kind of binary relations are allowed) and removes the restrictions on
> creating artists which are unit aware.

I think something like this is the way to go.  Even without the problem 
with units, I would like to see things like the bar family, errorbar, 
and boxplot moved out into their own classes; and there is no reason not 
to do the same for simple line plots (which are anything but simple in 
their input argument handling).  Then the Axes class can concentrate on 
Axes creation and manipulation.

I think there are also opportunities for factoring out common operations 
involving input parameter handling--not just units conversion, but 
validation, checking dimensions, generating X and Y with meshgrid when 
needed, etc.  Some of these things are already partly factored out, but 
helpers are scattered around, and I suspect there is some unproductive 
duplication.

Of course, the big question is how to get all this done... Fortunately, 
unless I am missing a key point, this sort of refactoring can be done 
incrementally; it is not as drastic as the transforms refactoring was.

Eric

> 
> It also makes for a nicer API:
> 
>   eb = ErrorBar(something)
>   eb.draw()
> 
>   # hmm, the cap widths are too small
>   eb.capwidth = 12
>   eb.draw()
> 
> ie, instead of getting back a bunch of artist primitives from errorbar
> which may be difficult to manipulate, you get back an ErrorBar object
> that knows how to update and plot itself.
> 
> With traits or properties so that the eb.capwidth attr setting
> triggers a unitized updating of primitives, then everything is fairly
> transparent to the user.
> 
> It would also make it easier support conta

Re: [matplotlib-devel] dropped spine support

[Eric Firing]

Andrew Straw wrote:
> I've implemented initial support for "dropped spines". This is motivated
> by the ability to draw figures that look like
> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
> attaching the patches and an image created by the new example.
> 
> This is a somewhat invasive change into the core of the axis rendering
> code, so I'm hereby requesting a review before committing it into the
> code base. In particular, I dropped the idea of using Traits in MPL not
> because I think it's a bad idea, but because that would involve more
> substantial changes.
> 
> Anyhow, I'm attaching the proposed implementation as a series of
> patches. If the general form of this looks OK, I'd write up doc strings
> and a CHANGELOG entry and commit it. Should I wait until after the trunk
> release?
> 
> Please let me know what you think. All the examples run with
> exaples/tests/backend_driver.py still seem to give OK results, and the
> test suite raises a few more failures, but these appear due to
> (sub)pixel shifts in text rendering rather than anything more severe.
> 
> -Andrew

Andrew,

It looks like that nicely addresses a frequent request.  Great! I 
haven't looked closely enough yet to see how it all works, but one 
immediate suggestion is that the adjust_spines function in your example 
looks like something that should be modified a bit and turned into an 
axes method with the usual pyplot wrapper.  That is a fine point, of 
course, that can be deferred.

It looks like the offset is defined as positive outward from center of 
the plot.  Are negative values allowed, so the spine goes through the 
middle of the plot, for example?

The name "spine" threw me off for a while; but I guess that is a 
reasonable description for a line with ticks. "Axis" and "Scale" are 
already taken, so maybe "spine" is as good as we can find.  "Dropped 
spine" sounds like a painful medical condition... Oh, well...

Eric


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] radial grids broken on polar?

[Eric Firing]

Jae-Joon Lee wrote:
> The default resolution (which is used to interpolate a path in polar
> coordinate) has change to 1 at some point. And because of this, a
> radial grid becomes a 0-length line. Increasing the resolution will
> bring back your gridlines.

This is not the right solution, though.  There was a reason for the 
change in default resolution to 1--it gives the expected behavior for 
plotting a line between two points in polar coordinates--and it is not 
going back.  The inability to set resolution on a per-artist basis is a 
serious problem that doesn't seem to have a simple solution.  Until one 
can be found, some sort of special case handling will be needed for the 
radial grid lines.

Eric

> 
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c',
> resolution=100)
> 
> -JJ
> 
> 
> 
> On Thu, May 21, 2009 at 10:13 PM, John Hunter  wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch).  Any ideas?
>>
>> import matplotlib
>> import numpy as np
>> from matplotlib.pyplot import figure, show, rc, grid
>>
>> # radar green, solid grid lines
>> rc('grid', color='#316931', linewidth=1, linestyle='-')
>> rc('xtick', labelsize=15)
>> rc('ytick', labelsize=15)
>>
>> # force square figure and square axes looks better for polar, IMO
>> width, height = matplotlib.rcParams['figure.figsize']
>> size = min(width, height)
>> # make a square figure
>> fig = figure(figsize=(size, size))
>> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>>
>> r = np.arange(0, 3.0, 0.01)
>> theta = 2*np.pi*r
>> ax.plot(theta, r, color='#ee8d18', lw=3)
>> ax.set_rmax(2.0)
>>
>> ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
>> ax.grid(True)
>>
>> ax.set_title("And there was much rejoicing!", fontsize=20)
>> show()
>>
>> --
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] radial grids broken on polar?

[Eric Firing]

Eric Firing wrote:
> Jae-Joon Lee wrote:
>> The default resolution (which is used to interpolate a path in polar
>> coordinate) has change to 1 at some point. And because of this, a
>> radial grid becomes a 0-length line. Increasing the resolution will
>> bring back your gridlines.
> 
> This is not the right solution, though.  There was a reason for the 
> change in default resolution to 1--it gives the expected behavior for 
> plotting a line between two points in polar coordinates--and it is not 
> going back.  The inability to set resolution on a per-artist basis is a 
> serious problem that doesn't seem to have a simple solution.  Until one 
> can be found, some sort of special case handling will be needed for the 
> radial grid lines.
> 
> Eric


Expanding on this: it looks like a possible solution is to attach a new 
"resolution" attribute to the Path object.  This would ordinarily be 
None, but could be set to another value when the Path is created (or 
later).  Then the PolarTransform.transform_path method (and the same in 
other curvilinear projections) could use that value, if not None, to 
control interpolation.  Some additional changes would be needed to apply 
this to the radial gridlines.

Now it is not clear to me that resolution should be an attribute of the 
PolarAxes at all--the interpolation is done by a path method, so that 
method doesn't need a resolution parameter at all if resolution is a 
Path attribute.  Except for backwards compatibility.  Comments, Mike?

I can't implement it right now, but if no one comes up with a better 
solution, or wants to implement something like this one, then I can do 
it in a day or two.

(Of course, I may not be seeing a stumbling block.)

Eric

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 'BlendedGenericTransform' object has no attribute '_interpolation_steps'

[Eric Firing]

Tony S Yu wrote:
> When running `pyplot.spy` I ran into the following error:
> 
> AttributeError: 'BlendedGenericTransform' object has no attribute  
> '_interpolation_steps'
> 
> Just from pattern matching (I have no idea what's going on in the  
> code), I noticed that _interpolation_steps was usually called from a  
> Path object, not a Transform object, so I tried switching the call  
> (see diff below), which seems to work for me. Since this was a recent  
> addition (r7130), I figure this was just a typo.

Fixed.  Thank you.

Eric

> 
> Cheers,
> -Tony
> 
> 
> ===
> --- lib/matplotlib/transforms.py  (revision 7133)
> +++ lib/matplotlib/transforms.py  (working copy)
> @@ -1145,7 +1145,7 @@
>   ``transform_path_affine(transform_path_non_affine(values))``.
>   """
>   return Path(self.transform_non_affine(path.vertices),  
> path.codes,
> -self._interpolation_steps)
> +path._interpolation_steps)
> 
>   def transform_angles(self, angles, pts, radians=False,  
> pushoff=1e-5):
>   """
> 
> 
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] radial grids broken on polar?

[Eric Firing]

Michael Droettboom wrote:
> That's right, Eric.  I think having resolution be an attribute of the 
> artist (and not the projection) is the "path" of least resistance here.  
> To clarify, however, the interpolation (more specifically, whether to 
> interpolate) should remain a function of the projection, not the path.  
> That's the important point that lead to it ending up in the wrong place 
> in the first place.  If we aim to keep the generalization that all grid 
> lines are the same kind of object regardless of the projection, and 
> therefore set a high resolution parameter on all the grid lines, we 
> wouldn't want this to slow down the standard rectilinear axes.  As long 
> as the standard axes don't obey the parameter, then would should be 
> fine.  It's somewhat confusing, but I also am seeing this the resolution 
> parameter on artists as more of an implementation detail than a public 
> API.  If someone wants to interpolate their data, IMHO that should be 
> the user's responsibility, since they know the best way to do it.  This 
> functionality isn't really about data points, IMHO.

Mike,

Thanks for taking care of this so quickly.

Although I agree that _interpolation_steps is a low-level, 
implementation-dependent attribute (which might not be the right 
specification if interpolation were changed to take advantage of Bezier 
curves, for example), I think that some sort of 
"follow_curvilinear_coordinates" public Artist attribute would be 
desirable.  For example, one might want to plot a set of arcs, or 
arc-shaped patches (warped rectangles) on a polar plot.  It would be 
nice to be able to do this using lines, line collections, rectangle 
patches, or rectangle collections, by adding a single kwarg to set that 
attribute.  Then it would be up to each Artist to use that attribute to 
set _interpolation_steps or whatever implementation mechanism is in 
place.  Possibly it does not make sense as a general Artist attribute 
but should be restricted to a subset, but it is probably simpler to put 
it at the Artist level and then selectively apply it.

Eric

> 
> The more difficult change seems to be being backward compatible about 
> the Polar plot accepting a resolution argument.  I'm not even certain 
> that it's worth keeping, since as you suggest, it makes more sense for 
> it to be a property of the artist.  I'd almost prefer to raise a warning 
> if the user provides a resolution argument (other than 1) to Polar 
> rather than trying to make it work.  Is anyone actually using it, other 
> than to set it to 1 on 0.98.x versions?
> 
> I should have some time to work on this today.
> 
> Mike
> 
> Eric Firing wrote:
>> Eric Firing wrote:
>>> Jae-Joon Lee wrote:
>>>> The default resolution (which is used to interpolate a path in polar
>>>> coordinate) has change to 1 at some point. And because of this, a
>>>> radial grid becomes a 0-length line. Increasing the resolution will
>>>> bring back your gridlines.
>>>
>>> This is not the right solution, though.  There was a reason for the 
>>> change in default resolution to 1--it gives the expected behavior for 
>>> plotting a line between two points in polar coordinates--and it is 
>>> not going back.  The inability to set resolution on a per-artist 
>>> basis is a serious problem that doesn't seem to have a simple 
>>> solution.  Until one can be found, some sort of special case handling 
>>> will be needed for the radial grid lines.
>>>
>>> Eric
>>
>>
>> Expanding on this: it looks like a possible solution is to attach a 
>> new "resolution" attribute to the Path object.  This would ordinarily 
>> be None, but could be set to another value when the Path is created 
>> (or later).  Then the PolarTransform.transform_path method (and the 
>> same in other curvilinear projections) could use that value, if not 
>> None, to control interpolation.  Some additional changes would be 
>> needed to apply this to the radial gridlines.
>>
>> Now it is not clear to me that resolution should be an attribute of 
>> the PolarAxes at all--the interpolation is done by a path method, so 
>> that method doesn't need a resolution parameter at all if resolution 
>> is a Path attribute.  Except for backwards compatibility.  Comments, 
>> Mike?
>>
>> I can't implement it right now, but if no one comes up with a better 
>> solution, or wants to implement something like this one, then I can do 
>> it in a day or two.
>>
>> (Of course, I may not be seeing a stumbling block.)
>>
>> Eric
> 


---

Re: [matplotlib-devel] Arc requires explicitly setting fill=False?

[Eric Firing]

Tony S Yu wrote:
> Currently, Arc in matplotlib.patches requires that it be called with  
> kwarg ``fill=False``. Was this behavior intentional? The code suggests  
> that a default value was left out of the kwarg lookup.
> 
> I've attached a simple patch to fix this (it still fails when fill set  
> to True).

Thanks. I committed a slightly different fix.  I think this handles all 
possibilities.

--- a/matplotlib/lib/matplotlib/patches.py  Mon May 25 00:00:46 2009 +
+++ b/matplotlib/lib/matplotlib/patches.py  Mon May 25 00:16:44 2009 +
@@ -1189,10 +1189,9 @@

  %(Patch)s
  """
-fill = kwargs.get('fill')  # returns None if key is absent
+fill = kwargs.setdefault('fill', False)
  if fill:
  raise ValueError("Arc objects can not be filled")
-kwargs['fill'] = False

  Ellipse.__init__(self, xy, width, height, angle, **kwargs)

Eric

> 
> Cheers,
> -Tony
> 
> Index: lib/matplotlib/patches.py
> ===
> --- lib/matplotlib/patches.py (revision 7137)
> +++ lib/matplotlib/patches.py (working copy)
> @@ -1189,7 +1189,7 @@
> 
>   %(Patch)s
>   """
> -fill = kwargs.pop('fill')
> +fill = kwargs.pop('fill', False)
>   if fill:
>   raise ValueError("Arc objects can not be filled")
>   kwargs['fill'] = False
> 
> 
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Arc requires explicitly setting fill=False?

[Eric Firing]

John Hunter wrote:
> On Sun, May 24, 2009 at 7:20 PM, Eric Firing  wrote:
>> Tony S Yu wrote:
>>> Currently, Arc in matplotlib.patches requires that it be called with
>>> kwarg ``fill=False``. Was this behavior intentional? The code suggests
>>> that a default value was left out of the kwarg lookup.
>>>
>>> I've attached a simple patch to fix this (it still fails when fill set
>>> to True).
>> Thanks. I committed a slightly different fix.  I think this handles all
>> possibilities.
>>
> 
> Michael can weigh in on this when he has a chance, but my recollection
> is that Arc was added to satisfy a JPL reported bug when one zooms
> into a small region of an ellipse -- in that case our 4 spline
> approximation code was inadequate, and in a heroic burst Michael
> provided an 8 spline interpolation limited to the viewport.  Ie,
> instead of getting 4 splines for the entire ellipse, with his Arc
> class you get 8 for the segment in the viewport.  As part of this, he
> decided it was mostly impossible to fully support filling, or at least
> too difficult, so he may have intentionally raised this error.  So we
> should be careful here, because it may be that simple arcs, those
> where everything is in the viewport, work ok with filling, but things
> break down when his zoom optimizations are triggered.

John,

Yes, Arc is a very special-purpose class, and not really a patch at all. 
  Actually, according to the docstrings, the Ellipse is calculated with 
8 splines, and Arc is calculated with 8 splines for the viewable portion 
alone.

The change I made merely made it so that Arc works with no fill kwarg at 
all, or with fill=False, and as before, it raises an error if 
fill==True.  I suspect this is the behavior Mike intended--I doubt he 
meant to *require* a kwarg that can take only one value without raising 
an error--but certainly he can correct me if I am mistaken.

Eric

> 
> JDH


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

[Eric Firing]

Andrew Straw wrote:
> Andrew Straw wrote:
>> I believe I addressed all the issues raised with the patch I emailed the
>> list last week and I tried to avoid any breakage. Thanks to all who
>> commented -- you made this a better implementation.
> 
> Upon further reflection, I realize I didn't add any Axes convenience 
> methods as Eric suggested. This is simply due to a lack of time -- not a 
> lack of enthusiasm.

Andrew,

No problem--it can be done later, no rush.  Your replacement of the 
frame with spines is a *big* improvement.  Thank you for the great work.

Eric

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Building docs

[Eric Firing]

Reinier Heeres wrote:
> Hi all,
> 
> While trying to work on some docs for mplot3d I ran into trouble
> building them. I started with the stock ubuntu sphinx (0.5.2), but
> that ran into errors. Following the documentation suggestion I tried
> the repository at http://svn.python.org/projects/doctools/trunk
> sphinx, but that seems to be deprecated (and also didn't work for me).
> Apparently the new location is a mercurial repo at
> http://bitbucket.org/birkenfeld/sphinx/ and that's a version that did
> the trick for me.
> 
> My guess is people knew this already, but shall I update the docs with
> this new repo? It will be easier for new people to get the docs built.

Yes, please do.

Eric

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel