From: John P. <joh...@st...> - 2006-04-18 00:11:32
|
Hi all I'm having a bit of trouble making sense of all the different numeric-array libraries that Matplotlib uses and allows. We're using Matplotlib as part of a larger application, and I want to make sure we use the best combination of libraries. Is it a case of 'whichever you like' or is one of the numeric-array libraries clearly better and more stable than the others? Also, what is Scipy doing these days? Is matplotlib still buried away inside it, as I believe it was, or have they switched to another plotting library altogether? I saw something about 'dynamic plots' but I wasn't sure it was at stable or development stage. Finally, from the documentation of Matplotlib, I got the impression that it would 'sniff out' and find a suitable numeric-array library. Instead it seems that it only tries to include one ('numeric' as I recall), and if you want to use any other one it won't try for it, you have to manually tell it so using something like the following. Would some automated attempt to load the numeric-array libraries, in order of most preferred to least preferred, be appropriate in the matplotlib code? import matplotlib import numarray matplotlib.rcParams['numerix'] = 'numarray' import pylab If I want to "back the winning horse" here, which numeric library should I tell the users of our software to install? Cheers JP -- John Pye Department of Mechanical and Manufacturing Engineering University of New South Wales, Sydney, Australia http://pye.dyndns.org/ |
From: Gary R. <gr...@bi...> - 2006-04-18 01:24:20
|
Hi John, John Pye wrote: > Hi all > > I'm having a bit of trouble making sense of all the different > numeric-array libraries that Matplotlib uses and allows. We're using > Matplotlib as part of a larger application, and I want to make sure we > use the best combination of libraries. > > Is it a case of 'whichever you like' or is one of the numeric-array > libraries clearly better and more stable than the others? They're all very stable, but I believe Numeric is explicitly not being supported anymore and numarray will probably eventually stop being supported in favour of numpy. numpy is very stable now, so my advice it to use numpy. This is an easier decision now than it was a few months ago since numpy will soon hit its 1.0 release. One post on this or the developer list suggested that Numeric and numarray support will eventually be removed from Matplotlib, but I think we are talking way off in the future for that. > Also, what is Scipy doing these days? Is matplotlib still buried away > inside it, as I believe it was, or have they switched to another > plotting library altogether? I saw something about 'dynamic plots' but I > wasn't sure it was at stable or development stage. Matplotlib was never a part of scipy. You may be thinking of gplt or xplt (from memory). Matplotlib remains completely separate from scipy but requires one of Numeric, numarray or numpy - your choice. > Finally, from the documentation of Matplotlib, I got the impression that > it would 'sniff out' and find a suitable numeric-array library. Instead > it seems that it only tries to include one ('numeric' as I recall), and > if you want to use any other one it won't try for it, you have to > manually tell it so using something like the following. Would some > automated attempt to load the numeric-array libraries, in order of most > preferred to least preferred, be appropriate in the matplotlib code? You're right; it doesn't sniff out the package you want, although I think it would be nice if it did. However, this will soon be unimportant because everyone will be using numpy and that will become the default. > import matplotlib > import numarray > matplotlib.rcParams['numerix'] = 'numarray' import pylab > > If I want to "back the winning horse" here, which numeric library should > I tell the users of our software to install? > > Cheers > JP Makybe Diva = numpy i.e. it's a one horse race. Gary |
From: Ryan K. <rya...@gm...> - 2006-04-18 02:24:55
|
just set numerix : numpy in your matplotlibrc and all will be happy. Ryan On 4/17/06, Gary Ruben <gr...@bi...> wrote: > Hi John, > > John Pye wrote: > > Hi all > > > > I'm having a bit of trouble making sense of all the different > > numeric-array libraries that Matplotlib uses and allows. We're using > > Matplotlib as part of a larger application, and I want to make sure we > > use the best combination of libraries. > > > > Is it a case of 'whichever you like' or is one of the numeric-array > > libraries clearly better and more stable than the others? > > They're all very stable, but I believe Numeric is explicitly not being > supported anymore and numarray will probably eventually stop being > supported in favour of numpy. numpy is very stable now, so my advice it > to use numpy. This is an easier decision now than it was a few months > ago since numpy will soon hit its 1.0 release. One post on this or the > developer list suggested that Numeric and numarray support will > eventually be removed from Matplotlib, but I think we are talking way > off in the future for that. > > > Also, what is Scipy doing these days? Is matplotlib still buried away > > inside it, as I believe it was, or have they switched to another > > plotting library altogether? I saw something about 'dynamic plots' but = I > > wasn't sure it was at stable or development stage. > > Matplotlib was never a part of scipy. You may be thinking of gplt or > xplt (from memory). Matplotlib remains completely separate from scipy > but requires one of Numeric, numarray or numpy - your choice. > > > Finally, from the documentation of Matplotlib, I got the impression tha= t > > it would 'sniff out' and find a suitable numeric-array library. Instead > > it seems that it only tries to include one ('numeric' as I recall), and > > if you want to use any other one it won't try for it, you have to > > manually tell it so using something like the following. Would some > > automated attempt to load the numeric-array libraries, in order of most > > preferred to least preferred, be appropriate in the matplotlib code? > > You're right; it doesn't sniff out the package you want, although I > think it would be nice if it did. However, this will soon be unimportant > because everyone will be using numpy and that will become the default. > > > import matplotlib > > import numarray > > matplotlib.rcParams['numerix'] =3D 'numarray' import pylab > > > > If I want to "back the winning horse" here, which numeric library shoul= d > > I tell the users of our software to install? > > > > Cheers > > JP > > Makybe Diva =3D numpy > > i.e. it's a one horse race. > > Gary > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
From: John P. <joh...@st...> - 2006-04-18 04:58:28
|
I don't have one and I don't think it's good design for my software installer to go creating one for people as part of a larger software installation. I think that sniffing would be a better (complementary, not replacement) solution, so that whichever the user decides to install, it just works. For now I will select numpy. Is that the one that Matplotlib looks for first? Ryan Krauss wrote: > just set > numerix : numpy > in your matplotlibrc and all will be happy. -- John Pye Department of Mechanical and Manufacturing Engineering University of New South Wales, Sydney, Australia http://pye.dyndns.org/ |
From: John H. <jdh...@ac...> - 2006-04-18 11:38:13
|
>>>>> "John" == John Pye <joh...@st...> writes: John> I don't have one and I don't think it's good design for my John> software installer to go creating one for people as part of John> a larger software installation. I think that sniffing would John> be a better (complementary, not replacement) solution, so John> that whichever the user decides to install, it just works. You have a few options. You can set the rc parameters inside your script, you do not need to change a system wide rc file from matplotlib import rcParams rcParams['numerix'] = 'numpy' #...now import matplotlib.numerix, pylab, etc... You can also provide per directory configuration files. Ie, you can create a matplotlibrc file (http://matplotlib.sf.net/matplotlibrc) in the same dir as your main-level script, and it will respect that one so you need not worry about overriding a system rc file when you install your software. John> For now I will select numpy. Is that the one that Matplotlib John> looks for first? There are two issues here: build time configuration and run time configuration. We used to do neither, now at built time we try and find one of numpy/numarray/Numeric (in that order) and then generate an rc file with the found one as the default. We could also do run time dynamic imports. I'm of two minds here: the more we try and do automatically, the harder it is to detect and fix bugs and problems when they arise. The setup is already pretty complex, if we are automatically choosing numerix and backend settings, I could see some difficulties in debugging problems. But I can see the advantages to it as well... JDH |
From: John P. <joh...@st...> - 2006-04-18 14:17:09
|
John Hunter wrote: > John> I don't have one and I don't think it's good design for my > John> software installer to go creating one for people as part of > John> a larger software installation. I think that sniffing would > John> be a better (complementary, not replacement) solution, so > John> that whichever the user decides to install, it just works. > > You have a few options. You can set the rc parameters inside your > script, you do not need to change a system wide rc file > > from matplotlib import rcParams > rcParams['numerix'] = 'numpy' > #...now import matplotlib.numerix, pylab, etc... > That's what I'm currently using, actually (see start of this thread). > You can also provide per directory configuration files. Ie, you can > create a matplotlibrc file (http://matplotlib.sf.net/matplotlibrc) in > the same dir as your main-level script, and it will respect that one > so you need not worry about overriding a system rc file when you > install your software. > I already have a config file for our application, if I did anything like this it would be to add an extra option to our existing config file, not create an additional one. Although this one was nice to know. > John> For now I will select numpy. Is that the one that Matplotlib > John> looks for first? > > There are two issues here: build time configuration and run time > configuration. We used to do neither, now at built time we try and > find one of numpy/numarray/Numeric (in that order) and then generate > an rc file with the found one as the default. > > We could also do run time dynamic imports. I'm of two minds here: the > more we try and do automatically, the harder it is to detect and fix > bugs and problems when they arise. The setup is already pretty > complex, if we are automatically choosing numerix and backend > settings, I could see some difficulties in debugging problems. But I > can see the advantages to it as well... > I'm thinking that *if* a preference has been specified, that should be used (and possibly throw and error if it fails). But if no preference is specified, then a sniffing approach should work, something like the following, which has worked for me without any issues so far, on a number of different platforms. This approach would facilitate debugging, knowing that you can force a particular numeric-array import. try: import psyco psyco.full() print "Running with PSYCO optimisation..." except ImportError: pass -- John Pye Department of Mechanical and Manufacturing Engineering University of New South Wales, Sydney, Australia http://pye.dyndns.org/ |
From: John P. <joh...@st...> - 2006-04-21 01:41:54
|
Hi John I implemented the sniffing for num* libraries in our own code, which maybe is of interest to other users: https://pse.cheme.cmu.edu/svn-view/ascend/code/trunk/pygtk/interface/gtkbrowser.py?rev=578&view=markup It's in about the second screenful there. I can see the reasoning for not having this code inside matplotlib, but for me, this does help to ease installation headaches for endusers. Cheers JP John Hunter wrote: >We could also do run time dynamic imports. I'm of two minds here: the >more we try and do automatically, the harder it is to detect and fix >bugs and problems when they arise. The setup is already pretty >complex, if we are automatically choosing numerix and backend >settings, I could see some difficulties in debugging problems. But I >can see the advantages to it as well... > > > |
From: Christopher B. <Chr...@no...> - 2006-04-21 16:58:30
|
John Pye wrote: > I implemented the sniffing for num* libraries in our own code, which > maybe is of interest to other users: I did something similar for my wxPython FloatCanvas, but I've been thinking that it should do something different: Rather than a pre-defined hierarchy of preference for package, perhaps it could start by check if any of the num* packages are loaded already. That way a user could so: import Numeric import matplotlib and MPL would use the Numeric that was already imported, rather than another. Just a thought. -Chris PS: I'm really looking forward to when we all just use numpy! -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Gary R. <gr...@bi...> - 2006-04-22 04:48:24
|
+1 on this way of working. I think you'd only want to trigger this if numerix was set to something like 'imported' or 'automatic'. However, if there's going to be a mass movement to numpy in the near future, I think this change should be a low priority. Gary R. Christopher Barker wrote: > John Pye wrote: >> I implemented the sniffing for num* libraries in our own code, which >> maybe is of interest to other users: > > I did something similar for my wxPython FloatCanvas, but I've been > thinking that it should do something different: > > Rather than a pre-defined hierarchy of preference for package, perhaps > it could start by check if any of the num* packages are loaded already. > That way a user could so: > > import Numeric > import matplotlib > > and MPL would use the Numeric that was already imported, rather than > another. > > Just a thought. > > -Chris > > PS: I'm really looking forward to when we all just use numpy! |