From david at ar.media.kyoto-u.ac.jp Tue Jul 1 03:57:06 2008 From: david at ar.media.kyoto-u.ac.jp (David Cournapeau) Date: Tue, 01 Jul 2008 16:57:06 +0900 Subject: [SciPy-dev] fftpack: what should the API for fftn be ? Message-ID: <4869E352.5080307@ar.media.kyoto-u.ac.jp> Hi, While taking a look at the ticket 244, there is something I don't quite understand about the current behaviour for scipy fftn. The problem in the ticket is that when both shape and axes arguments are given, fftn wrongly ignore axes when padding the input according to shape. OTOH, scipy fftn accepts shape and axes of different lengths (contrary to numpy fftn), and I don't understand the expected behavior in that case. Should we forbid the case len(shape) != len(axes); if not, what's the expected behavior ? cheers, David From cimrman3 at ntc.zcu.cz Tue Jul 1 10:13:46 2008 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 01 Jul 2008 16:13:46 +0200 Subject: [SciPy-dev] ANN: SfePy 00.46.02 Message-ID: <486A3B9A.8060106@ntc.zcu.cz> I am pleased announce the release of SfePy 00.46.02. SfePy is a finite element analysis software in Python, based primarily on Numpy and SciPy. Mailing lists, issue tracking, mercurial repository: http://sfepy.org Home page: http://sfepy.kme.zcu.cz Major improvements: - alternative short syntax for specifying essential boundary conditions, variables and regions - manufactured solutions tests: - SymPy support - site configuration now via script/config.py + site_cfg.py - new solvers - new terms For more information on this release, see http://sfepy.googlecode.com/svn/web/releases/004602_RELEASE_NOTES.txt If you happen to come to Leipzig for EuroSciPy 2008, see you there! Best regards, Robert Cimrman & SfePy developers From travis at enthought.com Wed Jul 2 10:34:01 2008 From: travis at enthought.com (Travis Vaught) Date: Wed, 2 Jul 2008 09:34:01 -0500 Subject: [SciPy-dev] Enthought Python Distribution Message-ID: <2D55089E-3CFC-42C0-A17D-FC4D3BF43793@enthought.com> Greetings, We're pleased to announce the beta release of the Enthought Python Distribution for *Mac OS X*. http://www.enthought.com/products/epd.php This release should safely install alongside other existing Python installations on your Mac. With the Mac OS X platform support, EPD now provides a consistent scientific application tool set across three major platforms (Windows, RedHat Linux (32 and 64 bit) and OS X). This is a _beta_ release, so install at your own risk. Please provide any feedback to info at enthought.com. See the included EPD Readme.txt for instructions and known issues. About EPD --------- The Enthought Python Distribution (EPD) is a "kitchen-sink-included" distribution of the Python? Programming Language, including over 60 additional tools and libraries. The EPD bundle includes the following major packages: Python Core Python NumPy Multidimensional arrays and fast numerics for Python SciPy Scientific Library for Python Enthought Tool Suite (ETS) A suite of tools including: Traits Manifest typing, validation, visualization, delegation, etc. Mayavi 3D interactive data exploration environment. Chaco Advanced 2D plotting toolkit for interactive 2D visualization. Kiva 2D drawing library in the spirit of DisplayPDF. Enable Object-based canvas for interacting with 2D components and widgets. Matplotlib 2D plotting library wxPython Cross-platform windowing and widget library. Visualization Toolkit (VTK) 3D visualization framework There are many more included packages as well. There's a complete list here: http://www.enthought.com/products/epdlibraries.php License ------- EPD is a bundle of software--every piece of which is available for free under various open-source licenses. The bundle itself is offered as a free download to academic and individual hobbyist use. Commercial and non-degree granting institutions and agencies may purchase individual subscriptions for the bundle (http://www.enthought.com/products/order.php?ver=MacOSX ) or contact Enthought to discuss an Enterprise license (http://www.enthought.com/products/enterprise.php ). Please see the FAQ for further explanation about how the software came together. (http://www.enthought.com/products/epdfaq.php) Thanks, Travis From pav at iki.fi Thu Jul 3 03:58:38 2008 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 3 Jul 2008 07:58:38 +0000 (UTC) Subject: [SciPy-dev] from scipy import * in r4484 doesn't load submodules Message-ID: Hi, It was so in Scipy 0.6 that >>> from scipy import * imported also the submodules 'optimize', 'integrate', 'special', 'linalg', etc, etc. to the namespace. It seems that this has changed in Scipy 0.7 SVN since that. Is removing these from __all__ and the API change intentional? (If it is, getting it to release notes would be nice.) -- Pauli Virtanen From robert.kern at gmail.com Thu Jul 3 04:00:59 2008 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 3 Jul 2008 03:00:59 -0500 Subject: [SciPy-dev] from scipy import * in r4484 doesn't load submodules In-Reply-To: References: Message-ID: <3d375d730807030100m532125b6k484fe67292a54bd2@mail.gmail.com> On Thu, Jul 3, 2008 at 02:58, Pauli Virtanen wrote: > Hi, > > It was so in Scipy 0.6 that > >>>> from scipy import * > > imported also the submodules 'optimize', 'integrate', 'special', > 'linalg', etc, etc. to the namespace. > > It seems that this has changed in Scipy 0.7 SVN since that. Is removing > these from __all__ and the API change intentional? (If it is, getting it > to release notes would be nice.) Yes. These were intended to have been removed long, long ago. They do not exist with just "import scipy". Their presence with "from scipy import *" was a bug that got fixed. -- 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 From jh at physics.ucf.edu Thu Jul 3 17:59:08 2008 From: jh at physics.ucf.edu (Joe Harrington) Date: Thu, 03 Jul 2008 17:59:08 -0400 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers Message-ID: This is an interim status report on the Summer Documentation Marathon. It is also an invitation and plea for all experienced users to participate! I am cross-posting in an effort to get broader participation. Please hold any discussion on the scipy-dev mailing list. As you know, our immediate goal is to produce first-draft docstrings for the user-visible parts of Numpy in time for a release before Fall classes (about 1 August). The short version is: We are really moving along! But, we need *your* help to make it in time for August. Here's the scoop: 1. We have all our infrastructure, standards, and procedure in place: We have a wiki that makes editing the docs easy and even fun. It communicates directly with the numpy sources. We have PDF and HTML reference guides being generated essentially automatically: http://sd-2116.dedibox.fr/pydocweb http://mentat.za.net/numpy/refguide/NumPy.pdf http://mentat.za.net/numpy/refguide/ The wiki front page contains or points to all you need to get started. The wiki lets you pull down a docstring with a few mouse clicks, edit on your machine, upload it, and see how it will look in its HTML version right away. You can also read everyone else's docstrings, comment on them, see the status of the project, and so on. The formatted versions necessarily lag the docstrings on the wiki because they are made whenever the docstrings are checked into the sources. 2. We have documented about 1/4 of numpy in a fairly professional way, comparable to the reference pages of the major commercial packages. The doc wiki is probably the next place to go if your question isn't answered by the docstring in the current version's help(), since you can look at the new docstrings we've generated, and they're *good*! 3. But, we're only 1/4 of the way there, we're halfway through the summer, and some of the initial enthusiasm is waning. The following page tells the tale: http://sd-2116.dedibox.fr/pydocweb/stats/ As you can see (you did click, right? please click...), there are 2323 numpy objects with docstrings. Of these, 1464 we deemed "unimportant" (for now). These are generally items not seen by regular users. This left 859 objects to document in this first pass. We've done 24% of them at this writing. Now, 24% is really exciting, and I'd like to take a moment to say a public "Hooray!" for the team (no particular order): St?fan van der Walt Pauli Virtanen Robert Hetland Gael Varoquaux Scott Sinclair Alan Jackson Tim Cera Johann Cohen-Tanugi David Huard Keith Goodman Together these ten have written around 7500 words of documentation on the community's behalf, mainly as volunteers. HOWEVER, we can all do the math. We've spent one of our two months. We are 1/4 of the way there. Progress is slowing, and even if it didn't, we wouldn't make it in time. This is not a sprint, it's a MARATHON. WE NEED YOUR HELP! And we need it now. Are you excited by the idea of having documentation for numpy by the Fall release? Of having docs that answer your questions, that have *good* examples, that really save you time? If so, then please invest just a fraction of the time that documentation will save you in the next year alone by signing up on the wiki and writing some. If each experienced user wrote just a few pages, we'd be done! If you don't think you know enough to write, then do some reviewing. Are the docs readable? Do you understand the examples? Each docstring on the wiki has an easy comment box waiting for your thoughts. You will have a reference guide in the next release of numpy! I hope you will help make it a complete one. Sign up on the doc wiki today: http://sd-2116.dedibox.fr/pydocweb/ Thanks, --jh-- and the SciPy Doc Team Prof. Joseph Harrington Department of Physics MAP 414 4000 Central Florida Blvd. University of Central Florida Orlando, FL 32816-2385 (407) 823-3416 voice (407) 823-5112 fax (407) 823-2325 physics office jh at physics.ucf.edu From roban at astro.columbia.edu Fri Jul 4 12:35:33 2008 From: roban at astro.columbia.edu (Roban Kramer) Date: Fri, 4 Jul 2008 12:35:33 -0400 Subject: [SciPy-dev] joining the effort Message-ID: <463180e60807040935te3acf92t48bc27ce936b95f5@mail.gmail.com> Hi, I'd like to join the docstrings marathon. I probably won't get to contribute until I'm back from a conference in a week or so, but I'd guess I'll mostly be reviewing and proofreading, though I could do some editing, too. Thanks, Roban From roban at astro.columbia.edu Fri Jul 4 12:36:03 2008 From: roban at astro.columbia.edu (Roban Kramer) Date: Fri, 4 Jul 2008 12:36:03 -0400 Subject: [SciPy-dev] joining the effort In-Reply-To: <463180e60807040935te3acf92t48bc27ce936b95f5@mail.gmail.com> References: <463180e60807040935te3acf92t48bc27ce936b95f5@mail.gmail.com> Message-ID: <463180e60807040936x1575b8b8jf67b0b7ed65633da@mail.gmail.com> Oh, uh... the username's RobanKramer On Fri, Jul 4, 2008 at 12:35 PM, Roban Kramer wrote: > Hi, > > I'd like to join the docstrings marathon. I probably won't get to > contribute until I'm back from a conference in a week or so, but I'd > guess I'll mostly be reviewing and proofreading, though I could do > some editing, too. > > Thanks, > Roban > From pav at iki.fi Fri Jul 4 14:10:12 2008 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 4 Jul 2008 18:10:12 +0000 (UTC) Subject: [SciPy-dev] joining the effort References: <463180e60807040935te3acf92t48bc27ce936b95f5@mail.gmail.com> <463180e60807040936x1575b8b8jf67b0b7ed65633da@mail.gmail.com> Message-ID: > On Fri, Jul 4, 2008 at 12:35 PM, Roban Kramer > wrote: >> I'd like to join the docstrings marathon. I probably won't get to >> contribute until I'm back from a conference in a week or so, but I'd >> guess I'll mostly be reviewing and proofreading, though I could do some >> editing, too. Thanks, feel free to edit/review when you have time. -- Pauli Virtanen From nwagner at iam.uni-stuttgart.de Fri Jul 4 16:05:39 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 04 Jul 2008 22:05:39 +0200 Subject: [SciPy-dev] http://projects.scipy.org/scipy/scipy/ticket/573 and mkufunc Message-ID: Hi, There seems to be a conflict of interest between http://projects.scipy.org/scipy/scipy/ticket/573 and the recent sandbox package mkufunc. Nils From alan at ajackson.org Fri Jul 4 21:40:31 2008 From: alan at ajackson.org (Alan Jackson) Date: Fri, 4 Jul 2008 20:40:31 -0500 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: References: Message-ID: <20080704204031.16e13896@ajackson.org> Let me add to the plea. I'm not actually *that* experienced a user - at least with numpy and python. But I can learn enough to write documentation, and it is forcing me to improve my numpy skills and knowledge, as well as deepening my knowledge of statistics (I've been working on the distributions). My point is this - you don't have to be an expert - you just have to be willing to expend some effort learning enough to write a document. And that effort will pay dividends - the best way to learn something is to teach or document it. Working on one of the docstrings already gave me an idea for a research project! On Thu, 03 Jul 2008 17:59:08 -0400 Joe Harrington wrote: > This is an interim status report on the Summer Documentation Marathon. > It is also an invitation and plea for all experienced users to > participate! I am cross-posting in an effort to get broader > participation. Please hold any discussion on the scipy-dev mailing > list. > > As you know, our immediate goal is to produce first-draft docstrings > for the user-visible parts of Numpy in time for a release before Fall > classes (about 1 August). The short version is: We are really moving > along! But, we need *your* help to make it in time for August. > > Here's the scoop: > > 1. We have all our infrastructure, standards, and procedure in place: > We have a wiki that makes editing the docs easy and even fun. It > communicates directly with the numpy sources. We have PDF and HTML > reference guides being generated essentially automatically: > > http://sd-2116.dedibox.fr/pydocweb > http://mentat.za.net/numpy/refguide/NumPy.pdf > http://mentat.za.net/numpy/refguide/ > > The wiki front page contains or points to all you need to get started. > > The wiki lets you pull down a docstring with a few mouse clicks, edit > on your machine, upload it, and see how it will look in its HTML > version right away. You can also read everyone else's docstrings, > comment on them, see the status of the project, and so on. The > formatted versions necessarily lag the docstrings on the wiki because > they are made whenever the docstrings are checked into the sources. > > 2. We have documented about 1/4 of numpy in a fairly professional way, > comparable to the reference pages of the major commercial packages. > The doc wiki is probably the next place to go if your question isn't > answered by the docstring in the current version's help(), since you > can look at the new docstrings we've generated, and they're *good*! > > 3. But, we're only 1/4 of the way there, we're halfway through the > summer, and some of the initial enthusiasm is waning. The following > page tells the tale: > > http://sd-2116.dedibox.fr/pydocweb/stats/ > > As you can see (you did click, right? please click...), there are > 2323 numpy objects with docstrings. Of these, 1464 we deemed > "unimportant" (for now). These are generally items not seen by > regular users. This left 859 objects to document in this first pass. > We've done 24% of them at this writing. > > Now, 24% is really exciting, and I'd like to take a moment to say a > public "Hooray!" for the team (no particular order): > > St?fan van der Walt Pauli Virtanen > Robert Hetland Gael Varoquaux > Scott Sinclair Alan Jackson > Tim Cera Johann Cohen-Tanugi > David Huard Keith Goodman > > Together these ten have written around 7500 words of documentation on > the community's behalf, mainly as volunteers. > > HOWEVER, we can all do the math. We've spent one of our two months. > We are 1/4 of the way there. Progress is slowing, and even if it > didn't, we wouldn't make it in time. This is not a sprint, it's a > MARATHON. > > WE NEED YOUR HELP! > > And we need it now. Are you excited by the idea of having > documentation for numpy by the Fall release? Of having docs that > answer your questions, that have *good* examples, that really save you > time? If so, then please invest just a fraction of the time that > documentation will save you in the next year alone by signing up on > the wiki and writing some. If each experienced user wrote just a few > pages, we'd be done! > > If you don't think you know enough to write, then do some reviewing. > Are the docs readable? Do you understand the examples? Each > docstring on the wiki has an easy comment box waiting for your > thoughts. > > You will have a reference guide in the next release of numpy! I hope > you will help make it a complete one. Sign up on the doc wiki today: > > http://sd-2116.dedibox.fr/pydocweb/ > > Thanks, > > --jh-- and the SciPy Doc Team > > Prof. Joseph Harrington > Department of Physics > MAP 414 > 4000 Central Florida Blvd. > University of Central Florida > Orlando, FL 32816-2385 > (407) 823-3416 voice > (407) 823-5112 fax > (407) 823-2325 physics office > jh at physics.ucf.edu > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev -- ----------------------------------------------------------------------- | Alan K. Jackson | To see a World in a Grain of Sand | | alan at ajackson.org | And a Heaven in a Wild Flower, | | www.ajackson.org | Hold Infinity in the palm of your hand | | Houston, Texas | And Eternity in an hour. - Blake | ----------------------------------------------------------------------- From ralf.gommers at googlemail.com Sat Jul 5 00:44:31 2008 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 5 Jul 2008 00:44:31 -0400 Subject: [SciPy-dev] joining the docs marathon Message-ID: Hi, I would like to help out with the documentation effort. The results look great so far, thanks for pushing hard for this! I'd like to do both reviewing and editing, and registered as RalfGommers. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From strawman at astraw.com Sat Jul 5 03:54:56 2008 From: strawman at astraw.com (Andrew Straw) Date: Sat, 05 Jul 2008 00:54:56 -0700 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: References: Message-ID: <486F28D0.2090307@astraw.com> One thing I notice about the organization of the doc site that seems sub-optimal is that functions are resolved to the module where they're defined rather than their canonical namespace. In particular, clicking on the page for array() from the main numpy page gives me a page with the primary header saying "numpy.core.multiarray.array". I think that's confusing, particularly to new users. All the more so since I believe the "numpy.core" namespace is more-or-less for internal implementation and it is discouraged to write external code referencing into numpy.core. OK, I'll shut up now until I actually do some writing or editing on the doc strings. -Andrew Joe Harrington wrote: > This is an interim status report on the Summer Documentation Marathon. > It is also an invitation and plea for all experienced users to > participate! I am cross-posting in an effort to get broader > participation. Please hold any discussion on the scipy-dev mailing > list. > > As you know, our immediate goal is to produce first-draft docstrings > for the user-visible parts of Numpy in time for a release before Fall > classes (about 1 August). The short version is: We are really moving > along! But, we need *your* help to make it in time for August. > > Here's the scoop: > > 1. We have all our infrastructure, standards, and procedure in place: > We have a wiki that makes editing the docs easy and even fun. It > communicates directly with the numpy sources. We have PDF and HTML > reference guides being generated essentially automatically: > > http://sd-2116.dedibox.fr/pydocweb > http://mentat.za.net/numpy/refguide/NumPy.pdf > http://mentat.za.net/numpy/refguide/ > > The wiki front page contains or points to all you need to get started. > > The wiki lets you pull down a docstring with a few mouse clicks, edit > on your machine, upload it, and see how it will look in its HTML > version right away. You can also read everyone else's docstrings, > comment on them, see the status of the project, and so on. The > formatted versions necessarily lag the docstrings on the wiki because > they are made whenever the docstrings are checked into the sources. > > 2. We have documented about 1/4 of numpy in a fairly professional way, > comparable to the reference pages of the major commercial packages. > The doc wiki is probably the next place to go if your question isn't > answered by the docstring in the current version's help(), since you > can look at the new docstrings we've generated, and they're *good*! > > 3. But, we're only 1/4 of the way there, we're halfway through the > summer, and some of the initial enthusiasm is waning. The following > page tells the tale: > > http://sd-2116.dedibox.fr/pydocweb/stats/ > > As you can see (you did click, right? please click...), there are > 2323 numpy objects with docstrings. Of these, 1464 we deemed > "unimportant" (for now). These are generally items not seen by > regular users. This left 859 objects to document in this first pass. > We've done 24% of them at this writing. > > Now, 24% is really exciting, and I'd like to take a moment to say a > public "Hooray!" for the team (no particular order): > > St?fan van der Walt Pauli Virtanen > Robert Hetland Gael Varoquaux > Scott Sinclair Alan Jackson > Tim Cera Johann Cohen-Tanugi > David Huard Keith Goodman > > Together these ten have written around 7500 words of documentation on > the community's behalf, mainly as volunteers. > > HOWEVER, we can all do the math. We've spent one of our two months. > We are 1/4 of the way there. Progress is slowing, and even if it > didn't, we wouldn't make it in time. This is not a sprint, it's a > MARATHON. > > WE NEED YOUR HELP! > > And we need it now. Are you excited by the idea of having > documentation for numpy by the Fall release? Of having docs that > answer your questions, that have *good* examples, that really save you > time? If so, then please invest just a fraction of the time that > documentation will save you in the next year alone by signing up on > the wiki and writing some. If each experienced user wrote just a few > pages, we'd be done! > > If you don't think you know enough to write, then do some reviewing. > Are the docs readable? Do you understand the examples? Each > docstring on the wiki has an easy comment box waiting for your > thoughts. > > You will have a reference guide in the next release of numpy! I hope > you will help make it a complete one. Sign up on the doc wiki today: > > http://sd-2116.dedibox.fr/pydocweb/ > > Thanks, > > --jh-- and the SciPy Doc Team > > Prof. Joseph Harrington > Department of Physics > MAP 414 > 4000 Central Florida Blvd. > University of Central Florida > Orlando, FL 32816-2385 > (407) 823-3416 voice > (407) 823-5112 fax > (407) 823-2325 physics office > jh at physics.ucf.edu > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > From david at ar.media.kyoto-u.ac.jp Sat Jul 5 06:29:13 2008 From: david at ar.media.kyoto-u.ac.jp (David Cournapeau) Date: Sat, 05 Jul 2008 19:29:13 +0900 Subject: [SciPy-dev] [numscons] 0.8.1 released Message-ID: <486F4CF9.9060606@ar.media.kyoto-u.ac.jp> Hi, I am pleased to announce numscons 0.8.1. numscons is a tentative for a new build system for numpy/scipy and other packages depending on numpy.distutils for extension code. You can get it through the usual channels: http://projects.scipy.org/scipy/numpy/wiki/NumScons I did not announce releases of numscons for quite some time, but this did not mean I did not continue working on numscons. The goal is to have a beta available for scipy conference in August, where I will present numscons. Most changes since 0.8.0 are internal, with code simplification (compiler customization, etc...). The goal is to put most of the code upstream into scons (numscons is now around 3700 lines of code, and I hope to be able to reduce this to ~ 2000 lines of code). In particular: - no custom code for fortran anymore, everything is now integrated upstream. - python extensions are now built using a scons tool. This means more reliability, and hopefully at some point upstream integration. There are still some rough edges, but hopefully, nothing fundamental. - VS 2003/2005/2008 are supported as well (numpy can build with python 2.6 alpha and Visual Studio express), using a method similar to distutils in python 2.6 to get informations from the var*.bat files (much simpler and more robust than relying on the brain-dead registry). Since 0.8, the changes are not backward compatible with < 0.8. In particular the names of python builders have changed, and you should now use 2 scons scripts instead of one. I am sorry I have not yet updated the documentation, but I really want to get a beta ready for scipy conference, and I don't have so much time to keep the doc in sync. The examples are up to date, though. cheers, David From pav at iki.fi Sat Jul 5 08:53:23 2008 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 5 Jul 2008 12:53:23 +0000 (UTC) Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers References: <486F28D0.2090307@astraw.com> Message-ID: Sat, 05 Jul 2008 00:54:56 -0700, Andrew Straw wrote: > One thing I notice about the organization of the doc site that seems > sub-optimal is that functions are resolved to the module where they're > defined rather than their canonical namespace. In particular, clicking > on the page for array() from the main numpy page gives me a page with > the primary header saying "numpy.core.multiarray.array". I think that's > confusing, particularly to new users. All the more so since I believe > the "numpy.core" namespace is more-or-less for internal implementation > and it is discouraged to write external code referencing into > numpy.core. It's a kind of a feature: a "canonical namespace" is not a well-defined concept, so it makes sense for the program to use the location where the object is defined as a "canonical name". This is always unique and it's actually possible to deduce it automatically just by looking at the Python object. So, there are technical reasons for using it. But I think you're referring more to the names appearing in the UI than the internal architecture. It is possible to map the names displayed to the aliases with the least number of dots, which I guess is as close to a "canonical namespace" as you can automatically get. -- Pauli Virtanen From vanforeest at gmail.com Sat Jul 5 16:19:11 2008 From: vanforeest at gmail.com (nicky van foreest) Date: Sat, 5 Jul 2008 22:19:11 +0200 Subject: [SciPy-dev] scipy documentation marathon Message-ID: Dear all, I like to participate as a reviewer in the documentation marathon. Thanks for all the effort you put into this. bye Nicky From jh at physics.ucf.edu Sun Jul 6 09:55:45 2008 From: jh at physics.ucf.edu (Joe Harrington) Date: Sun, 06 Jul 2008 09:55:45 -0400 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: <486F28D0.2090307@astraw.com> (message from Andrew Straw on Sat, 05 Jul 2008 00:54:56 -0700) References: <486F28D0.2090307@astraw.com> Message-ID: Thanks to all who have signed up since my update email, we've done another 5%! Woohoo! Let's all do it! We're putting together some sort of prize idea for the conference. Would folks prefer: colored conference badge ribbon T-shirt button dessert on me graphic for your personal website copy of the printed PDF autographed by Stefan van der Walt something else? You get a + for every 250 words you've written at the time you vote! You can total your score from the stats page: http://sd-2116.dedibox.fr/pydocweb/stats/ In order to allow people to buy as many votes as possible, we'll set the close of voting as midnight PDT Friday. Offer subject to logistical reality (i.e., a conversation with our accountant about legal uses of certain kinds of funds). I guess that makes this our MID-SUMMER DOCUMENTATION WIND SPRINT! readysetgo! Andrew Straw says: > One thing I notice about the organization of the doc site that seems > sub-optimal is that functions are resolved to the module where they're > defined rather than their canonical namespace. In particular, clicking > on the page for array() from the main numpy page gives me a page with > the primary header saying "numpy.core.multiarray.array". I think that's > confusing, particularly to new users. All the more so since I believe > the "numpy.core" namespace is more-or-less for internal implementation > and it is discouraged to write external code referencing into numpy.core. Keep your EYES on the PRIZE: *write*! Woohoo! ;-) --jh-- From vanforeest at gmail.com Sun Jul 6 13:29:19 2008 From: vanforeest at gmail.com (nicky van foreest) Date: Sun, 6 Jul 2008 19:29:19 +0200 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: References: <486F28D0.2090307@astraw.com> Message-ID: Dear Joe, Yesterday I sent a mail to the scipy-dev mailing list as a volunteer to review. However, I have not received any mail to show me that my rights would change. Is this perhaps the standard procedure? Thanks in advance, and even more for the initiative for taking up the documentation marathon. bye Nicky 2008/7/6 Joe Harrington : > Thanks to all who have signed up since my update email, we've done > another 5%! Woohoo! Let's all do it! > > We're putting together some sort of prize idea for the conference. > Would folks prefer: > > colored conference badge ribbon > T-shirt > button > dessert on me > graphic for your personal website > copy of the printed PDF autographed by Stefan van der Walt > something else? > > You get a + for every 250 words you've written at the time you vote! > You can total your score from the stats page: > > http://sd-2116.dedibox.fr/pydocweb/stats/ > > In order to allow people to buy as many votes as possible, we'll set > the close of voting as midnight PDT Friday. Offer subject to > logistical reality (i.e., a conversation with our accountant about > legal uses of certain kinds of funds). I guess that makes this our > > MID-SUMMER DOCUMENTATION WIND SPRINT! > > readysetgo! > > Andrew Straw says: > >> One thing I notice about the organization of the doc site that seems >> sub-optimal is that functions are resolved to the module where they're >> defined rather than their canonical namespace. In particular, clicking >> on the page for array() from the main numpy page gives me a page with >> the primary header saying "numpy.core.multiarray.array". I think that's >> confusing, particularly to new users. All the more so since I believe >> the "numpy.core" namespace is more-or-less for internal implementation >> and it is discouraged to write external code referencing into numpy.core. > > Keep your EYES on the PRIZE: *write*! Woohoo! ;-) > > --jh-- > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > From pav at iki.fi Sun Jul 6 16:56:42 2008 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 6 Jul 2008 20:56:42 +0000 (UTC) Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers References: <486F28D0.2090307@astraw.com> Message-ID: Hi Nicky, Sun, 06 Jul 2008 19:29:19 +0200, nicky van foreest wrote: > Yesterday I sent a mail to the scipy-dev mailing list as a volunteer to > review. However, I have not received any mail to show me that my rights > would change. Is this perhaps the standard procedure? I added the permissions for your account yesterday, but perhaps the mail I sent has not arrived. You should be able to leave comments & etc., but if not, please tell and we'll check if something is wrong. Best regards, Pauli From stefan at sun.ac.za Sun Jul 6 18:00:49 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 7 Jul 2008 00:00:49 +0200 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: References: <486F28D0.2090307@astraw.com> Message-ID: <9457e7c80807061500n8386a92q9fdc4c19d35ddfd3@mail.gmail.com> 2008/7/6 Joe Harrington : > We're putting together some sort of prize idea for the conference. > Would folks prefer: > > colored conference badge ribbon > T-shirt > button > dessert on me > graphic for your personal website > copy of the printed PDF autographed by Stefan van der Walt > something else? I don't see Free Beer on the list above. Last time I looked, that was worth a lot more than my signature... Cheers St?fan From jh at physics.ucf.edu Sun Jul 6 22:32:06 2008 From: jh at physics.ucf.edu (Joe Harrington) Date: Sun, 06 Jul 2008 22:32:06 -0400 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: (vanforeest@gmail.com) References: <486F28D0.2090307@astraw.com> Message-ID: Hi Nicky, Glad to have you on board for reviewing! Stefan or Pauli will get you added to the editor group on the wiki shortly. It's the weekend, so give them a day. We're being careful about wiki access: With over 2000 pages, it would be easy for someone unknown to us to mess with what we've done without our notice, or to spam the thing. Meanwhile, please familiarize yourself with the writing standards linked from the front page of the wiki. Once you have read the writing standards, you can start reading docstrings and making notes to enter in the comment areas when your account is active. We're in the final stages of putting together review criteria; you'll see those this week. Please wait for the review criteria before you mark anything as having passed review. It's been great to see how much progress has been made just this weekend: 20% of all the words written were written since I made my update post! Many hands make light work... --jh-- From cohen at slac.stanford.edu Mon Jul 7 00:44:03 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Sun, 06 Jul 2008 21:44:03 -0700 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: References: <486F28D0.2090307@astraw.com> Message-ID: <48719F13.80203@slac.stanford.edu> Sorry to ask a stupid question, but do you have a backup out of the network, just to be on the safe side? best, Johann Joe Harrington wrote: > Hi Nicky, > > Glad to have you on board for reviewing! Stefan or Pauli will get you > added to the editor group on the wiki shortly. It's the weekend, so > give them a day. We're being careful about wiki access: With over > 2000 pages, it would be easy for someone unknown to us to mess with > what we've done without our notice, or to spam the thing. Meanwhile, > please familiarize yourself with the writing standards linked from the > front page of the wiki. Once you have read the writing standards, you > can start reading docstrings and making notes to enter in the comment > areas when your account is active. We're in the final stages of > putting together review criteria; you'll see those this week. Please > wait for the review criteria before you mark anything as having passed > review. > > It's been great to see how much progress has been made just this > weekend: 20% of all the words written were written since I made my > update post! Many hands make light work... > > --jh-- > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > From pav at iki.fi Mon Jul 7 03:35:07 2008 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 7 Jul 2008 07:35:07 +0000 (UTC) Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers References: <486F28D0.2090307@astraw.com> <48719F13.80203@slac.stanford.edu> Message-ID: Sun, 06 Jul 2008 21:44:03 -0700, Johann Cohen-Tanugi wrote: > Sorry to ask a stupid question, but do you have a backup out of the > network, just to be on the safe side? Yes, the database is backed up daily, off-site. Pauli From vanforeest at gmail.com Tue Jul 8 16:43:33 2008 From: vanforeest at gmail.com (nicky van foreest) Date: Tue, 8 Jul 2008 22:43:33 +0200 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: References: <486F28D0.2090307@astraw.com> Message-ID: Hi, Sorry for a perhaps very basic question. I just took up the task of reviewing some entries. In the entry on the arccos I found an example that runs nearly out of the box. However, the example states to import matplotlib, while the demos on matplotlib use "from pylab import *". Is there any policy on what would be the "most" correct way to import libraries. Besides this, should examples always include the string "import numpy as np", or is this implicit? The problem is that I now had to complete the example with this import. I would prefer to use examples in the documentation that works completely foolproof, hence, include the string "import numpy as np" wherever appropriate. What is the policy on this? Thanks bye Nicky From stefan at sun.ac.za Tue Jul 8 17:00:06 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 8 Jul 2008 23:00:06 +0200 Subject: [SciPy-dev] Summer Doc Marathon status report and request for more writers In-Reply-To: References: <486F28D0.2090307@astraw.com> Message-ID: <9457e7c80807081400l7934ffeesad4419cef6151f4f@mail.gmail.com> 2008/7/8 nicky van foreest : > I just took up the task of reviewing some entries. In the entry on the > arccos I found an example that runs nearly out of the box. However, > the example states to import matplotlib, while the demos on matplotlib > use "from pylab import *". Is there any policy on what would be the > "most" correct way to import libraries. Besides this, should examples > always include the string "import numpy as np", or is this implicit? > The problem is that I now had to complete the example with this > import. I would prefer to use examples in the documentation that > works completely foolproof, hence, include the string "import numpy as > np" wherever appropriate. What is the policy on this? >From http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines#docstring-standard: """ The examples may assume that import numpy as np is executed before the example code in numpy, and import scipy as sp in scipy. Additional examples may make use of matplotlib for plotting, but should import it explicitly, e.g., import matplotlib.pyplot as plt. """ Regards St?fan From alan at ajackson.org Tue Jul 8 20:46:53 2008 From: alan at ajackson.org (Alan Jackson) Date: Tue, 8 Jul 2008 19:46:53 -0500 Subject: [SciPy-dev] possible bug in numpy.random.zipf Message-ID: <20080708194653.4bc5477b@ajackson.org> I think I may have found a bug in numpy.random.zipf As I was documenting the zipf function, I started playing with it to create some examples. It's pretty cool, actually. I had never heard of it before. To my surprise, it started giving occasional very large negative numbers as results whenever the 'a' parameter was less than 1.5. It appears that there is some numerical instability for parameters less than 1.5. In [44]: min(np.random.zipf(1.4, 1000)) Out[44]: 1 In [45]: min(np.random.zipf(1.4, 1000)) Out[45]: -2147483648 In [46]: min(np.random.zipf(1.4, 1000)) Out[46]: 1 In [47]: min(np.random.zipf(1.4, 1000)) Out[47]: 1 In [48]: min(np.random.zipf(1.4, 1000)) Out[48]: 1 In [49]: min(np.random.zipf(1.4, 1000)) Out[49]: 1 The minimum value should never be less than 1, I think. -- ----------------------------------------------------------------------- | Alan K. Jackson | To see a World in a Grain of Sand | | alan at ajackson.org | And a Heaven in a Wild Flower, | | www.ajackson.org | Hold Infinity in the palm of your hand | | Houston, Texas | And Eternity in an hour. - Blake | ----------------------------------------------------------------------- From robert.kern at gmail.com Tue Jul 8 21:54:54 2008 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 8 Jul 2008 20:54:54 -0500 Subject: [SciPy-dev] possible bug in numpy.random.zipf In-Reply-To: <20080708194653.4bc5477b@ajackson.org> References: <20080708194653.4bc5477b@ajackson.org> Message-ID: <3d375d730807081854x70e19407j986767df0df56b77@mail.gmail.com> On Tue, Jul 8, 2008 at 19:46, Alan Jackson wrote: > I think I may have found a bug in numpy.random.zipf > > As I was documenting the zipf function, I started playing with it to create > some examples. It's pretty cool, actually. I had never heard of it > before. > > To my surprise, it started giving occasional very large negative numbers as > results whenever the 'a' parameter was less than 1.5. It appears that > there is some numerical instability for parameters less than 1.5. > > In [44]: min(np.random.zipf(1.4, 1000)) > Out[44]: 1 > > In [45]: min(np.random.zipf(1.4, 1000)) > Out[45]: -2147483648 This looks like an integer wraparound problem rather than numerical instability per se. The correct result is above upper bound that a signed long can represent. It gets casted to -sys.maxint-1. Since the algorithm is just a simple rejection algorithm, we can include this test in the rejection condition. The function then models a Zipf distribution truncated to the range [1,sys.maxint]. The fix will be in SVN on the trunk and 1.1.x branch shortly. -- 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 From bsouthey at gmail.com Wed Jul 9 09:56:40 2008 From: bsouthey at gmail.com (Bruce Southey) Date: Wed, 09 Jul 2008 08:56:40 -0500 Subject: [SciPy-dev] possible bug in numpy.random.zipf In-Reply-To: <3d375d730807081854x70e19407j986767df0df56b77@mail.gmail.com> References: <20080708194653.4bc5477b@ajackson.org> <3d375d730807081854x70e19407j986767df0df56b77@mail.gmail.com> Message-ID: <4874C398.2090003@gmail.com> Robert Kern wrote: > On Tue, Jul 8, 2008 at 19:46, Alan Jackson wrote: > >> I think I may have found a bug in numpy.random.zipf >> >> As I was documenting the zipf function, I started playing with it to create >> some examples. It's pretty cool, actually. I had never heard of it >> before. >> >> To my surprise, it started giving occasional very large negative numbers as >> results whenever the 'a' parameter was less than 1.5. It appears that >> there is some numerical instability for parameters less than 1.5. >> >> In [44]: min(np.random.zipf(1.4, 1000)) >> Out[44]: 1 >> >> In [45]: min(np.random.zipf(1.4, 1000)) >> Out[45]: -2147483648 >> > > This looks like an integer wraparound problem rather than numerical > instability per se. The correct result is above upper bound that a > signed long can represent. It gets casted to -sys.maxint-1. Since the > algorithm is just a simple rejection algorithm, we can include this > test in the rejection condition. The function then models a Zipf > distribution truncated to the range [1,sys.maxint]. > > The fix will be in SVN on the trunk and 1.1.x branch shortly. > > Hi, Shouldn't this really depend on the precision being used because NumPy provides different precisions? Also sys.maxint will be history in Python 3.0 (http://docs.python.org/dev/3.0/whatsnew/3.0?highlight=maxint) as '[i]ntegers have unlimited precision'. Instead it could be sys.maxsize (http://docs.python.org/dev/3.0/library/sys.html#sys.maxsize) . Bruce From millman at berkeley.edu Wed Jul 9 13:04:29 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Wed, 9 Jul 2008 10:04:29 -0700 Subject: [SciPy-dev] REMINDER: SciPy 2008 Early Registration ends in 2 days Message-ID: Hello, This is a reminder that early registration for SciPy 2008 ends in two days on Friday, July 11th. To register, please see: http://conference.scipy.org/to_register This year's conference has two days for tutorials, two days of presentations, and ends with a two day coding sprint. If you want to learn more see my blog post: http://jarrodmillman.blogspot.com/2008/07/scipy-2008-conference-program-posted.html Cheers, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From robert.kern at gmail.com Wed Jul 9 15:22:38 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 9 Jul 2008 14:22:38 -0500 Subject: [SciPy-dev] possible bug in numpy.random.zipf In-Reply-To: <4874C398.2090003@gmail.com> References: <20080708194653.4bc5477b@ajackson.org> <3d375d730807081854x70e19407j986767df0df56b77@mail.gmail.com> <4874C398.2090003@gmail.com> Message-ID: <3d375d730807091222k67d7b517l81de0c4656497546@mail.gmail.com> On Wed, Jul 9, 2008 at 08:56, Bruce Southey wrote: > Robert Kern wrote: >> On Tue, Jul 8, 2008 at 19:46, Alan Jackson wrote: >> >>> I think I may have found a bug in numpy.random.zipf >>> >>> As I was documenting the zipf function, I started playing with it to create >>> some examples. It's pretty cool, actually. I had never heard of it >>> before. >>> >>> To my surprise, it started giving occasional very large negative numbers as >>> results whenever the 'a' parameter was less than 1.5. It appears that >>> there is some numerical instability for parameters less than 1.5. >>> >>> In [44]: min(np.random.zipf(1.4, 1000)) >>> Out[44]: 1 >>> >>> In [45]: min(np.random.zipf(1.4, 1000)) >>> Out[45]: -2147483648 >>> >> >> This looks like an integer wraparound problem rather than numerical >> instability per se. The correct result is above upper bound that a >> signed long can represent. It gets casted to -sys.maxint-1. Since the >> algorithm is just a simple rejection algorithm, we can include this >> test in the rejection condition. The function then models a Zipf >> distribution truncated to the range [1,sys.maxint]. >> >> The fix will be in SVN on the trunk and 1.1.x branch shortly. >> >> > Hi, > > Shouldn't this really depend on the precision being used because NumPy > provides different precisions? numpy in general handles multiple precisions, but this function does not. It just produces C longs which corresponds to the default numpy integer dtype. > Also sys.maxint will be history in Python 3.0 > (http://docs.python.org/dev/3.0/whatsnew/3.0?highlight=maxint) as > '[i]ntegers have unlimited precision'. Instead it could be sys.maxsize > (http://docs.python.org/dev/3.0/library/sys.html#sys.maxsize) . I don't reference sys.maxint explicitly; it just happens to correspond to the overflow limit on the currently available platforms. When the putative result is < 1, I assume that overflow happened and reject it. When Python 3.0 rolls along, the only thing that will be out-of-date is the comment. -- 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 From nwagner at iam.uni-stuttgart.de Thu Jul 10 02:30:28 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 10 Jul 2008 08:30:28 +0200 Subject: [SciPy-dev] svn access Message-ID: Hi all, If I do svn co http://svn.scipy.org/svn/numpy/trunk numpy Authentication realm: scipy.org Password for 'nwagner': Any idea ? Nils From nwagner at iam.uni-stuttgart.de Thu Jul 10 16:01:34 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 10 Jul 2008 22:01:34 +0200 Subject: [SciPy-dev] scipy 0.7 release Message-ID: Hi all, Is it planned to release scipy 0.7 before the forthcoming Scipy Conference ? I don't think that 89 tickets will be closed in the foreseeable future. http://projects.scipy.org/scipy/scipy/roadmap http://projects.scipy.org/scipy/scipy/query?status=new&status=assigned&status=reopened&milestone=0.7 Nils From millman at berkeley.edu Thu Jul 10 16:52:52 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Thu, 10 Jul 2008 13:52:52 -0700 Subject: [SciPy-dev] scipy 0.7 release In-Reply-To: References: Message-ID: On Thu, Jul 10, 2008 at 1:01 PM, Nils Wagner wrote: > Is it planned to release scipy 0.7 before the forthcoming > Scipy Conference ? I would like to get NumPy 1.2 and SciPy 0.7 out near the end of the SciPy conference. Unfortunately, I haven't had time to send out an email. I promise to get one out before the end of the night. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From neilcrighton at gmail.com Thu Jul 10 18:03:41 2008 From: neilcrighton at gmail.com (Neil Crighton) Date: Thu, 10 Jul 2008 23:03:41 +0100 Subject: [SciPy-dev] Doc marathon Message-ID: <63751c30807101503l25336b7av794605e3482d7bc1@mail.gmail.com> Hi, I'd like to help out with the doc marathon. Login name: nhmc. Probably as a reviewer. Neil From stefan at sun.ac.za Thu Jul 10 18:53:51 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 11 Jul 2008 00:53:51 +0200 Subject: [SciPy-dev] Doc marathon In-Reply-To: <63751c30807101503l25336b7av794605e3482d7bc1@mail.gmail.com> References: <63751c30807101503l25336b7av794605e3482d7bc1@mail.gmail.com> Message-ID: <9457e7c80807101553r261ee9b4p70b11c73ee6199e5@mail.gmail.com> 2008/7/11 Neil Crighton : > I'd like to help out with the doc marathon. Login name: nhmc. > Probably as a reviewer. Thanks, you're in! Please also read the newly updated review guidelines on the front page. Regards St?fan From astrofitz at gmail.com Fri Jul 11 18:04:37 2008 From: astrofitz at gmail.com (Michael Fitzgerald) Date: Fri, 11 Jul 2008 15:04:37 -0700 Subject: [SciPy-dev] Fwd: patch for ndimage.generic_filter References: <477CA520-C850-47AD-9888-92DDC968BBF3@gmail.com> Message-ID: <93D218F9-3DDD-4361-AEA5-25943AAAEC40@gmail.com> (Resending to dev list.) Begin forwarded message: > From: Michael Fitzgerald > Date: July 10, 2008 4:19:49 PM PDT > To: scipy-user at scipy.org > Subject: patch for ndimage.generic_filter > > > Hello, > > I found a small bug in ndimage.generic_filter() that arises when > using the 'size' keyword with multidimensional arrays. Patch > attached. > > Mike > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: filter.diff Type: application/octet-stream Size: 580 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis at enthought.com Sat Jul 12 11:34:57 2008 From: travis at enthought.com (Travis Vaught) Date: Sat, 12 Jul 2008 10:34:57 -0500 Subject: [SciPy-dev] SciPy 2008 Registration Deadline Extended Message-ID: <3A00FC0B-B463-4308-B0CF-7D6F3195E609@enthought.com> Greetings, The merchant account processor that we use for the SciPy Conference online registration has been experiencing some inexplicable problems authorizing some registrations. Apologies to those who have struggled to register and have not been successful. Because of the problems, we're extending the early-bird rates through Monday at midnight Central Time. If you experience any problems registering, please give us a call during business hours Monday (9:00am - 5:00pm Central - 512.536.1057). http://conference.scipy.org/ For those of you who have set up an account on the conference site, but have not yet registered, I encourage you to do so in time to take advantage of the lower rates. I also encourage everyone to make sure you've specified which tutorial track, T-shirt size, whether you'll attend the sprint, and meal preferences in your profile (http://conference.scipy.org/profile ). Please send me an email if you have any questions. Best, Travis From perry at stsci.edu Sat Jul 12 11:39:43 2008 From: perry at stsci.edu (Perry Greenfield) Date: Sat, 12 Jul 2008 11:39:43 -0400 Subject: [SciPy-dev] SciPy 2008 Registration Deadline Extended In-Reply-To: <3A00FC0B-B463-4308-B0CF-7D6F3195E609@enthought.com> References: <3A00FC0B-B463-4308-B0CF-7D6F3195E609@enthought.com> Message-ID: <3973AF91-E9EA-478A-B3D3-FEC1D1CBADD6@stsci.edu> Hi Travis, By the way, do you have any info on how many have signed up for the astronomical data analysis tutorial? It would be good to know if there are enough to justify the preparation needed. Thanks, Perry On Jul 12, 2008, at 11:34 AM, Travis Vaught wrote: > Greetings, > > The merchant account processor that we use for the SciPy Conference > online registration has been experiencing some inexplicable problems > authorizing some registrations. Apologies to those who have struggled > to register and have not been successful. Because of the problems, > we're extending the early-bird rates through Monday at midnight > Central Time. If you experience any problems registering, please give > us a call during business hours Monday (9:00am - 5:00pm Central - > 512.536.1057). > > http://conference.scipy.org/ > > For those of you who have set up an account on the conference site, > but have not yet registered, I encourage you to do so in time to take > advantage of the lower rates. I also encourage everyone to make sure > you've specified which tutorial track, T-shirt size, whether you'll > attend the sprint, and meal preferences in your profile (http:// > conference.scipy.org/profile > ). > > Please send me an email if you have any questions. > > Best, > > Travis > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev From dmitrey.kroshko at scipy.org Mon Jul 14 16:31:29 2008 From: dmitrey.kroshko at scipy.org (dmitrey) Date: Mon, 14 Jul 2008 23:31:29 +0300 Subject: [SciPy-dev] [OpenOpt] gsoc midterm evaluation Message-ID: <487BB7A1.8040206@scipy.org> Hi all, let me inform you about gsoc midterm evaluation. Contents of the letter is in accordance with request of my mentor Alan G Isaac. Let me remember you OpenOpt is free numerical optimization framework. For what it serves for and other details see OpenOpt homepage and introduction page: http://scipy.org/scipy/scikits/wiki/OpenOpt http://scipy.org/scipy/scikits/wiki/OOForeword for openopt capabilities see OO Doc page: http://scipy.org/scipy/scikits/wiki/OODoc All items from my timeline http://scipy.org/scipy/scikits/wiki/OOTimeLine have been implemented more details can be read at openopt blog: http://openopt.blogspot.com/ Let me also note that I have started my work 1 months earlier, so some work from part 2 (related to ralg enhancements) have been done. As for dependency patterns, some work have been done (during several weeks), I intend to describe it tomorrow in OO blog and Doc page. Thanks all who vote for openopt during GScC select phase and/or answered my questions in numpy/scipy mail lists. Also, thanks to my optimization department workers for a number of consultations and other support that have sufficiently improved openopt quality. Regards, Dmitrey. From alan.mcintyre at gmail.com Mon Jul 14 18:19:54 2008 From: alan.mcintyre at gmail.com (Alan McIntyre) Date: Mon, 14 Jul 2008 18:19:54 -0400 Subject: [SciPy-dev] Switching SciPy to use numpy.testing Message-ID: <1d36917a0807141519l397e76c3uf1053d0401892fe3@mail.gmail.com> Hi all, We've added the nose test setup from scipy/testing to NumPy, and should be ready to switch SciPy over to use it (and remove the scipy/testing directory). Unless somebody has an objection, I'll make the switch tomorrow or Wednesday, and post a message to the list when it's done. Thanks! Alan From millman at berkeley.edu Mon Jul 14 19:56:43 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Mon, 14 Jul 2008 16:56:43 -0700 Subject: [SciPy-dev] Switching SciPy to use numpy.testing In-Reply-To: <1d36917a0807141519l397e76c3uf1053d0401892fe3@mail.gmail.com> References: <1d36917a0807141519l397e76c3uf1053d0401892fe3@mail.gmail.com> Message-ID: On Mon, Jul 14, 2008 at 3:19 PM, Alan McIntyre wrote: > We've added the nose test setup from scipy/testing to NumPy, and > should be ready to switch SciPy over to use it (and remove the > scipy/testing directory). Unless somebody has an objection, I'll make > the switch tomorrow or Wednesday, and post a message to the list when > it's done. Excellent. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From travis at enthought.com Tue Jul 15 18:31:00 2008 From: travis at enthought.com (Travis Vaught) Date: Tue, 15 Jul 2008 17:31:00 -0500 Subject: [SciPy-dev] Tutorial attendance [was Re: SciPy 2008 Registration Deadline Extended] In-Reply-To: <3973AF91-E9EA-478A-B3D3-FEC1D1CBADD6@stsci.edu> References: <3A00FC0B-B463-4308-B0CF-7D6F3195E609@enthought.com> <3973AF91-E9EA-478A-B3D3-FEC1D1CBADD6@stsci.edu> Message-ID: On Jul 12, 2008, at 10:39 AM, Perry Greenfield wrote: > Hi Travis, > > By the way, do you have any info on how many have signed up for the > astronomical data analysis tutorial? It would be good to know if > there are enough to justify the preparation needed. Apologies for the delayed response. To date around 53 folks have paid for tutorials -- we're tracking about the same as last year, when we had ~65-70. Not many folks have indicated a tutorial preference, though (22 advanced, 5 intro). We don't have numbers for particular tutorials. Travis From alan.mcintyre at gmail.com Tue Jul 15 20:38:27 2008 From: alan.mcintyre at gmail.com (Alan McIntyre) Date: Tue, 15 Jul 2008 20:38:27 -0400 Subject: [SciPy-dev] scipy.testing removed from svn Message-ID: <1d36917a0807151738p25e3e60ap418cd376c18236e4@mail.gmail.com> Hi all, I just checked in a change that removes scipy.testing and updates all the unit tests to use numpy.testing instead. There are some recent updates in NumPy (as in, 30 seconds ago) that are needed to support the SciPy tests, so please update your NumPy from svn as well to avoid problems. If this breaks your code in any way, please let me know. I will be making more changes over the next couple of days to clear some deprecation warnings and make sure all the tests are getting run. Thanks, Alan From millman at berkeley.edu Tue Jul 15 21:31:23 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Tue, 15 Jul 2008 18:31:23 -0700 Subject: [SciPy-dev] scipy.testing removed from svn In-Reply-To: <1d36917a0807151738p25e3e60ap418cd376c18236e4@mail.gmail.com> References: <1d36917a0807151738p25e3e60ap418cd376c18236e4@mail.gmail.com> Message-ID: On Tue, Jul 15, 2008 at 5:38 PM, Alan McIntyre wrote: > I just checked in a change that removes scipy.testing and updates all > the unit tests to use numpy.testing instead. There are some recent > updates in NumPy (as in, 30 seconds ago) that are needed to support > the SciPy tests, so please update your NumPy from svn as well to avoid > problems. Thanks. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From alan.mcintyre at gmail.com Wed Jul 16 03:22:19 2008 From: alan.mcintyre at gmail.com (Alan McIntyre) Date: Wed, 16 Jul 2008 03:22:19 -0400 Subject: [SciPy-dev] Doctest execution context Message-ID: <1d36917a0807160022m6097f10cm65fa5ec8fd111e3b@mail.gmail.com> Hi all, Currently, the NumPy doctests, when executed via numpy.test(doctests=True), are run in a context that's pretty much equivalent to a fresh Python interpreter that's executed "import numpy as np". Should we do something similar for SciPy? For example, if the NoseTester figures out that it's running tests for SciPy or one of its packages, we could add "import scipy as sp" (or something similar) to the context. Alan From robert.kern at gmail.com Wed Jul 16 03:38:10 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 16 Jul 2008 02:38:10 -0500 Subject: [SciPy-dev] Doctest execution context In-Reply-To: <1d36917a0807160022m6097f10cm65fa5ec8fd111e3b@mail.gmail.com> References: <1d36917a0807160022m6097f10cm65fa5ec8fd111e3b@mail.gmail.com> Message-ID: <3d375d730807160038v358353esf465e79356110455@mail.gmail.com> On Wed, Jul 16, 2008 at 02:22, Alan McIntyre wrote: > Hi all, > > Currently, the NumPy doctests, when executed via > numpy.test(doctests=True), are run in a context that's pretty much > equivalent to a fresh Python interpreter that's executed "import numpy > as np". Should we do something similar for SciPy? For example, if the > NoseTester figures out that it's running tests for SciPy or one of its > packages, we could add "import scipy as sp" (or something similar) to > the context. Tricky. "import scipy" doesn't import the subpackages, so that's pretty useless. Can you customize it per docstring? I.e. for the docstring of scipy.linalg.qr(), have a "from scipy.linalg import qr" or "from scipy import linalg" in the context? -- 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 From alan.mcintyre at gmail.com Wed Jul 16 03:58:17 2008 From: alan.mcintyre at gmail.com (Alan McIntyre) Date: Wed, 16 Jul 2008 03:58:17 -0400 Subject: [SciPy-dev] Doctest execution context In-Reply-To: <3d375d730807160038v358353esf465e79356110455@mail.gmail.com> References: <1d36917a0807160022m6097f10cm65fa5ec8fd111e3b@mail.gmail.com> <3d375d730807160038v358353esf465e79356110455@mail.gmail.com> Message-ID: <1d36917a0807160058w5f791a7bwf9f8cdc35a9ab531@mail.gmail.com> On Wed, Jul 16, 2008 at 3:38 AM, Robert Kern wrote: > Tricky. "import scipy" doesn't import the subpackages, so that's > pretty useless. Can you customize it per docstring? I.e. for the > docstring of scipy.linalg.qr(), have a "from scipy.linalg import qr" > or "from scipy import linalg" in the context? We should be able to do that. Having an implicit "from scipy import linalg" for every doctest in scipy/linalg would be the least complicated thing, but if some other scheme makes more sense in terms of keeping the examples simple/reasonable, I don't mind. We can go down to the point of customizing it for each test if need be. From robert.kern at gmail.com Wed Jul 16 04:01:43 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 16 Jul 2008 03:01:43 -0500 Subject: [SciPy-dev] Doctest execution context In-Reply-To: <1d36917a0807160058w5f791a7bwf9f8cdc35a9ab531@mail.gmail.com> References: <1d36917a0807160022m6097f10cm65fa5ec8fd111e3b@mail.gmail.com> <3d375d730807160038v358353esf465e79356110455@mail.gmail.com> <1d36917a0807160058w5f791a7bwf9f8cdc35a9ab531@mail.gmail.com> Message-ID: <3d375d730807160101q52bd870es9bfd322768e57e53@mail.gmail.com> On Wed, Jul 16, 2008 at 02:58, Alan McIntyre wrote: > On Wed, Jul 16, 2008 at 3:38 AM, Robert Kern wrote: >> Tricky. "import scipy" doesn't import the subpackages, so that's >> pretty useless. Can you customize it per docstring? I.e. for the >> docstring of scipy.linalg.qr(), have a "from scipy.linalg import qr" >> or "from scipy import linalg" in the context? > > We should be able to do that. Having an implicit "from scipy import > linalg" for every doctest in scipy/linalg would be the least > complicated thing, but if some other scheme makes more sense in terms > of keeping the examples simple/reasonable, I don't mind. We can go > down to the point of customizing it for each test if need be. Per package is convenient enough, I think. -- 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 From as8ca at virginia.edu Wed Jul 16 13:29:11 2008 From: as8ca at virginia.edu (Alok Singhal) Date: Wed, 16 Jul 2008 13:29:11 -0400 Subject: [SciPy-dev] Tutorial attendance [was Re: SciPy 2008 Registration Deadline Extended] In-Reply-To: References: <3A00FC0B-B463-4308-B0CF-7D6F3195E609@enthought.com> <3973AF91-E9EA-478A-B3D3-FEC1D1CBADD6@stsci.edu> Message-ID: <20080716172911.GA23475@virginia.edu> Replying to Travis's message since I don't have Perry's message in my inbox anymore. On 15/07/08: 17:31, Travis Vaught wrote: > On Jul 12, 2008, at 10:39 AM, Perry Greenfield wrote: >> By the way, do you have any info on how many have signed up for the >> astronomical data analysis tutorial? It would be good to know if >> there are enough to justify the preparation needed. I am definitely interested in the astronomical data analysis tutorial, and will attend it (if there is one, that is). -Alok -- * * Alok Singhal * * * http://www.astro.virginia.edu/~as8ca/ * * From zachary.pincus at yale.edu Thu Jul 17 08:24:54 2008 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Thu, 17 Jul 2008 08:24:54 -0400 Subject: [SciPy-dev] Fwd: patch for ndimage.generic_filter In-Reply-To: <93D218F9-3DDD-4361-AEA5-25943AAAEC40@gmail.com> References: <477CA520-C850-47AD-9888-92DDC968BBF3@gmail.com> <93D218F9-3DDD-4361-AEA5-25943AAAEC40@gmail.com> Message-ID: <739139C9-D0FE-4CA5-9543-88F00F3B1F67@yale.edu> Hello, Thanks for the patch, Michael. I'm not a scipy dev, but I've used (and hacked on) ndimage enough that I have a feel for the library, so I gave a look at the patch and it's totally reasonable. I added it to the scipy trac: http://scipy.org/scipy/scipy/ticket/702 Scipy devs: No reason not to fix the typo that Michael found in scipy/ ndimage/filters.py -- it's a one-character error. Zach On Jul 11, 2008, at 6:04 PM, Michael Fitzgerald wrote: > (Resending to dev list.) > > Begin forwarded message: > >> From: Michael Fitzgerald >> Date: July 10, 2008 4:19:49 PM PDT >> To: scipy-user at scipy.org >> Subject: patch for ndimage.generic_filter >> >> >> Hello, >> >> I found a small bug in ndimage.generic_filter() that arises when >> using the 'size' keyword with multidimensional arrays. Patch >> attached. >> >> Mike >> > >> >> > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev From stefan at sun.ac.za Thu Jul 17 08:50:56 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 17 Jul 2008 14:50:56 +0200 Subject: [SciPy-dev] Fwd: patch for ndimage.generic_filter In-Reply-To: <739139C9-D0FE-4CA5-9543-88F00F3B1F67@yale.edu> References: <477CA520-C850-47AD-9888-92DDC968BBF3@gmail.com> <93D218F9-3DDD-4361-AEA5-25943AAAEC40@gmail.com> <739139C9-D0FE-4CA5-9543-88F00F3B1F67@yale.edu> Message-ID: <9457e7c80807170550o6d489996w7557fe8266ac916e@mail.gmail.com> Thanks for the patch, Michael. And thanks Zachary for the review. Applied in r4548. Cheers St?fan 2008/7/17 Zachary Pincus : > Hello, > > Thanks for the patch, Michael. I'm not a scipy dev, but I've used (and > hacked on) ndimage enough that I have a feel for the library, so I > gave a look at the patch and it's totally reasonable. > > I added it to the scipy trac: > http://scipy.org/scipy/scipy/ticket/702 > > Scipy devs: No reason not to fix the typo that Michael found in scipy/ > ndimage/filters.py -- it's a one-character error. > > Zach > > > > On Jul 11, 2008, at 6:04 PM, Michael Fitzgerald wrote: > >> (Resending to dev list.) >> >> Begin forwarded message: >> >>> From: Michael Fitzgerald >>> Date: July 10, 2008 4:19:49 PM PDT >>> To: scipy-user at scipy.org >>> Subject: patch for ndimage.generic_filter >>> >>> >>> Hello, >>> >>> I found a small bug in ndimage.generic_filter() that arises when >>> using the 'size' keyword with multidimensional arrays. Patch >>> attached. >>> >>> Mike >>> >> From nwagner at iam.uni-stuttgart.de Fri Jul 18 12:34:03 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 18 Jul 2008 18:34:03 +0200 Subject: [SciPy-dev] Fwd: [atlas-devel] ATLAS 3.9.0 & LAPACK Message-ID: This might be of interest ... --- the forwarded message follows --- -------------- next part -------------- An embedded message was scrubbed... From: Clint Whaley Subject: [atlas-devel] ATLAS 3.9.0 & LAPACK Date: Fri, 18 Jul 2008 06:19:10 -0500 Size: 9363 URL: From nwagner at iam.uni-stuttgart.de Fri Jul 18 13:43:19 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 18 Jul 2008 19:43:19 +0200 Subject: [SciPy-dev] scipy.test() error Message-ID: Hi Nathan, I found a new error in scipy.sparse. I have used >>> scipy.__version__ '0.7.0.dev4549' ====================================================================== ERROR: test_sparse_formats (test_mmio.TestMMIOCoordinate) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/scipy/io/tests/test_mmio.py", line 311, in test_sparse_formats mmwrite(fn, mat.asformat(fmt)) File "/usr/local/lib64/python2.5/site-packages/scipy/io/mmio.py", line 67, in mmwrite MMFile().write(target, a, comment, field, precision) File "/usr/local/lib64/python2.5/site-packages/scipy/io/mmio.py", line 284, in write self._write(stream, a, comment, field, precision) File "/usr/local/lib64/python2.5/site-packages/scipy/io/mmio.py", line 564, in _write IJV = vstack((a.row, a.col, a.data)).T File "/usr/local/lib64/python2.5/site-packages/scipy/sparse/csr.py", line 93, in __getattr__ return _cs_matrix.__getattr__(self, attr) File "/usr/local/lib64/python2.5/site-packages/scipy/sparse/base.py", line 393, in __getattr__ raise AttributeError, attr + " not found" AttributeError: row not found Nils From alan.mcintyre at gmail.com Sat Jul 19 10:16:28 2008 From: alan.mcintyre at gmail.com (Alan McIntyre) Date: Sat, 19 Jul 2008 10:16:28 -0400 Subject: [SciPy-dev] Deprecation warnings Message-ID: <1d36917a0807190716y7de7c5a4ncc9e8015d5a98cc5@mail.gmail.com> Hi all, The test suite currently generates a batch of deprecation warnings: - PyArray_FromDims: use PyArray_SimpleNew - PyArray_FromDimsAndDataAndDescr: use PyArray_NewFromDescr - set_local_path/restore_path will be removed in NumPy 1.3 The path manipulation functions were deemed not to be needed any more for NumPy; unless somebody can cite a reason they're needed in SciPy I'll take them out here too. I can try to clean up the other warnings if nobody else has the time at the moment. There's also a fair amount of test detail being spewed out inline with the unit test output, which makes things rather cluttered. Would anyone be horribly offended if I cleaned that up as well? It seems to me the unit tests should generally be silent unless something goes wrong. Thanks, Alan From mellerf at netvision.net.il Sat Jul 19 10:27:00 2008 From: mellerf at netvision.net.il (Yosef Meller) Date: Sat, 19 Jul 2008 17:27:00 +0300 Subject: [SciPy-dev] Removing globals from minpack wrapper, v3 Message-ID: <4881F9B4.7030804@netvision.net.il> Before I enter exams period, one more patch in the series: Changes: * Now optimize.leastsq() and optimize.fsolve() should be completely thread-safe. * Rearranged the macros to reduce code duplication. Still to do: * chkder, but I don't know if it's significant there. * smjac_* in __minpack.h - what is that function used for? -- http://yosefm.imagekind.com/Eclectic -------------- next part -------------- A non-text attachment was scrubbed... Name: nuke_globals-v3.patch Type: text/x-diff Size: 21011 bytes Desc: not available URL: From stefan at sun.ac.za Sat Jul 19 10:28:01 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 19 Jul 2008 16:28:01 +0200 Subject: [SciPy-dev] Deprecation warnings In-Reply-To: <1d36917a0807190716y7de7c5a4ncc9e8015d5a98cc5@mail.gmail.com> References: <1d36917a0807190716y7de7c5a4ncc9e8015d5a98cc5@mail.gmail.com> Message-ID: <9457e7c80807190728q5f5e8b4dmd5c268a32dd47ef2@mail.gmail.com> 2008/7/19 Alan McIntyre : > There's also a fair amount of test detail being spewed out inline with > the unit test output, which makes things rather cluttered. Would > anyone be horribly offended if I cleaned that up as well? It seems to > me the unit tests should generally be silent unless something goes > wrong. Yes, or unless verbose mode is requested. Please make those changes; it would be much appreciated. Regards St?fan From nwagner at iam.uni-stuttgart.de Sun Jul 20 10:03:18 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Sun, 20 Jul 2008 16:03:18 +0200 Subject: [SciPy-dev] Ticket #704 Message-ID: Hi all, who can close ticket http://scipy.org/scipy/scipy/ticket/704 ? It has been fixed in r4552. Nils From alan.mcintyre at gmail.com Sun Jul 20 23:44:41 2008 From: alan.mcintyre at gmail.com (Alan McIntyre) Date: Sun, 20 Jul 2008 23:44:41 -0400 Subject: [SciPy-dev] Functions with print statements Message-ID: <1d36917a0807202044s32f1eb27kfefe07055c093d43@mail.gmail.com> Hi all, There are some functions in SciPy that use print statements to warn the user of various questionable conditions, such as scipy.stats.shapiro, ansari, and wilcoxon. Should these be using warnings.warn instead? Thanks, Alan From robert.kern at gmail.com Sun Jul 20 23:47:18 2008 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 20 Jul 2008 22:47:18 -0500 Subject: [SciPy-dev] Functions with print statements In-Reply-To: <1d36917a0807202044s32f1eb27kfefe07055c093d43@mail.gmail.com> References: <1d36917a0807202044s32f1eb27kfefe07055c093d43@mail.gmail.com> Message-ID: <3d375d730807202047p12aaf26ch6e59339f838fd9fa@mail.gmail.com> On Sun, Jul 20, 2008 at 22:44, Alan McIntyre wrote: > Hi all, > > There are some functions in SciPy that use print statements to warn > the user of various questionable conditions, such as > scipy.stats.shapiro, ansari, and wilcoxon. Should these be using > warnings.warn instead? Typically, yes. -- 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 From wnbell at gmail.com Mon Jul 21 20:44:40 2008 From: wnbell at gmail.com (Nathan Bell) Date: Mon, 21 Jul 2008 19:44:40 -0500 Subject: [SciPy-dev] scipy.test() error In-Reply-To: References: Message-ID: On Fri, Jul 18, 2008 at 12:43 PM, Nils Wagner wrote: > Hi Nathan, > > I found a new error in scipy.sparse. I have used >>>> scipy.__version__ > '0.7.0.dev4549' > Nils, do you still observe this error in r4556 or newer? -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From nwagner at iam.uni-stuttgart.de Tue Jul 22 01:51:57 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Tue, 22 Jul 2008 07:51:57 +0200 Subject: [SciPy-dev] scipy.test() error In-Reply-To: References: Message-ID: On Mon, 21 Jul 2008 19:44:40 -0500 "Nathan Bell" wrote: > On Fri, Jul 18, 2008 at 12:43 PM, Nils Wagner > wrote: >> Hi Nathan, >> >> I found a new error in scipy.sparse. I have used >>>>> scipy.__version__ >> '0.7.0.dev4549' >> > > Nils, do you still observe this error in r4556 or newer? No. From wnbell at gmail.com Tue Jul 22 18:55:03 2008 From: wnbell at gmail.com (Nathan Bell) Date: Tue, 22 Jul 2008 17:55:03 -0500 Subject: [SciPy-dev] removing lil_eye() and lil_diags() Message-ID: Is there any objection to removing lil_eye() and lil_diags() from scipy.sparse? I believe these functions were added after the 0.6 release and have now been superceded by sparse.eye(..., format='lil') and sparse.spdiags(..., format='lil'). For reference: http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/sparse/construct.py -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From stefan at sun.ac.za Tue Jul 22 19:08:14 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 23 Jul 2008 01:08:14 +0200 Subject: [SciPy-dev] removing lil_eye() and lil_diags() In-Reply-To: References: Message-ID: <9457e7c80807221608x21d8e408pcf3a9031cd80861d@mail.gmail.com> Hi Nathan 2008/7/23 Nathan Bell : > Is there any objection to removing lil_eye() and lil_diags() from > scipy.sparse? I believe these functions were added after the 0.6 > release and have now been superceded by sparse.eye(..., format='lil') > and sparse.spdiags(..., format='lil'). I think that should be fine (I added them both, didn't I?). One question: the implementations were both exploiting properties of lil matrices to be constructed efficiently; is constructing a dia_matrix and then converting to lil format as good? It seems like a much cleaner solution, so I hope the answer is "yes"! Cheers St?fan From tteststudent at gmail.com Wed Jul 23 00:26:15 2008 From: tteststudent at gmail.com (theodore test) Date: Wed, 23 Jul 2008 00:26:15 -0400 Subject: [SciPy-dev] Once more unto the breach Message-ID: "Middling-to-fair pythonian seeking long walks on an interactive prompt with a triple-quoted beauty." In other words, I'd like to be an editor for the SciPy documentation marathon, please. user_name = theodore_test preferred_num_spaces = 4 sense_of_humor = True Thanks, Theo -------------- next part -------------- An HTML attachment was scrubbed... URL: From wnbell at gmail.com Wed Jul 23 01:43:02 2008 From: wnbell at gmail.com (Nathan Bell) Date: Wed, 23 Jul 2008 00:43:02 -0500 Subject: [SciPy-dev] removing lil_eye() and lil_diags() In-Reply-To: <9457e7c80807221608x21d8e408pcf3a9031cd80861d@mail.gmail.com> References: <9457e7c80807221608x21d8e408pcf3a9031cd80861d@mail.gmail.com> Message-ID: On Tue, Jul 22, 2008 at 6:08 PM, St?fan van der Walt wrote: > >> Is there any objection to removing lil_eye() and lil_diags() from >> scipy.sparse? I believe these functions were added after the 0.6 >> release and have now been superceded by sparse.eye(..., format='lil') >> and sparse.spdiags(..., format='lil'). > > I think that should be fine (I added them both, didn't I?). One > question: the implementations were both exploiting properties of lil > matrices to be constructed efficiently; is constructing a dia_matrix > and then converting to lil format as good? It seems like a much > cleaner solution, so I hope the answer is "yes"! > Although the conversion to LIL from DIA goes DIA->COO->CSR->LIL, the overall cost is still comparable. For instance, the cost of A = sparse.eye(10000, 10000, format='dia') is 0.130 ms and the breakdown of cost for converting A from DIA to LIL is as follows: 1.590 ms DIA->COO 0.636 ms COO->CSR 50.100 ms CSR->LIL The full process, i.e. eye(10000, 10000, format='lil'), takes about 52 ms. On the other hand, your version of lil_eye() [1], which exploits properties of the LIL format, requires only 32.3 ms. Since the DIA->LIL conversion is not significantly slower, I would prefer that we rely on format conversion here. The additional time spent making special-purpose implementations for LIL and DOK is probably better spent improving the conversions between sparse formats. Then, if the implementation of the LIL format changes, there will only be a few places (e.g. csr_matrix.tolil() ) that require modification. [1] http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/sparse/sparse.py?rev=3460#L2928 -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From stefan at sun.ac.za Wed Jul 23 05:10:01 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 23 Jul 2008 11:10:01 +0200 Subject: [SciPy-dev] removing lil_eye() and lil_diags() In-Reply-To: References: <9457e7c80807221608x21d8e408pcf3a9031cd80861d@mail.gmail.com> Message-ID: <9457e7c80807230210w32fa98fsdec679d9a8bd5d58@mail.gmail.com> 2008/7/23 Nathan Bell : > Although the conversion to LIL from DIA goes DIA->COO->CSR->LIL, the > overall cost is still comparable. For instance, the cost of A = > sparse.eye(10000, 10000, format='dia') is 0.130 ms and the breakdown > of cost for converting A from DIA to LIL is as follows: > 1.590 ms DIA->COO > 0.636 ms COO->CSR > 50.100 ms CSR->LIL > > The full process, i.e. eye(10000, 10000, format='lil'), takes about 52 ms. > > On the other hand, your version of lil_eye() [1], which exploits > properties of the LIL format, requires only 32.3 ms. That's not too bad. The code that was in `lil_diag` can probably be adapted quite easily to do DIA->LIL directly, if that ever became necessary. > Since the DIA->LIL conversion is not significantly slower, I would > prefer that we rely on format conversion here. The additional time > spent making special-purpose implementations for LIL and DOK is > probably better spent improving the conversions between sparse > formats. Then, if the implementation of the LIL format changes, there > will only be a few places (e.g. csr_matrix.tolil() ) that require > modification. Agreed; that's a significant advantage. Regards St?fan From stefan at sun.ac.za Wed Jul 23 05:23:29 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 23 Jul 2008 11:23:29 +0200 Subject: [SciPy-dev] Once more unto the breach In-Reply-To: References: Message-ID: <9457e7c80807230223udc136f3uf04f87f1486e8ce@mail.gmail.com> 2008/7/23 theodore test : > In other words, I'd like to be an editor for the SciPy documentation > marathon, please. Thanks, you're in! > user_name = theodore_test > preferred_num_spaces = 4 > sense_of_humor = True Between all those thousands of docstrings, I've seen this state progress into white_jacket = True before. Be strong! Cheers St?fan From uschmitt at mineway.de Wed Jul 23 11:40:53 2008 From: uschmitt at mineway.de (Uwe Schmitt) Date: Wed, 23 Jul 2008 17:40:53 +0200 Subject: [SciPy-dev] NNLS Message-ID: <48875105.7010708@mineway.de> Hi, I'm new to this mailing list. I just wraped NNLS (non negative least sqaures) from NETLIB using ctypes and want to ask if anybody is interested in my code ? As far as I know scipy does not contain this algorithm. Greetings, Uwe -- Dr. rer. nat. Uwe Schmitt F&E Mathematik mineway GmbH Science Park 2 D-66123 Saarbr?cken Telefon: +49 (0)681 8390 5334 Telefax: +49 (0)681 830 4376 uschmitt at mineway.de www.mineway.de Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer Amtsgericht Saarbr?cken HRB 12339 From robert.kern at gmail.com Wed Jul 23 16:43:53 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 23 Jul 2008 15:43:53 -0500 Subject: [SciPy-dev] NNLS In-Reply-To: <48875105.7010708@mineway.de> References: <48875105.7010708@mineway.de> Message-ID: <3d375d730807231343g6d979a80s36a58123a2651e21@mail.gmail.com> On Wed, Jul 23, 2008 at 10:40, Uwe Schmitt wrote: > Hi, > > I'm new to this mailing list. > I just wraped NNLS (non negative least sqaures) from NETLIB using > ctypes and want to ask if anybody is interested in my code ? > As far as I know scipy does not contain this algorithm. I am reluctant to include Lawson and Hanson's code into scipy without a clear copyright statement and license which allows us to do so. Perhaps their book includes such a statement, but none of the actual files containing their code do. -- 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 From aisaac at american.edu Wed Jul 23 16:59:40 2008 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 23 Jul 2008 16:59:40 -0400 Subject: [SciPy-dev] NNLS In-Reply-To: <3d375d730807231343g6d979a80s36a58123a2651e21@mail.gmail.com> References: <48875105.7010708@mineway.de> <3d375d730807231343g6d979a80s36a58123a2651e21@mail.gmail.com> Message-ID: > On Wed, Jul 23, 2008 at 10:40, Uwe Schmitt wrote: >> I'm new to this mailing list. >> I just wraped NNLS (non negative least sqaures) from NETLIB using >> ctypes and want to ask if anybody is interested in my code ? >> As far as I know scipy does not contain this algorithm. On Wed, 23 Jul 2008, Robert Kern apparently wrote: > I am reluctant to include Lawson and Hanson's code into scipy without > a clear copyright statement and license which allows us to do so. > Perhaps their book includes such a statement, but none of the actual > files containing their code do. Are the letters I forwarded last Sept not adequate in some way? Cheers, Alan Isaac From robert.kern at gmail.com Wed Jul 23 17:11:24 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 23 Jul 2008 16:11:24 -0500 Subject: [SciPy-dev] NNLS In-Reply-To: References: <48875105.7010708@mineway.de> <3d375d730807231343g6d979a80s36a58123a2651e21@mail.gmail.com> Message-ID: <3d375d730807231411u66ad4b39s58959a50cf427ab@mail.gmail.com> On Wed, Jul 23, 2008 at 15:59, Alan G Isaac wrote: >> On Wed, Jul 23, 2008 at 10:40, Uwe Schmitt wrote: >>> I'm new to this mailing list. >>> I just wraped NNLS (non negative least sqaures) from NETLIB using >>> ctypes and want to ask if anybody is interested in my code ? >>> As far as I know scipy does not contain this algorithm. > > On Wed, 23 Jul 2008, Robert Kern apparently wrote: >> I am reluctant to include Lawson and Hanson's code into scipy without >> a clear copyright statement and license which allows us to do so. >> Perhaps their book includes such a statement, but none of the actual >> files containing their code do. > > Are the letters I forwarded last Sept not adequate in some > way? I wasn't aware that NNLS was included as part of TOMS 733's code. Now, I'm not so sure that the ACM or the author of TOMS 733 actually had the rights to give us a BSD license on the whole set of code. People make mistakes. Find me a statement from Lawson or Hanson. -- 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 From aisaac at american.edu Wed Jul 23 18:30:55 2008 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 23 Jul 2008 18:30:55 -0400 Subject: [SciPy-dev] [Fwd: Re: permission requested] Message-ID: <4887B11F.3000106@american.edu> For completeness, I did ask them if their code could be included in SciPy under the BSD license. See the attached email response. Alan -------------- next part -------------- An embedded message was scrubbed... From: "C. Lawson" Subject: Re: permission requested Date: Sat, 15 Sep 2007 16:26:26 -0700 Size: 3247 URL: From robert.kern at gmail.com Wed Jul 23 18:34:47 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 23 Jul 2008 17:34:47 -0500 Subject: [SciPy-dev] [Fwd: Re: permission requested] In-Reply-To: <4887B11F.3000106@american.edu> References: <4887B11F.3000106@american.edu> Message-ID: <3d375d730807231534p1ea96221i37b7a2eda2aec13@mail.gmail.com> On Wed, Jul 23, 2008 at 17:30, Alan G Isaac wrote: > For completeness, > I did ask them if their code could be included > in SciPy under the BSD license. See the attached > email response. Thank you. I am satisfied. -- 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 From aisaac at american.edu Wed Jul 23 18:47:07 2008 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 23 Jul 2008 18:47:07 -0400 Subject: [SciPy-dev] NNLS In-Reply-To: <48875105.7010708@mineway.de> References: <48875105.7010708@mineway.de> Message-ID: On Wed, 23 Jul 2008, Uwe Schmitt apparently wrote: > I just wraped NNLS (non negative least sqaures) from NETLIB using > ctypes and want to ask if anybody is interested in my code ? Since Robert is satisfied that the licensing issues are fully addressed, the answer is: definitely! Please contribute this to SciPy! Cheers, Alan Isaac From aisaac at american.edu Wed Jul 23 18:47:08 2008 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 23 Jul 2008 18:47:08 -0400 Subject: [SciPy-dev] NNLS In-Reply-To: <48875105.7010708@mineway.de> References: <48875105.7010708@mineway.de> Message-ID: On Wed, 23 Jul 2008, Uwe Schmitt apparently wrote: > I just wraped NNLS (non negative least sqaures) from NETLIB using > ctypes and want to ask if anybody is interested in my code ? Since Robert is satisfied that the licensing issues are fully addressed, the answer is: definitely! Please contribute this to SciPy! Cheers, Alan Isaac From robert.kern at gmail.com Wed Jul 23 18:46:36 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 23 Jul 2008 17:46:36 -0500 Subject: [SciPy-dev] NNLS In-Reply-To: References: <48875105.7010708@mineway.de> Message-ID: <3d375d730807231546t72f468c4u1980650481ccb8a2@mail.gmail.com> On Wed, Jul 23, 2008 at 17:47, Alan G Isaac wrote: > On Wed, 23 Jul 2008, Uwe Schmitt apparently wrote: >> I just wraped NNLS (non negative least sqaures) from NETLIB using >> ctypes and want to ask if anybody is interested in my code ? > > Since Robert is satisfied that the licensing issues are > fully addressed, the answer is: definitely! Please > contribute this to SciPy! Well, I'd prefer an f2py version rather than a ctypes version, but yes, please. -- 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 From uschmitt at mineway.de Thu Jul 24 04:35:25 2008 From: uschmitt at mineway.de (Uwe Schmitt) Date: Thu, 24 Jul 2008 10:35:25 +0200 Subject: [SciPy-dev] [mailinglist] Re: NNLS In-Reply-To: <3d375d730807231546t72f468c4u1980650481ccb8a2@mail.gmail.com> References: <48875105.7010708@mineway.de> <3d375d730807231546t72f468c4u1980650481ccb8a2@mail.gmail.com> Message-ID: <48883ECD.6000109@mineway.de> Robert Kern schrieb: > On Wed, Jul 23, 2008 at 17:47, Alan G Isaac wrote: > > Well, I'd prefer an f2py version rather than a ctypes version, but yes, please. > > I had some problems because my local python.exe is from Enthought, which was compiled with MS Visual Studio. But I wanted g77 for compiling the Fortran code, which gives some problems when using f2py. Do you have some conventions about code layout, directory layort, etc ? How can I contribute the code ? Shall I post a link ? I found no developers faq or something like this. Greetings, Uwe -- Dr. rer. nat. Uwe Schmitt F&E Mathematik mineway GmbH Science Park 2 D-66123 Saarbr?cken Telefon: +49 (0)681 8390 5334 Telefax: +49 (0)681 830 4376 uschmitt at mineway.de www.mineway.de Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer Amtsgericht Saarbr?cken HRB 12339 From nwagner at iam.uni-stuttgart.de Thu Jul 24 12:06:50 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 24 Jul 2008 18:06:50 +0200 Subject: [SciPy-dev] ERROR: test_sparse_formats (test_mmio.TestMMIOCoordinate) Message-ID: The error mentioned in the subject happens with >>> scipy.__version__ '0.7.0.dev4559' ====================================================================== ERROR: test_sparse_formats (test_mmio.TestMMIOCoordinate) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/scipy/io/tests/test_mmio.py", line 311, in test_sparse_formats mmwrite(fn, mat.asformat(fmt)) File "/usr/local/lib64/python2.5/site-packages/scipy/io/mmio.py", line 67, in mmwrite MMFile().write(target, a, comment, field, precision) File "/usr/local/lib64/python2.5/site-packages/scipy/io/mmio.py", line 284, in write self._write(stream, a, comment, field, precision) File "/usr/local/lib64/python2.5/site-packages/scipy/io/mmio.py", line 564, in _write IJV = vstack((a.row, a.col, a.data)).T File "/usr/local/lib64/python2.5/site-packages/scipy/sparse/csr.py", line 93, in __getattr__ return _cs_matrix.__getattr__(self, attr) File "/usr/local/lib64/python2.5/site-packages/scipy/sparse/base.py", line 393, in __getattr__ raise AttributeError, attr + " not found" AttributeError: row not found Nils From wnbell at gmail.com Thu Jul 24 13:07:49 2008 From: wnbell at gmail.com (Nathan Bell) Date: Thu, 24 Jul 2008 12:07:49 -0500 Subject: [SciPy-dev] ERROR: test_sparse_formats (test_mmio.TestMMIOCoordinate) In-Reply-To: References: Message-ID: On Thu, Jul 24, 2008 at 11:06 AM, Nils Wagner wrote: > The error mentioned in the subject happens with > >>>> scipy.__version__ > '0.7.0.dev4559' > Did you intend to send this again? It's been fixed. -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From nwagner at iam.uni-stuttgart.de Thu Jul 24 13:43:52 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 24 Jul 2008 19:43:52 +0200 Subject: [SciPy-dev] ERROR: test_sparse_formats (test_mmio.TestMMIOCoordinate) In-Reply-To: References: Message-ID: On Thu, 24 Jul 2008 12:07:49 -0500 "Nathan Bell" wrote: > On Thu, Jul 24, 2008 at 11:06 AM, Nils Wagner > wrote: >> The error mentioned in the subject happens with >> >>>>> scipy.__version__ >> '0.7.0.dev4559' >> > > Did you intend to send this again? It's been fixed. > Nathan, Oops! I forgot to remove /usr/local/lib64/python2.5/site-packages/scipy Sorry for the noise. Nils From robert.kern at gmail.com Thu Jul 24 14:37:57 2008 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 24 Jul 2008 13:37:57 -0500 Subject: [SciPy-dev] [mailinglist] Re: NNLS In-Reply-To: <48883ECD.6000109@mineway.de> References: <48875105.7010708@mineway.de> <3d375d730807231546t72f468c4u1980650481ccb8a2@mail.gmail.com> <48883ECD.6000109@mineway.de> Message-ID: <3d375d730807241137s47df563av9ba9d19beba9ea65@mail.gmail.com> On Thu, Jul 24, 2008 at 03:35, Uwe Schmitt wrote: > Robert Kern schrieb: >> On Wed, Jul 23, 2008 at 17:47, Alan G Isaac wrote: >> >> Well, I'd prefer an f2py version rather than a ctypes version, but yes, please. >> >> > I had some problems because my local python.exe is from Enthought, which > was compiled > with MS Visual Studio. But I wanted g77 for compiling the Fortran code, > which gives some problems when using f2py. Can you describe these problems? The g77 we distribute with EPD is compatible with the compiler used to build the Python executable, at least when used from distutils. But basically, we can't use ctypes for Fortran code in scipy. The calling conventions are different between Fortran compilers; f2py has worked out most of these, but I have seen no equivalent work done for ctypes. Additionally, the story for building non-extension shared libraries inside scipy is not really worked out, yet. > Do you have some conventions about code layout, directory layort, etc ? I suspect this should go into scipy.optimize, so look into integrating it there. > How can I contribute the code ? Shall I post a link ? If you would like someone else to take a look at it first, then please do post a link. However, I will arrange for you to get SVN access. I recommend working on a branch first. -- 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 From nwagner at iam.uni-stuttgart.de Thu Jul 24 15:28:15 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 24 Jul 2008 21:28:15 +0200 Subject: [SciPy-dev] Windows binary for openopt ? Message-ID: Hi all, I am looking for a windows binary of openopt. Is it available somewhere ? Nils From millman at berkeley.edu Fri Jul 25 00:53:16 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Thu, 24 Jul 2008 21:53:16 -0700 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule Message-ID: Now that NumPy 1.1.1 is almost out, I wanted to remind everyone of the NumPy 1.2.0 schedule: - 8/05/08 tag the 1.2.0rc1 release and prepare packages - 8/12/08 tag the 1.2.0rc2 release and prepare packages - 8/23/08 tag the 1.2.0 release and prepare packages - 8/24/08 announce release Ideally, I would like to release SciPy 0.7.0 at the same time. In order for this to have any chance of success, I will need help keeping an eye on the outstanding tickets and help rallying everyone to fix bugs. In particular, I would appreciate it if you could let me know of any bugs that should be considered release blockers. According to this release schedule, the first release candidate is due in a little less than two weeks with the final release in exactly one month. While this may seem an aggressive release schedule, I believe it is very achievable if everyone pitches in. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From stefan at sun.ac.za Fri Jul 25 03:35:51 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 25 Jul 2008 09:35:51 +0200 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: References: Message-ID: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> 2008/7/25 Jarrod Millman : > Now that NumPy 1.1.1 is almost out, I wanted to remind everyone of the > NumPy 1.2.0 schedule: > - 8/05/08 tag the 1.2.0rc1 release and prepare packages > - 8/12/08 tag the 1.2.0rc2 release and prepare packages > - 8/23/08 tag the 1.2.0 release and prepare packages > - 8/24/08 announce release > > Ideally, I would like to release SciPy 0.7.0 at the same time. In > order for this to have any chance of success, I will need help keeping > an eye on the outstanding tickets and help rallying everyone to fix > bugs. Does the release schedule of SciPy look the same then? I.e. do we release 0.7rc1 on the same day as 1.2.0rc1? Or does SciPy only get a single release? St?fan From emanuele at relativita.com Fri Jul 25 04:23:15 2008 From: emanuele at relativita.com (Emanuele Olivetti) Date: Fri, 25 Jul 2008 10:23:15 +0200 Subject: [SciPy-dev] Windows binary for openopt ? In-Reply-To: References: Message-ID: <48898D73.4060703@relativita.com> Isn't OpenOpt made just of pure Python code? So I guess source==binary in this case. If you refer to third party's addons (ALGENCAN, ipopt etc.) they are not provided with OpenOpt "out-of-the box". You need to find out if windows binaries of these optional packages are available from their respective websites. Best, E. Nils Wagner wrote: > Hi all, > > I am looking for a windows binary of openopt. > Is it available somewhere ? > > Nils > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > > From uschmitt at mineway.de Fri Jul 25 05:35:43 2008 From: uschmitt at mineway.de (Uwe Schmitt) Date: Fri, 25 Jul 2008 11:35:43 +0200 Subject: [SciPy-dev] [mailinglist] Re: NNLS In-Reply-To: <3d375d730807241137s47df563av9ba9d19beba9ea65@mail.gmail.com> References: <48875105.7010708@mineway.de> <3d375d730807231546t72f468c4u1980650481ccb8a2@mail.gmail.com> <48883ECD.6000109@mineway.de> <3d375d730807241137s47df563av9ba9d19beba9ea65@mail.gmail.com> Message-ID: <48899E6F.1090505@mineway.de> Robert Kern schrieb: > On Thu, Jul 24, 2008 at 03:35, Uwe Schmitt wrote: > >> Robert Kern schrieb: >> >>> On Wed, Jul 23, 2008 at 17:47, Alan G Isaac wrote: >>> >>> Well, I'd prefer an f2py version rather than a ctypes version, but yes, please. >>> >>> >>> >> I had some problems because my local python.exe is from Enthought, which >> was compiled >> with MS Visual Studio. But I wanted g77 for compiling the Fortran code, >> which gives some problems when using f2py. >> > > Can you describe these problems? The g77 we distribute with EPD is > compatible with the compiler used to build the Python executable, at > least when used from distutils. > Hi, if I use "python f2py.py --compiler=mingw32 -c NNLS.f" I get on stdout: running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src building extension "untitled" sources f2py options: [] f2py:> c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5\untitledmodule.c creating c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy creating c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5 Reading fortran codes... Reading file 'NNLS.F' (format:fix,strict) Post-processing... Block: untitled Block: nnls Block: diff Block: h12 Block: g1 Post-processing (stage 2)... Building modules... Building module "untitled"... Constructing wrapper function "nnls"... getarrdims:warning: assumed shape array, using 0 instead of '*' getarrdims:warning: assumed shape array, using 0 instead of '*' getarrdims:warning: assumed shape array, using 0 instead of '*' getarrdims:warning: assumed shape array, using 0 instead of '*' getarrdims:warning: assumed shape array, using 0 instead of '*' getarrdims:warning: assumed shape array, using 0 instead of '*' nnls(a,m,n,b,x,rnorm,w,zz,index_bn,mode,[mda]) Creating wrapper for Fortran function "diff"("diff")... Constructing wrapper function "diff"... diff = diff(x,y) Constructing wrapper function "h12"... getarrdims:warning: assumed shape array, using 0 instead of '*' getarrdims:warning: assumed shape array, using 0 instead of '*' h12(mode,lpivot,l1,m,u,up,c,ice,icv,ncv,[iue]) Constructing wrapper function "g1"... g1(a,b,cterm,sterm,sig) Wrote C/API module "untitled" to file "c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5/untitledmodule.c" Fortran 77 wrappers are saved to "c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5\untitled-f2pywrappers.f" adding 'c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5\fortranobject.c' to sources. adding 'c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5' to include_dirs. copying c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\f2py\src\fortranobject.c -> c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5 copying c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\f2py\src\fortranobject.h -> c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5 adding 'c:\dokume~1\uschmi~2.000\lokale~1\temp\tmpzs6mqy\src.win32-2.5\untitled-f2pywrappers.f' to sources. running build_ext And on stderr: rmbadname1: Replacing "index" with "index_bn". rmbadname1: Replacing "index" with "index_bn". Traceback (most recent call last): File "f2py.py", line 26, in main() File "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\f2py\f2py2e.py", line 558, in main run_compile() File "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\f2py\f2py2e.py", line 545, in run_compile setup(ext_modules = [ext]) File "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\core.py", line 176, in setup return old_setup(**new_attr) File "C:\Python25\lib\distutils\core.py", line 151, in setup dist.run_commands() File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands self.run_command(cmd) File "C:\Python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "C:\Python25\lib\distutils\command\build.py", line 112, in run self.run_command(cmd_name) File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "C:\Python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\command\build_ext.py", line 78, in run force=self.force) File "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\ccompiler.py", line 366, in new_compiler compiler = klass(None, dry_run, force) File "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\mingw32ccompiler.py", line 46, in __init__ verbose,dry_run, force) File "c:\Python25\lib\distutils\cygwinccompiler.py", line 84, in __init__ get_versions() File "c:\Python25\lib\distutils\cygwinccompiler.py", line 424, in get_versions ld_version = StrictVersion(result.group(1)) File "C:\Python25\lib\distutils\version.py", line 40, in __init__ self.parse(vstring) File "C:\Python25\lib\distutils\version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '2.18.50.20080625' Greetings, Uwe -- Dr. rer. nat. Uwe Schmitt F&E Mathematik mineway GmbH Science Park 2 D-66123 Saarbr?cken Telefon: +49 (0)681 8390 5334 Telefax: +49 (0)681 830 4376 uschmitt at mineway.de www.mineway.de Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer Amtsgericht Saarbr?cken HRB 12339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at ar.media.kyoto-u.ac.jp Fri Jul 25 05:33:05 2008 From: david at ar.media.kyoto-u.ac.jp (David Cournapeau) Date: Fri, 25 Jul 2008 18:33:05 +0900 Subject: [SciPy-dev] [mailinglist] Re: NNLS In-Reply-To: <48899E6F.1090505@mineway.de> References: <48875105.7010708@mineway.de> <3d375d730807231546t72f468c4u1980650481ccb8a2@mail.gmail.com> <48883ECD.6000109@mineway.de> <3d375d730807241137s47df563av9ba9d19beba9ea65@mail.gmail.com> <48899E6F.1090505@mineway.de> Message-ID: <48899DD1.7050606@ar.media.kyoto-u.ac.jp> Uwe Schmitt wrote: > And on stderr: > > rmbadname1: Replacing "index" with "index_bn". > rmbadname1: Replacing "index" with "index_bn". > Traceback (most recent call last): > File "f2py.py", line 26, in > main() > File > "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\f2py\f2py2e.py", > line 558, in main > run_compile() > File > "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\f2py\f2py2e.py", > line 545, in run_compile > setup(ext_modules = [ext]) > File > "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\core.py", > line 176, in setup > return old_setup(**new_attr) > File "C:\Python25\lib\distutils\core.py", line 151, in setup > dist.run_commands() > File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands > self.run_command(cmd) > File "C:\Python25\lib\distutils\dist.py", line 994, in run_command > cmd_obj.run() > File "C:\Python25\lib\distutils\command\build.py", line 112, in run > self.run_command(cmd_name) > File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command > self.distribution.run_command(command) > File "C:\Python25\lib\distutils\dist.py", line 994, in run_command > cmd_obj.run() > File > "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\command\build_ext.py", > line 78, in run > force=self.force) > File > "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\ccompiler.py", > line 366, in new_compiler > compiler = klass(None, dry_run, force) > File > "c:\Python25\lib\site-packages\numpy-1.0.4.0003-py2.5-win32.egg\numpy\distutils\mingw32ccompiler.py", > line 46, in __init__ > verbose,dry_run, force) > File "c:\Python25\lib\distutils\cygwinccompiler.py", line 84, in > __init__ > get_versions() > File "c:\Python25\lib\distutils\cygwinccompiler.py", line 424, > in get_versions > ld_version = StrictVersion(result.group(1)) > File "C:\Python25\lib\distutils\version.py", line 40, in __init__ > self.parse(vstring) > File "C:\Python25\lib\distutils\version.py", line 107, in parse > raise ValueError, "invalid version number '%s'" % vstring > ValueError: invalid version number '2.18.50.20080625' > That's a problem of distutils not dealing with some special releases (e.g. 2.18.50 for binutils is OK). I don't know if there is a fix outside patching directly the sources (to remove this version checking which does not make any sense to me ?). It may worth being handled by use because with recent mingw (specially with 4.* releases of gcc), those release numbers are the ones present in the recent "releases". cheers, David From nwagner at iam.uni-stuttgart.de Fri Jul 25 08:24:13 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 25 Jul 2008 14:24:13 +0200 Subject: [SciPy-dev] Ticket 709 Message-ID: Hi all, Can someone reproduce the bug http://scipy.org/scipy/scipy/ticket/709 ? The eigencurves should be smooth. Nils From uschmitt at mineway.de Fri Jul 25 09:34:16 2008 From: uschmitt at mineway.de (Uwe Schmitt) Date: Fri, 25 Jul 2008 15:34:16 +0200 Subject: [SciPy-dev] [mailinglist] Ticket 709 In-Reply-To: References: Message-ID: <4889D658.4010504@mineway.de> Nils Wagner schrieb: > Hi all, > > Can someone reproduce the bug > http://scipy.org/scipy/scipy/ticket/709 ? > Yes, I got the same result. I condensed the code to the following code: from base64 import b64decode from numpy import loads from scipy.linalg import eig Abin='gAJjbnVtcHkuY29yZS5tdWx0aWFycmF5Cl9yZWNv'\ 'bnN0cnVjdApxAWNudW1weQpuZGFycmF5CnECSwCF'\ 'VQFih1JxAyhLAUsQhWNudW1weQpkdHlwZQpxBFUC'\ 'ZjhLAEsBh1JxBShLA1UBPE5OTkr/////Sv////9L'\ 'AHRiiVWAAAAAAAAA8D8AAAAAAAAAAAAAAAAAAAAA'\ 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPA/AAAAAAAA'\ 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4juM4'\ 'juMYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'\ 'AAAAAACAOI7jOI7jGMB0Yi4=' Bbin='gAJjbnVtcHkuY29yZS5tdWx0aWFycmF5Cl9yZWNv'\ 'bnN0cnVjdApxAWNudW1weQpuZGFycmF5CnECSwCF'\ 'VQFih1JxAyhLAUsQhWNudW1weQpkdHlwZQpxBFUC'\ 'ZjhLAEsBh1JxBShLA1UBPE5OTkr/////Sv////9L'\ 'AHRiiVWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPA/'\ 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'\ 'AAAAAAAAAADwPwAAAAAAAPA/AAAAAAAAAAAAAAAA'\ 'AAAAAKuqqqqqqgrAAAAAAAAAAAAAAAAAAADwP6uq'\ 'qqqqqgpAAAAAAAAAAAB0Yi4=' A= loads(b64decode(Abin)).reshape(4,4) B= loads(b64decode(Bbin)).reshape(4,4) print A print print B print eig(A,B) numpy is 1.0.4 scipy is 0.6.0 Greetings, Uwe > The eigencurves should be smooth. > > Nils > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > > -- Dr. rer. nat. Uwe Schmitt F&E Mathematik mineway GmbH Science Park 2 D-66123 Saarbr?cken Telefon: +49 (0)681 8390 5334 Telefax: +49 (0)681 830 4376 uschmitt at mineway.de www.mineway.de Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer Amtsgericht Saarbr?cken HRB 12339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwagner at iam.uni-stuttgart.de Fri Jul 25 09:52:08 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 25 Jul 2008 15:52:08 +0200 Subject: [SciPy-dev] [mailinglist] Ticket 709 In-Reply-To: <4889D658.4010504@mineway.de> References: <4889D658.4010504@mineway.de> Message-ID: On Fri, 25 Jul 2008 15:34:16 +0200 Uwe Schmitt wrote: > Nils Wagner schrieb: >> Hi all, >> >> Can someone reproduce the bug >> http://scipy.org/scipy/scipy/ticket/709 ? >> > Yes, I got the same result. > I condensed the code to the following > code: > > from base64 import b64decode > from numpy import loads > from scipy.linalg import eig > > Abin='gAJjbnVtcHkuY29yZS5tdWx0aWFycmF5Cl9yZWNv'\ > 'bnN0cnVjdApxAWNudW1weQpuZGFycmF5CnECSwCF'\ > 'VQFih1JxAyhLAUsQhWNudW1weQpkdHlwZQpxBFUC'\ > 'ZjhLAEsBh1JxBShLA1UBPE5OTkr/////Sv////9L'\ > 'AHRiiVWAAAAAAAAA8D8AAAAAAAAAAAAAAAAAAAAA'\ > 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPA/AAAAAAAA'\ > 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4juM4'\ > 'juMYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'\ > 'AAAAAACAOI7jOI7jGMB0Yi4=' > > > Bbin='gAJjbnVtcHkuY29yZS5tdWx0aWFycmF5Cl9yZWNv'\ > 'bnN0cnVjdApxAWNudW1weQpuZGFycmF5CnECSwCF'\ > 'VQFih1JxAyhLAUsQhWNudW1weQpkdHlwZQpxBFUC'\ > 'ZjhLAEsBh1JxBShLA1UBPE5OTkr/////Sv////9L'\ > 'AHRiiVWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPA/'\ > 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'\ > 'AAAAAAAAAADwPwAAAAAAAPA/AAAAAAAAAAAAAAAA'\ > 'AAAAAKuqqqqqqgrAAAAAAAAAAAAAAAAAAADwP6uq'\ > 'qqqqqgpAAAAAAAAAAAB0Yi4=' > > A= loads(b64decode(Abin)).reshape(4,4) > B= loads(b64decode(Bbin)).reshape(4,4) > > print A > print > print B > > print eig(A,B) > > numpy is 1.0.4 > scipy is 0.6.0 > > Greetings, Uwe > >> The eigencurves should be smooth. >> >> Nils >> >> >> _______________________________________________ >> Scipy-dev mailing list >> Scipy-dev at scipy.org >> http://projects.scipy.org/mailman/listinfo/scipy-dev >> >> > > > -- > Dr. rer. nat. Uwe Schmitt >F&E Mathematik > > mineway GmbH > Science Park 2 > D-66123 Saarbr?cken > > Telefon: +49 (0)681 8390 5334 > Telefax: +49 (0)681 830 4376 > > uschmitt at mineway.de > www.mineway.de > > Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer > Amtsgericht Saarbr?cken HRB 12339 > > I found an old entry http://projects.scipy.org/scipy/scipy/ticket/224 David, please can you comment on that. Nils From david at ar.media.kyoto-u.ac.jp Fri Jul 25 10:28:40 2008 From: david at ar.media.kyoto-u.ac.jp (David Cournapeau) Date: Fri, 25 Jul 2008 23:28:40 +0900 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> References: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> Message-ID: <4889E318.8060602@ar.media.kyoto-u.ac.jp> St?fan van der Walt wrote: > > Does the release schedule of SciPy look the same then? I.e. do we > release 0.7rc1 on the same day as 1.2.0rc1? Or does SciPy only get a > single release? > > It depends on what we want for scipy 0.7. I don't think it is realistic to expect to close most bugs for 0.7 at that time. Some bugs are not trivial, and some require a lot of work. There are also some new packages which did not build cleanly up to recently (stats.models ?). Generally, I am a bit worried by the amount of new code in scipy: there was a bit too much new functionality since 0.6 IMHO. What about releaseing a 0.7 at the same time as numpy 1.2, and then focusing more on bug fixing/API consolidation in 0.8 ? cheers, David From fperez.net at gmail.com Fri Jul 25 12:10:12 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 25 Jul 2008 09:10:12 -0700 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: <4889E318.8060602@ar.media.kyoto-u.ac.jp> References: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> <4889E318.8060602@ar.media.kyoto-u.ac.jp> Message-ID: On Fri, Jul 25, 2008 at 7:28 AM, David Cournapeau wrote: > Generally, I am a bit worried by the amount of new code in scipy: there > was a bit too much new functionality since 0.6 IMHO. What about > releaseing a 0.7 at the same time as numpy 1.2, and then focusing more > on bug fixing/API consolidation in 0.8 ? +1 I think overly long release cycles are worse in the long run than a release with a few rough edges. We could even sprinkle suitable warning("tech preview package") here and there as orange cones in front of the largest potholes. Cheers f From nwagner at iam.uni-stuttgart.de Fri Jul 25 12:22:13 2008 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 25 Jul 2008 18:22:13 +0200 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: References: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> <4889E318.8060602@ar.media.kyoto-u.ac.jp> Message-ID: On Fri, 25 Jul 2008 09:10:12 -0700 "Fernando Perez" wrote: > On Fri, Jul 25, 2008 at 7:28 AM, David Cournapeau > wrote: > >> Generally, I am a bit worried by the amount of new code >>in scipy: there >> was a bit too much new functionality since 0.6 IMHO. >>What about >> releaseing a 0.7 at the same time as numpy 1.2, and then >>focusing more >> on bug fixing/API consolidation in 0.8 ? > > +1 > > I think overly long release cycles are worse in the long >run than a > release with a few rough edges. We could even sprinkle >suitable > warning("tech preview package") here and there as orange >cones in > front of the largest potholes. > > Cheers > > f IMHO it would be nice if all tests pass. Moreover it would be nice if ticket 709 http://projects.scipy.org/scipy/scipy/ticket/709 will be closed before. Nils From millman at berkeley.edu Fri Jul 25 13:23:04 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Fri, 25 Jul 2008 10:23:04 -0700 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: <4889E318.8060602@ar.media.kyoto-u.ac.jp> References: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> <4889E318.8060602@ar.media.kyoto-u.ac.jp> Message-ID: On Fri, Jul 25, 2008 at 7:28 AM, David Cournapeau wrote: > Generally, I am a bit worried by the amount of new code in scipy: there > was a bit too much new functionality since 0.6 IMHO. What about > releaseing a 0.7 at the same time as numpy 1.2, and then focusing more > on bug fixing/API consolidation in 0.8 ? I would rather see us focus on getting a series of bugfix releases (0.7.1, 0.7.2, etc.) out than starting to work on 0.8.0. Of course, that is just another way of saying I completely agree with you. I think we will also need to mark a few packages (e.g., stats.models) as technology previews with the expectation that there may be bugs and that the API for these specific packages hasn't been finalized. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From millman at berkeley.edu Fri Jul 25 13:26:08 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Fri, 25 Jul 2008 10:26:08 -0700 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> References: <9457e7c80807250035y7d93e29dq1b03c2aa678b575a@mail.gmail.com> Message-ID: On Fri, Jul 25, 2008 at 12:35 AM, St?fan van der Walt wrote: > Does the release schedule of SciPy look the same then? I.e. do we > release 0.7rc1 on the same day as 1.2.0rc1? Or does SciPy only get a > single release? Sorry I should have been more explicit. Yes, I was that we use the exact same schedule for both releases. Specifically, here is the SciPy release schedule: - 8/05/08 tag the 0.7.0rc1 release and prepare packages - 8/12/08 tag the 0.7.0rc2 release and prepare packages - 8/23/08 tag the 0.7.0 release and prepare packages - 8/24/08 announce release -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From eads at soe.ucsc.edu Fri Jul 25 18:36:35 2008 From: eads at soe.ucsc.edu (Damian Eads) Date: Fri, 25 Jul 2008 15:36:35 -0700 (PDT) Subject: [SciPy-dev] numpy long vs. int Message-ID: <42041.128.165.112.85.1217025395.squirrel@squirrelmail.soe.ucsc.edu> Hi there, I had some problems porting some internal extension code I wrote recently. The code worked fine on 32-bit but did not work on 64-bit. When np.int_ is used as the dtype argument to np.zeros or np.asarray, an array results that has typecode NPY_INT on 32-bit and NPY_LONG on 64-bit. This inconsistency is problematic when type checking arrays in C-space prior to passing them to a C function expecting a specific type, like int. Changing dtype=np.int_ to dtype='i' seems to consistently result in an array with typecode NPY_INT on both architectures, which is desired. I didn't think to write about this until I encountered the very same problem today when trying to compile the ANN scikit on 64-bit. All the tests failed because the kd-tree array passed was of type long. ====================================================================== ERROR: test_ann.TestANNWrapper.test_knn_returns_nearest_neighbor(array([[ 0.53209373, 0.2149725 ], ---------------------------------------------------------------------- Traceback (most recent call last): File "/mirror/ssrc/eads/sci-tools/prefix-x86-64/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/mirror/ssrc/eads/sci-tools-source/x86-64/ann/scikits/ann/tests/test_ann.py", line 49, in checkReturnNN nn,nn_distances = tree.knn(pt,1) File "scikits/ann/__init__.py", line 113, in knn self._knn2(pts, idx, d2, eps) File "scikits/ann/ANN.py", line 45, in _knn2 def _knn2(*args): return _ANN._kdtree__knn2(*args) TypeError: Array of type 'int' required. Array of type 'long' given ================================= Changing line 110 from dtype=np.int_ to dtype='i' fixed the problem. Some people seem insistent on using a type object (e.g. np.int_ or np.float_) instead of a string. In fact, when I checked in my hierarchical clustering code, I noticed someone eventually changed all the dtype's in my code to use the type objects. I had no qualms with this until now. Are there type objects that can be passed to dtype to guarantee consistency in translation to NPY_XXX type codes? We should probably write a caveat in the Numpy C extensions help document explaining this inconsistency. Thanks, Damian From robert.kern at gmail.com Fri Jul 25 18:43:28 2008 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 25 Jul 2008 17:43:28 -0500 Subject: [SciPy-dev] numpy long vs. int In-Reply-To: <42041.128.165.112.85.1217025395.squirrel@squirrelmail.soe.ucsc.edu> References: <42041.128.165.112.85.1217025395.squirrel@squirrelmail.soe.ucsc.edu> Message-ID: <3d375d730807251543h678facc6s7626f337cf7044f@mail.gmail.com> On Fri, Jul 25, 2008 at 17:36, Damian Eads wrote: > Hi there, > > I had some problems porting some internal extension code I wrote recently. > The code worked fine on 32-bit but did not work on 64-bit. When np.int_ is > used as the dtype argument to np.zeros or np.asarray, an array results > that has typecode NPY_INT on 32-bit and NPY_LONG on 64-bit. This > inconsistency is problematic when type checking arrays in C-space prior to > passing them to a C function expecting a specific type, like int. Changing > dtype=np.int_ to dtype='i' seems to consistently result in an array with > typecode NPY_INT on both architectures, which is desired. > > I didn't think to write about this until I encountered the very same > problem today when trying to compile the ANN scikit on 64-bit. All the > tests failed because the kd-tree array passed was of type long. > > ====================================================================== > ERROR: test_ann.TestANNWrapper.test_knn_returns_nearest_neighbor(array([[ > 0.53209373, 0.2149725 ], > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/mirror/ssrc/eads/sci-tools/prefix-x86-64/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py", > line 182, in runTest > self.test(*self.arg) > File > "/mirror/ssrc/eads/sci-tools-source/x86-64/ann/scikits/ann/tests/test_ann.py", > line 49, in checkReturnNN > nn,nn_distances = tree.knn(pt,1) > File "scikits/ann/__init__.py", line 113, in knn > self._knn2(pts, idx, d2, eps) > File "scikits/ann/ANN.py", line 45, in _knn2 > def _knn2(*args): return _ANN._kdtree__knn2(*args) > TypeError: Array of type 'int' required. Array of type 'long' given > ================================= > > Changing line 110 from dtype=np.int_ to dtype='i' fixed the problem. Some > people seem insistent on using a type object (e.g. np.int_ or np.float_) > instead of a string. In fact, when I checked in my hierarchical clustering > code, I noticed someone eventually changed all the dtype's in my code to > use the type objects. I had no qualms with this until now. Are there type > objects that can be passed to dtype to guarantee consistency in > translation to NPY_XXX type codes? We should probably write a caveat in > the Numpy C extensions help document explaining this inconsistency. numpy.intc gives NPY_INT. numpy.int_ gives NPY_LONG (since Python ints are C longs). -- 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 From eads at soe.ucsc.edu Fri Jul 25 18:45:59 2008 From: eads at soe.ucsc.edu (Damian Eads) Date: Fri, 25 Jul 2008 15:45:59 -0700 (PDT) Subject: [SciPy-dev] numpy long vs. int In-Reply-To: <3d375d730807251543h678facc6s7626f337cf7044f@mail.gmail.com> References: <42041.128.165.112.85.1217025395.squirrel@squirrelmail.soe.ucsc.edu> <3d375d730807251543h678facc6s7626f337cf7044f@mail.gmail.com> Message-ID: <39596.128.165.112.85.1217025959.squirrel@squirrelmail.soe.ucsc.edu> > On Fri, Jul 25, 2008 at 17:36, Damian Eads wrote: >> Hi there, >> >> I had some problems porting some internal extension code I wrote >> recently. >> The code worked fine on 32-bit but did not work on 64-bit. When np.int_ >> is >> used as the dtype argument to np.zeros or np.asarray, an array results >> that has typecode NPY_INT on 32-bit and NPY_LONG on 64-bit. This >> inconsistency is problematic when type checking arrays in C-space prior >> to >> passing them to a C function expecting a specific type, like int. >> Changing >> dtype=np.int_ to dtype='i' seems to consistently result in an array with >> typecode NPY_INT on both architectures, which is desired. >> >> I didn't think to write about this until I encountered the very same >> problem today when trying to compile the ANN scikit on 64-bit. All the >> tests failed because the kd-tree array passed was of type long. >> >> ====================================================================== >> ERROR: >> test_ann.TestANNWrapper.test_knn_returns_nearest_neighbor(array([[ >> 0.53209373, 0.2149725 ], >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/mirror/ssrc/eads/sci-tools/prefix-x86-64/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py", >> line 182, in runTest >> self.test(*self.arg) >> File >> "/mirror/ssrc/eads/sci-tools-source/x86-64/ann/scikits/ann/tests/test_ann.py", >> line 49, in checkReturnNN >> nn,nn_distances = tree.knn(pt,1) >> File "scikits/ann/__init__.py", line 113, in knn >> self._knn2(pts, idx, d2, eps) >> File "scikits/ann/ANN.py", line 45, in _knn2 >> def _knn2(*args): return _ANN._kdtree__knn2(*args) >> TypeError: Array of type 'int' required. Array of type 'long' given >> ================================= >> >> Changing line 110 from dtype=np.int_ to dtype='i' fixed the problem. >> Some >> people seem insistent on using a type object (e.g. np.int_ or np.float_) >> instead of a string. In fact, when I checked in my hierarchical >> clustering >> code, I noticed someone eventually changed all the dtype's in my code to >> use the type objects. I had no qualms with this until now. Are there >> type >> objects that can be passed to dtype to guarantee consistency in >> translation to NPY_XXX type codes? We should probably write a caveat in >> the Numpy C extensions help document explaining this inconsistency. > > numpy.intc gives NPY_INT. numpy.int_ gives NPY_LONG (since Python ints > are C longs). Any reason why there aren't np.floatc or np.doublec equivalents? Just curious, Damian From rmay31 at gmail.com Fri Jul 25 19:00:22 2008 From: rmay31 at gmail.com (Ryan May) Date: Fri, 25 Jul 2008 19:00:22 -0400 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: References: Message-ID: <488A5B06.8000105@gmail.com> Jarrod Millman wrote: > Now that NumPy 1.1.1 is almost out, I wanted to remind everyone of the > NumPy 1.2.0 schedule: > - 8/05/08 tag the 1.2.0rc1 release and prepare packages > - 8/12/08 tag the 1.2.0rc2 release and prepare packages > - 8/23/08 tag the 1.2.0 release and prepare packages > - 8/24/08 announce release > > Ideally, I would like to release SciPy 0.7.0 at the same time. In > order for this to have any chance of success, I will need help keeping > an eye on the outstanding tickets and help rallying everyone to fix > bugs. > > In particular, I would appreciate it if you could let me know of any > bugs that should be considered release blockers. According to this > release schedule, the first release candidate is due in a little less > than two weeks with the final release in exactly one month. While > this may seem an aggressive release schedule, I believe it is very > achievable if everyone pitches in. Can I get someone to look at #581: http://scipy.org/scipy/scipy/ticket/581 It's got a patch that works for me. It'd be nice for the fall signal processing students to have a working chebwin() instead of wondering why their output doesn't match their textbook (like I did). Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma From matthieu.brucher at gmail.com Sat Jul 26 03:40:33 2008 From: matthieu.brucher at gmail.com (Matthieu Brucher) Date: Sat, 26 Jul 2008 09:40:33 +0200 Subject: [SciPy-dev] numpy long vs. int In-Reply-To: <39596.128.165.112.85.1217025959.squirrel@squirrelmail.soe.ucsc.edu> References: <42041.128.165.112.85.1217025395.squirrel@squirrelmail.soe.ucsc.edu> <3d375d730807251543h678facc6s7626f337cf7044f@mail.gmail.com> <39596.128.165.112.85.1217025959.squirrel@squirrelmail.soe.ucsc.edu> Message-ID: > Any reason why there aren't np.floatc or np.doublec equivalents? > > Just curious, Hi, Ints and longs have a differnet length on different platform. Floating point number are a standard, so you can allows rely on float = numpy.float32 and double = numpy.float64. Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher From wnbell at gmail.com Sat Jul 26 03:46:09 2008 From: wnbell at gmail.com (Nathan Bell) Date: Sat, 26 Jul 2008 02:46:09 -0500 Subject: [SciPy-dev] numpy long vs. int In-Reply-To: References: <42041.128.165.112.85.1217025395.squirrel@squirrelmail.soe.ucsc.edu> <3d375d730807251543h678facc6s7626f337cf7044f@mail.gmail.com> <39596.128.165.112.85.1217025959.squirrel@squirrelmail.soe.ucsc.edu> Message-ID: On Sat, Jul 26, 2008 at 2:40 AM, Matthieu Brucher wrote: > > Ints and longs have a differnet length on different platform. Floating > point number are a standard, so you can allows rely on float = > numpy.float32 and double = numpy.float64. > Well, they are standardized until you get to longdouble :) -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From mellerf at netvision.net.il Sat Jul 26 03:59:24 2008 From: mellerf at netvision.net.il (Yosef Meller) Date: Sat, 26 Jul 2008 10:59:24 +0300 Subject: [SciPy-dev] Removing globals from minpack wrapper, v3 In-Reply-To: <4881F9B4.7030804@netvision.net.il> References: <4881F9B4.7030804@netvision.net.il> Message-ID: <488AD95C.1080501@netvision.net.il> Yosef Meller wrote: > > Before I enter exams period, one more patch in the series: > > Changes: > * Now optimize.leastsq() and optimize.fsolve() should be completely > thread-safe. > * Rearranged the macros to reduce code duplication. > > Still to do: > * chkder, but I don't know if it's significant there. > * smjac_* in __minpack.h - what is that function used for? Will this patch be considered for merging before 0.7? -- http://yosefm.imagekind.com/Eclectic From oliphant at enthought.com Sat Jul 26 08:19:44 2008 From: oliphant at enthought.com (Travis E. Oliphant) Date: Sat, 26 Jul 2008 07:19:44 -0500 Subject: [SciPy-dev] Removing globals from minpack wrapper, v3 In-Reply-To: <488AD95C.1080501@netvision.net.il> References: <4881F9B4.7030804@netvision.net.il> <488AD95C.1080501@netvision.net.il> Message-ID: <488B1660.3010809@enthought.com> Yosef Meller wrote: > Yosef Meller wrote: > >> Before I enter exams period, one more patch in the series: >> >> Changes: >> * Now optimize.leastsq() and optimize.fsolve() should be completely >> thread-safe. >> * Rearranged the macros to reduce code duplication. >> >> Still to do: >> * chkder, but I don't know if it's significant there. >> * smjac_* in __minpack.h - what is that function used for? >> > > Will this patch be considered for merging before 0.7? > I'd like it to happen. -Travis From uschmitt at mineway.de Sat Jul 26 09:29:28 2008 From: uschmitt at mineway.de (Uwe Schmitt) Date: Sat, 26 Jul 2008 15:29:28 +0200 Subject: [SciPy-dev] [mailinglist] Re: NNLS In-Reply-To: <3d375d730807241137s47df563av9ba9d19beba9ea65@mail.gmail.com> References: <48875105.7010708@mineway.de> <3d375d730807231546t72f468c4u1980650481ccb8a2@mail.gmail.com> <48883ECD.6000109@mineway.de> <3d375d730807241137s47df563av9ba9d19beba9ea65@mail.gmail.com> Message-ID: Am 24.07.2008 um 20:37 schrieb Robert Kern: > On Thu, Jul 24, 2008 at 03:35, Uwe Schmitt > wrote: >> Robert Kern schrieb: >>> On Wed, Jul 23, 2008 at 17:47, Alan G Isaac >>> wrote: >>> >>> Well, I'd prefer an f2py version rather than a ctypes version, but >>> yes, please. >>> >>> >> I had some problems because my local python.exe is from Enthought, >> which >> was compiled >> with MS Visual Studio. But I wanted g77 for compiling the Fortran >> code, >> which gives some problems when using f2py. > > Can you describe these problems? The g77 we distribute with EPD is > compatible with the compiler used to build the Python executable, at > least when used from distutils. But basically, we can't use ctypes for > Fortran code in scipy. The calling conventions are different between > Fortran compilers; f2py has worked out most of these, but I have seen > no equivalent work done for ctypes. Additionally, the story for > building non-extension shared libraries inside scipy is not really > worked out, yet. It works now. Using a naked VM with WinXP and Enthoughtedietion 2.5.1 did it. > > >> Do you have some conventions about code layout, directory layort, >> etc ? > > I suspect this should go into scipy.optimize, so look into > integrating it there. > . Ok > >> How can I contribute the code ? Shall I post a link ? > > If you would like someone else to take a look at it first, then please > do post a link. However, I will arrange for you to get SVN access. I > recommend working on a branch first. > Ok, I will look at scipy.optimize and will develop the module. I will send you the result per email. Greetings, Uwe > -- > 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 > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev From charlesr.harris at gmail.com Sat Jul 26 10:44:18 2008 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 26 Jul 2008 08:44:18 -0600 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: References: Message-ID: On Thu, Jul 24, 2008 at 10:53 PM, Jarrod Millman wrote: > Now that NumPy 1.1.1 is almost out, I wanted to remind everyone of the > NumPy 1.2.0 schedule: > - 8/05/08 tag the 1.2.0rc1 release and prepare packages > - 8/12/08 tag the 1.2.0rc2 release and prepare packages > - 8/23/08 tag the 1.2.0 release and prepare packages > - 8/24/08 announce release > > Ideally, I would like to release SciPy 0.7.0 at the same time. In > order for this to have any chance of success, I will need help keeping > an eye on the outstanding tickets and help rallying everyone to fix > bugs. > Will numpy 1.2 be a dependency of SciPy 0.7.0 or will it work equally well with numpy 1.1.1? What is the Python version dependence? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From wnbell at gmail.com Sat Jul 26 11:14:35 2008 From: wnbell at gmail.com (Nathan Bell) Date: Sat, 26 Jul 2008 10:14:35 -0500 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: References: Message-ID: On Sat, Jul 26, 2008 at 9:44 AM, Charles R Harris wrote: > > > > Will numpy 1.2 be a dependency of SciPy 0.7.0 or will it work equally well > with numpy 1.1.1? SciPy currently depends on NumPy from SVN, so I think 1.2 will be a requirement. > What is the Python version dependence? SciPy SVN requires 2.4 now. I believe NumPy 1.2 does also. -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From millman at berkeley.edu Sat Jul 26 11:50:56 2008 From: millman at berkeley.edu (Jarrod Millman) Date: Sat, 26 Jul 2008 08:50:56 -0700 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: References: Message-ID: On Sat, Jul 26, 2008 at 8:14 AM, Nathan Bell wrote: > On Sat, Jul 26, 2008 at 9:44 AM, Charles R Harris > wrote: >> Will numpy 1.2 be a dependency of SciPy 0.7.0 or will it work equally well >> with numpy 1.1.1? > > SciPy currently depends on NumPy from SVN, so I think 1.2 will be a requirement. > >> What is the Python version dependence? > > SciPy SVN requires 2.4 now. I believe NumPy 1.2 does also. Yes, SciPy 0.7 requires NumPy 1.2 and Python 2.4. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ From david at ar.media.kyoto-u.ac.jp Sun Jul 27 05:53:32 2008 From: david at ar.media.kyoto-u.ac.jp (David Cournapeau) Date: Sun, 27 Jul 2008 18:53:32 +0900 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: References: Message-ID: <488C459C.9040308@ar.media.kyoto-u.ac.jp> Nathan Bell wrote: > > SciPy currently depends on NumPy from SVN, so I think 1.2 will be a requirement. > > Am I the only one who find this far from ideal ? Scipy 0.6 was out like 9 months ago, we build some new numpy releases in between, and no release of scipy for them ? What requires numpy 1.2 in scipy ? cheers, David From wnbell at gmail.com Sun Jul 27 09:25:27 2008 From: wnbell at gmail.com (Nathan Bell) Date: Sun, 27 Jul 2008 08:25:27 -0500 Subject: [SciPy-dev] NumPy 1.2.0 and SciPy 0.7.0 schedule In-Reply-To: <488C459C.9040308@ar.media.kyoto-u.ac.jp> References: <488C459C.9040308@ar.media.kyoto-u.ac.jp> Message-ID: On Sun, Jul 27, 2008 at 4:53 AM, David Cournapeau wrote: > > Am I the only one who find this far from ideal ? Scipy 0.6 was out like > 9 months ago, we build some new numpy releases in between, and no > release of scipy for them ? > > What requires numpy 1.2 in scipy ? > If I'm not mistaken, the unit testing framework moved from scipy.testing to numpy.testing recently. I don't see a problem with bundling the two. -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From joel.schaerer at insa-lyon.fr Mon Jul 28 05:13:23 2008 From: joel.schaerer at insa-lyon.fr (Joel Schaerer) Date: Mon, 28 Jul 2008 09:13:23 +0000 (UTC) Subject: [SciPy-dev] scipy.signal.convolve2d very slow, why is it there exactly? Message-ID: Hi all, I had previously reported that signal.convolve2d was significantly slower than matlab for the following code: ------------- #!/usr/bin/python import scipy.io as io import scipy.signal aa=io.loadmat('input.mat') seq=aa["seq"] #seq_f=scipy.empty(seq.shape) seq_f=[] kernel=scipy.randn(21,21) for k in xrange(seq.shape[2]): seq_f.append(scipy.signal.convolve2d(seq[:,:,k],kernel,'same')) io.savemat("output_python2.mat",{"seq_f":seq_f}) ----------------- Turns out, I can get even better results than matlab by using fftconvolve instead of convolve2d. The generic signal.convolve gives intermediary results, a lot better than convolve2d but still slower than matlab. Here are the results of my measurements for anyone interested: convolve2d : 9 minutes convolve : 3 minutes matlab's conv2 : 1m2s fftconvolve : 35s So the question seems to be, why is convolve2d even there? It's very slow and limited to 2D arrays. It's misleading to newcommers who might very well conclude from its use that scipy is too slow to be useful. From mellerf at netvision.net.il Mon Jul 28 09:41:06 2008 From: mellerf at netvision.net.il (Yosef Meller) Date: Mon, 28 Jul 2008 16:41:06 +0300 Subject: [SciPy-dev] Removing globals from minpack wrapper, v3 In-Reply-To: <488B1660.3010809@enthought.com> References: <4881F9B4.7030804@netvision.net.il> <488AD95C.1080501@netvision.net.il> <488B1660.3010809@enthought.com> Message-ID: <488DCC72.9070508@netvision.net.il> Travis E. Oliphant wrote: > Yosef Meller wrote: >> Will this patch be considered for merging before 0.7? >> > I'd like it to happen. > > -Travis So, what is the process to merge it? From dsdale24 at gmail.com Tue Jul 29 11:43:54 2008 From: dsdale24 at gmail.com (Darren Dale) Date: Tue, 29 Jul 2008 11:43:54 -0400 Subject: [SciPy-dev] physical quantities: udunits? Message-ID: <200807291143.55141.dsdale24@gmail.com> I was wondering if anyone is familiar with the udunits package, would it be suitable as the foundation for physical quantities support in python? http://www.unidata.ucar.edu/software/udunits/ According to freshmeat, udunits is released under a BSD-style license. From doutriaux1 at llnl.gov Tue Jul 29 17:29:19 2008 From: doutriaux1 at llnl.gov (Charles Doutriaux) Date: Tue, 29 Jul 2008 14:29:19 -0700 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <200807291143.55141.dsdale24@gmail.com> References: <200807291143.55141.dsdale24@gmail.com> Message-ID: <488F8BAF.309@llnl.gov> Hi Darren, We are using it in cdat, we even have a direct python wrapping to it. (I tried to email it to the list but it got held becasue it's too big) On another C project I'm using udunits2 it's much easier to build. Anyhow if you want i can email you our package (unless it gets approved on the list here) and you can either use it, discard it or improve it. Best regards, C. Darren Dale wrote: > I was wondering if anyone is familiar with the udunits package, would it be > suitable as the foundation for physical quantities support in python? > > http:// www. unidata.ucar.edu/software/udunits/ > > According to freshmeat, udunits is released under a BSD-style license. > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http:// projects.scipy.org/mailman/listinfo/scipy-dev > > > From stefan at sun.ac.za Tue Jul 29 17:57:28 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 29 Jul 2008 23:57:28 +0200 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <488F8BAF.309@llnl.gov> References: <200807291143.55141.dsdale24@gmail.com> <488F8BAF.309@llnl.gov> Message-ID: <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> Hi Charles 2008/7/29 Charles Doutriaux : > Anyhow if you want i can email you our package (unless it gets approved > on the list here) and you can either use it, discard it or improve it. Rather put such big files on the web, and send us a link. That way, interested parties can download the code, without scipy-dev mailing large attachments to all subscribers. Whereas sharing SVN repositories requires some configuration, bzr and mercurial can be shared very easily (i.e. just dump it on the web, or use launchpad, hgwebdir, ...). On the other hand, a .tar.gz is also perfectly acceptable! Looking forward to seeing what you came up with! Cheers St?fan From doutriaux1 at llnl.gov Tue Jul 29 18:15:46 2008 From: doutriaux1 at llnl.gov (Charles Doutriaux) Date: Tue, 29 Jul 2008 15:15:46 -0700 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> References: <200807291143.55141.dsdale24@gmail.com> <488F8BAF.309@llnl.gov> <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> Message-ID: <488F9692.9030301@llnl.gov> Hi Stepfan Weel it was a tar.gz that wasn't that big (43k) ... anyway you can svn it out at: svn export http://www-pcmdi.llnl.gov/svn/repository/cdat/trunk/Packages/unidata C. St?fan van der Walt wrote: > Hi Charles > > 2008/7/29 Charles Doutriaux : > >> Anyhow if you want i can email you our package (unless it gets approved >> on the list here) and you can either use it, discard it or improve it. >> > > Rather put such big files on the web, and send us a link. That way, > interested parties can download the code, without scipy-dev mailing > large attachments to all subscribers. Whereas sharing SVN > repositories requires some configuration, bzr and mercurial can be > shared very easily (i.e. just dump it on the web, or use launchpad, > hgwebdir, ...). On the other hand, a .tar.gz is also perfectly > acceptable! > > Looking forward to seeing what you came up with! > > Cheers > St?fan > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http:// projects.scipy.org/mailman/listinfo/scipy-dev > > > From stefan at sun.ac.za Tue Jul 29 18:52:19 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 30 Jul 2008 00:52:19 +0200 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <488F9692.9030301@llnl.gov> References: <200807291143.55141.dsdale24@gmail.com> <488F8BAF.309@llnl.gov> <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> <488F9692.9030301@llnl.gov> Message-ID: <9457e7c80807291552y95f39f4p1ab87ae8b9b1fab1@mail.gmail.com> 2008/7/30 Charles Doutriaux : > Weel it was a tar.gz that wasn't that big (43k) ... anyway you can svn > it out at: > svn export > http://www-pcmdi.llnl.gov/svn/repository/cdat/trunk/Packages/unidata Loos like we need a password for that? Cheers St?fan From john at curioussymbols.com Tue Jul 29 19:35:04 2008 From: john at curioussymbols.com (John Pye) Date: Wed, 30 Jul 2008 09:35:04 +1000 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <200807291143.55141.dsdale24@gmail.com> References: <200807291143.55141.dsdale24@gmail.com> Message-ID: <488FA928.1010704@curioussymbols.com> Hi Darren Darren Dale wrote: > I was wondering if anyone is familiar with the udunits package, would it be > suitable as the foundation for physical quantities support in python? > > http://www.unidata.ucar.edu/software/udunits/ > > According to freshmeat, udunits is released under a BSD-style license. FWIW I have a small units-of-measurement class that I've used a bit in my own code. Example of use is here: http://freesteam.svn.sourceforge.net/viewvc/freesteam/freesteam/trunk/python/example.py?revision=441&view=markup The implementation is here: http://freesteam.svn.sourceforge.net/viewvc/freesteam/freesteam/trunk/measurement.cpp?view=markup The interesting thing about this implementation is that it interfaces with some C++ template-based code that performs units-of-measurement checking at *compile time*, with no runtime overhead. So the idea is that Python is used for a slightly 'heavy' system of storing values (plus their dimension data, eg M L T^-1) and these values are efficiently passed into C/C++ where units-checked calculations are done with no overhead. I'm not suggesting this is a 'mature' and 'complete' system but if anyone's thinking about making some sort of official implementation for this stuff, these ideas might be worth some thought. Also might be worth thinking about efficient storing of arrays of values with the same unit-dimensions eg via numpy. Cheers JP From jdh2358 at gmail.com Wed Jul 30 10:16:46 2008 From: jdh2358 at gmail.com (John Hunter) Date: Wed, 30 Jul 2008 09:16:46 -0500 Subject: [SciPy-dev] fmin_cobyla hangs on solaris x86 (sometimes) Message-ID: <88e473830807300716s2d923e65iff59f730cadec080@mail.gmail.com> I have been using fmin_cobya so solve a constrained optimization problem, and for some initial parameters, the code hangs (unresponsive to CTRL-C) indefinitely. I have a free-standing script that replicates the problem, and it always hangs at the same point in the execution. Unfortunately, the problem is not repeatable on other platforms I have tried (linux xeon and os x x86). I'm testing all platforms with svn HEAD. To make matters worse, I spent some time trying to isolate where in the FORTRAN the code was hanging, using poor-man's insert print statements into cobyla2.f and trstlp.f, divide and conquer. What I find is that by the time I have inserted enough print statements to get to narrow down where it is occuring, the hang disappears (heisenbug). The same thing happens if I insert no print statements but set iprint=3 (the hang disappears). But I had isolated the freeze to trstlp.f before the hang mysteriously disappeared when I tried to narrow it down further. So I am not too hopeful that anyone will be able to help me, but I wanted to put this out there in case anyone has any ideas what might be going wrong. Fernando suggested offlist that is might be a gcc compiler problem, since we are using an old version here 3.4.1 and gcc isn't the most robust compiler on solaris x86. In any case, here is output of the code, which hangs at function call 18: johnh at flag:tmp> python port_opt_test.py call: 1 call: 2 call: 3 call: 4 call: 5 call: 6 call: 7 call: 8 call: 9 call: 10 call: 11 call: 12 call: 13 call: 14 call: 15 call: 16 call: 17 call: 18 and here is the example code: import numpy as np import scipy.optimize as optimize class OptimalPortfolio: """ Compute the optimal weighting for a risky portfolio given returns matrix R and investor risk tolerance factor q; see http://en.wikipedia.org/wiki/Modern_portfolio_theory """ def __init__(self, R, Sigma): """ R is a Nasset return vector Sigma is Nasset x Nasset covariance matrix """ self.numassets = len(R) self.R = np.matrix(R) self.R.shape = self.numassets, 1 self.Sigma = np.matrix(Sigma) self._cnt = 0 assert self.Sigma.shape==(self.numassets, self.numassets) def __call__(self, weights): """ evaluate the cost function with portfolio weights """ w = np.matrix(weights) w.shape = self.numassets, 1 self._cnt += 1 print 'call: %d'%self._cnt ret = float(0.5 * w.transpose() * self.Sigma * w - self.q * self.R.transpose() * w) return ret def optimal(self, w0, bounds=None, q=0.5, **kwargs): """ return the optimal portfolio weighting starting with initial guess w0 bounds, if not None, is a sequence of (min, max) bounds for each weight. q is the investor risk preference if the kwargs are passed on to scipy.optimize.fmin_cobyla, eg to control the maximum number of function calls or the verbosity of the print output. See help for details """ w0 = np.asarray(w0) self.q = float(q) def weights_leq1(w): 'the sum of the weights must be <= 1' ws = -(w.sum()-1) return ws def weights_geq1(w): 'the sum of the weights must be >=1' ws = w.sum()-1 return ws constraints = [weights_leq1, weights_geq1] if bounds is None: bounds = [] for w in w0: bounds.append((0,1)) if len(bounds)!=len(w0): raise ValueError('length of bounds must be equal to length of weights') class MinBound: def __init__(self, i, bound): self.i = i self.bound = bound def __call__(self, weights): v = weights[self.i]-self.bound return v class MaxBound: def __init__(self, i, bound): self.i = i self.bound = bound def __call__(self, weights): v = self.bound-weights[self.i] return v for i, (bmin, bmax) in enumerate(bounds): if bmin<0 or bmin>1: raise ValueError('bounds must be in 0..1') if bmax<0 or bmax>1: raise ValueError('bounds must be in 0..1') constraints.append(MinBound(i, bmin)) constraints.append(MaxBound(i, bmax)) xopt = optimize.fmin_cobyla(self, w0, constraints, **kwargs) return xopt q = 0.3 R = np.fromstring('\xf3\x8ci\xd6\xee\xdb[?#\x85phk\x0b[?\x89"\xa9\r6\xc7K?5.-\xa0\xff\x1a6?\x96\xd7X<\x87tU?\xc18h\xda\r\x84P?\xeb\x0f$\xf7&ga?u&Ho:\xbc[?\x1c\xfd|\xad.\xb7M?\xd8\x1a\x992\xc2\r??k)]\x94\x8c"U?\xed\x00$\xaf\x06\x8eg?', np.float64) C = np.fromstring('\xe6EU"\x0b 3?\x8f\x90b\xbeJ[\xdc>.w\xb7\xc8"\x9f\xda\xbe\x99\x87\x02o\xff\x8e\xd6\xbet\x89t\xf4\x7f\xa2\xa3>\xe8\x99\xef\xceK\x0b\xcc>\xf2\xc7\xc3\xedx\xe8\xfa>#um#\x0b\xf4\x03?\xd9\x10\xeac.\x87\x08?\xbe$\x15\xb6\xf9N#?%\xc2\xc2\xba\x9d\x06\x1e?\xbfJ\x01\x04p}\x17?\x8f\x90b\xbeJ[\xdc>r3\x9f\xebW\xd92?U\xa1/\xa9rQ\xd6>\x81\x94 ,\xd9X\x01\xbfa1\x9cv5-\xd4\xbe!\x84\x87\xd3\xa5\x96\xe1\xbe\xf3\xc1m\x9b\\/\xda\xbe8F\xdaF\xac\x9a\xd0\xbe\xd7\x15\xf7\x16\x0f\xe6\xc1\xbe\x84~\xc4\xfa\xda\xde\xb8>\x8f\xccyO\xf7\x99\xe9>Yn\x1e6j^\xd3\xbe9w\xb7\xc8"\x9f\xda\xbeU\xa1/\xa9rQ\xd6>\xeb\x91%,\x99\x1e3?h\xce\x12\x14E\x8c\xe3\xbeN%\xca\xc51\x1e\xf8\xbeb)\xf7,\x14@\xe8\xbe\xa1\xc8`\x8d>\xc0\xb8\xbe(\xd67{c"\xe3\xbe\x94/\x9b\x13\x87\xf0\xe5>K\x9a\xb1j\xde\x13\xe6\xbeV\xf2\xa7n3\xe5\xf0\xbe\\\xb1\xb6`,g\xe7\xbe\x99\x87\x02o\xff\x8e\xd6\xbe\x81\x94 ,\xd9X\x01\xbfh\xce\x12\x14E\x8c\xe3\xbe\x83_\x1atI\x892?\x88\xb2\xdb\xcbl\x9c\xf6>\x17P\xfa\xa6\xf8C\xf2>g\x97\xd3\xb8\xa6\x93\xef\xbe\xbd\x90\xe6\xb7\xe0I\xbf\xbe\xceA\x8a\x14=\xa1\xd9\xbel`\xd8C\x05b\xd3\xbe[\xc2\xa3z:\x1c\xea\xbe1\x7f V(\xe1\xaf>t\x89t\xf4\x7f\xa2\xa3>a1\x9cv5-\xd4\xbe?%\xca\xc51\x1e\xf8\xbe\x88\xb2\xdb\xcbl\x9c\xf6>g\x87+O\xc7D1?\xe2o\x95\xd0\xa8?-?\xd8\xf0]_\x88l\xf5\xbe\x96FD\xbd\x99h\xdc\xbe\x9e\x19\x14\xf0\x89-\xd4\xbe\xcf\xdfc\xceP\x1d\xde\xbe\xb5\xd0\x84o"\x10\xee\xbe\x9cl\xa3\x0c\x15"\xc3\xbe\xe8\x99\xef\xceK\x0b\xcc>!\x84\x87\xd3\xa5\x96\xe1\xbeb)\xf7,\x14@\xe8\xbe\x17P\xfa\xa6\xf8C\xf2>\xe2o\x95\xd0\xa8?-?H\xe8\x91 \x08\x9b1?\x97(\xe6\xed<\x89\xe5\xbe\xfd\x00\xd4\xb6\x92p\xc6\xbe.Y\xad\xa8\xd6\x9f\xe0\xbe\x8f\xb32U%_\xd7>\x01F\xa8\x18\n\xd6\xd2\xbe\xed\xda4u\xeb\xd8\xce>\xef\xc7\xc3\xedx\xe8\xfa>\xf3\xc1m\x9b\\/\xda\xbe\xa1\xc8`\x8d>\xc0\xb8\xbeg\x97\xd3\xb8\xa6\x93\xef\xbe\xef\xf0]_\x88l\xf5\xbe\x97(\xe6\xed<\x89\xe5\xbe)\x04z(\xe5x7?:u~~\xb9S"?\x9f&\xfdV\x07\x84\xd4>\x84\xb0c{\x94c\xf0\xbeSFj\xf4m\xc3\x93>\xedW\x84\x98SA\x07?#um#\x0b\xf4\x03?7F\xdaF\xac\x9a\xd0\xbe(\xd67{c"\xe3\xbe\xbd\x90\xe6\xb7\xe0I\xbf\xbe\x96FD\xbd\x99h\xdc\xbe\xfc\x00\xd4\xb6\x92p\xc6\xbe:u~~\xb9S"?fcJ\x9a\xa8\xc15?\x95\xd6\xb1\xdc\xc0w\xf1>>"\x86\xce}\xd6\xea>\xed\x8dhG\xd4\x90\xf5>\xba\xf2\xb7\xb6~\xfb\x05?\xd9\x10\xeac.\x87\x08?\xd7\x15\xf7\x16\x0f\xe6\xc1\xbe\x97/\x9b\x13\x87\xf0\xe5>\xceA\x8a\x14=\xa1\xd9\xbe\x9e\x19\x14\xf0\x89-\xd4\xbe.Y\xad\xa8\xd6\x9f\xe0\xbe\xb5&\xfdV\x07\x84\xd4>\x95\xd6\xb1\xdc\xc0w\xf1>h\x0bv\xf9\xc4)3?\xe5\x14\xc7-N\x87\x18?\xd8F\xd6\xe8\xe3\x82\x02?N\x84\xa7\xb6\x93f\xe1\xbe\xbe$\x15\xb6\xf9N#?\x84~\xc4\xfa\xda\xde\xb8>K\x9a\xb1j\xde\x13\xe6\xbek`\xd8C\x05b\xd3\xbe\xcf\xdfc\xceP\x1d\xde\xbe\x8f\xb32U%_\xd7>\x84\xb0c{\x94c\xf0\xbe>"\x86\xce}\xd6\xea>\xe5\x14\xc7-N\x87\x18?X*\xa7\n\xa8\xb36?\xd4\xf3\x15xRr\x19?\xe6C\x17\x83\xcd\x86\xea>/\xc2\xc2\xba\x9d\x06\x1e?\x8f\xccyO\xf7\x99\xe9>V\xf2\xa7n3\xe5\xf0\xbe[\xc2\xa3z:\x1c\xea\xbe\x89\xd0\x84o"\x10\xee\xbe\x01F\xa8\x18\n\xd6\xd2\xbeSFj\xf4m\xc3\x93>\xed\x8dhG\xd4\x90\xf5>\xceF\xd6\xe8\xe3\x82\x02?\xd4\xf3\x15xRr\x19?\x89\x1d\x9f\xd6\xaa<9?\xcaj\xabG\'u\x0b?\xbfJ\x01\x04p}\x17?Zn\x1e6j^\xd3\xbe\\\xb1\xb6`,g\xe7\xbe1\x7f V(\xe1\xaf>\x9cl\xa3\x0c\x15"\xc3\xbe\xee\xda4u\xeb\xd8\xce>\xedW\x84\x98SA\x07?\xba\xf2\xb7\xb6~\xfb\x05?N\x84\xa7\xb6\x93f\xe1\xbe\xe6C\x17\x83\xcd\x86\xea>\xcaj\xabG\'u\x0b?\x8a\xbcAnx\xa32?', np.float64) C.shape = len(R), len(R) w0 = np.ones(len(R)) / len(R) opt = OptimalPortfolio(R, C) w = opt.optimal(w0, q=q, iprint=0) print w From doutriaux1 at llnl.gov Wed Jul 30 17:02:40 2008 From: doutriaux1 at llnl.gov (Charles Doutriaux) Date: Wed, 30 Jul 2008 14:02:40 -0700 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <9457e7c80807291552y95f39f4p1ab87ae8b9b1fab1@mail.gmail.com> References: <200807291143.55141.dsdale24@gmail.com> <488F8BAF.309@llnl.gov> <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> <488F9692.9030301@llnl.gov> <9457e7c80807291552y95f39f4p1ab87ae8b9b1fab1@mail.gmail.com> Message-ID: <4890D6F0.2070205@llnl.gov> Hi Stefan, No it shouldn't need a password, this is the trunk anybody can access it, what message do you get? C. St?fan van der Walt wrote: > 2008/7/30 Charles Doutriaux : > >> Weel it was a tar.gz that wasn't that big (43k) ... anyway you can svn >> it out at: >> svn export >> http:// www-pcmdi.llnl.gov/svn/repository/cdat/trunk/Packages/unidata >> > > Loos like we need a password for that? > > Cheers > St?fan > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http:// projects.scipy.org/mailman/listinfo/scipy-dev > > > From guyer at nist.gov Wed Jul 30 17:38:38 2008 From: guyer at nist.gov (Jonathan Guyer) Date: Wed, 30 Jul 2008 17:38:38 -0400 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <4890D6F0.2070205@llnl.gov> References: <200807291143.55141.dsdale24@gmail.com> <488F8BAF.309@llnl.gov> <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> <488F9692.9030301@llnl.gov> <9457e7c80807291552y95f39f4p1ab87ae8b9b1fab1@mail.gmail.com> <4890D6F0.2070205@llnl.gov> Message-ID: <7C6C8BFB-9627-490E-BAA9-C0CFAA6CD69F@nist.gov> On Jul 30, 2008, at 5:02 PM, Charles Doutriaux wrote: > No it shouldn't need a password, this is the trunk anybody can access > it, what message do you get? To view this page, you need to log in to area ?PCMDI Subversion Repository? on www-pcmdi.llnl.gov:80. Your password will be sent in the clear. From doutriaux1 at llnl.gov Wed Jul 30 19:00:13 2008 From: doutriaux1 at llnl.gov (Charles Doutriaux) Date: Wed, 30 Jul 2008 16:00:13 -0700 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <7C6C8BFB-9627-490E-BAA9-C0CFAA6CD69F@nist.gov> References: <200807291143.55141.dsdale24@gmail.com> <488F8BAF.309@llnl.gov> <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> <488F9692.9030301@llnl.gov> <9457e7c80807291552y95f39f4p1ab87ae8b9b1fab1@mail.gmail.com> <4890D6F0.2070205@llnl.gov> <7C6C8BFB-9627-490E-BAA9-C0CFAA6CD69F@nist.gov> Message-ID: <4890F27D.1020005@llnl.gov> Ok I'm not sure if that's the problem, but our server is now "breaking" links... (too worried we might be sending link to viruses or whatever...) So make sure you DO NOT copy the space in the url between http and www-pcmdi C. Jonathan Guyer wrote: > On Jul 30, 2008, at 5:02 PM, Charles Doutriaux wrote: > > >> No it shouldn't need a password, this is the trunk anybody can access >> it, what message do you get? >> > > > > To view this page, you need to log in to area ?PCMDI Subversion > Repository? on www-pcmdi.llnl.gov:80. > > Your password will be sent in the clear. > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http:// projects.scipy.org/mailman/listinfo/scipy-dev > > > From dpeterson at enthought.com Wed Jul 30 21:16:57 2008 From: dpeterson at enthought.com (Dave Peterson) Date: Wed, 30 Jul 2008 20:16:57 -0500 Subject: [SciPy-dev] [ANNOUNCE] Traits 3.0 has been released Message-ID: <48911289.70702@enthought.com> Hello, I am very pleased to announce that Traits 3.0 has just been released! All Traits projects have been registered with PyPi (aka The Cheeseshop) and each project's listing on PyPi currently includes a source tarball. In the near future, we will also upload binary eggs for Windows and Mac OS X platforms. Installation of Traits 3.0 is now as simple as: easy_install Traits The Traits projects include: http://pypi.python.org/pypi?:action=display&name=Traits&version=3.0.0 http://pypi.python.org/pypi?:action=display&name=TraitsGUI&version=3.0.0 http://pypi.python.org/pypi?:action=display&name=TraitsBackendQt&version=3.0.0 http://pypi.python.org/pypi?:action=display&name=TraitsBackendWX&version=3.0.0 The Traits project is at the center of all Enthought Tool Suite development and has changed the mental model used at Enthought for programming in the already extremely efficient Python programming language. We encourage everyone to join us in enjoying the productivity gains from using such a powerful approach. The Traits project allows Python programmers to use a special kind of type definition called a trait, which gives object attributes some additional characteristics: * Initialization: A trait has a default value, which is automatically set as the initial value of an attribute before its first use in a program. * Validation: A trait attribute's type is explicitly declared. The type is evident in the code, and only values that meet a programmer-specified set of criteria (i.e., the trait definition) can be assigned to that attribute. * Delegation: The value of a trait attribute can be contained either in the defining object or in another object delegated to by the trait. * Notification: Setting the value of a trait attribute can notify other parts of the program that the value has changed. * Visualization: User interfaces that allow a user to interactively modify the value of a trait attribute can be automatically constructed using the trait's definition. (This feature requires that a supported GUI toolkit be installed. If this feature is not used, the Traits project does not otherwise require GUI support.) A class can freely mix trait-based attributes with normal Python attributes, or can opt to allow the use of only a fixed or open set of trait attributes within the class. Trait attributes defined by a classs are automatically inherited by any subclass derived from the class. -- Dave From guyer at nist.gov Wed Jul 30 22:24:55 2008 From: guyer at nist.gov (Jonathan Guyer) Date: Wed, 30 Jul 2008 22:24:55 -0400 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <4890F27D.1020005@llnl.gov> References: <200807291143.55141.dsdale24@gmail.com> <488F8BAF.309@llnl.gov> <9457e7c80807291457t50c6b226qf2c8a0587a6dc261@mail.gmail.com> <488F9692.9030301@llnl.gov> <9457e7c80807291552y95f39f4p1ab87ae8b9b1fab1@mail.gmail.com> <4890D6F0.2070205@llnl.gov> <7C6C8BFB-9627-490E-BAA9-C0CFAA6CD69F@nist.gov> <4890F27D.1020005@llnl.gov> Message-ID: On Jul 30, 2008, at 7:00 PM, Charles Doutriaux wrote: > Ok I'm not sure if that's the problem, but our server is now > "breaking" > links... (too worried we might be sending link to viruses or > whatever...) > So make sure you DO NOT copy the space in the url between http and > www-pcmdi I noticed that in your message. There was no space in the URL I tested. From cimrman3 at ntc.zcu.cz Thu Jul 31 10:42:22 2008 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Thu, 31 Jul 2008 16:42:22 +0200 Subject: [SciPy-dev] latest svn broken? Message-ID: <4891CF4E.5010500@ntc.zcu.cz> >>> import scipy Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/site-packages/scipy/__init__.py", line 86, in ? ImportError: cannot import name Tester Looks like this update to scipy/__init__.py caused it: r4545 | alan.mcintyre | 2008-07-16 02:26:23 +0200 (Wed, 16 Jul 2008) | 2 lines Remove the testing package, and switched all test modules to use numpy.test instead. r. From wnbell at gmail.com Thu Jul 31 10:47:38 2008 From: wnbell at gmail.com (Nathan Bell) Date: Thu, 31 Jul 2008 09:47:38 -0500 Subject: [SciPy-dev] latest svn broken? In-Reply-To: <4891CF4E.5010500@ntc.zcu.cz> References: <4891CF4E.5010500@ntc.zcu.cz> Message-ID: On Thu, Jul 31, 2008 at 9:42 AM, Robert Cimrman wrote: > > Looks like this update to scipy/__init__.py caused it: > > r4545 | alan.mcintyre | 2008-07-16 02:26:23 +0200 (Wed, 16 Jul 2008) | 2 > lines > > Remove the testing package, and switched all test modules to use > numpy.test instead. > You'll need to update your numpy installation. -- Nathan Bell wnbell at gmail.com http://graphics.cs.uiuc.edu/~wnbell/ From cimrman3 at ntc.zcu.cz Thu Jul 31 10:54:33 2008 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Thu, 31 Jul 2008 16:54:33 +0200 Subject: [SciPy-dev] latest svn broken? In-Reply-To: References: <4891CF4E.5010500@ntc.zcu.cz> Message-ID: <4891D229.8020607@ntc.zcu.cz> Nathan Bell wrote: > On Thu, Jul 31, 2008 at 9:42 AM, Robert Cimrman wrote: >> Looks like this update to scipy/__init__.py caused it: >> >> r4545 | alan.mcintyre | 2008-07-16 02:26:23 +0200 (Wed, 16 Jul 2008) | 2 >> lines >> >> Remove the testing package, and switched all test modules to use >> numpy.test instead. >> > > You'll need to update your numpy installation. I see. I use a simple script to update both numpy and scipy for me, and did not notice the following: compile options: '-Ibuild/src.linux-i686-2.4/numpy/core/src -Inumpy/core/include -Ibuild/src.linux-i686-2.4/numpy/core/include/numpy -Inumpy/core/src -Inumpy/core/include -I/usr/include/python2.4 -I/usr/include/python2.4 -c' i486-pc-linux-gnu-gcc: numpy/core/src/multiarraymodule.c numpy/core/src/multiarraymodule.c:130: error: static declaration of 'PyArray_OverflowMultiplyList' follows non-static declaration numpy/core/src/arrayobject.c:10185: error: previous implicit declaration of 'PyArray_OverflowMultiplyList' was here numpy/core/src/multiarraymodule.c:130: error: static declaration of 'PyArray_OverflowMultiplyList' follows non-static declaration numpy/core/src/arrayobject.c:10185: error: previous implicit declaration of 'PyArray_OverflowMultiplyList' was here error: Command "i486-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -Ibuild/src.linux-i686-2.4/numpy/core/src -Inumpy/core/include -Ibuild/src.linux-i686-2.4/numpy/core/include/numpy -Inumpy/core/src -Inumpy/core/include -I/usr/include/python2.4 -I/usr/include/python2.4 -c numpy/core/src/multiarraymodule.c -o build/temp.linux-i686-2.4/numpy/core/src/multiarraymodule.o" failed with exit status 1 -> I cannot compile the latest numpy. (5578) r. From dsdale24 at gmail.com Thu Jul 31 16:15:42 2008 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 31 Jul 2008 16:15:42 -0400 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <4890F27D.1020005@llnl.gov> References: <200807291143.55141.dsdale24@gmail.com> <7C6C8BFB-9627-490E-BAA9-C0CFAA6CD69F@nist.gov> <4890F27D.1020005@llnl.gov> Message-ID: <200807311615.43016.dsdale24@gmail.com> Hi Charles, On Wednesday 30 July 2008 07:00:13 pm Charles Doutriaux wrote: > Ok I'm not sure if that's the problem, but our server is now "breaking" > links... (too worried we might be sending link to viruses or whatever...) > So make sure you DO NOT copy the space in the url between http and > www-pcmdi Thank you for posting the link, but I also have not been able to access the repository: Authentication realm: PCMDI Subversion Repository Password for '***': Darren From dpeterson at enthought.com Thu Jul 31 18:47:03 2008 From: dpeterson at enthought.com (Dave Peterson) Date: Thu, 31 Jul 2008 17:47:03 -0500 Subject: [SciPy-dev] [ANNOUNCE] ETS 3.0.0b1 released! Message-ID: <489240E7.90104@enthought.com> Hello, I am very pleased to announce that ETS 3.0.0b1 has just been tagged and released! All ETS sub-projects, including Traits, Chaco, Mayavi, and Envisage, have been tagged and released in one form or another (alpha, beta, final) as part of this effort. All ETS projects have now been registered with PyPi and source tarballs have been uploaded! As a result, for the first time ever, you can now easy_install all of ETS via a simple command like: easy_install ETS Or, alternatively, you can get only specific projects with commands like: easy_install Mayavi Or easy_install Chaco We anticipate the final release of ETS 3.0, and all of its sub-projects at their current version number, in a matter of weeks. Please join us in helping make this final release the most robust release it can be by participating in this beta shakeout period. Discussions about the status of ETS and its sub-projects happens on the enthought-dev mailing list, who's home page is at: https://mail.enthought.com/mailman/listinfo/enthought-dev Thank you to all who have worked so hard on making this release possible! -- Dave Enthought Tool Suite --------------------------- The Enthought Tool Suite (ETS) is a collection of components developed by Enthought and open source participants, which we use every day to construct custom scientific applications. It includes a wide variety of components, including: * an extensible application framework * application building blocks * 2-D and 3-D graphics libraries * scientific and math libraries * developer tools The cornerstone on which these tools rest is the Traits package, which provides explicit type declarations in Python; its features include initialization, validation, delegation, notification, and visualization of typed attributes. More information is available for all the packages within ETS from the Enthought Tool Suite development home page at http://code.enthought.com/projects/tool-suite.php. Testimonials ---------------- "I set out to rebuild an application in one week that had been developed over the last seven years (in C by generations of post-docs). Pyface and Traits were my cornerstones and I knew nothing about Pyface or Wx. It has been a hectic week. But here ... sits in front of me a nice application that does most of what it should. I think this has been a huge success. ... Thanks to the tools Enthought built, and thanks to the friendly support from people on the [enthought-dev] list, I have been able to build what I think is the best application so far. I have built similar applications (controlling cameras for imaging Bose-Einstein condensate) in C+MFC, Matlab, and C+labWindows, each time it has taken me at least four times longer to get to a result I regard as inferior. So I just wanted to say a big "thank you". Thank you to Enthought for providing this great software open-source. Thank you for everybody on the list for your replies." ? Ga?l Varoquaux, Laboratoire Charles Fabry, Institut d?Optique, Palaiseau, France "I'm currently writing a realtime data acquisition/display application ? I'm using Enthought Tool Suite and Traits, and Chaco for display. IMHO, I think that in five years ETS/Traits will be the most comonly used framework for scientific applications." ? Gary Pajer, Department of Chemistry, Biochemistry and Physics, Rider University, Lawrenceville NJ From doutriaux1 at llnl.gov Thu Jul 31 18:56:33 2008 From: doutriaux1 at llnl.gov (Charles Doutriaux) Date: Thu, 31 Jul 2008 15:56:33 -0700 Subject: [SciPy-dev] physical quantities: udunits? In-Reply-To: <200807311615.43016.dsdale24@gmail.com> References: <200807291143.55141.dsdale24@gmail.com> <7C6C8BFB-9627-490E-BAA9-C0CFAA6CD69F@nist.gov> <4890F27D.1020005@llnl.gov> <200807311615.43016.dsdale24@gmail.com> Message-ID: <48924321.7060109@llnl.gov> Darren, Ok looks like our security update was a bit too strong :) can you try again ? Thx, C. Darren Dale wrote: > Hi Charles, > > On Wednesday 30 July 2008 07:00:13 pm Charles Doutriaux wrote: > >> Ok I'm not sure if that's the problem, but our server is now "breaking" >> links... (too worried we might be sending link to viruses or whatever...) >> So make sure you DO NOT copy the space in the url between http and >> www-pcmdi >> > > Thank you for posting the link, but I also have not been able to access the > repository: > > Authentication realm: PCMDI Subversion > Repository > Password for '***': > > Darren > > >