Re: [matplotlib-devel] Event handling example not working
Neil Crighton wrote: > I noticed on the event handling doc page: > > matplotlib-devel@lists.sourceforge.net > > that the draggable rectangle example doesn't work in version 0.98.3. > The rectangle class no longer seems to have the xy property. If you > replace the current on_press() method in the example with the code > below it seem to work. > > def on_press(self, event): > 'on button press we will see if the mouse is over us and store > some data' > if event.inaxes != self.rect.axes: return > > contains, attrd = self.rect.contains(event) > if not contains: return > xy = self.rect.get_x(),self.rect.get_y() > print 'event contains', xy > x0, y0 = xy > self.press = x0, y0, event.xdata, event.ydata > Good catch. I checked in a slightly different version of the fix. 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
Re: [matplotlib-devel] Event handling example not working
> Neil Crighton wrote: >> I noticed on the event handling doc page: >> >> matplotlib-devel@lists.sourceforge.net >> >> that the draggable rectangle example doesn't work in version 0.98.3. >> The rectangle class no longer seems to have the xy property. If you >> replace the current on_press() method in the example with the code >> below it seem to work. >> >> def on_press(self, event): >> 'on button press we will see if the mouse is over us and store >> some data' >> if event.inaxes != self.rect.axes: return >> >> contains, attrd = self.rect.contains(event) >> if not contains: return >> xy = self.rect.get_x(),self.rect.get_y() >> print 'event contains', xy >> x0, y0 = xy >> self.press = x0, y0, event.xdata, event.ydata >> Here's probably a better question to ask than just to fix the example. Was it intended that the Rectangle.xy attribute disappear? I couldn't find it documented in API_CHANGES. It appears that there was just a change at some point in Michael's transforms work. If it's considered desirable to have it back, I'll volunteer to whip up a patch to make it a property. If not, let's just make sure we document this in API_CHANGES. My opinion is that randomly breaking API is always bad, and there's not much effort involved in fixing it here. On the other hand, we've already had 3 with this breakage, and no complaints up until now (and that's from our own docs :P) Thoughts? 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
Re: [matplotlib-devel] Event handling example not working
John Hunter wrote: > On Wed, Oct 29, 2008 at 4:00 PM, Ryan May <[EMAIL PROTECTED]> wrote: > >> Here's probably a better question to ask than just to fix the example. >> Was it intended that the Rectangle.xy attribute disappear? I couldn't >> find it documented in API_CHANGES. It appears that there was just a >> change at some point in Michael's transforms work. If it's considered >> desirable to have it back, I'll volunteer to whip up a patch to make it >> a property. If not, let's just make sure we document this in API_CHANGES. > > I have no problem with you adding it back in as a convenience > property. Can't see the harm. Done in r6366. Also reverted the changes to the exercise, as the description still mentioned using the xy attribute. 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] mlab.psd API
Hi, How much freedom would I (and my colleague) have in changing up some of the behavior/API of mlab.psd? My current issues with the function: 1) Returning one-sided or two-sided depends on whether the data is complex. I'd like that to be controlled by a keyword parameter (could take strings, such as 'two-sided' like matlab) 2) We'd like to add a parameter to control how many points are used for performing the FFT (automatic zero padding for increased plotting detail). The obvious name for this would be nfft, but this seems to conflict with the NFFT parameter. NFFT, confusingly, is used to specify the blocksize used for averaging. If we can't outright change names here, I'd love for suggestions on a good way forward. 3) Can we remove the requirement for even NFFT (blocksize)? 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
Re: [matplotlib-devel] Help with scatter
Andrew Stock wrote: > My interpretation of this is that either of the three values attempted > in the code example should work. However, all of these fail. > > from pylab import * > > x = [1,2,3] > y = [2,4,6] > c = ['#ff', '#00ff00', '#ff'] > c = ['b','r', 'g'] > c = [(1,0,0), (0,1,0), (0,0,1)] > > scatter(x, y, c=c) > > show() > > If I change the call to scatter() to a call to bar() as so: > > bar(x, y, color = c) > > then each of the three examples work as I would expect. > > Am I missing something in my interpretation of the documentation for > scatter? Can anyone point out what I've missed? 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.) 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
Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py
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... 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
Re: [matplotlib-devel] Help with scatter
Andrew Stock wrote: > My interpretation of this is that either of the three values attempted > in the code example should work. However, all of these fail. > > from pylab import * > > x = [1,2,3] > y = [2,4,6] > c = ['#ff', '#00ff00', '#ff'] > c = ['b','r', 'g'] > c = [(1,0,0), (0,1,0), (0,0,1)] > > scatter(x, y, c=c) > > show() I'm working on a better fix right now, but can you try making sure you have more (or less) colors specified than needed? I think that should work around (or it seems to on SVN HEAD). 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
Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py
Eric Firing wrote:
> 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.
I agree. It's even more egregious when you consider that:
>>>s = numpy.string_('Foo')
>>>isinstance(s, str)
True
I think a nicer workaround at the moment might be to just see if the
passed in object *is* indeed a string instance, and if so, return True.
I can't imagine that breaking anything. Figuring out why font
dictionary handling breaks would be good to do however.
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
Re: [matplotlib-devel] Help with scatter
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
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
import matplotlib.pyplot as plt
import numpy as np
x,y,r,g,b = np.random.rand(5, 30)
hex_strings = ['#ff', '#00ff00', '#ff', '#00', '#ff00ff', '#00']
tuples = np.array(zip(r,g,b))
#This makes sure we have *exactly* as many names as we have values
names = ['red', 'green', 'blue', 'black', 'cyan', 'yellow', 'orange']
names = names * (len(x)//len(names) + 1)
names = names[:len(x)]
#This makes sure we have more letters than scatter values, so that we can test
#that case
letters = ['b','r', 'g', 'c', 'm', 'y', 'k']
letters = letters * (len(x)//len(letters) + 1)
for sub, c in enumerate((hex_strings, letters, tuples, names)):
plt.subplot(2, 2, sub+1)
plt.scatter(x, y, c=c, s=50)
plt.show()
Index: lib/matplotlib/cbook.py
===
--- lib/matplotlib/cbook.py (revision 6385)
+++ lib/matplotlib/cbook.py (working copy)
@@ -267,6 +267,7 @@
def is_string_like(obj):
'return true if *obj* looks like a string'
+if isinstance(obj, np.string_): return True
if hasattr(obj, 'shape'): return False
try: obj + ''
except (TypeError, ValueError): return False
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 6384)
+++ lib/matplotlib/axes.py (working copy)
@@ -4930,7 +4930,7 @@
# The inherent ambiguity is resolved in favor of color
# mapping, not interpretation as rgb or rgba.
-if not is_string_like(c):
+if not (is_string_like(c) or cbook.is_sequence_of_strings(c)):
sh = np.shape(c)
if len(sh) == 1 and sh[0] == len(x):
colors = None # use cmap, norm after collection is created
Index: lib/matplotlib/colors.py
===
--- lib/matplotlib/colors.py(revision 6384)
+++ lib/matplotlib/colors.py(working copy)
@@ -343,7 +343,7 @@
# with modified items so that items can be appended to
# it. This is needed for examples/dynamic_collections.py.
if isinstance(c, np.ndarray):
-if len(c.shape) != 2:
+if len(c.shape) != 2 and not cbook.is_sequence_of_strings(c):
raise ValueError("Color array must be two-dimensional")
result = np.zeros((len(c), 4))
-
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
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
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
import matplotlib.pyplot as plt
import numpy as np
x,y,r,g,b = np.random.rand(5, 30)
hex_strings = ['#ff', '#00ff00', '#ff', '#00', '#ff00ff', '#00']
tuples = np.array(zip(r,g,b))
#This makes sure we have *exactly* as many names as we have values
names = ['red', 'green', 'blue', 'black', 'cyan', 'yellow', 'orange']
names = names * (len(x)//len(names) + 1)
names = names[:len(x)]
#This makes sure we have more letters than scatter values, so that we can test
#that case
letters = ['b','r', 'g', 'c', 'm', 'y', 'k']
letters = letters * (len(x)//len(letters) + 1)
for sub, c in enumerate((hex_strings, letters, tuples, names)):
plt.subplot(2, 2, sub+1)
plt.scatter(x, y, c=c, s=50)
plt.show()
Index: lib/matplotlib/cbook.py
===
--- lib/matplotlib/cbook.py (revision 6385)
+++ lib/matplotlib/cbook.py (working copy)
@@ -267,6 +267,7 @@
def is_string_like(obj):
'return true if *obj* looks like a string'
+if isinstance(obj, np.string_): return True
if hasattr(obj, 'shape'): return False
try: obj + ''
except (TypeError, ValueError): return False
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 6384)
+++ lib/matplotlib/axes.py (working copy)
@@ -4930,7 +4930,7 @@
# The inherent ambiguity is resolved in favor of color
# mapping, not interpretation as rgb or rgba.
-if not is_string_like(c):
+if not (is_string_like(c) or cbook.is_sequence_of_strings(c)):
sh = np.shape(c)
if len(sh) == 1 and sh[0] == len(x):
colors = None # use cmap, norm after collection is created
Index: lib/matplotlib/colors.py
===
--- lib/matplotlib/colors.py(revision 6384)
+++ lib/matplotlib/colors.py(working copy)
@@ -343,7 +343,7 @@
# with modified items so that items can be appended to
# it. This is needed for examples/dynamic_collections.py.
if isinstance(c, np.ndarray):
-if len(c.shape) != 2:
+if len(c.shape) != 2 and not cbook.is_sequence_of_strings(c):
raise ValueError("Color array must be two-dimensional")
result = np.zeros((len(c), 4))
-
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
On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <[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 -- 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
Re: [matplotlib-devel] Help with scatter
Eric Firing wrote: > 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. You have stolen my glory! :) Actually, I was thinking at this point it was more your patch anyways, and I had just done the work of tracking down all the problem spots. Saves me the effort of doing the checkin. :) 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] Repeating docs
Hi, In tweaking mlab.psd(), I'm noticing there is a lot of overlap between the keyword args for psd() and csd(). In fact, csd() doesn't document them itself, but just references psd(). Additionally, the csd() and psd() Axes methods duplicate these docs, with a few additional parameters. Would it be a good thing to restructure the duplicated docs into it's own string that can be incorporated when necessary? Or is this kind of "monkey patching" of the docs something we're trying to minimize? 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
Re: [matplotlib-devel] Repeating docs
John Hunter wrote: >> In tweaking mlab.psd(), I'm noticing there is a lot of overlap between >> the keyword args for psd() and csd(). In fact, csd() doesn't document >> them itself, but just references psd(). Additionally, the csd() and >> psd() Axes methods duplicate these docs, with a few additional >> parameters. Would it be a good thing to restructure the duplicated docs >> into it's own string that can be incorporated when necessary? Or is >> this kind of "monkey patching" of the docs something we're trying to >> minimize? > > No, this is something we are doing more of lately (eg see the contour > docs) but the psd, csd, cohere predated this docstring manipulation. > So feel free to consolidate. I've done psd and csd so far. I might get to cohere (and spectrogram) later. It got a little ugly doing the axes methods, since you can only use a single dictionary for string replacement. On a separate note, there is *A LOT* of code duplication between psd() and csd() in mlab. It's bugged me while I've been doing these tweaks, but the problem was that csd() would end up doing an extra FFT vs. the same call to psd. I think I might finally have a solution: 1) Have psd(x) call csd(x,x) 2) Have csd() check if y is x, and if so, avoid doing the extra work. Would this be an acceptable solution to reduce code duplication? On a separate note, once I get done with these tweaks, are there any objections to submitting something based on this to scipy? 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
Re: [matplotlib-devel] Repeating docs
John Hunter wrote: > On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <[EMAIL PROTECTED]> wrote: > >> 1) Have psd(x) call csd(x,x) >> 2) Have csd() check if y is x, and if so, avoid doing the extra work. >> >> Would this be an acceptable solution to reduce code duplication? > > Sure, that should work fine. Ok, I noticed that specgram() duplicated much of the same code, so I factored it all out and made a _spectral_helper() function, which pretty much implements a cross-spectrogram. csd() and specgram() use this, and then psd still calls csd(). Now all of the spectral analysis stuff is using the same computational code base. >> On a separate note, once I get done with these tweaks, are there any >> objections to submitting something based on this to scipy? > > No objections here -- if it were put into numpy though, we could > depend on it and avoid the duplication. I would campaign for numpy > first, eg np.fft.psd, etc. I agree it'd be better for us if it went to numpy, but I've gotten the sense that they're not really receptive to adding things like this now. I'll give it a try, but I sense that scipy.signal would end up being a more likely home. That wouldn't help us with duplication, but would help the community at large. It's always bugged me that I can't just grab a psd() function from my general computing packages. (In my opinion, anything in mlab that doesn't involve plotting should really exist in a more general package.) 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] pyplot.fill() and masked arrays
Hi, Is there any reason pyplot.fill() doesn't support masked arrays? Or was it just overlooked? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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
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. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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 wrote: > Ryan May wrote: >> 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) Well, combine all that pixie dust with a few wonderful thoughts, and we should all be flying like Peter Pan! :) Seriously, thanks for the pointer. _process_unit_info() combined with convert_[x|y]units() made it work. Old example and my own code here both work. Checked into r6497. Thanks, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] CHANGELOG tabs
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 -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] dashtick.py example broken
Hi, Was just looking through the examples and noticed that pylab_examples/dashtick.py does not work here for me on SVN head. Traceback (most recent call last): File "dashtick.py", line 61, in test_dashticklabel() File "dashtick.py", line 40, in test_dashticklabel fontsize=FONTSIZE, File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 162, in setp ret = _setp(*args, **kwargs) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/artist.py", line 982, in setp func = getattr(o,funcName) AttributeError: 'Text' object has no attribute 'set_dashrotation' I'm clueless on this code, so this is just an FYI. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] TextCollection
Hi, I was going to try to start working on a TextCollection class (finally!), and I thought it might be good to discuss some of it here before I get too far along. Motivations: *Speed up and simplify drawing of multiple text objects with common properties by reusing a single graphics context while drawing *Useful for doing plots using the text representation of values (think of a scatter plot with numbers instead of markers). This is my particular use case. *Useful for handling tick labels Current thoughts: - TextCollection will draw multiple strings (at multiple locations) with a common FontProperties(), rotation, linespacing, and alignment. - TextCollection will inherit from Text so that all of the getting/setting of these common properties is gotten "for free". What about all of the new Fancy bbox support of text? Do we handle this in text collection as well? - Should TextCollection also inherit from ScalarMappable so that we can colormap text values? On one hand this sounds nice and would be similar to the other collections. On the other, I can see this making for a difficult to understand plot. My feeling is that if there's no technical reason not to add a feature, give the user the power (to shoot themselves in the foot). - Create a new Axes method `text_plot()` (anyone got a better name?) that works like scatter, based on TextCollection. Takes x,y, and data values, as well as optional colormapping array. Also takes a string or function that controls formatting of text as well as (optional) x0,y0 scalar offsets (in points/pixels) that control where the text is placed in relation to the x,y location. These offsets would, for instance, allow one to plot city names above the dot marking the location instead of on top of it. Any thoughts? I'm especially interested in any potential pitfalls (like inheriting from Text). Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] (group) id support for artist
Jae-Joon Lee wrote: > John and others, > > I just committed a small patch that add gid(group id) as a property of > the Artist. > And also some small changes here and there, so that the svg backend > use this gid as the ID of each element. To do this, I slightly changed > the calling convention of the open_group() methods in Backends class. > I have mentioned about this some time ago, and these changes are meant > to be useful for some postprocessing of the svg fie > > http://www.nabble.com/Re%3A-SVG-clickable-images-p20241569.html > > I added two example, which apply gaussian blurring filter (for > dropshadow) and some lighting effects to the svg files created with > MPL. I added them under "examples/misc" because the examples are SVG > specific. Let me know if there is any other suitable place. > > Note that the svg filter is not supported by all the svg renderer. > Inkscape is the best open source tool that I know of which supports > svg filter. The lighting filters (used svg_filter_pie.py) work fine > with inkscape. Gaussian blurring (svg_filter_line.py) is also > supported by firefox. Wow. Very nice work, those look great. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] Native backend for Mac OS X
John Hunter wrote: > Hi Michiel, > > This looks great -- in particular I am intrigued by the final timing > results which show your backend 12 times faster than tkagg. I am not > sure where this speedup is coming from -- do you have some ideas? > Because you are creating lots-o-subplots in that example, there is a > lot of overhead at the python layer (many axes, many ticks, etc) so I > don't see how a faster backend could generate such a significant > improvement. What kind of timings do you see if you issue a plot > rather than bar call in that example? One thing about bar in > particular is that we draw lots of separate rectangles, each with thie > own gc, and it has been on my wishlist for some time to do this as a > collection. If you are handling gc creation, etc, in C, that may > account for a big part of the difference. > > Since the new macosx backend was released in 0.98.5, I also need to > decide whether this patch belongs on the branch, and hence will get > pushed out as early as today in a bugfix release when some changes JJ > and Michael are working on are ready, or the trunk, in which case it > could be months. In favor of the trunk: this is more of a feature > enhancement than a bugfix, and patches to the branch should be > bugfixes with an eye to stability of the released code, though a good > argument could be made that this is a bugfix. In favor of the branch: > it is brand new code advertised as beta in 0.98.5 and so it is > unlikely that anyone is using it seriously yet, and since it is beta, > we should get as much of it out there ASAP so folks can test and pound > on it. I'm in favor of branch, but I wanted to bring this up here > since we are fairly new to the branch/trunk release maintenance game > and want to get some input and provide some color about which patches > should go where, especially in gray areas like this. I'm +1 on going ahead and putting this on the branch, for the reasons you mentioned. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] Basemap inclusion of pupynere
Jeff, Would it be a lot of work for basemap to use the system copy of pupynere if it's installed, instead of installing its own copy? (like what's already done for dap and httplib2) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] Basemap inclusion of pupynere
Jeff Whitaker wrote: > Ryan May wrote: >> Jeff, >> >> Would it be a lot of work for basemap to use the system copy of >> pupynere if it's installed, instead of installing its own copy? (like >> what's already done for dap and httplib2) >> >> Ryan >> >> > > Ryan: The basemap version is modified to automatically unpack scaled > short integers into floats using the add_offset and scale_factor > variable attributes. It also automatically turns data with missing > values into masked arrays. > Is having two versions causing you any problems? > "import pupynere" should give you the system copy. You'd have to "from > mpl_toolkits.basemap import pupynere" to get the Basemap version. Good to know. It's not that it's a big deal for me (it's one python file after all), I just noticed that Gentoo's ebuild is blowing it away and just requiring/installing mainline pupynere. From a purist standpoint, I don't like having multiple copies of the same code hanging around, but I'm not about to lose sleep over it. It might make your job easier if you could convince Roberto to take those changes upstream. :) It sounds to me, however, that I need to file a Gentoo bug. I will say that pupynere seems to be spreading, but not in a good way. There's the standalone version. Then there's your tweaked version. And there's a (now out-dated) copy in scipy. On a related note, is there any reason that Basemap/pyshapelib couldn't use a system copy of shapelib? Right now, Gentoo's patching the setup.py to do this. I was curious if we could move that upstream. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] Basemap inclusion of pupynere
Jeff Whitaker wrote: > Ryan May wrote: >> On a related note, is there any reason that Basemap/pyshapelib >> couldn't use a system copy of shapelib? Right now, Gentoo's patching >> the setup.py to do this. I was curious if we could move that upstream. > I know it's silly at some level to have multiple copies, but if basemap > installs it's own (which doesn't conflict with the system copy) at least > I'm sure it's going to work. For me, it means I have to spend less time > helping folks figure out why they can't open shapefiles. It's a quite a > bit harder to check if a C library works from within python code than it > is a python package. > > Bottom line - it could be done, but I don't think it's worth it. > Shapelib is tiny anyway. Fine by me. I just thought I'd see what could be done. It sounds like it'd be a maintainance pain for you. So long as you don't go messing with setup.py's handling of shapelib too often, Gentoo should be fine as it already has a patch. :) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] Matplotlib patch on EPD trac?
John Hunter wrote: > Ryan May has been doing all the heavy lifting with respect to PSD and > specgram, so I am going to turf this to him :-) It may be that the > bug filer's problems are resolved in the recent changes in 98.5.2, but > Ryan should confirm > > On Fri, Jan 9, 2009 at 2:45 PM, Dave Peterson wrote: >> Hi John, >> >> Sorry for sending this directly, but I'm still waiting for my matplotlib >> devel mailing subscription to go through >> >> We've just had an EPD user submit a patch for matplotlib to 'fix' a problem >> they were seeing with the PSD function. Is this a known issue or something >> that you'd be interested in including in future versions of matplotlib? Or >> is it something that you disagree is 'right'? >> >> https://svn.enthought.com/epd/ticket/581 >> >> I'd like to know to do the right thing with the matplotlib we include in >> EPD. :-) Specgram specifically handles the case of moving frequencies to -Fs/2 to Fs/2, instead of 0 to Fs. It was this way before I did any of my changes and I just left it as it was. Psd returns frequencies 0 to Fs for Matlab compatibility (I think anyways, John?). Personally, I'd also prefer to have -Fs/2 to Fs/2 returned as well, so I don't have to do it in my own code. However, I'm also loath to add yet another flag to toggle Matlab compatibility. As far as the patch goes, it looks fine. It won't work as is with the refactoring I've already done in SVN, but it wouldn't be hard to implement the changes, if we decide to go that way. Maybe it's time to refactor here to get routine(s) that operate how we want (IMO more sanely than Matlab), and we provide wrappers that give Matlab-like behavior. Maybe we can also get these sane routines upstream into Scipy. At that point, however, I'm not sure what to do about the plotting functions, since there's a variety of behavior. Thoughts? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] Matplotlib patch on EPD trac?
Paul Kienzle wrote: > > On Jan 9, 2009, at 6:12 PM, Ryan May wrote: > >> Maybe it's time to refactor here to get routine(s) that operate how we >> want (IMO >> more sanely than Matlab), and we provide wrappers that give >> Matlab-like behavior. >> Maybe we can also get these sane routines upstream into Scipy. At >> that point, >> however, I'm not sure what to do about the plotting functions, since >> there's a >> variety of behavior. > > My policy when working on Octave was to avoid inventing new interfaces > when the existing interfaces are good enough. This doesn't apply to the > same degree in pylab of course because there is little hope of running > matlab code directly off the net, but it still helps users if things > with the same name share the same interface. It would not be good if > importing psd from the matlab compatibility package gave a different > interface than the same function name imported directly from mpl or scipy. I agree 100%. My thoughts were having a flexible, yet simple and straightforward implementation in scipy/matplotlib, and reimplement psd() on top of that. I don't think psd is a good name anyways, since it is specifically based on the welch method. While general, this is only 1 way of estimating the psd of the signal. > In terms of refactoring, consider having a spectral density object. The > following properties of psd naturally lends itself to an object interface: > > * a number of related functions (psd, csd, transfer function, > coherence) can be calculated from the same internal state > * the state can be fed new inputs and updated frame by frame, > * confidence intervals may or may not be requested, > * data can be plotted in multiple ways > * users may want to extract the data for further processing > > It would be pretty easy to build the matlab interface on top of such an > object. I hadn't thought of an OO interface, but that's not usually my primary way of thinking. It actually sounds like a good way to go, and is, in fact, the way MatLab has gone now. It would also allow making a class hierarchy that uses different methods for doing these calculation (plain periodogram, welch's method, etc.). Some food for thought anyways. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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
Neal Becker wrote: > What's wrong here? > This code snippet: > > from pylab import plot, show > print Id > print pout > > plot (Id, pout) > show() > > produces: > ['50', '100', '150', '200', '250', '300', '350', '400', '450', '500', '550', > '600', '650', '700', '750', '800', '850', '900', '950', '1000', '1050'] > ['0', '7.4', '11.4', '14.2', '16.3', '18.1', '19.3', '20.6', '21.6', '22.6', > '23.4', '24.1', '24.9', '25.4', '26.1', '26.5', '26.9', '27.1', '27.3', > '27.4', '27.4'] The problem here is that you're trying to plot lists of strings instead of lists of numbers. You need to convert all of these values to numbers. However, matplotlib could behave a bit more nicely in this case rather than simply recursing until it hits the limit. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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
Ryan May wrote:
> Neal Becker wrote:
>> What's wrong here?
>> This code snippet:
>>
>> from pylab import plot, show
>> print Id
>> print pout
>>
>> plot (Id, pout)
>> show()
>>
>> produces:
>> ['50', '100', '150', '200', '250', '300', '350', '400', '450', '500', '550',
>> '600', '650', '700', '750', '800', '850', '900', '950', '1000', '1050']
>> ['0', '7.4', '11.4', '14.2', '16.3', '18.1', '19.3', '20.6', '21.6', '22.6',
>> '23.4', '24.1', '24.9', '25.4', '26.1', '26.5', '26.9', '27.1', '27.3',
>> '27.4', '27.4']
>
> The problem here is that you're trying to plot lists of strings instead of
> lists
> of numbers. You need to convert all of these values to numbers. However,
> matplotlib could behave a bit more nicely in this case rather than simply
> recursing until it hits the limit.
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
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]?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
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
John Hunter wrote:
> On Thu, Jan 15, 2009 at 4:58 PM, 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
>> 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?
>
> Nope -- good idea
Ok, I'll check it in when I have a chance to run backend_driver.py and makes
sure
nothing breaks. (Not that it should). I'll also take a crack at adding a test.
For future reference, plotting lists/arrays of strings works (at least for
lines)
because Path calls .astype() on the arrays passed in, which will do the
conversion for us. So (part of) matplotlib actually does support plotting
sequences of string representations of numbers, it was just hindered by the unit
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 loop works for generic iterables that are not indexable and also
> for length 0 iterables
Ok, that makes sense.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
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] units/ example scripts
Hi, In fixing the recursion bug in the units support, I went through the examples in units/ and found two broken examples (broken before I fixed the recursion bug): 1) artist_tests.py Traceback (most recent call last): File "artist_tests.py", line 30, in lc = collections.LineCollection(verts, axes=ax) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/collections.py", line 917, in __init__ self.set_segments(segments) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/collections.py", line 927, in set_segments seg = np.asarray(seg, np.float_) File "/home/rmay/.local/lib64/python2.5/site-packages/numpy/core/numeric.py", line 230, in asarray return array(a, dtype, copy=False, order=order) ValueError: setting an array element with a sequence. 2) bar_unit_demo.py Traceback (most recent call last): File "bar_unit_demo.py", line 15, in p1 = ax.bar(ind, menMeans, width, color='r', bottom=0*cm, yerr=menStd) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/axes.py", line 4134, in bar fmt=None, ecolor=ecolor, capsize=capsize) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/axes.py", line 4678, in errorbar in cbook.safezip(y,yerr)] TypeError: unsupported operand type(s) for -: 'int' and 'TaggedValue' If anyone has any quick ideas on what might have gone wrong (or if these are just outdated), let me know. Otherwise, I'll start digging... Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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
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 :-) Ok, so what I'm taking from your responses is that it's not a waste of time to fix these, but that it is likely more involved than something I can do when I have only a short time to hack. I'll file these away (though if anyone else feels motivated, feel free!) :) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] set_aspect with shared axes
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:
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
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
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] online docs updating?
Hi, Do the online docs automatically update themselves from changes in SVN? I thought there was a nightly cron. I made some changes a few days ago (just a few typos) and they haven't shown up online yet. The changes were to doc/users/shell.rst. I'm assuming I should see the corresponding changes on http://matplotlib.sourceforge.net/users/shell.html. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] online docs updating?
John Hunter wrote: > On Tue, Jan 27, 2009 at 3:33 PM, Ryan May wrote: >> Hi, >> >> Do the online docs automatically update themselves from changes in SVN? I >> thought there was a nightly cron. I made some changes a few days ago (just >> a few >> typos) and they haven't shown up online yet. The changes were to >> doc/users/shell.rst. I'm assuming I should see the corresponding changes on >> http://matplotlib.sourceforge.net/users/shell.html. > > I had them in a cron and voluntarily disabled it. I'm amenable to > re-enabling it. The problem is that as examples become available in > svn, they automatically get pushed out to the gallery, but these may > not run on the latest released version. I thought perhaps the site > should more closely track the latest released version, so the last few > times I've pushed the docs out, I did so from the branch. So if you > want to see doc changes get pushed out sooner, you should patch the > branch and merge to the trunk. I am in general a big fan of > encouraging people to use the svn snapshots as much as possible, and > updating the gallery and site docs nightly helps this because the new > features in the gallery entice them, but in the absence of nightly > builds and snapshots I don't think this is too helpful. Is there any way to merge changes done on the trunk onto the branch? Or should I just do it manually? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] Patch to fix api/matplotlib_configuration_api.html
Sandro Tosi wrote: > Hi all! > Attached a very simple patch to show "matplotlib.patches" correctly in > the docpage above. Checked in on the trunk and maintainance branch, so it should get picked up whenever John pushes new docs to the website. Thanks for catching this. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Build Failure on Windows using Python25
On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw wrote: > Patrick, > > Can you see if adding "#include " at the top of src/path.cpp > will do the job? > > I'm not super-optimistic, though -- I think this is defined by the C99 > standard, which I'm not sure Microsoft supports. > Well, we're also talking about C++ here and not C, so C99 does not apply. A quick googling around seems to indicate that some of the open source compilers support such a type, but it not standardized by C++. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Build Failure on Windows using Python25
On Fri, Feb 6, 2009 at 4:48 PM, Andrew Straw wrote: > Ryan May wrote: > > On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw > <mailto:straw...@astraw.com>> wrote: > > > > Patrick, > > > > Can you see if adding "#include " at the top of > src/path.cpp > > will do the job? > > > > I'm not super-optimistic, though -- I think this is defined by the > C99 > > standard, which I'm not sure Microsoft supports. > > > > > > Well, we're also talking about C++ here and not C, so C99 does not > > apply. A quick googling around seems to indicate that some of the > > open source compilers support such a type, but it not standardized by > C++. > There is no or the type is not defined in stdint.h? > > Maybe as a workaround you could use mingw... > I meant that uint8_t is not a standardized C++ type. If that's the case, wouldn't it be better to tweak the code to use something standard rather than just use a compiler that supports the non-standard type? Especially given that the official Python 2.5 build uses this compiler? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Status of Wx backend
Hi,
What's the official status of the plain Wx backend (not WxAgg) ? I'm
noticing that the following script produces black outlines with Wx, but
should not (and does not on other backends). I also noticed font
differences between the two. I was curious if this is something to track
down or if plain Wx is just kind of abandoned. I've also attached images
made with Wx and GtkAgg.
#!/usr/bin/env python
import matplotlib.mlab as mlab
from pylab import figure, show
import numpy as np
x = np.arange(0.0, 2, 0.01)
y1 = np.sin(2*np.pi*x)
y2 = 1.2*np.sin(4*np.pi*x)
# now fill between y1 and y2 where a logical condition is met. Note
# this is different than calling
# fill_between(x[where], y1[where],y2[where]
# because of edge effects over multiple contiguous regions.
fig = figure()
ax = fig.add_subplot(111)
#ax.plot(x, y1, x, y2, color='black')
ax.fill_between(x, y1, y2, where=y2>y1, facecolor='#8388FC',
edgecolor='None')
ax.fill_between(x, y1, y2, where=y2<=y1, facecolor='#C14F53',
edgecolor='None')
ax.set_title('fill between where')
show()
Thoughts?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] svnmerge other files?
Hi, Can anyone explain why everytime I go to merge changes from the maintainance branch, it wants to tweak these files (besides the ones I actually changed)? doc/pyplots/README doc/sphinxext/gen_gallery.py doc/sphinxext/gen_rst.py Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States. -- 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
On Sun, Mar 1, 2009 at 8:17 AM, 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. > > > 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. Other than the automatic regeneration from latex, what you want sounds like what we already have: small python scripts. In general, I'm completely amazed by how many people want to develop a new markup/script language to wrap what is already a simple and expressive language, both for plots and (at least around here) analyses. If there are some spots that require too many lines of code to accomplish something really simple, then maybe we need to API additions. But in general, I think we have a format for specifying how to make a plot: python. Now, if we're taking the output from some monstrous application or set of scripts, it might be nice to get the commands that made the plot, like MayaVi 2 and its ability to record. However, at the end of the day what MayaVi creates is a python script, and I think that's more useful than any general markup since I can look at that file and figure out what's going on without learning anything new. Now, a matplotlib backend that writes out python code could be useful and cool, though it would only matter for the large applications/scripts. In fact, it's at the application level that such functionality would probably belong. My 0.02 anyways. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States. -- 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
On Mon, Mar 2, 2009 at 3:52 PM, Gael Varoquaux < gael.varoqu...@normalesup.org> wrote: > On Mon, Mar 02, 2009 at 01:49:38PM -0600, Ryan May wrote: > >Other than the automatic regeneration from latex, what you want sounds > >like what we already have: small python scripts. > > >In general, I'm completely amazed by how many people want to develop a > new > >markup/script language to wrap what is already a simple and expressive > >language, both for plots and (at least around here) analyses. If > there > >are some spots that require too many lines of code to accomplish > something > >really simple, then maybe we need to API additions. But in general, I > >think we have a format for specifying how to make a plot: python. > > Although I agree with you that reinventing an extra scripting layer is > often a bad solution to a problem which should simply be solved by having > a good scripting API in Python, I believe there is here a fundamental > misconception. > > Python is an imperative, Turing-complete. This is a very good thing for a > scripting language. For making a description of a static object as a > plot, this is not a good thing. For instance, if I want to make a plot, > save it, and later blow up all the fonts, I really don't want to be using > an imperative, Turing-complete language for the persistence model, as > static analysis of this persisted object is going to be next to > impossible. Same thing if I want to change colormaps, or just about > anything in my persisted object, for the same reason. > > A good rule for most software design is that the state of the > application, or of the object of interest, in our case the plot, should > be fully represented by a fully-static set of values, that I like to call > the model. Although this sounds like a tautology, this design rule is > more often broken than followed. For instance the status of an > application may be entirely dependent on its past, or the important state > variables may be hidden in places where you can't get hold of them (eg > the status of a GUI widget, or inside a generator). > > Having a very clean separation between your (fully-static) model, and the > logics around is a very important part of good application design, and I > believe I know this because I have so often made an error and violated > this rule :). > > If you have this static model, rather than an imperative language, then > you can have persistence. By the way, Mayavi2 achieves its code > generation by introspection on the model. The generated lines of code are > just a way of expressing the changes. > > Sorry for being fussy, I am just trying to pass on what I believe I am > learning painfully :). > Not at all. You made some good points. I hadn't really thought about the prospect of things changing in the core of the rest of the code. It was probably just a knee jerk reaction to something I hear a lot around here, regarding making a small language/configuration file for automating analyses *in python*. :) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States. -- 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
[matplotlib-devel] stixsans + mathtext.default : regular
Mike (or anyone else),
I've been using the following combination of settings:
mathtext.fontset : stixsans
mathtext.default : regular
I've noticed this crashes when I run scripts that include mathtext with
\rm{} commands. In fact, I get a massive traceback with this configuration
when running the mathtext_examples.py. Here's the last few lines:
File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyparsing.py",
line 950, in _parseNoCache
tokens = fn( instring, tokensStart, retTokens )
File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 2381, in symbol
return [Hlist( [self._make_space(0.2),
File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 2351, in _make_space
state.font, rcParams['mathtext.default'], 'm', state.fontsize,
state.dpi)
File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 446, in get_metrics
info = self._get_info(font, font_class, sym, fontsize, dpi)
File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 579, in _get_info
self._get_glyph(fontname, font_class, sym, fontsize)
File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 812, in _get_glyph
fontname, font_class, uniindex)
File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 919, in _map_virtual_font
mapping = mapping[font_class]
KeyError: 'regular'
Is this a supported configuration? I know that I personally like the look
of the text with these two settings. Thoughts?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
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
[matplotlib-devel] stixsans + mathtext.default : regular
On Wed, Mar 4, 2009 at 12:16 PM, Michael Droettboom wrote: > The 'regular' font stuff just isn't very well tested yet. I think I have a > fix in SVN now. Thanks for the quick fix, it got rid of my errors. However, I'm seeing a little more of the funky font baseline that you had fixed. My original script doesn't show any problem, but I've attached an image produced with the mathtext_demo.py. Notice the odd baseline for versus in the title and sin in the equation on the graph. Thoughts? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma <>-- 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] stixsans + mathtext.default : regular
That fixes it for me. Thanks a lot for the quick fixes! Ryan On Wed, Mar 4, 2009 at 2:53 PM, Michael Droettboom wrote: > I was rounding where I should have been truncating. I think this is fixed > now in SVN. > > Mike > > Ryan May wrote: > >> On Wed, Mar 4, 2009 at 12:16 PM, Michael Droettboom > md...@stsci.edu>> wrote: >> >>The 'regular' font stuff just isn't very well tested yet. I think >>I have a fix in SVN now. >> >> >> Thanks for the quick fix, it got rid of my errors. However, I'm seeing a >> little more of the funky font baseline that you had fixed. My original >> script doesn't show any problem, but I've attached an image produced with >> the mathtext_demo.py. Notice the odd baseline for versus in the title and >> sin in the equation on the graph. Thoughts? >> >> Ryan >> >> -- >> Ryan May >> Graduate Research Assistant >> School of Meteorology >> University of Oklahoma >> >> >> >> >> >> >> -- >> 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 >> >> > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States. -- 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] Patch for screenshot.rst - pie
Checked in on the branch. I'm seeing some merge conflicts on backend_cairo.py at the moment, so I'll let someone smarter than me merge to trunk. :) Good find. Ryan On Mon, Mar 23, 2009 at 1:01 PM, Sandro Tosi wrote: > Hi all, > I found a really nice typo: > > >>> > $ svn diff > Index: doc/users/screenshots.rst > === > --- doc/users/screenshots.rst (revision 7000) > +++ doc/users/screenshots.rst (working copy) > @@ -82,7 +82,7 @@ > == > > The :func:`~matplotlib.pyplot.pie` command > -uses a matlab(TM) compatible syntax to produce py charts. Optional > +uses a matlab(TM) compatible syntax to produce pie charts. Optional > features include auto-labeling the percentage of area, exploding one > or more wedges out from the center of the pie, and a shadow effect. > Take a close look at the attached code that produced this figure; nine > <<< > > Indeed pronunciation is the same, but the result is quite funny :) > > Cheers, > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > > > -- > 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 > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States. -- 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
[matplotlib-devel] QuadMesh method for setting grid
Hi, Does anyone know if there is a reason that quadmesh objects don't have a method for setting the geometry of the grid (i.e. the _coordinates attribute)? If there's not a reason, I'll add one. Now, this gets to a larger scale matplotlib API question. Should I add this as a property (either coordinates or verts) which would be pythonic? Or do I proliferate the use of getter and setter functions which is consistent? Or do I meet in the middle and use set_* and get_* to implement the property? Personally, I prefer the first one from purity, but recognize the need for a consistent API. Looking over the code base right now, it seems pretty organic, with a variety of all 3 of the approaches I mentioned being taken. Thoughts? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States. -- 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] Rasterized artists have wrong transform
On Thu, Apr 23, 2009 at 9:54 PM, Eric Bruning wrote: > On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee > wrote: > > The discussion about what to do with my patch fizzled. I created a > decorator that made mixed-mode switching a one-line change per artist > type. I also added get/set_rasterized and an _rasterized attribute to > the Artist base class. I've used it on and off for a few months now > with no noted bugs. > > If we don't like the decorator, we can just make a helper function > that is called at the beginning of every artist.draw() method. It's > not a very complicated modification. I think part of the problem with decorators before was that they came around in 2.4. I think we only support >=2.4 now, so this is no longer an issue. IMO, decorators seem like a sensible way to go. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] python-2.6 compatible matplotlib
On Thu, Apr 9, 2009 at 8:18 PM, Adam Mercer wrote:
> On Thu, Apr 9, 2009 at 13:46, Michael Droettboom wrote:
> > I did a lot of the initial fixes for Python 2.6 within the first week of
> the
> > 2.6.0 release -- they were mostly of the warning/style nature. I've been
> > running it on 2.6 on and off ever since, so it should be ok. But let us
> > know if you find anything.
>
> The only things I've seen so far are some deprecation warnings of the form:
>
>
> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/texmanager.py:55:
> DeprecationWarning: os.popen4 is deprecated. Use the subprocess
> module.
> stdin, stdout = os.popen4('dvipng -version')
>
I fixed this in r7063. It works for me on Linux, but the windows users
might want to double check that there isn't some weird subprocess
incompatibility. (tex_demo.py exercises this code.)
I also fixed the use of os.popen in cbook.report_memory(). Again, it works
for me here, but I'd love for others to check. There is no code for windows
with this one, but there is code for Macs.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] time series zoom/pan speedup
On Wed, May 13, 2009 at 3:07 PM, Eric Firing wrote: > > 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. > Works great for me here, nice work. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] attempting to enable buildbot
On Wed, May 20, 2009 at 3:48 AM, Andrew Straw wrote: > Andrew Straw wrote: > > Hi all, > > > > I am attempting to get a collective.buildbot service working on the > > Matplotlib trunk (branches could be enabled in the future) and James > > Evans' test suite. Right there are errors that prevent the test suite > > from even being run. I'll attempt to work through these, and you can > > check progress on the nascent buildbot display here: > > > > http://mpl-buildbot.code.astraw.com > > OK, the tests are now actually running, although most of the tests are > failing, which is worse than when I run the tests manually. :( > > If anyone wants to attempt to get the tests passing, the buildmaster > should be configured to trigger a build on an svn commit (it is supposed > to poll the svn server every 10 minutes). You can also trigger a build > attempt by clicking the "Force Build" button after following the builder > link in the Web GUI (I may have to disable this if the load gets too high.) > > Let's see if we can get all the tests passing and if this buildbot > approach looks sustainable -- if so, I'd like to get some more build > slaves into the mix and make MPL a good continuous integration citizen. > I don't think the buildbot master will take many resources on my server, > so I'm happy to host it there. I could put it under a different domain > name, too -- that may be desirable for marketing reasons. I'll see if I can get the buildbot running on my gentoo AMD64 box. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Tests and matplotlibrc
Hi, Is there any way to make the tests force a certain default set of rcparams? When I first ran the test suite just now, I got a lot of image comparison failures because I have my default font set to 10 in my matplotlibrc. Changing this eliminated 13 of my 16 failures. I really don't feel like having to edit my matplotlibrc every time I want to run the test suite. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 1:10 PM, Christopher Barker wrote: > > Darren Dale was working on a full-fledged package for adding units to > > numpy arrays called quantities > > (http://packages.python.org/quantities/user/tutorial.html), > > thanks for the reminder -- that does look like a really nice package. It > would be great to have a semi-standard for this stuff in the SciPy world > -- and certainly MPL compatible! > > > last I saw it stalled a little due to issues with subclassing ndarray. > > Darn. I hope I'll get a chance to delve into it soon. That's not to say that it's not currently functional, I just believe that some ufuncs don't work properly and that there are some corner cases that don't work, which I think is why Darren hasn't made an official release/announcement. Last time I played with it however, it was quite useful. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 11:38 AM, Ryan May wrote: > Hi, > > In looking over a test failure, I'm seeing some behavior that doesn't make > sense to me. It looks like data passed to a line object is being improperly > converted when units are involved. Here's a version of the code in the test > script, but modified to use the units in basic_units.py (in the > examples/units directory). You should be able to just drop this script into > the examples/units directory and run it: It looks like revision 7020 broke this in the process of adding units support for fill(). If I change the following lines (in the _xy_from_xy() function): if bx: x = self.axes.convert_xunits(x) if by: y = self.axes.convert_yunits(y) back to: if bx or by: return x, y, False the example I posted works and the test failure I was seeing is gone. Of course, this breaks fill() with unit-ed quantities. I'm getting a little over my head here in terms of tracing the flow of units, so I'd love to hear opinions on how to actually fix this. IMHO, we *really* need to standardize on how units are handled. In some cases the axes method handles converting units, but in this case, the Line2D object also registers for changes to axis units so it can update itself. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
On Wed, May 20, 2009 at 10:20 AM, John Hunter wrote: > On Wed, May 20, 2009 at 10:12 AM, Ryan May wrote: > > Hi, > > > > Is there any way to make the tests force a certain default set of > rcparams? > > When I first ran the test suite just now, I got a lot of image comparison > > failures because I have my default font set to 10 in my matplotlibrc. > > Changing this eliminated 13 of my 16 failures. I really don't feel like > > having to edit my matplotlibrc every time I want to run the test suite. > > > > the config system will pick up a matplotlibrc file in the current dir > if there is one, so perhaps we should drop the rc file assumed by the > tests into the dir from which they are run > > http://matplotlib.sourceforge.net/users/customizing.html > Thanks, I wasn't aware of that. It seems that if I just put an empty matplotlibrc file in that directory, it serves the same purpose. Can I just check that in (perhaps containing only a clarifying comment) so that it stays in sync with the current matplotlib defaults? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Wed, May 20, 2009 at 11:54 AM, Christopher Barker wrote: > Ryan May wrote: > > use the units in basic_units.py (in the examples/units directory). > > This looks like pretty cool stuff. However, I can't seem to find > matplotlib.units or basic_units.py in the online Sphinx docs. Is this a > doc bug, or intentional? > > There are units examples in the docs. matplotlib.units maintains the api for registering unit-ed quantities and various other nuts and bolts. It's another one of those modules whose docs hasn't been converted to sphinx yet, but it does have doc strings. However, it does not provide any units itself. basic_units.py is an example with just a few basic quantities to show off how support in matplotlib works, but is not itself all that useful. Darren Dale was working on a full-fledged package for adding units to numpy arrays called quantities ( http://packages.python.org/quantities/user/tutorial.html), that would (I think) work with some of this, but last I saw it stalled a little due to issues with subclassing ndarray. I haven't seen any other simple packages/modules that suppors general units for the simple goal of doing conversions for plotting. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Units issue
Hi, In looking over a test failure, I'm seeing some behavior that doesn't make sense to me. It looks like data passed to a line object is being improperly converted when units are involved. Here's a version of the code in the test script, but modified to use the units in basic_units.py (in the examples/units directory). You should be able to just drop this script into the examples/units directory and run it: from basic_units import secs, minutes, cm import matplotlib.pyplot as plt xdata = [ x*secs for x in range(10) ] ydata1 = [ (1.5*y - 0.5)*cm for y in range(10) ] ydata2 = [ (1.75*y - 1.0)*cm for y in range(10) ] fig = plt.figure() ax = plt.subplot( 111 ) l1, = ax.plot( xdata, ydata1, color='blue', xunits=secs ) l2, = ax.plot( xdata, ydata2, color='green', xunits=minutes ) print l1._xorig print l2._xorig print ax.lines plt.show() Based on the original test, it seems like this behavior should work (just rescale the x-axis without actually changing the plot). Am I missing something, or is this a real bug? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
On Wed, May 20, 2009 at 3:37 PM, John Hunter wrote: > On Wed, May 20, 2009 at 3:30 PM, James Evans > wrote: > > When I wrote the test stuff I had forgotten all about the matplotlibrc > stuff. I think it would make sense to just use a default > > (empty) matplotlibrc for the tests, this way we are always testing > against the defaults. If the defaults ever change it would also > > allow us to more easily catch those changes to note if there is any > negative consequences of the change. > > > OK, Ryan, go ahead with this. > Done. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mplot3d update
On Sun, Jun 14, 2009 at 7:13 PM, Gökhan SEVER wrote: > > Could you tell me how to import axes3d module from within Ipython? > from mpl_toolkits.mplot3d import axes3d Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] please add this example: legend translucent
On Tue, Jul 21, 2009 at 11:05 AM, Sandro Tosi wrote: > Hi all, > I really liked the snipped John wrote in a mail some time ago, so I > mock up a very simple example to set the alpha on a legend. > > It seems interesting to have such an example, also in the gallery. > > Since I don't have much time to dive into the sphinx example > generation and so, I just hand you the code, asking to include it. Done in 7279. And just FYI, if you're just adding an example to a directory that is already included in the examples gallery (I put this one in pylab_examples), there's nothing to be changed. It will be automatically included. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] curvelinear coordinate support in axes_grid and a possible refactoring of mpl.
I'll be there on the ground, though my flight leaves 1:50 on Sunday. We might also consider doing some discussions during the week, maybe a BoF? Ryan On Sat, Aug 1, 2009 at 11:41 AM, John Hunter wrote: > On Sat, Aug 1, 2009 at 1:39 AM, Andrew Straw wrote: > > > I'll be there, too. I think an MPL sprint would be very good. > > Great -- give that we have JJ (remotely), you and me confirmed, two > obvious topics to work on are: > > * buildbot : JDH & Andrew > > * integrating JJ's curvilinear ticking w/ Andrew's spines > > I'm up for anything else that people want to work on, but at least > we'll have the right people in the room, if only virtually, for these > topics. Anyone else planning on attending on-ground or on-line? > > JDH > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] example data in example code
On Wed, Aug 5, 2009 at 7:11 AM, John Hunter wrote:
> >>> import matplotlib.mlab as mlab
> >>> import matplotlib.cbook as cbook
> >>> r = mlab.csv2rec( cbook.get_mpl_data('testdata.csv') )
> Traceback (most recent call last):
> File "", line 1, in
> File "/Users/jdhunter/dev/lib/python2.6/site-packages/matplotlib/mlab.py",
> line 2108, in csv2rec
>fh = cbook.to_filehandle(fname)
> File
> "/Users/jdhunter/dev/lib/python2.6/site-packages/matplotlib/cbook.py",
> line 339, in to_filehandle
>raise ValueError('fname must be a string or file handle')
> ValueError: fname must be a string or file handle
>
> Perhaps we could return a plain file handle pointing to the cached data?
Another option is to use StringIO to create a new file-like object after
read()-ing in all the data.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever wrote: > Shouldn't colorbar_doc name be hidden from users? It doesn't look like the > rest other function documentation in pyplot.py file. > > In [10]: color > colorbar colorbar_doc colormaps colors Good catch. Fixed in 7406. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, OK, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 1:55 PM, John Hunter wrote: > On Thu, Aug 6, 2009 at 1:50 PM, Ryan May wrote: > > > > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever > wrote: > >> > >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like > the > >> rest other function documentation in pyplot.py file. > >> > >> In [10]: color > >> colorbar colorbar_doc colormaps colors > > > > Good catch. Fixed in 7406. > > Just reading this, it looks like you missed the import > matplotlib.colorbar part, no? Or am I missing something? On my machine, the import didn't seem to be necessary. matplotlib.colorbar is available just with: import matplotlib Would it be better to explicitly import matplotlib.colorbar anyways? > When possible, could you make bugfixes to the branch and merge to the > trunk? I know this is a bit of a hassle, but we often live on a > release branch for several bug fix release cycles, so it is nice to > put the simple fixes there > > http://matplotlib.sourceforge.net/devel/coding_guide.html > Yeah, my bad. I just remembered after committing to trunk and was working on checking out the new branch and applying there when you made your fix. So what n ow? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 2:03 PM, John Hunter wrote: > On Thu, Aug 6, 2009 at 1:59 PM, Ryan May wrote: > > On Thu, Aug 6, 2009 at 1:55 PM, John Hunter wrote: > >> > >> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May wrote: > >> > > >> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever > >> > wrote: > >> >> > >> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look > like > >> >> the > >> >> rest other function documentation in pyplot.py file. > >> >> > >> >> In [10]: color > >> >> colorbar colorbar_doc colormaps colors > >> > > >> > Good catch. Fixed in 7406. > >> > >> Just reading this, it looks like you missed the import > >> matplotlib.colorbar part, no? Or am I missing something? > > > > On my machine, the import didn't seem to be necessary. > matplotlib.colorbar > > is available just with: > > > > import matplotlib > > Strange... > > j> python > Python 2.4.5 (#4, Apr 12 2008, 09:09:16) > [GCC 3.4.1] on sunos5 > Type "help", "copyright", "credits" or "license" for more information. > >>> import matplotlib > >>> matplotlib.colorbar > Traceback (most recent call last): >File "", line 1, in ? > AttributeError: 'module' object has no attribute 'colorbar' > >>> matplotlib.__version__ > '1.0.svn' > Stranger still (or it is to me): Python 2.6.2 (r262:71600, Aug 3 2009, 10:34:14) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import matplotlib >>> matplotlib.colorbar Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'colorbar' >>> from matplotlib import pyplot >>> matplotlib.colorbar > > > Would it be better to explicitly import matplotlib.colorbar anyways? > > Yes > Clearly. >> When possible, could you make bugfixes to the branch and merge to the >> trunk? I know this is a bit of a hassle, but we often live on a >> release branch for several bug fix release cycles, so it is nice to >> put the simple fixes there >> >> http://matplotlib.sourceforge.net/devel/coding_guide.html > > Yeah, my bad. I just remembered after committing to trunk and was working > on checking out the new branch and applying there when you made your fix. > So what n ow? Ahh, now the pain begins. I believe the easiest path is to put the > change in the branch, svn commit, go over to the trunk, svnmerge, > resolve any conflicts and commit. Now wasn't that easy? I remember doing this before now. I don't think there will be any problems with making the changes outside of svnmerge. The alternative is to change trunk back and use svnmerge. I don't mind doing either. Got a preference on which way to handle colorbar_doc? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[7506] branches/v0_99_maint/lib/matplotlib/lines.py
On Wed, Aug 19, 2009 at 5:35 PM, Darren Dale wrote: > Ryan, > > I don't think these calls should be removed. Would you convert them to > asanyarray() instead? That will preserve the masked arrays. > Darren, I couldn't find a case where those calls weren't already duplicated when set_data() was called. According to the code, np.asarray() will be called if ma.isMaskedArray() returns false. Am I missing something? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merge tracking of v0_99_maint broken?
On Sat, Aug 22, 2009 at 3:01 AM, Jouni K. Seppänen wrote: > I fixed some doc typos on the v0_99_maint branch and was going to merge > the fixes to the trunk, but it didn't work: > > % svnmerge.py avail -S v0_99_maint > svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous > substring of a repository path, nor a working directory > % svnmerge.py avail > svnmerge: multiple sources found. Explicit source argument (-S/--source) > required. > The merge sources available are: > /branches/mathtex > /branches/v0_91_maint > /branches/v0_98_5_maint > > I'm pretty sure that this used to work. What has changed in the repository? Same behavior here. I had been having trouble doing any merges, but never had tracked it down. I guess this is related. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Los Angeles, California, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merge tracking of v0_99_maint broken?
Works for me now, but I can't give it a good test until I have actual changes to merge. Ryan On Mon, Aug 24, 2009 at 7:53 AM, Michael Droettboom wrote: > Just catching up with mail now. Is this still a problem for either Ryan or > Jouni? It seems to work for me as well. All I can suggest is making sure > the working copy of the trunk is fully updated (but I'm sure you've thought > of that already). > > > svnmerge avail > svnmerge: multiple sources found. Explicit source argument (-S/--source) > required. > The merge sources available are: > /branches/v0_99_maint > /branches/mathtex > /branches/v0_98_5_maint > > > John Hunter wrote: > >> On Sat, Aug 22, 2009 at 3:24 AM, Ryan May wrote: >> >> >> >>> Same behavior here. I had been having trouble doing any merges, but never >>> had tracked it down. I guess this is related. >>> >>> >> >> The following just worked for me >> >> svnmerge.py merge -Sv0_99_maint >> >> managed to merge almost 15 commits from the branch to the trunk w/ no >> conflicts despite all the docstring changes, etc. Nice! >> >> JDH >> >> >> -- >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment - and >> focus on what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merge tracking of v0_99_maint broken?
On Sat, Aug 22, 2009 at 3:24 AM, Ryan May wrote: > > > On Sat, Aug 22, 2009 at 3:01 AM, Jouni K. Seppänen wrote: > >> I fixed some doc typos on the v0_99_maint branch and was going to merge >> the fixes to the trunk, but it didn't work: >> >> % svnmerge.py avail -S v0_99_maint >> svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous >> substring of a repository path, nor a working directory >> % svnmerge.py avail >> svnmerge: multiple sources found. Explicit source argument (-S/--source) >> required. >> The merge sources available are: >> /branches/mathtex >> /branches/v0_91_maint >> /branches/v0_98_5_maint >> >> I'm pretty sure that this used to work. What has changed in the >> repository? > > > Same behavior here. I had been having trouble doing any merges, but never > had tracked it down. I guess this is related. > Just to follow up and put in the archives for anyone searching. It looks like the svnmerge.py script was updated at some point since the last time I downloaded it (probably to keep in sync with changes in SVN itself). I was having problems merging today, but updating to this latest version solved all the problems. Just FYI. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] proposed change to colors.py
On Wed, Sep 30, 2009 at 7:47 PM, Dr. Phillip M. Feldman wrote: > > I've added three function defs at the end of colors.py. The revised > colors.py is attached. (I haven't been able to figure out how to make SVN > save the diff to a file). http://www.nabble.com/file/p25691605/colors.py > colors.py svn diff > filename Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] AutoDateFormatter/AutoDateLocator
Hi, Anybody know what the status of AutoDateLocator/AutoDateFormatter in matplotlib.dates are? They work and seem reasonably well documented. However, they do not show up in our online docs: http://matplotlib.sourceforge.net/api/dates_api.html They show up in the inheritance graph, but are not mentioned elsewhere in the page and in fact have no link from the image. They're also not present in the __all__ in the dates module. If this is just an oversight, what do I need to do to make the classes show up in the docs? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AutoDateFormatter/AutoDateLocator
On Wed, Oct 14, 2009 at 3:08 PM, John Hunter wrote: > Most likely this is just due to an oversight in the __all__ so just > add it there in the branch and it should get picked up next time we > build the docs Done. I also added them to the module-level docstring. Along these lines, I was trying to make use of AutoDateLocator, and as far as I can tell, there's no way to customize its behavior right now. So when trying to use this for doing major and minor ticks, there's no difference. It looks like in the get_locator() method of AutoDateLocator, numticks is used to control what types of ticking (yearly, monthly) is used. Would it make sense to have this as an attribute of self so that the user can tweak it? Or maybe go to: 1) minticks (instead of numticks) which specifies a minimum number of ticks that are desired, to select yearly, monthly, etc. 2) maxticks, which specifies a maximum number of ticks, which can be used to calculate the interval (every N'th month). Right now, the rules for selecting this are hard coded. I'm interested in hacking this up. But since you wrote the code, I want to make sure that going this direction makes sense to you. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AutoDateFormatter/AutoDateLocator
On Wed, Oct 14, 2009 at 3:59 PM, John Hunter wrote: > I don't have a strong opinion on this -- making it more customizable > is a good thing -- this came up at scipy as well, where I contributed > a patch to make the AutoDateFormatter a little more customizable by > exposing a scaled dictionary mapping the scale to a format string. As > long as the extension to the AutoDateLocator preserves the core > functionality, I say have at it. Here's a patch that implements the ideas I have. To the best of my ability, it preserves the same behavior as before, it just opens it up to configuration by the user instead of being hard-coded. It adds: 1) Configuring the minimum number of ticks, which determines whether to do yearly, monthly, etc. ticking 2) Configuring the maximum number of ticks, which is used to select what interval of ticking to use. This is actually done on a per-frequency basis. This helps to keep in line with previous behavior and is useful for keeping tick spacing in line with what the label would be for a given frequency. The user can also simply pass an integer that gives the maximum for all frequencies. 3) A dictionary of intervals corresponding to each frequency. This keeps the previous functionality of appropriate intervals for each frequency, but also opens it up to user configuration. 4) Optional ticking on multiples of the interval. Previously, if you were ticking with, say, 10 minute intervals, and the range happened to start at 33 minutes, you'd get ticks at 33, 43, 53, etc. With this flag set, the ticks instead end up at 40, 50, 0, 10, etc. I'd appreciate anyone looking this over for any glaring problems before I check this in. I've done my best to preserve old functionality, though I'm still working on getting the unit tests to run here. It also passes my own testing here when I fiddle with the new knobs that have been exposed. My one question is: how important is keeping API compatibility? The constructor tries to follow the convention of the rest of the module (tz is last or nearly so), but this breaks compatibility (where tz was the only argument). Also, to me, it would be nice to tick multiples of the interval by default. Thoughts? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States autodatelocator.diff Description: Binary data -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AutoDateFormatter/AutoDateLocator
[Putting this back on devel] > Have you checked scikits.timeseries.lib.plotlib ? We provide some functions > that adapt the ticks to the frequency of you base series, but also according > to the range of the axes. For example, if you work with a 100-y daily > timeseries, you'll have major ticks every 5 years if you plot the whole > series, every month if you plot or zoom on one year only, etc. > it may be worthwhile to give it a try. I'd be happy to help adapting our > code to remove the dependency on scikits.timeseries if needed... No, I hadn't seen this. And argh!, I wish I had *before* I had coded up something that met my needs. I hate to see a duplication of effort and would love to see more of your matplotlib extensions moved into matplotlib itself. Having said that, I now have a patch that accomplishes what I want and (now) keeps our unit tests passing. I've also pretty much expended all the time I have for matplotlib development in the short term. So if one of the other devs is interested, awesome. But for me at this point, I can't go study yet more code when I have something IMO ready to check in. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Persistent Matplotlib Figures
On Wed, Dec 16, 2009 at 4:45 PM, Joey Wilson wrote: > Let me say why I think this feature is so essential. Anyone who is in > research or academia knows that figures often need to be edited when a > publication comes back from peer review. It's already happened to me many > times, and I've learned that I absolutely have to save my figures for later > editing to save myself a lot of time. Some people have argued that a script > that generates the plots/figures should be saved, and that if you need to > edit the figure, just re-run the script. The problem with this argument is > that scientific plots often take hours, days, or even weeks of computation > to generate. For example, generating a bit-error-rate curve in > communications takes days. Therefore, always re-running from a script is > just not practical. Ignoring the issue of having saved matplotlib figures, I'd argue you should separate the parts of the code that do computation from those that do plotting into separate scripts. Is there anything keeping you from saving all of the results from the computation into (for instance) a NetCDF file? Then the plotting script can just read in the file and do the plotting. This is exactly how my workflow is set up. I'd be happy to address any concerns you see with doing things this way. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Persistent Matplotlib Figures
On Sat, Dec 19, 2009 at 2:03 PM, Eric Firing wrote: > Exactly. I *strongly* oppose any move in this direction. It would be > enabling bad workflow strategy on the part of users, providing no > benefit that cannot be achieved better with a good workflow strategy, > and adding complexity. We have enough of that already. We need to > think about how to clean up mpl and make it easier to maintain and > improve, not clutter it with ever more complexity. +1 That pretty much sums up how I feel. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] zorder for contours
Hi, I was shown a bug today by a colleague, demonstrated by the following example: import numpy as np import matplotlib.pyplot as plt a = np.zeros([10, 10]) a[2:6,3:8] = 1 ls = plt.contour(a, 1, colors='r', linewidths=3, zorder=5) print ls.collections[0]l.get_zorder() rect = plt.Rectangle([2, 3], 5, 4, zorder=3) plt.gca().add_artist(rect) plt.show() Unless I completely misunderstand zorder, the contour should be *on top* of the rectangle. Also note that printing the zorder for the contour's collection (a LineCollection object) gives a value of 2, even though the call to contour() specified 5 for the zorder. Looking over the code for contour, the zorder is never mentioned. The reason the LineCollection ends up with a value of 2 is that this is the default for a LineCollection. My question is: is there any reason *not* to use the passed in zorder for contours/filled contours? If this is the proper fix, I'll check it in myself, I just wanted to make sure I'm not missing some special case here. As an aside, this is yet another example where it would be nice to know that a keyword argument was not being used. If there's no objections, I'd be willing to change ContourSet to pop arguments off of **kwargs so that it can see if some aren't used and throw an exception if not all are used. On the other hand, this could break existing code that are passing extra/useless kwargs, so maybe a warning would be better? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] zorder for contours
On Thu, Jan 28, 2010 at 1:03 PM, Eric Firing wrote: > Ryan May wrote: >> Unless I completely misunderstand zorder, the contour should be *on >> top* of the rectangle. Also note that printing the zorder for the >> contour's collection (a LineCollection object) gives a value of 2, >> even though the call to contour() specified 5 for the zorder. Looking >> over the code for contour, the zorder is never mentioned. The reason >> the LineCollection ends up with a value of 2 is that this is the >> default for a LineCollection. My question is: is there any reason >> *not* to use the passed in zorder for contours/filled contours? If >> this is the proper fix, I'll check it in myself, I just wanted to make >> sure I'm not missing some special case here. > > Ryan, > > Certainly it makes sense to support zorder in some fashion, and the simple > way is as you suggest, with one value per call to contour. It may be best > to stop there--but I can imagine the next complaint being, "why doesn't > zorder support a sequence?", and then things get quite a bit more > complicated. > > Anyway, go ahead and put in the simple zorder support; I don't see any > downside to it. Will do shortly. >> As an aside, this is yet another example where it would be nice to >> know that a keyword argument was not being used. If there's no >> objections, I'd be willing to change ContourSet to pop arguments off >> of **kwargs so that it can see if some aren't used and throw an >> exception if not all are used. On the other hand, this could break >> existing code that are passing extra/useless kwargs, so maybe a >> warning would be better? > > Careful. Keeping track of which kwargs are used, and making sure they are > always popped, and don't need to remain in the kwargs dictionary, could get > tricky. I just added support for the units-related kwargs. I think what > you suggest will work, and I agree that some error-trapping for kwarg > accidents (misspelling kwargs, or otherwise trying to use a kwarg that has > no effect) is a good idea. > > This sounds like an area where some general mpl coding guidelines, and quite > a bit of work to implement them, would be good. Agreed. After I wrote this, I thought about it some more, and it's not something you can really do piecemeal due to passing off to base classes and what not. It's a big usability wart however, like when accidentally using 'linewidth' instead of 'linewidths' for calling contour. I'll just leave this as a future improvement. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] registerable backend and minor refactoring of backend-ps
On Wed, Feb 3, 2010 at 2:01 PM, Jae-Joon Lee wrote:
> Dear all,
>
> I just committed a small change that enables a user to register a
> custom backend that will be used with "savefig".
> For example,
>
> import matplotlib.backend_bases
> from matplotlib.backends.backend_ps import FigureCanvasPS, RendererPS
>
> class RendererPSCustom(RendererPS):
> def draw_path(self, gc, path, transform, rgbFace=None):
> print "custom draw path"
> RendererPS.draw_path(self, gc, path, transform, rgbFace)
>
> class FigureCanvasPSCustom(FigureCanvasPS):
> _renderer_class = RendererPSCustom
>
> def print_eps_custom(self, outfile, *args, **kwargs):
> print "Using Custome backend"
> return self._print_ps(outfile, 'eps', *args, **kwargs)
>
>
> matplotlib.backend_bases.register_backend("eps_custom", FigureCanvasPSCustom)
>
> plt.plot([1,2,3])
> plt.savefig("a.eps", format="eps_custom") # this will save the file
> using backend_ps_cmyk
>
>
> The api may need some cleanups or modifications, and any suggestion
> will be welcomed.
>
> Also committed is a some refactoring of ps backend but the change
> should be quite transparent.
I like it. Out of curiosity, is there anything that this approach
brings (other than simplicity) that isn't already covered by the
support for:
matplotlib.use('module:://')
?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Contouring unstructured triangular grids
On Mon, Mar 15, 2010 at 12:37 PM, Ian Thomas wrote: > Ben Axelrod wrote: >> I am a little unclear on what this is and what it is used for. > > It is used to generate contour plots for data that is defined on > unstructured triangular grids. Currently mpl supports generating > contour plots on regular rectangular grids; if you have an > unstructured grid you have to interpolate it onto a regular grid > before contouring it. Contouring directly from the triangular grid > avoids the need for this interpolation. Well then the meteorologist in me is an overwhelmingly +1 on having such functionality available. Are you looking at making it possible to construct a triangulation from the delaunay triangulation that is used by griddata? (Sorry, I didn't follow the thread that closely.) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 12:20 PM, Eric Firing wrote: > Fernando Perez wrote: >> While chatting today with John, he suggested that a better api for >> this would be to return an *array* of supblots, so that one could >> index them with a[i,j] for the plot in row i, column j. I've >> implemented this already, but before committing it, I have one doubt: >> what to do when nrows==ncols==1, the single subplot case? I'm inclined >> to return only the subplot instead of a one-element array, so that one >> can say >> >> f, a = fig_subplot() >> a.plot(...) >> >> instead of having to do >> >> f, a = fig_subplot() >> a[0].plot(...) >> >> But this means the return value of the function would be: >> - fig, axis if nr=nc=1 >> - fig, axis_array in all other cases. > > The behavior one wants depends on whether one is calling fig_subplot in > a program in which the number of subplots could range from 0 to n, or > whether the call is being made with the number of subplots hardwired. > The latter may be most common, but the former seems like an important > use case. I suggest providing a kwarg, e.g. "squeeze=True" as the > default, to eliminate zero-size-dimensions from the array, and False for > the case where nrows and/or ncols could be zero but one wants to be able > to iterate over the resulting array regardless. +1 This feels like a clean solution to the problem. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] gtk.Tooltips() deprecated
Hi, I just started running PyGTK 2.16 and noticed the following everytime I run a matplotlib script: /home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621: DeprecationWarning: Use the new widget gtk.Tooltip self.tooltips = gtk.Tooltips() Right now, we support >= PyGTK 2.2. The new, non-deperecated API (gtk.Tooltip) was added in 2.12 (and the gtk.Tooltips API was deprecated at this time). So, my question is how do we want to handle this? Do we want to create a helper method that hides the logic to determine what method to use (there doesn't look to be an easy way to support both)? Or do we just bump our required version? 2.12.0 was released in fall 2007. I'm not sure what versions are supplied with the various distros. Thoughts? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] gtk.Tooltips() deprecated
On Sat, Mar 20, 2010 at 5:53 PM, Eric Firing wrote: > Ryan May wrote: >> >> Hi, >> >> I just started running PyGTK 2.16 and noticed the following everytime >> I run a matplotlib script: >> >> >> /home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621: >> DeprecationWarning: Use the new widget gtk.Tooltip >> self.tooltips = gtk.Tooltips() >> >> Right now, we support >= PyGTK 2.2. The new, non-deperecated API > > pygtk_version_required = (2,4,0) Ok. I got my number from our install docs: http://matplotlib.sourceforge.net/users/installing.html#build-requirements There it says PyGTK 2.2 as a (optional) build dependency. >> (gtk.Tooltip) was added in 2.12 (and the gtk.Tooltips API was >> deprecated at this time). So, my question is how do we want to handle >> this? Do we want to create a helper method that hides the logic to >> determine what method to use (there doesn't look to be an easy way to >> support both)? Or do we just bump our required version? 2.12.0 was >> released in fall 2007. I'm not sure what versions are supplied with >> the various distros. >> > > My sense is that RHEL4 is still common, and will be supported by RH through > early 2012 (http://www.redhat.com/security/updates/errata/). It is way back > at pygtk 2.4. > > I just now committed to svn a little bit of conditional code to support the > new api along with the old one. Minimal testing on my system (new api) > looks OK; more testing with new API, and testing with pygtk < 2.12, are > needed. The changes are extremely simple, but I might have overlooked > something. Awesome, works great here, thanks. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee wrote: > On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing wrote: >>> Or, how about we make axes an context manager. >> >> This would require dropping support for Python 2.4. > > I don't think making the Axes a context manager means dropping python > 2.4 support > (note that I'm not saying we use "with" statement in the mpl source). > Everything should work fine in python 2.4 (please correct me if I'm wrong). > It just gives a user a choice. If a user runs his/her script with > python 2.5 and higher, he/she has an option to use an axes as an > context manager. Of course, if he/she want his/her own code supported > in python 2.4, he/she should not use "with" statement. I see what you're saying. While the use of the language syntax is restricted to 2.5 and above, we could add the needed methods to the Axes object, which would just be ignored by python <2.5. That's not a bad idea. I'm +1 on the idea. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Problem with Quiver+Basemap
Eric, I just hit a problem with using quiver with Basemap when when angles='xy'. Because Basemap's x,y units are in meters, you end up with angles that are quantized due to floating point truncation (3. + 0.001*u = 3.). Changing to angles='uv' fixes the problem, but it probably should be automatically scaled, as noted in the comments: elif self.angles == 'xy' or self.scale_units == 'xy': # We could refine this by calculating eps based on # the magnitude of U, V relative to that of X, Y, # to ensure we are always making small shifts in X, Y. I managed to fix the problem locally by setting: angles, lengths = self._angles_lengths(U, V, eps=0.0001 * self.XY.max()) but I'm not sure if you would want a different fix. If you're happy with this fix, I'll go ahead an check in. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Quiver+Basemap
Ping. Not sure if you missed it first time around or are just that busy. Ryan On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: > Eric, > > I just hit a problem with using quiver with Basemap when when > angles='xy'. Because Basemap's x,y units are in meters, you end up > with angles that are quantized due to floating point truncation > (3. + 0.001*u = 3.). Changing to angles='uv' fixes the > problem, but it probably should be automatically scaled, as noted in > the comments: > > elif self.angles == 'xy' or self.scale_units == 'xy': > # We could refine this by calculating eps based on > # the magnitude of U, V relative to that of X, Y, > # to ensure we are always making small shifts in X, Y. > > I managed to fix the problem locally by setting: > > angles, lengths = self._angles_lengths(U, V, eps=0.0001 * > self.XY.max()) > > but I'm not sure if you would want a different fix. If you're happy > with this fix, I'll go ahead an check in. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Animation Class
Hi, A "quick afternoon hack" developed into what seems to me to be a useful and simple framework for doing animations in matplotlib, utilizing the timed idle event in GTK (currently). It also supports writing out a movie file using ffmpeg. Particular issues: 1) Supporting backends other than gtk. I'm not sure how to mimic the behavior of gobject.idle_add() with Qt and Wx. Also, I'm not sure if code to mimic this belongs with the animation class or should be kept with the backend to allow use elsewhere. 2) The FuncAnimation class is written to allow an easy way to make a more "procedural" animation, such as one that displays data while reading from a live source, or draws a line repeatedly adding the points. My question is whether the interface makes sense or if it's even worthwhile since it's just saving a couple lines of code that would be necessary to just to a straightforward Animation subclass. The code still needs quite a bit of clean up and thought to make sure that the classes are broken up into the proper parts, as well as documentation, but I wanted to see if this seems like a good way to go to add easy animation support to matplotlib. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma animation.py Description: Binary data -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Quiver+Basemap
On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing wrote: >> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: >>> I just hit a problem with using quiver with Basemap when when >>> angles='xy'. Because Basemap's x,y units are in meters, you end up >>> with angles that are quantized due to floating point truncation >>> (3. + 0.001*u = 3.). Changing to angles='uv' fixes the >>> problem, but it probably should be automatically scaled, as noted in >>> the comments: >>> >>> elif self.angles == 'xy' or self.scale_units == 'xy': >>> # We could refine this by calculating eps based on >>> # the magnitude of U, V relative to that of X, Y, >>> # to ensure we are always making small shifts in X, Y. >>> >>> I managed to fix the problem locally by setting: >>> >>> angles, lengths = self._angles_lengths(U, V, eps=0.0001 * >>> self.XY.max()) >>> > > I don't think this will work in all cases. For example, there could be a > single arrow at (0,0). Good point. > Instead of self.XY.max(), how about abs(self.ax.dataLim.width)? Wouldn't this have problems if we zoom in sufficiently that the width is much less than magnitude of the values? Not exactly sure what data set would sensibly yield this, so I'm not sure if we should worry about it. If we do care, we could just put a minimum bound on eps: eps=max(1e-8, 0.0001 * self.XY.max()) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Quiver+Basemap
On Fri, Apr 2, 2010 at 11:42 AM, Eric Firing wrote: > Ryan May wrote: >> >> On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing wrote: >>>> >>>> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: >>>>> >>>>> I just hit a problem with using quiver with Basemap when when >>>>> angles='xy'. Because Basemap's x,y units are in meters, you end up >>>>> with angles that are quantized due to floating point truncation >>>>> (3. + 0.001*u = 3.). Changing to angles='uv' fixes the >>>>> problem, but it probably should be automatically scaled, as noted in >>>>> the comments: >>>>> >>>>> elif self.angles == 'xy' or self.scale_units == 'xy': >>>>> # We could refine this by calculating eps based on >>>>> # the magnitude of U, V relative to that of X, Y, >>>>> # to ensure we are always making small shifts in X, Y. >>>>> >>>>> I managed to fix the problem locally by setting: >>>>> >>>>> angles, lengths = self._angles_lengths(U, V, eps=0.0001 * >>>>> self.XY.max()) >>>>> >>> I don't think this will work in all cases. For example, there could be a >>> single arrow at (0,0). >> >> Good point. >> >>> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)? >> >> Wouldn't this have problems if we zoom in sufficiently that the width >> is much less than magnitude of the values? Not exactly sure what data >> set would sensibly yield this, so I'm not sure if we should worry >> about it. >> >> If we do care, we could just put a minimum bound on eps: >> >> eps=max(1e-8, 0.0001 * self.XY.max()) > > I don't like taking the max of a potentially large array every time; and one > needs max absolute value in any case. I think the following is better: > > eps = np.abs(self.ax.dataLim.extents).max() * 0.001 I hadn't thought about performance. I think that's more important than any worries about bounds being disproportionately smaller. I'll check this in. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] getting legend loc
On Fri, Apr 9, 2010 at 12:16 AM, Peter Butterworth wrote:
> Hi,
>
> I'm having trouble getting some properties that are easily set :
>
>
> leg=legend(loc=0)
> is there a way to retrieve the legend location ?
leg._loc
I'm not sure why it's given a leading '_' to signal a private
variable, since it's implemented as a property. I'd probably still use
it.
> In a similar vein :
> axis('scaled')
> is there a way to retrieve the "scaled" property ?
Not really, since scaled isn't stored, but is merely a helper for
self.set_aspect('equal', adjustable='box', anchor='C')
self.set_autoscale_on(False)
You can get all of these properties individually:
ax = plt.gca()
ax.get_aspect()
ax.get_adjustable()
ax.get_anchor()
ax.get_autoscale_on()
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Close events
Hi, Does anyone know if there's a matplotlib event that fires when a figure window is closed? I can't seem to find one. If there's not one, any I shouldn't add one? I need to stop my animation timers when the figure is closed. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Close events
I went ahead an implemented the close events. These work for me on the following backends that I was able to test: TkAgg, Wx/WxAgg, Qt4Agg, Gtk/GtkAgg. I can't test Cocoa or PyQt3, so I didn't implement. All that is needed is to add a call (preferably on a FigureCanvasBase subclass) that calls the FigureCanvasBase.close_event(). Ryan On Thu, Apr 15, 2010 at 5:18 PM, Ryan May wrote: > Hi, > > Does anyone know if there's a matplotlib event that fires when a > figure window is closed? I can't seem to find one. > > If there's not one, any I shouldn't add one? I need to stop my > animation timers when the figure is closed. > > Ryan > > -- > Ryan May > Graduate Research Assistant > School of Meteorology > University of Oklahoma > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] margins, locator_params, formatter offset
On Tue, Apr 20, 2010 at 2:46 PM, Eric Firing wrote: > During the last few days I have added some convenience methods and > pyplot functions. Please review them to see whether names, APIs, or > functionality should be changed. The general motivation is that > formatters and locators are a bit obscure and hidden in the object > hierarchy, so I wanted to make it easier for people to make simple > changes. In addition, in autoscaling, one might want an option that is > almost "tight" but leaves a little margin, so symbols at the edge don't > get sliced off, for example. No comments other than these seem like really good changes to reduce the barrier for the users. Nice work! Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New generic timers
Hi, Continuing the spurt of (independent) development that's been going on lately, I committed support for generic timers. There's a base class TimerBase that provides the basic API for a timer (start, stop, controlling the interval, adding callbacks, etc.), and each GUI backend subclasses this to wrap around their toolkit's native timer classes. I added a method to each backend's canvas object to facilitate creating a backend-specific timer without having to know what backend was running. So far, I'm quite happy with how it turned out, but I'm curious to hear feedback. Specifically: 1) Anything missing in the basic TimerBase API? 2) Is adding new_timer() the canvas a good way to go? I needed a way to get to backend-specific classes without actually knowing what backend I'm running (and without calling _pylab_helpers or pyplot.get_backend()). Figure.canvas seemed to be just about the only way to go about this. It also makes some sense, because in the case of Wx and Tk, an actual widget is required to hook up the timer. I've added an example in: examples/event_handling/timers.py This just makes a plot with a title that is continually (100 ms) updating with the current time including milliseconds. It does a good job of showing the ease with which such interactive updates can be done now. In fact, this could probably be used to update and simplify the existing animation demos. However, I'm already finishing up a more complete animation framework based on this, which should simplify some of those even further. At that point, I'll probably update the examples. I still need to add some documentation to the event handling section of the User's Guide, though this might better belong with a section on animation's that I promise to write once the new framework is checked in. Also, I didn't add a TimerBase implementation for the CocoaAgg backend. I have no idea about that toolkit, so I'd appreciate some help there so we can have an implementation for all of the active GUI toolkits. Any feedback is appreciated. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New generic timers
On Tue, Apr 20, 2010 at 4:02 PM, John Hunter wrote: > On Tue, Apr 20, 2010 at 3:26 PM, Ryan May wrote: >> Hi, >> >> Continuing the spurt of (independent) development that's been going on >> lately, I committed support for generic timers. There's a base class >> TimerBase that provides the basic API for a timer (start, stop, >> controlling the interval, adding callbacks, etc.), and each GUI >> backend subclasses this to wrap around their toolkit's native timer >> classes. I added a method to each backend's canvas object to >> facilitate creating a backend-specific timer without having to know >> what backend was running. So far, I'm quite happy with how it turned >> out, but I'm curious to hear feedback. Specifically: >> >> 1) Anything missing in the basic TimerBase API? > > You might want to pass the argument as keywords on from the > add_timerr, so you can do > > timer = fig.canvas.new_timer(interval=100, callbacks=[(update_title, ax)]) > > or something like that... Or support a single callback object. I'll look at that. I had been trying to keep the constructor simple, but those extra calls to get it fully initialized aren't in line with the rest of the matplotlib API (been doing too much Qt!). I'll probably make it callbacks=[(func, args, kwargs)], as I think I'm going to go back and add **kwargs anyways. > Speaking of callbacks, do you know about cbook.CallbackRegistry? It > would be nice to standardize on a single interface for handling > callbacks so users and developers can manipulate it directly. We use > this elsewhere in support of mpl event handling and the toolbar so it > is fairly robust. Can you further describe what you see here? I looked at this before, and it seems more valuable if you have a variety of signals. I would have 1. I *could* add a time_event to the list of events in the canvas and use the canvas-level callback registry, but that would actually seem to undo the encapsulation of the timer object. Plus that would only allow one timer attached to a canvas. More importantly, the CallbackRegistry, when processing signals, calls each callback with the same arguments, so there's no way to specify per callback information. Maybe I'm just being dense, so please correct me if I'm missing your vision here. I'd always love to reuse existing code and reduce my "opportunity" to contribute bugs to matplotlib. :) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imsave, image size
On Thu, May 6, 2010 at 1:40 PM, Michael Droettboom wrote: > It looks like the conversion from dots-per-inch (matplotlib's internal > representation) to dots-per-meter (the unit defined in the PNG standard) > was bogus. This should be fixed in SVN r8298. Are you sure that's right? This doesn't look like a conversion to dots per meter: size_t dots_per_meter = dpi * 2.54 * 100.0 To my eyes, unit-wise, that looks like dots/inch * cm/inch * cm/m = dots * m / inch**2. The original looks correct in regard to units to me: size_t dots_per_meter = dpi * 100 * (1 / 2.54) -> dots/inch * cm/m * inch/cm -> dots/m Am I missing something? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] axes.set_xlim has wrong keyword documentation
On Fri, May 28, 2010 at 10:52 AM, Jason Grout wrote: > I just noticed here: > > http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_xlim > > that the keywords that are documented for set_xlim are actually the > keywords for set_ylim. Surely this is just a copy-paste error. Surely. Fixed in SVN, thanks for the report. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] QuadMesh zorder
Hi, Ben Root gave me a bug report that pcolormesh (and hence QuadMesh) were not respecting zorder. This turns out to be due to the fact that kwargs are not being forwarded on as appropriate. This is easy enough to fix and make work, but I wanted to first ask for any insight on the following "helpful" comment in axes.py: collection = mcoll.QuadMesh( Nx - 1, Ny - 1, coords, showedges, antialiased=antialiased, shading=shading) # kwargs are not used (It's be great if this comment gave some actual reasoning rather than stating the obvious). Anyone know if there's an explicit design choice for QuadMesh not taking kwargs, or is it just an omission? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote: > Markus, > > That is good to know that it has been fixed. As for the difference in > pcolor and pcolormesh, I think it has to do with the fact that pcolormesh is > composed of many lines while pcolor is composed of many polygons. It is > probably more efficient to rasterize polygons than lines. To be blunt, this makes no sense whatsoever. First, pcolormesh and pcolor differ in that it pcolor uses a generic PolyCollection to draw the quads, while pcolormesh uses a quadmesh object, which can be more efficient at the cost of generality, as it only needs to render a set of identical quads. Second, if you're talking rasterized drawing, in the end what gets written to a file is a 2D array of RGBA values. It doesn't matter what you use to produce the results: identical image on the screen -> identical array in file. It's possible that there are slight differences that you can't really see that produce different arrays, but that won't cause a factor of 8 difference in size. My guess is that pcolormesh isn't rasterizing properly. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
