Re: [matplotlib-devel] rcParams and validation
On 7/19/07, Darren Dale <[EMAIL PROTECTED]> wrote: > Damn, that is really cool. So you can generate default config files from the > MPLConfig instance. We create a default matplotlibrc file from a template, > setting default backend and numerix values based on what is available on the > users system. It looks like it would be even easier with your scheme: import > MPLConfig in setup.py, set the attributes, dump to a default config file. Yup. If you update, I just committed the last changes I can make to this for now. I need to switch gears (real work calls...), but this stuff is mostly functional. It needs a solid cleanup and my quick tests to be moved into proper doc/unit tests, but I think it's looking reasonably good. The examples/tests part of the file shows exactly what you are asking for. > > In summary, I'm fairly happy with the results, and I think the benefit > > is enough to convince me of falling in the embrace of the gods of > > Traits. It seems John is going for Traits as well, so perhaps we can > > use this little config setup across our systems, and even make it > > something that others use in the future. I think there's value for > > end users in having common, uniform configuration systems across the > > various parts of the scientific python 'ecosystem'. > > I agree. It looks really elegant. What about the circular dependencies you > mentioned in a previous email, is that still a potential problem? Nope, gone (I think). Since the config file is pure text, it will never pull the main project's objects in via code. One can allow a config field to specify a file to execute *later*, once everything is up and running, but the building of these config objects is going to be strictly declarative via traits, so we should be OK. Brian has more experience with those headaches than I, so he may still spot issues with this, but I think this setup is looking very reasonable. Cheers, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Wed, Jul 18, 2007 at 11:24:09AM -0600, Brian Granger wrote:
> At some level though, configuration is a very different thing than an
> application's runtime API. While they may be related (by exposing
> common functionality), not everything that can be configured would
> appear in a runtime API and vice-versa. Also, some events that need
> to happen when an attribute is changed at runtime can't happen at
> config time as the application might not yet be up and running yet.
Well that easy to sort out. You can put a flag to the traits handler that
simply forbids it as long as the application is not running. Something
like:
def if_app_running(callback):
app = get_application() # get_application could be anything that
# returns the current application
def modified_callback(self, *args, **kwargs):
if app.running:
callback(self, *args, **kwargs)
return modified_callback
class ConfigurationObject(HasTraits):
prompt = String('[%i]')
@if_app_running
def _prompt_changed(self):
do whatever you want here
Gaël
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] error: package directory 'lib/matplotlib/numerix/mlab' does not exist
Nils, I just committed 3582 which reverted numerix to 3573, so please try again. It works for me now. Eric Nils Wagner wrote: > Hi, > > I cannot install matplotlib from latest svn. > error: package directory 'lib/matplotlib/numerix/mlab' does not exist > > Nils - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] error: package directory 'lib/matplotlib/numerix/mlab' does not exist
Eric Firing wrote: > Nils, > > I just committed 3582 which reverted numerix to 3573, so please try > again. It works for me now. > > Eric > > > Nils Wagner wrote: >> Hi, >> >> I cannot install matplotlib from latest svn. >> error: package directory 'lib/matplotlib/numerix/mlab' does not exist >> >> Nils Hi Eric, It doesn't work for me. Amatplotlib/fft Amatplotlib/fft/__init__.py Amatplotlib/npyma Amatplotlib/npyma/__init__.py Amatplotlib/linear_algebra Amatplotlib/linear_algebra/__init__.py Amatplotlib/mlab Amatplotlib/mlab/__init__.py Amatplotlib/mlab/.cvsignore Amatplotlib/random_array Amatplotlib/random_array/__init__.py Amatplotlib/_sp_imports.py Amatplotlib/ma Amatplotlib/ma/__init__.py Amatplotlib/_na_imports.py Amatplotlib/_nc_imports.py Checked out revision 3582. cd matplotlib rm -rf build python setup.py install ... error: package directory 'lib/matplotlib/numerix/mlab' does not exist Nils - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] error: package directory 'lib/matplotlib/numerix/mlab' does not exist
Nils, Rats! I thought I had svn figured out, but I managed to foul it up. Ok, stand by, I will try to straighten it out. I know what the directory tree should look like, I just don't know exactly how to get svn to do what I want it to do. I will have to undo the last fiasco and try something else. Eric Nils Wagner wrote: > Eric Firing wrote: >> Nils, >> >> I just committed 3582 which reverted numerix to 3573, so please try >> again. It works for me now. >> >> Eric >> >> >> Nils Wagner wrote: >>> Hi, >>> >>> I cannot install matplotlib from latest svn. >>> error: package directory 'lib/matplotlib/numerix/mlab' does not exist >>> >>> Nils > Hi Eric, > > It doesn't work for me. > > Amatplotlib/fft > Amatplotlib/fft/__init__.py > Amatplotlib/npyma > Amatplotlib/npyma/__init__.py > Amatplotlib/linear_algebra > Amatplotlib/linear_algebra/__init__.py > Amatplotlib/mlab > Amatplotlib/mlab/__init__.py > Amatplotlib/mlab/.cvsignore > Amatplotlib/random_array > Amatplotlib/random_array/__init__.py > Amatplotlib/_sp_imports.py > Amatplotlib/ma > Amatplotlib/ma/__init__.py > Amatplotlib/_na_imports.py > Amatplotlib/_nc_imports.py > Checked out revision 3582. > > cd matplotlib > rm -rf build > python setup.py install > ... > > error: package directory 'lib/matplotlib/numerix/mlab' does not exist > > Nils > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] error: package directory 'lib/matplotlib/numerix/mlab' does not exist
Eric Firing wrote: > Nils, > > Two more commits, now at 3584, and I think I have it straightened out. >I hope so. I'm going offline for 8 hours or so, so if it is not > fixed now either someone else will have to do it, or it will have to wait. > > Eric > > Hi Eric, Works for me ! Thank you very much ! Cheers, Nils - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] error: package directory 'lib/matplotlib/numerix/mlab' does not exist
Nils, Two more commits, now at 3584, and I think I have it straightened out. I hope so. I'm going offline for 8 hours or so, so if it is not fixed now either someone else will have to do it, or it will have to wait. Eric Nils Wagner wrote: > Eric Firing wrote: >> Nils, >> >> I just committed 3582 which reverted numerix to 3573, so please try >> again. It works for me now. >> >> Eric >> >> >> Nils Wagner wrote: >>> Hi, >>> >>> I cannot install matplotlib from latest svn. >>> error: package directory 'lib/matplotlib/numerix/mlab' does not exist >>> >>> Nils > Hi Eric, > > It doesn't work for me. > > Amatplotlib/fft > Amatplotlib/fft/__init__.py > Amatplotlib/npyma > Amatplotlib/npyma/__init__.py > Amatplotlib/linear_algebra > Amatplotlib/linear_algebra/__init__.py > Amatplotlib/mlab > Amatplotlib/mlab/__init__.py > Amatplotlib/mlab/.cvsignore > Amatplotlib/random_array > Amatplotlib/random_array/__init__.py > Amatplotlib/_sp_imports.py > Amatplotlib/ma > Amatplotlib/ma/__init__.py > Amatplotlib/_na_imports.py > Amatplotlib/_nc_imports.py > Checked out revision 3582. > > cd matplotlib > rm -rf build > python setup.py install > ... > > error: package directory 'lib/matplotlib/numerix/mlab' does not exist > > Nils > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Apology
Hi everybody, I think I have to apologize, especially to Eric and John, for the confusion that I caused by the commits yesterday. The whole thing started as a bit of cleaning up and then I got carried away. I think there were two points that caused confusion. One is that the new revisions would have required anybody to dump build and installation directories, so a warning on the mailing list would certainly have been appropriate. The other point was that I did not consider those people who explicitely use numerix in their own code. I always thought of numerix as an internal compatibility layer of matplotlib not a wrapper that should be used outside. Guess, I was wrong there. I will sort through the reverted code. I believe, it would be best to revert only the first of my two commits, leaving the numerix directory in its original state, but leave the second commit in place (that one cuts nearly all internal dependencies on numerix, except those in pylab.py, mlab.py and those on ma/npyma which still have to be sorted out. I did not do a full numpification (changing to "from numpy import ..." to "import numpy as npy") but only those steps necessary to cut the dependency. So, once again: Sorry for the confusion. Greetings, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
Ken McIvor wrote: >> This means someone needs to figure out how to get TkInter talking to >> a python >> buffer object or a numpy array. > > I think PIL's ImageTk module would do the trick for converting RGBA -> > PIL Image -> Tk Bitmap/PhotoImage. That's what I was thinking, too. I don't think there's a way to do this in a raw Tkinter. But is PIL something we plan to depend on? Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Polygon examples broken
I just noticed that the example poly_editor.py is broken. It appears to be the Artist.update_from(self.line, poly) that is called when the polygon is changed. The problem is that no change is saved after a subsequent modification. Also, clippath_test.py (that also uses Polygons) appears to be broken as well, but I'm not sure where to look for the bug... Also, while I am writing, there are two other things I have been meaning to mention: First, it has bothered me that from pylab import * and from numpy import * both import 'load' statements. Yes, I realize that I can put them in their own name space, but I only use python for mpl and numpy -- for me python is a matlab replacement. So, I have come to the realization that these two things (alone) I want in my top namespace. It would be nice if they didn't conflict. Second, much of what I do involves plotting model data (on a curvilinear grid). I generally like to use pcolor for these plots. I *always* want shading='flat' Some of my grids are large, and I only see lines if I don't. Even with smaller grids, those black lines get in the way. I don't want to suggest an RC setting for everything, but this one single setting would save me thousands of characters typed per week. Can we add an RC shading option? -Rob Rob Hetland, Associate Professor Dept. of Oceanography, Texas A&M University http://pong.tamu.edu/~rob phone: 979-458-0096, fax: 979-845-6331 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
On Jul 20, 2007, at 6:26 AM, Michael Droettboom wrote: > Ken McIvor wrote: >>> >> I think PIL's ImageTk module would do the trick for converting >> RGBA -> >> PIL Image -> Tk Bitmap/PhotoImage. > > That's what I was thinking, too. I don't think there's a way to do > this > in a raw Tkinter. But is PIL something we plan to depend on? I don't know, although I'm warming to the idea myself. If we don't want the Tk backend to depend on PIL, we could create a string containing an X11 bitmap of the renderer's RGB array and use it to construct or update a Tkinter.BitmapImage. Ken - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Fri, Jul 20, 2007 at 08:53:30AM -0400, Rob Hetland wrote: > Second, much of what I do involves plotting model data (on a > curvilinear grid). I generally like to use pcolor for these plots. > I *always* want shading='flat' Some of my grids are large, and I > only see lines if I don't. Even with smaller grids, those black > lines get in the way. I don't want to suggest an RC setting for > everything, but this one single setting would save me thousands of > characters typed per week. Can we add an RC shading option? If your data is on a quadrilateral mesh, try using the pcolormesh function. It is orders of magnitude faster than pcolor and we solved the black lines problem by using transparency on the mesh grid (though of course you can use 'flat' if you want). We only implemented this for the Agg backend, otherwise it falls back to the pcolor style rendering of a collection of polygons. - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
Ken McIvor wrote: > On Jul 20, 2007, at 6:26 AM, Michael Droettboom wrote: >> Ken McIvor wrote: >>> I think PIL's ImageTk module would do the trick for converting RGBA -> >>> PIL Image -> Tk Bitmap/PhotoImage. >> >> That's what I was thinking, too. I don't think there's a way to do this >> in a raw Tkinter. But is PIL something we plan to depend on? > > I don't know, although I'm warming to the idea myself. If we don't > want the Tk backend to depend on PIL, we could create a string > containing an X11 bitmap of the renderer's RGB array and use it to > construct or update a Tkinter.BitmapImage. Tkinter.BitmapImage s are one-bit -- it would have to be a Tkinter.PhotoImage. The options for file formats are GIF and PGM/PPM. PPM is the only of those that supports TrueColor. It would have to be able to be generated efficiently enough from pure Python (seems possible, but I haven't tried yet). My bigger concern, though, is that there seems to be no way to update just a subregion of the PhotoImage from pure Python. I see that the C code in _tkagg.cpp can do this. Does that actually get used or is it always a full image? Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
On 7/20/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > er concern, though, is that there seems to be no way to update > just a subregion of the PhotoImage from pure Python. I see that the C > code in _tkagg.cpp can do this. Does that actually get used or is it > always a full image? Yes we use it and this is a very useful feature, one we can hopefully expand on for more efficient rendering. Eg, FigureCanvasTkAgg.blit uses it. Truth be told, the tk GUI code has never caused us any real headaches from a compilation perspective, so we *could* live with it, but don't let me dissuade you from finding a creative python solution. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Jul 20, 2007, at 9:07 AM, Paul Kienzle wrote: > On Fri, Jul 20, 2007 at 08:53:30AM -0400, Rob Hetland wrote: >> Second, much of what I do involves plotting model data (on a >> curvilinear grid). I generally like to use pcolor for these plots. >> I *always* want shading='flat' Some of my grids are large, and I >> only see lines if I don't. Even with smaller grids, those black >> lines get in the way. I don't want to suggest an RC setting for >> everything, but this one single setting would save me thousands of >> characters typed per week. Can we add an RC shading option? > > If your data is on a quadrilateral mesh, try using the pcolormesh > function. It is orders of magnitude faster than pcolor and we > solved the black lines problem by using transparency on the mesh > grid (though of course you can use 'flat' if you want). We only > implemented this for the Agg backend, otherwise it falls back to > the pcolor style rendering of a collection of polygons. Yes, pcolormesh works great. Still, when I use the default values [pcolormesh(x, y, z)] I get a Morrey (sp?) pattern instead of seeing the grid -- i.e., better than pcolor(..., shading='faceted'), but still not a great plot. Is it possible to set RC defaults to get the equivalent of shading='flat' in pcolormesh? As far as I know, it is not possible in pcolor. -r Rob Hetland, Associate Professor Dept. of Oceanography, Texas A&M University http://pong.tamu.edu/~rob phone: 979-458-0096, fax: 979-845-6331 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Apology
On 7/20/07, Norbert Nemec <[EMAIL PROTECTED]> wrote: > I think I have to apologize, especially to Eric and John, for the > confusion that I caused by the commits yesterday. The whole thing > started as a bit of cleaning up and then I got carried away. Thanks for the apology -- it was a minor inconvenience. That's why they call it the bleeding edge :-) > I think there were two points that caused confusion. One is that the new > revisions would have required anybody to dump build and installation > directories, so a warning on the mailing list would certainly have been > appropriate. Strange, when I was testing, I *thought* I did blow away my build and install and still couldn't run anything, but Eric says he could, so maybe I was just screwing up. > The other point was that I did not consider those people who explicitely > use numerix in their own code. I always thought of numerix as an > internal compatibility layer of matplotlib not a wrapper that should be > used outside. Guess, I was wrong there. > > I will sort through the reverted code. I believe, it would be best to > revert only the first of my two commits, leaving the numerix directory > in its original state, but leave the second commit in place (that one > cuts nearly all internal dependencies on numerix, except those in > pylab.py, mlab.py and those on ma/npyma which still have to be sorted out. > > I did not do a full numpification (changing to "from numpy import ..." > to "import numpy as npy") but only those steps necessary to cut the > dependency. On balance, I think it may be better to try and do the "full numpification" on each module at a time, rather than a partial one on many. It will increase the pressure on us to get these things cleaned up once and for all, whereas if we do them partially, we are less likely to get to them again. Thanks, JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] remove artists
Hi, Not hearing back one way or the other, I checked in the remove artist stuff. It is a pretty minor patch. It is cheap (a lambda and an attribute per artist), but unfortunately not free for those who don' need it :-( I can turn the lambdas into methods pretty easily if the python experts say the savings will be significant. I'll submit an example this weekend which uses it. I've got a pretty extensive application now which uses it, but I need something smaller for that purpose. - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Numpification - next try
Hi there, I sorted out the reverted commits (sorry once again) and tried another commit. This time trying to think of everything that was said: * the numerix/ directory is unchanged * code in matplotlib is independent of numerix * code in matplotlib imports numpy as npy * everything is triple checked, running backend_drivers completely * no files are added or removed, so installation should not pose problems What remains to be done is sorting pylab and mlab. I think quite a bit of the code in there is redundant. Question is whether pylab should offer Numeric/numarray compatibility? Hope this new version does not cause any new problems... Greetings, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Numpification - next try
On 7/20/07, Norbert Nemec <[EMAIL PROTECTED]> wrote: > Hi there, > > I sorted out the reverted commits (sorry once again) and tried another > commit. This time trying to think of everything that was said: > > * the numerix/ directory is unchanged > * code in matplotlib is independent of numerix > * code in matplotlib imports numpy as npy > * everything is triple checked, running backend_drivers completely > * no files are added or removed, so installation should not pose problems wow, talk about atonement -- fantastic work! > What remains to be done is sorting pylab and mlab. I think quite a bit > of the code in there is redundant. Question is whether pylab should > offer Numeric/numarray compatibility? No it shouldn't. Only the numerix layer should, and it should not be imported anywhere within mpl > Hope this new version does not cause any new problems... Preliminary tests look good. Thanks a lot. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
> 3. Traits. We (Brian and I) have gone back and forth a lot on Traits, > and we've come very close to just making them a dependency. The only > real issue holding us back is that ipython so far has exactly *zero* > extension code, which is a plus in terms of ease of > installation/deployment. Having said that, as far as extension code > is concerned, Traits is light and clean, and nowhere near the kinds of > complexities that MPL deals with. But since anything is more than > zero, it is a bit of an issue for us. We may tip over though, I'm > just stating what our reasoning so far has been. > > In terms of Traits, point (2) above makes them even more attractive. > The delegation aspect of Traits is a very appealing way of combining > validation with additional action for the runtime modification of an > object. For example: > > ipython.color_scheme = "foo" > > If color_scheme were a Trait, the above could simply: > > a) validate that "foo" was acceptable as a value > b) trigger the chain of other trait updates (dependent color schemes > for exceptions, prompts, etc). At some level though, configuration is a very different thing than an application's runtime API. While they may be related (by exposing common functionality), not everything that can be configured would appear in a runtime API and vice-versa. Also, some events that need to happen when an attribute is changed at runtime can't happen at config time as the application might not yet be up and running yet. Using Traits in the runtime API is an entirely different ballgame than simply using it for type validation in configuration: When using Traits for validation+configuration, the objects that inherit from HasTraits are simply bunch/dict like objects that do type validation - but they don't contain any application logic. The actually application logic is contained in classes that aren't traited themselves, but that consume traited config objects to configure themselves at startup. If traited objects are exposed in a runtime API, all of a sudden the application logic moves to the traited classes themselves. Then, the entire application (any object that needs config or has a runtime API) is built upon traits at its core. This is very from the previous case where traited classes are used as a minor implementation detail of the config system. I am not saying that it is bad to build an application with traits at its core, but only that that is very different from the path that ipython and matplotlib have taken thus far. Also, it makes the commitment level to traits much higher than if it is used merely as a component in the config system - which could easily be swapped out if desired. Brian > All of this can obviously be done with python properties, but before I > write Traits again, poorly (I'm no David Morrill) I'd rather ride > Enthought's back. > > This approach via Traits (or something like them) also ensures that > the work done in ensuring the consitency/robustness of an object's > *runtime* configuration API becomes automatically useful to users, and > it simplifies the init-time config API, since it gives us the option > to defer more complicated tasks to runtime. > > > So this is a summary of where we stand. It's surprising that the > 'simple question' of configuring an application can turn out to be > such a can of worms, but for us it has proven to be. Input/ideas from > you all would be very welcome, as it's quite likely we've missed > possible solutions. > > I'd love to get out of this discussion some ideas, clarity and > ultimately a plan for how to proceed in the long haul. If in addition > this means that ipython, mpl and others end up uniformizing further > our approach to this problem, even better! Having our end users find > familiar configuration mechanisms across their various libraries would > only be a good thing in the long run. > > Cheers, > > Brian and f. > > > ps - I debated on having this discussion on ipython-dev, but for now > I'm going to not cross-post. The MPL team is attentive to the issue > now, so I'd rather collect your wisdom here, and I'll take it upon > myself to summarize our conclusions on ipython-dev later. I just want > to avoid list cross-posting. > -- Brian E. Granger, Ph.D. Research Scientist Tech-X Corporation phone: 720-974-1850 [EMAIL PROTECTED] [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
> Damn, that is really cool. So you can generate default config files from the > MPLConfig instance. We create a default matplotlibrc file from a template, > setting default backend and numerix values based on what is available on the > users system. It looks like it would be even easier with your scheme: import > MPLConfig in setup.py, set the attributes, dump to a default config file. My thought for IPython is to have defaults set in the traited config class itself so you wouldn't even have to do the second step. Just import MPLConfig and dump to a file. I too think this is one of the really nice benefits of this approach. Generating the default config file for IPython1 was becoming a real problem. > [...] > > In summary, I'm fairly happy with the results, and I think the benefit > > is enough to convince me of falling in the embrace of the gods of > > Traits. It seems John is going for Traits as well, so perhaps we can > > use this little config setup across our systems, and even make it > > something that others use in the future. I think there's value for > > end users in having common, uniform configuration systems across the > > various parts of the scientific python 'ecosystem'. > > I agree. It looks really elegant. What about the circular dependencies you > mentioned in a previous email, is that still a potential problem? The circular dependency problem goes away in the following way. The config files and config objects will only consist of basic types (int, strings, float, lists, dicts, etc) - not executable python code. If you need to specify python code (the name of a class that implements some behavior for example) that would be specified as a string. During the initial parts of the configuration process, that would remain a string, thus avoiding the circular dependency problem. Only after it is safe to execute/import, would the string be exec'd. > Darren > -- Brian E. Granger, Ph.D. Research Scientist Tech-X Corporation phone: 720-974-1850 [EMAIL PROTECTED] [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Paul Kienzle wrote: > On Fri, Jul 20, 2007 at 08:53:30AM -0400, Rob Hetland wrote: >> Second, much of what I do involves plotting model data (on a >> curvilinear grid). I generally like to use pcolor for these plots. >> I *always* want shading='flat' Some of my grids are large, and I >> only see lines if I don't. Even with smaller grids, those black >> lines get in the way. I don't want to suggest an RC setting for >> everything, but this one single setting would save me thousands of >> characters typed per week. Can we add an RC shading option? > > If your data is on a quadrilateral mesh, try using the pcolormesh > function. It is orders of magnitude faster than pcolor and we > solved the black lines problem by using transparency on the mesh > grid (though of course you can use 'flat' if you want). We only > implemented this for the Agg backend, otherwise it falls back to > the pcolor style rendering of a collection of polygons. Paul, Quadmesh has a bug in it that I would love to see squashed. Can you look at it, or induce someone else to do so? I tried but couldn't figure it out--it is something deep in the use of Agg. It is illustrated by examples/quadmesh_demo.py. With masked data (right-hand subplot), the masked region is not set to the background but is instead picking up odd things. If you don't see it immediately, try reshaping and resizing the plot a few times. Thanks. Eric > > - Paul > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Friday 20 July 2007 12:31:00 pm Brian Granger wrote: > > Damn, that is really cool. So you can generate default config files from > > the MPLConfig instance. We create a default matplotlibrc file from a > > template, setting default backend and numerix values based on what is > > available on the users system. It looks like it would be even easier with > > your scheme: import MPLConfig in setup.py, set the attributes, dump to a > > default config file. > > My thought for IPython is to have defaults set in the traited config > class itself so you wouldn't even have to do the second step. Just > import MPLConfig and dump to a file. I too think this is one of the > really nice benefits of this approach. Generating the default config > file for IPython1 was becoming a real problem. Although, the config files generated this way are not very well organized, due to the seemingly random order that a dict's items are accessed. Look at the mpl3.conf file that is generated with Fernando's proof-of-concept: interactive = False backend = 'TkAgg' [figure] edgecolor = 'white' facecolor = 0.75 dpi = 100 figsize = [6.4004, 4.7998] [[subplot]] top = 0.90002 right = 0.90002 bottom = 0.10001 left = 0.125 [lines] linewidth = 2.0 linestyle = '-' [InitOnly] numerix = 'numpy' That is not too bad for small config files, but matplotlib's selection of rc parameters is pretty large, and it is nice to have them appear in the file in a meaningful order. Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] patch to fix examples
Hi everyone,
Some of the examples in the repository are broken. Attached is a
patch to fix them (it also required one or two changes in the rest of
matplotlib).
I haven't monitored the list for a while, and I'm glad to hear that
mpl1 is on the table. I hope automated testing will be one of the new
features.
Regards
Stéfan
Index: lib/matplotlib/patches.py
===
--- lib/matplotlib/patches.py (revision 3584)
+++ lib/matplotlib/patches.py (working copy)
@@ -548,7 +548,7 @@
cx = float(dx)/L
sx = float(dy)/L
M = npy.array( [ [ cx, sx],[ -sx, cx ] ] )
-verts = npy.matrixmultiply( arrow, M )+ [x,y]
+verts = npy.dot( arrow, M )+ [x,y]
Polygon.__init__( self, [ tuple(t) for t in verts ], **kwargs )
__init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd
@@ -622,7 +622,7 @@
cx = float(dx)/distance
sx = float(dy)/distance
M = npy.array([[cx, sx],[-sx,cx]])
-verts = npy.matrixmultiply(coords, M) + (x+dx, y+dy)
+verts = npy.dot(coords, M) + (x+dx, y+dy)
Polygon.__init__(self, map(tuple, verts), **kwargs)
__init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 3584)
+++ lib/matplotlib/axes.py (working copy)
@@ -2359,7 +2359,7 @@
if len(xmin)==1:
xmin = xmin*ones(y.shape, y.dtype)
-if len(ymax)==1:
+if len(xmax)==1:
xmax = xmax*ones(y.shape, y.dtype)
xmin = npy.asarray(xmin)
@@ -3682,7 +3682,7 @@
distance = max(positions) - min(positions)
widths = min(0.15*max(distance,1.0), 0.5)
if isinstance(widths, float) or isinstance(widths, int):
-widths = npy.ones((col,), numpy.float_) * widths
+widths = npy.ones((col,), npy.float_) * widths
# loop through columns, adding each to plot
self.hold(True)
Index: examples/embedding_in_wx3.py
===
--- examples/embedding_in_wx3.py (revision 3584)
+++ examples/embedding_in_wx3.py (working copy)
@@ -21,27 +21,25 @@
import sys, time, os, gc
import matplotlib
matplotlib.use('WXAgg')
-# some of this code is numarray dependent
-matplotlib.rcParams['numerix'] = 'numarray'
import matplotlib.cm as cm
from matplotlib.backends.backend_wxagg import Toolbar, FigureCanvasWxAgg
from matplotlib.figure import Figure
-import matplotlib.numerix as numerix
+import numpy as npy
import matplotlib.numerix.mlab as mlab
from matplotlib.mlab import meshgrid
-from wxPython.wx import *
-from wxPython.xrc import *
+from wx import *
+from wx.xrc import *
ERR_TOL = 1e-5 # floating point slop for peak-detection
matplotlib.rc('image', origin='lower')
-class PlotPanel(wxPanel):
+class PlotPanel(Panel):
def __init__(self, parent):
-wxPanel.__init__(self, parent, -1)
+Panel.__init__(self, parent, -1)
self.fig = Figure((5,4), 75)
self.canvas = FigureCanvasWxAgg(self, -1, self.fig)
@@ -50,27 +48,25 @@
#self.toolbar.set_active([0,1])
# Now put all into a sizer
-sizer = wxBoxSizer(wxVERTICAL)
+sizer = BoxSizer(VERTICAL)
# This way of adding to sizer allows resizing
-sizer.Add(self.canvas, 1, wxLEFT|wxTOP|wxGROW)
+sizer.Add(self.canvas, 1, LEFT|TOP|GROW)
# Best to allow the toolbar to resize!
-sizer.Add(self.toolbar, 0, wxGROW)
+sizer.Add(self.toolbar, 0, GROW)
self.SetSizer(sizer)
self.Fit()
def init_plot_data(self):
a = self.fig.add_subplot(111)
-x = numerix.arange(120.0)*2*numerix.pi/60.0
-y = numerix.arange(100.0)*2*numerix.pi/50.0
+x = npy.arange(120.0)*2*npy.pi/60.0
+y = npy.arange(100.0)*2*npy.pi/50.0
self.x, self.y = meshgrid(x, y)
-z = numerix.sin(self.x) + numerix.cos(self.y)
+z = npy.sin(self.x) + npy.cos(self.y)
self.im = a.imshow( z, cmap=cm.jet)#, interpolation='nearest')
zmax = mlab.max(mlab.max(z))-ERR_TOL
-
-ymax_i, xmax_i = numerix.nonzero(
-numerix.greater_equal(z, zmax))
+ymax_i, xmax_i = npy.nonzero(z >= zmax)
if self.im.origin == 'upper':
ymax_i = z.shape[0]-ymax_i
self.lines = a.plot(xmax_i,ymax_i,'ko')
@@ -83,14 +79,13 @@
return self.toolbar
def OnWhiz(self,evt):
-self.x += numerix.pi/15
-self.y += numerix.pi/20
-z = numerix.sin(self.x) + numerix.cos(self.y)
+self.x += npy.pi/15
+self.y += npy.pi/20
+z = npy.sin(self.x) + npy.cos(self.y)
self.im.set_array(z)
zmax = mlab.max(mlab.max(z))-ERR_TOL
-ymax_i, xmax_i = numerix.nonzero(
-nume
Re: [matplotlib-devel] mpl1 draft
Ken McIvor wrote: >>But is PIL something we plan to depend on? > > I don't know, although I'm warming to the idea myself. Is PIL's DrawAgg numpy-aware? I suspect not. That could make difference when drawing lines with LOTS of points, for instance. I suppose we could contribute the array-aware code, but I don't know if it would be accepted. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Rob Hetland wrote: > First, it has bothered me that from pylab import * and from numpy > import * both import 'load' statements. Yes, I realize that I can put > them in their own name space, but I only use python for mpl and numpy That's why: "Namespaces are one honking great idea". They really are. Trust me on this. Also, doesn't pylab hold all of numerix anyway? Why do you need both? If you want to use the latest numpy API (which I do) then again -- "Namespaces are one honking great idea". This is what they are for. Otherwise, you're stuck with using numerix and waiting until MPL goes pure numpy ( I don't know when that might be). pylab and numpy stomp all over each other (if you use import *) by design. It comes down to this: if you use "import *" you're forced to use the decision made by others -- the numerix API, which, quite reasonably, they are keeping backward compatible. Is it really that hard to use this? import numpy as N # or "as npy", the mpl standard. a = N.arange(10) a.sum() etc, etc... One of the nice things about numpy is that there are lot more array methods, rather than functions, so it works better with namespaces -- you really don't need to type the "N." all that much. from pylab import * import numpy as N May be a reasonable compromise. > -- for me python is a matlab replacement. In many ways it is for me too, but it's so much better! take advantage of the advantages -- like namespaces. If you're anything like me, you may not be writing big programs, but even quickie scripts are edited and re-edited a lot -- a little extra typing makes little difference. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
Darren Dale wrote: > Is there much demand for BSD-compliant svg, pdf, and ps backends? Is the demand any different than for any other back end? I wonder about the demand for BSD MPL over all. I know we want people to be able to use MPL in proprietary apps, but the LGPL allows that. How important is it that people can actually improve MPL without contributing those improvements back? Isn't that what BSD allows that LGPL doesn't? By the way, isn't wxPython modified LGPL? We have a wx back-end. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Rob Hetland wrote: > On Jul 20, 2007, at 9:07 AM, Paul Kienzle wrote: > >> On Fri, Jul 20, 2007 at 08:53:30AM -0400, Rob Hetland wrote: >>> Second, much of what I do involves plotting model data (on a >>> curvilinear grid). I generally like to use pcolor for these plots. >>> I *always* want shading='flat' Some of my grids are large, and I >>> only see lines if I don't. Even with smaller grids, those black >>> lines get in the way. I don't want to suggest an RC setting for >>> everything, but this one single setting would save me thousands of >>> characters typed per week. Can we add an RC shading option? >> If your data is on a quadrilateral mesh, try using the pcolormesh >> function. It is orders of magnitude faster than pcolor and we >> solved the black lines problem by using transparency on the mesh >> grid (though of course you can use 'flat' if you want). We only >> implemented this for the Agg backend, otherwise it falls back to >> the pcolor style rendering of a collection of polygons. > > Yes, pcolormesh works great. Still, when I use the default values > [pcolormesh(x, y, z)] I get a Morrey (sp?) pattern instead of seeing > the grid -- i.e., better than pcolor(..., shading='faceted'), but > still not a great plot. Is it possible to set RC defaults to get the > equivalent of shading='flat' in pcolormesh? As far as I know, it is > not possible in pcolor. Rob, That horrible default of 'faceted' is an evil side-effect of patterning pylab after matlab; it is ugly and annoying in matlab, and equally so in pylab. We can either break the matlab compatibility or put in an rc setting--but I agree, one or the other is needed, and should apply in the same way to pcolor as to pcolormesh. The path of least resistance is yet another rc setting, but it might be worth a question to matplotlib-users to see if *anyone* really likes keeping the Matlab-style default. Probably there are such people. Eric > > -r > > > Rob Hetland, Associate Professor > Dept. of Oceanography, Texas A&M University > http://pong.tamu.edu/~rob > phone: 979-458-0096, fax: 979-845-6331 > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote: > Although, the config files generated this way are not very well organized, due > to the seemingly random order that a dict's items are accessed. Look at the > mpl3.conf file that is generated with Fernando's proof-of-concept: > > interactive = False > backend = 'TkAgg' > [figure] > edgecolor = 'white' > facecolor = 0.75 > dpi = 100 > figsize = [6.4004, 4.7998] > [[subplot]] > top = 0.90002 > right = 0.90002 > bottom = 0.10001 > left = 0.125 > [lines] > linewidth = 2.0 > linestyle = '-' > [InitOnly] > numerix = 'numpy' > > That is not too bad for small config files, but matplotlib's selection of rc > parameters is pretty large, and it is nice to have them appear in the file in > a meaningful order. Not a whole lot we can do about that, since the write method comes from the configobj code. Since they try to write in the same place the original file had things (to preserve comments and such), I don't think this is easy to fix. However, it's not all gloom and doom: one can simply generate a config file from the object description, edit it for ordering, and after that keep it synced with changes to the object description fairly easily. The current code only works in one direction: the file overrides the object. It should take me about 5 minutes to add a method to go in the other, since the code is really already there. With that, you can then use the workflow of generating once, manually fixing it, and then updating it from the class. That way, you can always keep the default file you like as internal MPL data, but at install time, update that file as needed from runtime config before putting it in the user's directory. It lets you keep a nicely commented, organized file, but update it at installation time with proper info. I'll code this up after I get back from lunch, and then I'll really stop touching this code. I mean it :) Cheers, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch to fix examples
Stefan,
Thanks. I will apply them shortly, after a bit of checking. (There
were commits after 3584, but things look easy enough to straighten out.)
Eric
Stefan van der Walt wrote:
> Hi everyone,
>
> Some of the examples in the repository are broken. Attached is a
> patch to fix them (it also required one or two changes in the rest of
> matplotlib).
>
> I haven't monitored the list for a while, and I'm glad to hear that
> mpl1 is on the table. I hope automated testing will be one of the new
> features.
>
> Regards
> Stéfan
>
>
>
>
> Index: lib/matplotlib/patches.py
> ===
> --- lib/matplotlib/patches.py (revision 3584)
> +++ lib/matplotlib/patches.py (working copy)
> @@ -548,7 +548,7 @@
> cx = float(dx)/L
> sx = float(dy)/L
> M = npy.array( [ [ cx, sx],[ -sx, cx ] ] )
> -verts = npy.matrixmultiply( arrow, M )+ [x,y]
> +verts = npy.dot( arrow, M )+ [x,y]
> Polygon.__init__( self, [ tuple(t) for t in verts ], **kwargs )
> __init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd
>
> @@ -622,7 +622,7 @@
> cx = float(dx)/distance
> sx = float(dy)/distance
> M = npy.array([[cx, sx],[-sx,cx]])
> -verts = npy.matrixmultiply(coords, M) + (x+dx, y+dy)
> +verts = npy.dot(coords, M) + (x+dx, y+dy)
>
> Polygon.__init__(self, map(tuple, verts), **kwargs)
> __init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd
> Index: lib/matplotlib/axes.py
> ===
> --- lib/matplotlib/axes.py(revision 3584)
> +++ lib/matplotlib/axes.py(working copy)
> @@ -2359,7 +2359,7 @@
>
> if len(xmin)==1:
> xmin = xmin*ones(y.shape, y.dtype)
> -if len(ymax)==1:
> +if len(xmax)==1:
> xmax = xmax*ones(y.shape, y.dtype)
>
> xmin = npy.asarray(xmin)
> @@ -3682,7 +3682,7 @@
> distance = max(positions) - min(positions)
> widths = min(0.15*max(distance,1.0), 0.5)
> if isinstance(widths, float) or isinstance(widths, int):
> -widths = npy.ones((col,), numpy.float_) * widths
> +widths = npy.ones((col,), npy.float_) * widths
>
> # loop through columns, adding each to plot
> self.hold(True)
> Index: examples/embedding_in_wx3.py
> ===
> --- examples/embedding_in_wx3.py (revision 3584)
> +++ examples/embedding_in_wx3.py (working copy)
> @@ -21,27 +21,25 @@
> import sys, time, os, gc
> import matplotlib
> matplotlib.use('WXAgg')
> -# some of this code is numarray dependent
> -matplotlib.rcParams['numerix'] = 'numarray'
> import matplotlib.cm as cm
> from matplotlib.backends.backend_wxagg import Toolbar, FigureCanvasWxAgg
> from matplotlib.figure import Figure
> -import matplotlib.numerix as numerix
> +import numpy as npy
> import matplotlib.numerix.mlab as mlab
> from matplotlib.mlab import meshgrid
>
> -from wxPython.wx import *
> -from wxPython.xrc import *
> +from wx import *
> +from wx.xrc import *
>
> ERR_TOL = 1e-5 # floating point slop for peak-detection
>
>
> matplotlib.rc('image', origin='lower')
>
> -class PlotPanel(wxPanel):
> +class PlotPanel(Panel):
>
> def __init__(self, parent):
> -wxPanel.__init__(self, parent, -1)
> +Panel.__init__(self, parent, -1)
>
> self.fig = Figure((5,4), 75)
> self.canvas = FigureCanvasWxAgg(self, -1, self.fig)
> @@ -50,27 +48,25 @@
> #self.toolbar.set_active([0,1])
>
> # Now put all into a sizer
> -sizer = wxBoxSizer(wxVERTICAL)
> +sizer = BoxSizer(VERTICAL)
> # This way of adding to sizer allows resizing
> -sizer.Add(self.canvas, 1, wxLEFT|wxTOP|wxGROW)
> +sizer.Add(self.canvas, 1, LEFT|TOP|GROW)
> # Best to allow the toolbar to resize!
> -sizer.Add(self.toolbar, 0, wxGROW)
> +sizer.Add(self.toolbar, 0, GROW)
> self.SetSizer(sizer)
> self.Fit()
>
> def init_plot_data(self):
> a = self.fig.add_subplot(111)
>
> -x = numerix.arange(120.0)*2*numerix.pi/60.0
> -y = numerix.arange(100.0)*2*numerix.pi/50.0
> +x = npy.arange(120.0)*2*npy.pi/60.0
> +y = npy.arange(100.0)*2*npy.pi/50.0
> self.x, self.y = meshgrid(x, y)
> -z = numerix.sin(self.x) + numerix.cos(self.y)
> +z = npy.sin(self.x) + npy.cos(self.y)
> self.im = a.imshow( z, cmap=cm.jet)#, interpolation='nearest')
>
> zmax = mlab.max(mlab.max(z))-ERR_TOL
> -
> -ymax_i, xmax_i = numerix.nonzero(
> -numerix.greater_equal(z, zmax))
> +ymax_i, xmax_i = npy.nonzero(z >= zmax)
> if self.im.origin == '
Re: [matplotlib-devel] Polygon examples broken
On Fri, Jul 20, 2007 at 06:57:26AM -1000, Eric Firing wrote: > Paul Kienzle wrote: > > On Fri, Jul 20, 2007 at 08:53:30AM -0400, Rob Hetland wrote: > >> Second, much of what I do involves plotting model data (on a > >> curvilinear grid). I generally like to use pcolor for these plots. > >> I *always* want shading='flat' Some of my grids are large, and I > >> only see lines if I don't. Even with smaller grids, those black > >> lines get in the way. I don't want to suggest an RC setting for > >> everything, but this one single setting would save me thousands of > >> characters typed per week. Can we add an RC shading option? > > > > If your data is on a quadrilateral mesh, try using the pcolormesh > > function. It is orders of magnitude faster than pcolor and we > > solved the black lines problem by using transparency on the mesh > > grid (though of course you can use 'flat' if you want). We only > > implemented this for the Agg backend, otherwise it falls back to > > the pcolor style rendering of a collection of polygons. > > Paul, > > Quadmesh has a bug in it that I would love to see squashed. Can you > look at it, or induce someone else to do so? I tried but couldn't > figure it out--it is something deep in the use of Agg. It is illustrated > by examples/quadmesh_demo.py. With masked data (right-hand subplot), > the masked region is not set to the background but is instead picking up > odd things. If you don't see it immediately, try reshaping and resizing > the plot a few times. We should be able to track it down. We need to go deep in the code again anyway to figure out why performance bogs when zooming. We won't be touching it before the end of summer though. - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/20/07, Fernando Perez <[EMAIL PROTECTED]> wrote: > However, it's not all gloom and doom: one can simply generate a config > file from the object description, edit it for ordering, and after that > keep it synced with changes to the object description fairly easily. > The current code only works in one direction: the file overrides the > object. It should take me about 5 minutes to add a method to go in > the other, since the code is really already there. With that, you can > then use the workflow of generating once, manually fixing it, and then > updating it from the class. > > That way, you can always keep the default file you like as internal > MPL data, but at install time, update that file as needed from runtime > config before putting it in the user's directory. It lets you keep a > nicely commented, organized file, but update it at installation time > with proper info. > > I'll code this up after I get back from lunch, and then I'll really > stop touching this code. I mean it :) Nah, whoo needs lunch. Done: svn commit -m"Add option for class defaults to override files, so projects can impose changing defaults on files. After Darren's suggestion for MPL." This should give you a very reasonable solution for what you wanted to do. Now, I'll get lunch! Cheers, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Paul Kienzle wrote: [...] >> Quadmesh has a bug in it that I would love to see squashed. Can you >> look at it, or induce someone else to do so? I tried but couldn't >> figure it out--it is something deep in the use of Agg. It is illustrated >> by examples/quadmesh_demo.py. With masked data (right-hand subplot), >> the masked region is not set to the background but is instead picking up >> odd things. If you don't see it immediately, try reshaping and resizing >> the plot a few times. > > We should be able to track it down. We need to go deep in the code > again anyway to figure out why performance bogs when zooming. We > won't be touching it before the end of summer though. > > - Paul Good, thank you. This brings up the larger question of the major redesign that is underway, and how to make sure we don't lose the benefit of wonderful speedups like quadmesh. How hard would it be to translate it to use the swig-wrapped version of agg rather than accessing agg directly via the present pycxx _backend_agg.cpp? And how much performance do you think would be lost? Alternatively, is there a better way to put the fast rendering capability in a smaller piece of extension code that can be used in the new framework and that would not rely on pycxx? E.g., a small swiggable chunk? Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Fri, Jul 20, 2007 at 11:02:45AM -0700, Christopher Barker wrote: > Rob Hetland wrote: > > First, it has bothered me that from pylab import * and from numpy > > import * both import 'load' statements. Yes, I realize that I can put > > them in their own name space, but I only use python for mpl and numpy > > > That's why: "Namespaces are one honking great idea". They really are. > Trust me on this. > > Also, doesn't pylab hold all of numerix anyway? Why do you need both? > > If you want to use the latest numpy API (which I do) then again -- > "Namespaces are one honking great idea". This is what they are for. > > Otherwise, you're stuck with using numerix and waiting until MPL goes > pure numpy ( I don't know when that might be). pylab and numpy stomp all > over each other (if you use import *) by design. > > It comes down to this: if you use "import *" you're forced to use the > decision made by others -- the numerix API, which, quite reasonably, > they are keeping backward compatible. > > Is it really that hard to use this? > > import numpy as N # or "as npy", the mpl standard. > > a = N.arange(10) > > a.sum() > > etc, etc... > > One of the nice things about numpy is that there are lot more array > methods, rather than functions, so it works better with namespaces -- > you really don't need to type the "N." all that much. > > from pylab import * > import numpy as N > > May be a reasonable compromise. > > > -- for me python is a matlab replacement. > > In many ways it is for me too, but it's so much better! take advantage > of the advantages -- like namespaces. > > If you're anything like me, you may not be writing big programs, but > even quickie scripts are edited and re-edited a lot -- a little extra > typing makes little difference. > > -Chris To throw out some nonsense: import numpy as npy res = npy.sqrt(2*npy.sin(npy.pi*x**2) + npy.cos(x**2) - npy.exp(2*npy.pi*1j)) is not very readable. This is improved somewhat as: import numpy as N res = N.sqrt(2*N.sin(N.pi*x**2) + N.cos(x**2) - N.exp(2*N.pi*1j)) but the following is better: from mpl.math import * res = sqrt(2*sin(pi*x**2) + cos(x**2) - exp(2*pi*1j)) Can we create a math.py which makes a standard set of math functions available? Posix libc is an excellent place to start, though I would also appreciate inf, nan, pi and eps as well. I'm guessing a function sqrt(-1.) which returns 1j is out of the question? - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On 7/20/07, Eric Firing <[EMAIL PROTECTED]> wrote: > ngs up the larger question of the major > redesign that is underway, and how to make sure we don't lose the > benefit of wonderful speedups like quadmesh. How hard would it be to > translate it to use the swig-wrapped version of agg rather than > accessing agg directly via the present pycxx _backend_agg.cpp? And how > much performance do you think would be lost? Alternatively, is there a > better way to put the fast rendering capability in a smaller piece of > extension code that can be used in the new framework and that would not > rely on pycxx? E.g., a small swiggable chunk? One can fairly easily add custom extension code into the SWIG wrappers themselves. A single example is swig/agg_buffer.h, a small C++ class I added to expose the underlying image buffer to python. We would definitely port over stuff like quadmesh, where the hard part is not in the python wrapper interface, but in the code and algorithm itself, which should port fairly easily. JDH JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Fri, Jul 20, 2007 at 09:03:21AM -1000, Eric Firing wrote: > Good, thank you. This brings up the larger question of the major > redesign that is underway, and how to make sure we don't lose the > benefit of wonderful speedups like quadmesh. How hard would it be to > translate it to use the swig-wrapped version of agg rather than > accessing agg directly via the present pycxx _backend_agg.cpp? And how > much performance do you think would be lost? Alternatively, is there a > better way to put the fast rendering capability in a smaller piece of > extension code that can be used in the new framework and that would not > rely on pycxx? E.g., a small swiggable chunk? It is a long time since I've looked at the code, and I wasn't even the original author. Furthermore I don't know swig, nor am I particularly familiar with pycxx, so I can't answer your question. I imagine given an agg context, however that is usually done, that a walk of some arrays is all we need to do. Simplifying the representations on the python side will help a lot IIRC. The interface to my OpenGL plotter (not pylab enabled, sorry!) wasn't complex. Anyway, I'll be gone next week until mid-August, so don't expect anything before the end of summer. - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Paul Kienzle wrote: > This is improved somewhat as: > > import numpy as N > res = N.sqrt(2*N.sin(N.pi*x**2) + N.cos(x**2) - N.exp(2*N.pi*1j)) > > but the following is better: > > from mpl.math import * > res = sqrt(2*sin(pi*x**2) + cos(x**2) - exp(2*pi*1j)) quite true. Interestingly, I find that expressions like that are not a large fraction of my code these days -- maybe that's a bad thing, I used to do math! > Can we create a math.py which makes a standard set of math functions > available? You're right that for math expressions, it is nice to have them in the namespace, so this is used a lot: from numpy import sqrt, sin, cos, exp Maybe it's a reasonable idea to write a Nmath.py, which would have an import line like that. Out of 491 names in the numpy namespace, I found 26 that would commonly be found in math expressions. Not bad, really, much better than including all 491. Inf NaN abs angle arccos arccosh arcsin arcsinh arctan arctan2 arctanh cos cosh exp log log10 pi sign sin sinc sinh sqrt square tan tanh > I'm guessing a function sqrt(-1.) which returns 1j is out of the question? what's wrong with "1j" as a literal? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Plot with no labels
This question really belongs to the user ML, but I don't want to subscribe to another ML, so please, indulge me. I often have a figure with a lot of plot, some of them created in a for loop. I want some of them to display in the legend, and some of them not to. Now this is possible, using the two positionnal argument form of "legend", but this means I have to keep trak of all the plots created, and of the associated label. Is there a way to specify that a plot should not have a legend when creating it. Something like "plot( ..., label=False)" would be great. If not, would it be possible to have such a feature ? Cheers, Gaël - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
On 7/20/07, Christopher Barker <[EMAIL PROTECTED]> wrote: > > On Jul 19, 2007, at 12:18 PM, John Hunter wrote: > >> I also plan to use the SWIG agg wrapper > > Where can I find that? I did some googling, and no luck. mpl1/mpl1.py uses it It is available in matplotlib installs as from matplotlib import agg. The SWIG code is in the swig dir in mpl svn, and there is a partially broken example in examples/agg_test.py JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plot with no labels
On 7/20/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> This question really belongs to the user ML, but I don't want to
> subscribe to another ML, so please, indulge me.
>
> I often have a figure with a lot of plot, some of them created in a for
> loop. I want some of them to display in the legend, and some of them not
> to. Now this is possible, using the two positionnal argument form of
> "legend", but this means I have to keep trak of all the plots created,
> and of the associated label. Is there a way to specify that a plot should
> not have a legend when creating it. Something like "plot( ...,
> label=False)" would be great.
>
> If not, would it be possible to have such a feature ?
In recent mpl, label='' should do it. In order versions, label='_nolegend_'
>From the legend docstring:
USAGE:
Make a legend with existing lines
>>> legend()
legend by itself will try and build a legend using the label
property of the lines/patches/collections. You can set the label of
a line by doing plot(x, y, label='my data') or line.set_label('my
data'). If label is set to '_nolegend_', the item will not be shown
in legend.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
> On Jul 19, 2007, at 12:18 PM, John Hunter wrote: >> I also plan to use the SWIG agg wrapper Where can I find that? I did some googling, and no luck. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote: > You're right that for math expressions, it is nice to have them in the > namespace, so this is used a lot: > > from numpy import sqrt, sin, cos, exp > > Maybe it's a reasonable idea to write a Nmath.py, which would have an > import line like that. > > Out of 491 names in the numpy namespace, I found 26 that would commonly > be found in math expressions. Not bad, really, much better than > including all 491. > > Inf NaN abs angle arccos arccosh arcsin arcsinh arctan > arctan2 arctanh cos cosh exp log log10 pi sign sin > sinc sinh sqrt square tan tanh The C99 math/complex headers define a number of symbols. constants: log: M_E M_LOG2E M_LOG10E M_LN2 M_LN10 pi: M_PI M_PI_2 M_PI_4 M_1_PI M_2_PI M_2_SQRTPI sqrt(2): M_SQRT2 M_SQRT1_2 functions: isfinite isnormal isnan isinf acos asin atan atan2 cos sin tan acosh asinh atanh cosh sinh tanh exp log log10 expm1 log1p exp2 log2 pow sqrt cbrt erf erfc lgamma tgamma hypot fmod remainder remquo fabs fdim fmax fmin copysign signbit frexp ldexp logb modf scalbn ceil floor rint nexttoward nearbyingt round trunc complex functions: acos asin atan atan2 cos sin tan acosh asinh atanh cosh sinh tanh exp log pow sqrt conj cproj abs arg imag real The glibc header files are not the most concise source so likely I've made mistakes (e.g., missing inf/nan defs) and included things that are not actually standard (e.g., hypot?). Making a lot of these available in mpl.math would be nice. Short of installing all of scipy, anyone know where I can pick up erf()? > > I'm guessing a function sqrt(-1.) which returns 1j is out of the question? > > what's wrong with "1j" as a literal? Let me rephrase: Can we have a function sqrt(x) which returns real if x is nonnegative, and complex if it is negative? Similarly for other math functions such as log which produce complex values for negative numbers? I suppose the numpy list is the place to debate this, but it seems like it ought to be a feature of pylab in as much as pylab helps matlab users do pythonic things in a familiar environment. - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
Darren Dale wrote: > That is not too bad for small config files, but matplotlib's selection of rc > parameters is pretty large, and it is nice to have them appear in the file in > a meaningful order. You guys may want to consider iniparse instead of configobj. It will preserve order, indentation, comments(!), and blank lines. http://code.google.com/p/iniparse/ The drawback is that it doesn't support nested sections, to my knowledge. There might also be more special features of configobj that Fernando uses; I haven't taken a very close look at the code, yet. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Paul Kienzle wrote: > Let me rephrase: Can we have a function sqrt(x) which returns real if x is > nonnegative, and complex if it is negative? Similarly for other math > functions > such as log which produce complex values for negative numbers? > > I suppose the numpy list is the place to debate this, but it seems like it > ought to be a feature of pylab in as much as pylab helps matlab users do > pythonic things in a familiar environment. numpy.sqrt() won't do that (we've already discussed it). scipy.sqrt() does, though. The functions that work like this are in numpy.lib.scimath. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Rob Hetland wrote: > There is also quite a bit of advice on the internet and otherwise > that 'from numpy import *' is the way to import the library. For > example, this is the approach in Oliphant's 'Guide to Numpy.' You'll often see it in examples because it's the only way to make examples clear and to the point. It's not a recommendation. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/20/07, Robert Kern <[EMAIL PROTECTED]> wrote: > Darren Dale wrote: > > > That is not too bad for small config files, but matplotlib's selection of rc > > parameters is pretty large, and it is nice to have them appear in the file > > in > > a meaningful order. > > You guys may want to consider iniparse instead of configobj. It will preserve > order, indentation, comments(!), and blank lines. > > http://code.google.com/p/iniparse/ > > The drawback is that it doesn't support nested sections, to my knowledge. > There > might also be more special features of configobj that Fernando uses; I haven't > taken a very close look at the code, yet. Mmh, but configobj does preserve all those as well. Darren's comment was about not being able to get a clean file when made purely from a HasTraits description. But when there is an existing file on disk, configobj is actually really good at preserving it. So it seems to me that iniparse appears to be a limited subset of configobj (we really want nested sections in ipython, and MPL has them as well already). It does have the a.b instead of a['b'] convenience, but we get that via traits anyway. Am I missing something? Cheers, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Jul 20, 2007, at 2:02 PM, Christopher Barker wrote: > That's why: "Namespaces are one honking great idea". They really are. > Trust me on this. I get namespaces. They are really great. It's just that I use numpy and mpl *so* much that the namespaces get in the way. Most of my (smaller) coding errors involve forgetting 'pl.' in front of an mpl function. There is also quite a bit of advice on the internet and otherwise that 'from numpy import *' is the way to import the library. For example, this is the approach in Oliphant's 'Guide to Numpy.' And really, numpy and mpl coexist beautifully, except for a few small exceptions. 'load' is one. (There are others I have run across as well). I think mpl should play nice even for folks like me who occasionally like to abandon separate namespaces. -Rob Rob Hetland, Associate Professor Dept. of Oceanography, Texas A&M University http://pong.tamu.edu/~rob phone: 979-458-0096, fax: 979-845-6331 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
Fernando Perez wrote: > Am I missing something? No, I just wasn't paying close enough attention. Never mind me. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > This should give you a very reasonable solution for what you wanted to do. > > Great! I'm surprised that this was possible. And actually easy, for once. > Im attaching a patch for the ipython1 sandbox, which adds configobj.py, moves > the ipython and mpl config code into their own .py files, and moves the test > code into mpltest.py and ipythontest.py. Great, thanks! Committed as r2526. Later we'll move configobj.py into ipython/externals, but for now it's OK to have it in, so it's nicely self-contained for people to test this while we settle on something long-term. I've moved the lot into a subdirectory now, so that we can have more than one set of toys in our sandbox, so update to 2527 and you'll have tconfig as a self-contained project we can play with until happiness arrives. Cheers, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/20/07, Fernando Perez <[EMAIL PROTECTED]> wrote: > On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > > > This should give you a very reasonable solution for what you wanted to do. > > > > Great! I'm surprised that this was possible. > > And actually easy, for once. > > > Im attaching a patch for the ipython1 sandbox, which adds configobj.py, > > moves > > the ipython and mpl config code into their own .py files, and moves the test > > code into mpltest.py and ipythontest.py. > > Great, thanks! Committed as r2526. Later we'll move configobj.py > into ipython/externals, but for now it's OK to have it in, so it's > nicely self-contained for people to test this while we settle on > something long-term. I also just (r2528) updated things to use a cleaner import convention: I don't like importing things from modules *they* imported. To clarify: planck[tconfig]> svn diff -r2527:2528 mpltest.py Index: mpltest.py === --- mpltest.py (revision 2527) +++ mpltest.py (revision 2528) @@ -1,5 +1,11 @@ -from mplconfig import MPLConfig, ConfigManager, mkConfigObj +# import/reload base modules for interactive testing/development +import tconfig, mplconfig +reload(tconfig) +reload(mplconfig) +from tconfig import ConfigManager, mkConfigObj +from mplconfig import MPLConfig The point is that instead of -from mplconfig import MPLConfig, ConfigManager, mkConfigObj I prefer: +from tconfig import ConfigManager, mkConfigObj +from mplconfig import MPLConfig since ConfigManager and mkConfigObj really live in tconfig, I'm not tying my top-level code to an implementation detail of an intermediate module (what it imports and how it names it). I mention this explicitly just because I think it's a good bit of coding practice. The reload tricks also allow me to continue running the top-level test codes while mucking with the stuff underneath, and have changes make their way through consistently. Thanks again, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Friday 20 July 2007 05:25:06 pm Fernando Perez wrote: > I also just (r2528) updated things to use a cleaner import convention: > I don't like importing things from modules *they* imported. [...] > The point is that instead of > > -from mplconfig import MPLConfig, ConfigManager, mkConfigObj > > I prefer: > > +from tconfig import ConfigManager, mkConfigObj > +from mplconfig import MPLConfig > > since ConfigManager and mkConfigObj really live in tconfig, I'm not > tying my top-level code to an implementation detail of an intermediate > module (what it imports and how it names it). I mention this > explicitly just because I think it's a good bit of coding practice. I was thinking along the lines of your config/api.py file, a single entry point to the ipython or mpl config API. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/20/07, Darren Dale <[EMAIL PROTECTED]> wrote: > On Friday 20 July 2007 05:25:06 pm Fernando Perez wrote: > > I also just (r2528) updated things to use a cleaner import convention: > > I don't like importing things from modules *they* imported. > [...] > > The point is that instead of > > > > -from mplconfig import MPLConfig, ConfigManager, mkConfigObj > > > > I prefer: > > > > +from tconfig import ConfigManager, mkConfigObj > > +from mplconfig import MPLConfig > > > > since ConfigManager and mkConfigObj really live in tconfig, I'm not > > tying my top-level code to an implementation detail of an intermediate > > module (what it imports and how it names it). I mention this > > explicitly just because I think it's a good bit of coding practice. > > I was thinking along the lines of your config/api.py file, a single entry > point to the ipython or mpl config API. Ah, OK. Since we haven't really organized such an api yet, I was still thinking of the individual components. I see your point. Cheers, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
Robert Kern wrote: > Rob Hetland wrote: >> There is also quite a bit of advice on the internet and otherwise >> that 'from numpy import *' is the way to import the library. For >> example, this is the approach in Oliphant's 'Guide to Numpy.' > > You'll often see it in examples because it's the only way to make examples > clear > and to the point. It's not a recommendation. Indeed. way back when, in the days of Numeric, it WAS the recommendation, then we were in a state of flux, and as Robert said, many quick examples are still written using "import *". However, I have seen a real shift on the numpy list over the last year (or two), toward using the namespace. Paul Kienzle wrote: > On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote: >> Out of 491 names in the numpy namespace, I found 26 that would commonly >> be found in math expressions. > The C99 math/complex headers define a number of symbols. Sure, but you don't need all of those. My idea was thus: "Namespaces are one honking great idea" but they are kind of ugly inside math expressions. But: "Practicality beats purity" so I think it does make sense to bring the common names that show up in math expressions into the main namespace. Not all the handy little names ( like isnan, zeros, linspace, etc.) only the ones that show up in the depths of nested math expressions, so that we can write code that looks like math. That's how I came up with my personal list of 26. This is probably best just done by each individual according to his/her taste. Rob Hetland wrote: > I get namespaces. They are really great. It's just that I use numpy > and mpl *so* much that the namespaces get in the way. Maybe using Paul's suggestion of having a "math" namespace that you "import *" would help. Or use "from pylab import *" and reference just the numpy names you want separately. > And really, numpy and mpl coexist beautifully, except for a few small > exceptions. 'load' is one. (There are others I have run across as well). > > I think mpl should play nice even for folks like me who occasionally > like to abandon separate namespaces. But it does. numpy was designed pretty much to do just that -- give you one big namespace to import. And it provides the numerix interface as part of that. However, if you do that, you have to deal with the decisions MPL developers make. numpy is designed by a separate team, and is not designed to be "import *"ed into the pylab namespace (I think it is designed not to clash with the python built-ins at least). This is a common issue with packages developed by different people for similar purposes, and python already has namespaces as a great way to deal with it! Indeed, in this case, I suppose it's the numpy folks that aren't "playing nice" -- numpy.load was added after pylab.load was already there. But it's not a goal of the numpy team to be name-compatible with pylab. -Chris This is really is pretty OT for the devel list, though, so I'll stop here. -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Fri, Jul 20, 2007 at 02:53:42PM -0700, Christopher Barker wrote: > Paul Kienzle wrote: > > On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote: > >> Out of 491 names in the numpy namespace, I found 26 that would commonly > >> be found in math expressions. > > > The C99 math/complex headers define a number of symbols. > > Sure, but you don't need all of those. My idea was thus: > > "Namespaces are one honking great idea" > > but they are kind of ugly inside math expressions. But: > > "Practicality beats purity" > > so I think it does make sense to bring the common names that show up in > math expressions into the main namespace. Not all the handy little names > ( like isnan, zeros, linspace, etc.) only the ones that show up in the > depths of nested math expressions, so that we can write code that looks > like math. That's how I came up with my personal list of 26. > > This is probably best just done by each individual according to his/her > taste. That's what I'm trying to get away from. I want to be able to write the contains() function in patch.py and just use the normal math where it makes sense to use normal math. I suppose one approach is to go through all of mpl, find what is being imported with what frequency, and build the list based on that. Maybe I will get a chance this weekend. Right now I have to go back to the "matplotlib svn doesn't build on windows" problem. - Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
>> so I think it does make sense to bring the common names that show up in >> math expressions into the main namespace. >> This is probably best just done by each individual according to his/her >> taste. > > That's what I'm trying to get away from. I want to be able to write > the contains() function in patch.py and just use the normal math where > it makes sense to use normal math. Ahh -- we're back on an a mpl-devel topic now. I was thinking that you were proposing a "math" namespace for pylab users -- but it sounds like you're proposing a standard set of math names that will be brought in to modules for the matplotlib project itself. Different issue. I don't write enough MPL internal code to have any opinion on that. Does anyone else think this is a good idea? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch to fix examples
Thanks for applying the patch, Eric. I should also mention that there are two other problems that my patch didn't solve: In agg_resize.py: Traceback (most recent call last): File "_tmp_agg_resize.py", line 12, in interp = agg.span_interpolator_linear(imMatrix); AttributeError: 'module' object has no attribute 'span_interpolator_linear' In polar_bar.py: Traceback (most recent call last): File "_tmp_polar_bar.py", line 22, in bars = ax.bar(theta, radii, width=width, bottom=0.1) File "/home/stefan/lib/python2.5/site-packages/matplotlib/axes.py", line 3137, in bar xconv = self.xaxis.converter AttributeError: 'NoneType' object has no attribute 'converter' Cheers Stéfan On Fri, Jul 20, 2007 at 08:29:11AM -1000, Eric Firing wrote: > Stefan, > > Thanks. I will apply them shortly, after a bit of checking. (There > were commits after 3584, but things look easy enough to straighten out.) > > Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch to fix examples
Stefan van der Walt wrote: > Thanks for applying the patch, Eric. I should also mention that there > are two other problems that my patch didn't solve: Thank you for your patch, and for pointing out the additional problems. > > In agg_resize.py: > > Traceback (most recent call last): > File "_tmp_agg_resize.py", line 12, in > interp = agg.span_interpolator_linear(imMatrix); > AttributeError: 'module' object has no attribute 'span_interpolator_linear' This is broken because of a problem with the swig wrapper for agg, which is not used in present code but will be used in John's new version. > > In polar_bar.py: > > Traceback (most recent call last): > File "_tmp_polar_bar.py", line 22, in > bars = ax.bar(theta, radii, width=width, bottom=0.1) > File "/home/stefan/lib/python2.5/site-packages/matplotlib/axes.py", line > 3137, in bar > xconv = self.xaxis.converter > AttributeError: 'NoneType' object has no attribute 'converter' I fixed this in the bar method of axes; but this demo, as well as the hack I applied to bar, actually illustrates how poor our support for polar coordinates is right now. Solving this problem is one of the goals of the new version. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Polygon examples broken
On Jul 20, 2007, at 5:53 PM, Christopher Barker wrote: > However, I have seen a real shift on the numpy list over the last year > (or two), toward using the namespace. Yes, I do that to, primarily in scripts. However, for interactive sessions, I usually import into the top namespace. I imagine others might as well. Particularly people coming from environments like matlab will initially want everything up top. Separate namespaces are great. I still think from pylab import * should not overlap with from numpy import * I don't think it would be hard to make sure that there are no duplicate function names in the top namespace. E.g., mpl load could be put in mpl, matplotlib, or mpl_io, or something similar. People will migrate to separate namespaces eventually, as they get more familear with python, but they will be annoyed initially with any overlaps. -Rob Rob Hetland, Associate Professor Dept. of Oceanography, Texas A&M University http://pong.tamu.edu/~rob phone: 979-458-0096, fax: 979-845-6331 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
