[matplotlib-devel] dashed steps plot
Hi all,
I ran into a problem where I wanted to plot a step-plot with dashed
lines instead of solid lines which can be important for print media.
This isn't possible with the current matplotlib version, so I added
support for this. The patch is attached, but I didn't commit it yet
since I wanted to ask for feedback first. It basically adds support to do
pylab.plot(x, y, 'steps--')
to create a step plot with dashed lines.
mm
Index: lines.py
===
--- lines.py (revision 6055)
+++ lines.py (working copy)
@@ -561,11 +561,27 @@
if linestyle not in self._lineStyles:
if ls_mapper.has_key(linestyle):
linestyle = ls_mapper[linestyle]
-else:
+elif not linestyle.startswith('steps'):
verbose.report('Unrecognized line style %s, %s' %
(linestyle, type(linestyle)))
if linestyle in [' ','']:
linestyle = 'None'
+if linestyle.startswith('steps'):
+stepslinestyle = linestyle[-2:]
+if stepslinestyle=='--':
+self._stepslineFunc = getattr(self, self._lineStyles['--'])
+linestyle = linestyle[:-2]
+elif stepslinestyle=='-.':
+self._stepslineFunc = getattr(self, self._lineStyles['-.'])
+linestyle = linestyle[:-2]
+elif stepslinestyle[1]==':':
+self._stepslineFunc = getattr(self, self._lineStyles[':'])
+linestyle = linestyle[:-1]
+elif stepslinestyle[1]=='-':
+self._stepslineFunc = getattr(self, self._lineStyles['-'])
+linestyle = linestyle[:-1]
+else:
+self._stepslineFunc = getattr(self, self._lineStyles['-'])
self._linestyle = linestyle
self._lineFunc = self._lineStyles[linestyle]
@@ -676,7 +692,7 @@
path = Path(steps)
path = path.transformed(self.get_transform())
-self._draw_solid(renderer, gc, path, IdentityTransform())
+self._stepslineFunc(renderer, gc, path, IdentityTransform())
def _draw_steps_post(self, renderer, gc, path, trans):
@@ -688,7 +704,7 @@
path = Path(steps)
path = path.transformed(self.get_transform())
-self._draw_solid(renderer, gc, path, IdentityTransform())
+self._stepslineFunc(renderer, gc, path, IdentityTransform())
def _draw_steps_mid(self, renderer, gc, path, trans):
@@ -703,7 +719,7 @@
path = Path(steps)
path = path.transformed(self.get_transform())
-self._draw_solid(renderer, gc, path, IdentityTransform())
+self._stepslineFunc(renderer, gc, path, IdentityTransform())
def _draw_dashed(self, renderer, gc, path, trans):
-
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] dashed steps plot
Manuel Metz wrote: > Hi all, > I ran into a problem where I wanted to plot a step-plot with dashed > lines instead of solid lines which can be important for print media. > This isn't possible with the current matplotlib version, so I added > support for this. The patch is attached, but I didn't commit it yet > since I wanted to ask for feedback first. It basically adds support to do > > pylab.plot(x, y, 'steps--') > > to create a step plot with dashed lines. Hm, okay - I just noticed that the patch doesn't work with legend. This needs to be fixed ... mm - 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] irregularly spaced grids and imshowm: PATCH for bilinear interp
It's funny you should mention this. One of the things I realized after SciPy this year is that there is a lot of interfacing of Numpy with C++ (as opposed to C) that could really benefit from a standard C++ wrapper around Numpy. A bunch of different projects all had home-grown, semi-complete solutions. A standard wrapper would be good for all of the reasons you mention (basically resource management), but also to have a cleaner syntax for accessing the elements that would abstract away striding, ordering etc. It may actually be possible to build it around boost::multiarray (the closest thing the upcoming C++-0x standard has to a n-dimensional array). Can't imagine I'll find time for it anytime soon, but it would be fun to work on... Cheers, Mike Christopher Barker wrote: > Michael Droettboom wrote: > >> I think we want to use std::vector where possible for new code, and >> convert as we go through old code. Manual malloc/free is just too error >> prone. (We're forced to do some by interfacing with Python, but it >> should be kept to a minimum). >> > > My understanding is that this is exactly the issue -- with std::vector > and friends you can't both get the data pointer and create a vector with > a data pointer, which would be what you'd want to do to interface > efficiently with numpy arrays. > > I've been looking for a way to address this problem, but my C++ is > pretty week. maybe smart pointers and/or other boost classes could help. > > > I do have an idea, though. The goal is a set of classes for working with > data that are convenient to use with pure C++, but also play with numpy > arrays. > > I imagine a simple vector/array set of classes build on top of a simple > object: a reference counted data block. This data block object would > simply hold a pointer to a block of data, maybe know how large it is, > maybe know what type the data is, and hold a reference count. when that > count drops to zero it deletes itself. > > The vector/array classes built on top of it would use the data block to > store their data, and increment/decrement the reference count as need > be. This would allow them to share data, have one array that is a subset > of another, using the same data block, etc. > > It should be easy to build numpy arrays from a system like this. > > Ideally (but I'm not sure how), the data blocks reference counting > system could be integrated with Python's, so that when a numpy array was > constructed from one, its reference count would be managed by python as > well as your C++ code. > > But maybe that's all just too much work... > > > -Chris > > > > - 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] a patch to have a correct baseline when usetex=True
Sphinx contains one way to do this in its new "pngmath" extension. It
uses the LaTeX package "preview" which does all of this magic
internally. And I believe it's a little more general. If I recall, the
approach you're taking won't work with some LaTeX constructs such as:
\begin{align}
x & = 2
y & = 2
\end{align}
Plus, Sphinx is BSD-licensed, so it should be fine to copy-and-paste
whatever code is necessary.
Of course, latex-preview is required to be installed, but I think it's a
pretty common package.
See here:
http://svn.python.org/projects/doctools/trunk/sphinx/ext/pngmath.py
Cheers,
Mike
Jae-Joon Lee wrote:
> On Thu, Aug 28, 2008 at 4:18 PM, John Hunter <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>>
>>
>>> First of all, I borrowed this idea from the PyX which is in GPL.
>>> Although there is little of copying, other than the basic idea, I'm
>>> not 100% sure if this could be BSD-compatible.
>>>
>> I think it is fine to borrow the idea; what we need to do is a clean
>> room implementation with no copying. You can best answer that, so if
>> you tell us your patch is cleanly implemented, we can accept it.
>>
>> JDH
>>
>>
>
> Thanks for the response.
>
> Well, the only part I borrowed from PyX is TeX related commands they
> use (there is not much of implementation as far as TeX-related code is
> concerned). From their code, I learned the meaning and usage of the
> following TeX commands
>
> \newbox
> \setbox
> \immediate\write16
>
> And I used the same TeX commands in my code.
> But I personally think this is not a (code) copy.
>
> Other than this, the code is clean.
> Regards,
>
> -JJ
>
> -
> 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] a patch to have a correct baseline when usetex=True
Thanks,
I quickly went through the code of the pngmath.py, and it seems that
the depth(descent) of the dvi file is reported by "dvipng" (but the
preview package must be used in the tex file for this to work
correctly). Therefore, with this method, we need to run dvipng even if
we use ps of pdf backend. Although this seems fine to me, I'll see if
I can extract the depth of the text without running the dvipng.
Regards,
-JJ
On Fri, Aug 29, 2008 at 7:59 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Sphinx contains one way to do this in its new "pngmath" extension. It uses
> the LaTeX package "preview" which does all of this magic internally. And I
> believe it's a little more general. If I recall, the approach you're taking
> won't work with some LaTeX constructs such as:
>
> \begin{align}
>x & = 2
>y & = 2
> \end{align}
>
> Plus, Sphinx is BSD-licensed, so it should be fine to copy-and-paste
> whatever code is necessary.
>
> Of course, latex-preview is required to be installed, but I think it's a
> pretty common package.
>
> See here:
>
> http://svn.python.org/projects/doctools/trunk/sphinx/ext/pngmath.py
>
> Cheers,
> Mike
>
> Jae-Joon Lee wrote:
>>
>> On Thu, Aug 28, 2008 at 4:18 PM, John Hunter <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>
First of all, I borrowed this idea from the PyX which is in GPL.
Although there is little of copying, other than the basic idea, I'm
not 100% sure if this could be BSD-compatible.
>>>
>>> I think it is fine to borrow the idea; what we need to do is a clean
>>> room implementation with no copying. You can best answer that, so if
>>> you tell us your patch is cleanly implemented, we can accept it.
>>>
>>> JDH
>>>
>>>
>>
>> Thanks for the response.
>>
>> Well, the only part I borrowed from PyX is TeX related commands they
>> use (there is not much of implementation as far as TeX-related code is
>> concerned). From their code, I learned the meaning and usage of the
>> following TeX commands
>>
>> \newbox
>> \setbox
>> \immediate\write16
>>
>> And I used the same TeX commands in my code.
>> But I personally think this is not a (code) copy.
>>
>> Other than this, the code is clean.
>> Regards,
>>
>> -JJ
>>
>> -
>> 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] Plot 1 point at a time, results in very bad performance and the figuring entering a state of non-response
Hello Everyone This is my first post, I really enjoy using python/numpy/scipy/matplotlib - great replacement for matlab. I am having a problem, with plot 1 point at a time. i am attempt to emulate an issue in the lab, where we get samples every second and plot them. The figure becomes non-responsive and eventually stops plotting, does anyone have an idea. Cheers Ray *Code* *--* from numpy import * from scipy import * from pylab import * import time; ion() figure(1) subplot(412);plot([925],[0.296000],'o') subplot(413);plot([925],[0.247000],'o') subplot(414);plot([925],[0.145000],'o') subplot(411);plot([926],[0.516000],'o') time.sleep(1) subplot(412);plot([926],[0.77],'o') subplot(413);plot([926],[0.82],'o') subplot(414);plot([926],[0.405000],'o') subplot(411);plot([927],[0.704000],'o') time.sleep(1) subplot(412);plot([927],[0.721000],'o') subplot(413);plot([927],[0.996000],'o') subplot(414);plot([927],[0.219000],'o') subplot(411);plot([928],[0.414000],'o') time.sleep(1) subplot(412);plot([928],[0.281000],'o') subplot(413);plot([928],[0.066000],'o') subplot(414);plot([928],[0.398000],'o') subplot(411);plot([929],[0.718000],'o') subplot(412);plot([929],[0.247000],'o') subplot(413);plot([929],[0.887000],'o') subplot(414);plot([929],[0.562000],'o') subplot(411);plot([930],[0.386000],'o') time.sleep(1) subplot(412);plot([930],[0.173000],'o') subplot(413);plot([930],[0.678000],'o') subplot(414);plot([930],[0.635000],'o') subplot(411);plot([931],[0.746000],'o') time.sleep(1) subplot(412);plot([931],[0.332000],'o') subplot(413);plot([931],[0.468000],'o') subplot(414);plot([931],[0.373000],'o') subplot(411);plot([932],[0.568000],'o') time.sleep(1) subplot(412);plot([932],[0.929000],'o') subplot(413);plot([932],[0.096000],'o') subplot(414);plot([932],[0.132000],'o') subplot(411);plot([933],[0.84],'o') time.sleep(1) subplot(412);plot([933],[0.946000],'o') subplot(413);plot([933],[0.607000],'o') subplot(414);plot([933],[0.094000],'o') subplot(411);plot([934],[0.69],'o') time.sleep(1) subplot(412);plot([934],[0.33],'o') subplot(413);plot([934],[0.955000],'o') subplot(414);plot([934],[0.101000],'o') subplot(411);plot([935],[0.931000],'o') time.sleep(1) subplot(412);plot([935],[0.515000],'o') subplot(413);plot([935],[0.444000],'o') subplot(414);plot([935],[0.425000],'o') subplot(411);plot([936],[0.96],'o') time.sleep(1) subplot(412);plot([936],[0.676000],'o') subplot(413);plot([936],[0.295000],'o') subplot(414);plot([936],[0.861000],'o') subplot(411);plot([937],[0.564000],'o') time.sleep(1) subplot(412);plot([937],[0.948000],'o') subplot(413);plot([937],[0.159000],'o') subplot(414);plot([937],[0.512000],'o') subplot(411);plot([938],[0.884000],'o') time.sleep(1) subplot(412);plot([938],[0.542000],'o') subplot(413);plot([938],[0.409000],'o') subplot(414);plot([938],[0.079000],'o') subplot(411);plot([939],[0.194000],'o') time.sleep(1) subplot(412);plot([939],[0.91],'o') subplot(413);plot([939],[0.901000],'o') subplot(414);plot([939],[0.153000],'o') subplot(411);plot([940],[0.183000],'o') time.sleep(1) subplot(412);plot([940],[0.578000],'o') subplot(413);plot([940],[0.241000],'o') subplot(414);plot([940],[0.484000],'o') subplot(411);plot([941],[0.261000],'o') time.sleep(1) subplot(412);plot([941],[0.436000],'o') subplot(413);plot([941],[0.12],'o') subplot(414);plot([941],[0.798000],'o') subplot(411);plot([942],[0.339000],'o') time.sleep(1) subplot(412);plot([942],[0.927000],'o') subplot(413);plot([942],[0.964000],'o') subplot(414);plot([942],[0.526000],'o') subplot(411);plot([943],[0.289000],'o') time.sleep(1) subplot(412);plot([943],[0.167000],'o') subplot(413);plot([943],[0.695000],'o') subplot(414);plot([943],[0.788000],'o') subplot(411);plot([944],[0.863000],'o') time.sleep(1) subplot(412);plot([944],[0.054000],'o') subplot(413);plot([944],[0.568000],'o') subplot(414);plot([944],[0.054000],'o') subplot(411);plot([945],[0.858000],'o') time.sleep(1) subplot(412);plot([945],[0.461000],'o') subplot(413);plot([945],[0.916000],'o') subplot(414);plot([945],[0.549000],'o') subplot(411);plot([946],[0.575000],'o') time.sleep(1) subplot(412);plot([946],[0.056000],'o') subplot(413);plot([946],[0.331000],'o') subplot(414);plot([946],[0.864000],'o') subplot(411);plot([947],[0.65],'o') time.sleep(1) subplot(412);plot([947],[0.205000],'o') subplot(413);plot([947],[0.036000],'o') subplot(414);plot([947],[0.951000],'o') subplot(411);plot([948],[0.289000],'o') time.sleep(1) subplot(412);plot([948],[0.446000],'o') subplot(413);plot([948],[0.132000],'o') subplot(414);plot([948],[0.562000],'o') subplot(411);plot([949],[0.084000],'o') time.sleep(1) subplot(412);plot([949],[0.429000],'o') subplot(413);plot([949],[0.451000],'o') subplot(414);plot([949],[0.994000],'o') subplot(411);plot([950],[0.52],'o') time.sleep(1) subplot(412);plot([950],[0.28],'o') subplot(413);plot([950],[0.575000],'o') subplot(414);plot([950],[0.152000],'o') subplot(411);plot([951],[0.253000],'o') time.
Re: [matplotlib-devel] Plot 1 point at a time, results in very bad performance and the figuring entering a state of non-response
On Fri, Aug 29, 2008 at 12:01 PM, Ray Salem <[EMAIL PROTECTED]> wrote:
>This is my first post, I really enjoy using python/numpy/scipy/matplotlib
> - great replacement for matlab. I am having a problem, with plot 1 point at
> a time. i am attempt to emulate an issue in the lab, where we get samples
> every second and plot them. The figure becomes non-responsive and eventually
> stops plotting, does anyone have an idea.
Yep, this is a bad idea. The line object in matplotlib is a fairly
heavy object which has a lot of stuff under the hood. Each plot
command creates a new line object. What you want to do is create just
one (or a few) line objects, each of which handles many points. Below
is the first pass naive implementation to show you how to do this --
you will probably want to improve on this by using a better data
structure to store the growing points, eg a buffer that drops old
points off the end, or a dynamically resizing numpy array which grows
intelligently when it gets full. The main point is that we create a
single line object and add the new data to it
import time
import matplotlib
matplotlib.use('TkAgg')
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.collections as collections
plt.ion() # interactive plotting
fig = plt.figure()
ax = fig.add_subplot(111, autoscale_on=False)
xdata, ydata = [0.], [0.]
line, = ax.plot(xdata, ydata, 'o')
dt = 0.1
for i in range(100):
x = xdata[-1] + dt
y = np.sin(2*np.pi*x)
xdata.append(x)
ydata.append(y)
line.set_data(xdata, ydata)
ax.set_xlim(x-1, x)
ax.set_ylim(-1.1, 1.1)
fig.canvas.draw()
time.sleep(0.1)
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
Re: [matplotlib-devel] irregularly spaced grids and imshowm: PATCH for bilinear interp
Michael Droettboom wrote: > It's funny you should mention this. > > One of the things I realized after SciPy this year is that there is a > lot of interfacing of Numpy with C++ (as opposed to C) that could really > benefit from a standard C++ wrapper around Numpy. Absolutely. Though now that you mention it, isn't there one in boost::python? or at least one that worked with Numeric. > projects all had home-grown, semi-complete solutions. > A standard wrapper would be good for all of the reasons you mention > (basically resource management), but also to have a cleaner syntax for > accessing the elements that would abstract away striding, ordering etc. I think I'm thinking of something slightly different. What I'd like is set of array classes that can interface well with numpy, and also be quite usable all by themselves in C++ code that has nothing to do with python. I don't really envision a C++ ndarray -- I generally think of C++ as static enough that I'm happy to define that I need, for example, a NX2 array of doubles. I don't see using a generic array like ndarray that could hold any type, shape, etc. But maybe others do -- it would be pretty cool. I guess to some extent the question is whether you are writing extensions for python, or a C++ that you want to use from C++, and also wrap for python. But maybe both need can be met by the same C++ classes (templates?) > It may actually be possible to build it around boost::multiarray Do you know off hand if multiarray can be constructed from an existing pointer to a data block? > Can't imagine I'll find time for it anytime soon, too bad, but if you do -- I'd love to hear about it! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - 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] irregularly spaced grids and imshowm: PATCH for bilinear interp
Grégory Lielens wrote: > Thanks a lot for reviewing my patch! > I have corrected most of the problems (I think ;-) ) > I indeed introduced memory leak, I think it is fixed now, I have also > reorganized the code to avoid duplication of the cleanup code. I used an > helper function instead of the goto, because this cleanup is needed for > normal exit too, so the helper function can come in handy for that. > std::vector would have been nice, but I tried to respect the original > coding style, maybe this could be changed but I guess the original > author should have something to say about it > Only thing I did not change is the allocation of acols/arows even when > they are not used. It is not difficult to do, but the code will be a > little more complex and I think that the extra memory used is not > significant: The memory for those mapping structure is doubled (1 float > and 1 int vector of size N, instead of a single int vector of size N), > but those mapping structures are an order of magnitude smaller than the > image buffer of size N*N of 4 char anyway... > > If one agree that this is to be saved at the (slight) expense of code > conciseness/simplicity, I can add this optimisation... > > Thanks for pointing the error at the left/bottom pixel lines, it is > corrected now :-) > > And I set interpolation to NEAREST by default, so that the behavior of > NonUniformImage remains the same as before if the user do not specify > otherwise (I forgot to do it in the first patch)... > > > I include the new patch, Gregory, I am sorry to be late in joining in, but I have a basic question about what you are trying to do. It arises from the fact that there are two styles of image-like plots: 1) In the original Image and NonuniformImage, the colors and locations of "pixel" (or patch or subregion or whatever) centers are specified. 2) In pcolor, quadmesh, and pcolorimage, the patch *boundaries* are specified. pcolorimage is my modification of the original NonuniformImage code to work with boundaries. I left the original in place, since presumably it meets some people's needs, even though it does not meet mine. When the grid is uniform, it doesn't really make any difference; but when the grid is nonuniform, then I don't think style #1 makes much sense for pcolor-style plotting, in which there is no interpolation; there is no unique way to specify the boundaries, so it is up to the plotting routine, and that is bad. For an image, it is clear how the interpolation should work: the color values are given at the centers of the "pixels" (meaning on the original image grid, not on the screen or other output device grid), which are uniformly spaced, and interpolated between. Exactly what is your patch supposed to do for the nonuniform case? Would you describe and demonstrate it, please, for a simple case with a 2x2 array of colors and 3x3 arrays for boundary x and y? Thanks. Eric > > Best regards, > > Greg. > > On Fri, 2008-08-15 at 15:45 -0400, Michael Droettboom wrote: >> Thanks for all the work you put into this patch. >> >> As you say, it would be nice to have a generic framework for this so >> that new types of interpolation could be easily added and to be able to >> support arbitrary (non-axis-aligned) quadmeshes as well. But that's >> even more work -- if we keep waiting for everything we want, we'll never >> get it... ;) I agree that Agg probably won't be much help with that. >> >> There are a couple of comments with the patch as it stands --> >> >> There seems to be a gap extrapolating over the left and bottom edge (see >> attached screenshot from pcolor_nonuniform.py). >> >> Memory management looks problematic, some of which I think you inherited >> from earlier code. For example, arows and acols are never freed. >> Personally, I think these temporary buffers should be std::vector's so >> they'll be free'd automatically when scope is left. It might also be >> nice to move all of the Py_XDECREF's that happen when exceptions are >> thrown to either a master try/catch block or an "exit" goto label at the >> bottom. The amount of duplication and care required to ensure >> everything will be freed by all of the different exit paths is a little >> cumbersome. >> >> Also, acols and arows are only used in BILINEAR interpolation, but they >> are allocated always. >> >> Once these issues are addressed, it would be great to have someone who >> *uses* the nonuniform pcolor functionality (Eric Firing?) have a look at >> this patch for any regressions etc.. Assuming none, I'll be happy to >> commit it (but I won't be around for a week or so). >> >> Cheers, >> Mike >> >> Grégory Lielens wrote: >>> Hi all, >>> >>> here is a patch which implement bilinear interpolation on irregular grid >>> ( i.e. it allows NonUniformImage >>> to accept both 'nearest' and 'bilinear' interpoaltion, instead of only >>> 'nearest'.) >>> >>> It is not perfect, given the current architecture of
Re: [matplotlib-devel] irregularly spaced grids and imshowm: PATCH for bilinear interp
Christopher Barker wrote: > Michael Droettboom wrote: > >> It's funny you should mention this. >> >> One of the things I realized after SciPy this year is that there is a >> lot of interfacing of Numpy with C++ (as opposed to C) that could really >> benefit from a standard C++ wrapper around Numpy. >> > > Absolutely. Though now that you mention it, isn't there one in > boost::python? or at least one that worked with Numeric. > > Yes, but AFAICT it forces the use of boost::python, at least to convert the object. It would be nicer (in some cases) to have something that could be wrapper-system-agnostic. I spent a little time working on this today, and I was actually pleasantly surprised by how far I got. I have something that exposes Numpy arrays as boost::multi_arrays on the C++ side, and also allows for creating new Numpy-backed arrays from C++. The memory is still managed with Python reference counting, and the references are automatically freed from the constructor. It requires boost and Numpy, of course, but not boost::python. A standalone C++ class for this would perhaps have been nicer, but that's not an afternoon's 200-line hack like this is. I wouldn't really consider this a "wrapper" around Numpy, since it doesn't actually use Numpy for any of the indexing or computation. It simply converts the Numpy description (pointer + strides, etc.) to a boost::multi_array, without copying the underlying data. > >> projects all had home-grown, semi-complete solutions. >> A standard wrapper would be good for all of the reasons you mention >> (basically resource management), but also to have a cleaner syntax for >> accessing the elements that would abstract away striding, ordering etc. >> > > I think I'm thinking of something slightly different. What I'd like is > set of array classes that can interface well with numpy, and also be > quite usable all by themselves in C++ code that has nothing to do with > python. > This should fit that bill. Just templatize all your algorithms to accept anything with the "boost::multi_array" interface. When building extensions for Numpy, pass in a wrapped numpy array -- when not, use a pure boost::multi_array. Of course, the pure boost::multi_array doesn't have reference-counted memory management. Use of boost::shared_ptr may help, but it's not "built-in" -- views of boost::multi_arrays don't automatically keep their parent data alive. It's the usual C++ "you're on your own" approach. > I don't really envision a C++ ndarray -- I generally think of C++ as > static enough that I'm happy to define that I need, for example, a NX2 > array of doubles. I don't see using a generic array like ndarray that > could hold any type, shape, etc. But maybe others do -- it would be > pretty cool. > My approach (being based on boost::multi_array) has a fixed type and number of dimensions at compile time. If you try to pass in a Numpy array that can't be converted to that, an exception is thrown. Personally, I feel that's good enough for most domain-specific algorithms. Theoretically, one could write algorithms that are templatized on the data type and then dispatch at run time to different instantiations of that template -- but my code doesn't do anything like that yet. > I guess to some extent the question is whether you are writing > extensions for python, or a C++ that you want to use from C++, and also > wrap for python. > I'm just doing this out of curiosity rather than to meet a need. We don't have much C++ code at the Institute. I could see this being very handy in matplotlib, however, but the dependency on Boost is probably a showstopper... :( > But maybe both need can be met by the same C++ classes (templates?) > I think so. See above. > >> It may actually be possible to build it around boost::multiarray >> > > Do you know off hand if multiarray can be constructed from an existing > pointer to a data block? > Yep. multi_array_ref seems custom-built for that purpose. > >> Can't imagine I'll find time for it anytime soon, >> I went ahead and created a Google Code project for this here: http://code.google.com/p/numpy-boost/ Just because it's up there doesn't mean it's anything more than an experimental hack. It needs documentation and more complete unit tests... etc... 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
