Mailman 3 January 2005 - SciPy-Dev

Python (Enthought Edition) for Windows test release
by Joe Cooper 03 Feb '05

03 Feb '05

Hi all, The much anticipated new release of the Enthought Edition of Python (a.k.a. Enthon) is just about ready for release into the real world. I'd like for some of you brave developer-type folks to give it a go before I announce it more widely and link it from the Enthon home page. Some highlights of the latest version: - iPython 0.6.7_rc2 is the default shell - The Enthought Open Source Python tools have been added. This includes a few things that migrated out of the SciPy CVS repository and into the Enthought SVN repository about a year ago, or thereabouts. Specifically, new versions of traits, chaco, kiva, etc. It's all really cool, but documentation is not yet available that I know of. If it doesn't work for you, ask Dave lots of questions. Tell him I said it would be OK. (I'm joking. Don't ask Dave anything. Documentation exists, somewhere, and I'll chase someone around the office until it is made available on the website.) - matplotlib - Pyrex - Elmer - Most packages have been updated to their latest revision, with exceptions for compatibility - readline (from UNC Tools, to be specific) - Additional documentation and some reorganization of the menus to make it less confusing and more functional - An extra 20 megabytes of random-seeming stuff...Woohoo! It's not over 100MB, yet, but I reckon one more revision will do it. What isn't in this latest version: - Python 2.4 There will be an all-singing, all-dancing, all-new, from-scratch Enthon built from the new MSI-based Python 2.4 installer, but it's a pretty big job, so I wanted to get a final 2.3 release out into the world before I hunker down and figure out the new msi installer. That said, I'm downright ecstatic to be giving Wise the boot. If I never see that line editor again in this lifetime, it will be too soon. In the meantime, if you all can grab this latest test release and let me know how it works for you, I'd be very grateful. Do whatever it is that you currently do with build 1057 of Enthon (the last public release), and if it doesn't work right in build 1062, let me know--send the error output and a test case so I can reproduce it and know it is fixed. If there's other stuff you'd like to be able to do, but Enthon never quite worked right, I won't mind hearing about that either. So, without further ado, here's the link: http://download.enthought.com/enthought_python-2.3.3-1062.exe Thanks!

12 35

Gnuplot for Numarray (OS X)
by Scott Condie 27 Jan '05

27 Jan '05

Searching through past mailing lists and google and such it appears that it may be hard to find a "port" of Michael Haggerty's Gnuplot module that runs with numarray instead of Numeric. If I am incorrect about this I apologize for the wasted bandwidth. In the true open source tradition I have taken 5 minutes and replaced a bunch of instances of "Numeric" with "numarray" in the tar distribution that I got from http://prdownloads.sourceforge.net/gnuplot-py/gnuplot-py-1.7.tar.gz? download I then tested it for another 5 minutes on the project I was doing and then tarred it back up in case anyone else wants to have a go with it. The demo in the distribution runs and it works on the project that I am doing, but I haven't tested it any further. I have posted it at http://www.scipy.org/Members/spence/gnuplot-py-1.7-numarrayOSX.tar.gz/ file_view Let me know what you think. Best, Spence

1 0

wiki to resolve numeric vs. numarray
by Joe Harrington 27 Jan '05

27 Jan '05

Since the arguments in the numeric vs. numarray debate have been spread over many months, they have been hard for me and others to follow. There is now a wiki on scipy.org for summaries of the main points and requests for tasks to be done in resolving the issue: http://www.scipy.org/wikis/featurerequests/ArrayMathCore The wiki states facts about each package that are relevant to the debate, and the desires people have for an eventual array package. Under "Desires", please feel free to pose questions that need to be resolved and tasks that need to be done. If you are interested in helping to resolve this split, consider taking on one of those tasks. Do post to the mailing list to see if anyone else is doing it and to get feedback on how to do it well. --jh--

1 0

Primary storage mode for sparse matrices in scipy ?
by Nils Wagner 25 Jan '05

25 Jan '05

Hi all, Is there a primary storage mode for sparse matrices in scipy ? Which one is favoured (CSR, MSR, JAD, CSC, ELL, VBR) ? Nils

2 1

Re: [SciPy-dev] Python (Enthought Edition) for Windows test release
by Fernando Perez 22 Jan '05

22 Jan '05

John Hunter wrote: > FYI, I'm getting an ipython warning error when I use > > C:\Enthon23\python.exe C:\Enthon23\Scripts\ipython -p enthought > > WARNING: Program configuration file enthought not found > > Note I did use a non-standard install path. Where on win32 should the > enthought config file reside? From the manpage: -profile|p <name> Assume that your config file is ipythonrc-<name> (looks in current dir first, then in IPYTHONDIR). This is a quick way to keep and load multiple config files for different tasks, espe- cially if you use the include option of config files. You can keep a basic IPYTHONDIR/ipythonrc file and then have other 'profiles' which include this one and load extra things for particular tasks. For example: 1) $HOME/.ipython/ipythonrc : load basic things you always want. 2) $HOME/.ipython/ipythonrc-math : load (1) and basic math- related modules. 3) $HOME/.ipython/ipythonrc-numeric : load (1) and Numeric and plotting modules. Since it is possible to create an endless loop by having circular file inclusions, IPython will stop if it reaches 15 recursive inclusions. The code in ipython which tries to answer what 'home' is follows (from IPython.genutils): def get_home_dir(): """Return the closest possible equivalent to a 'home' directory. For Posix systems, this is $HOME, and on NT it's $HOMEDRIVE\$HOMEPATH. Currently only Posix and NT are implemented, a HomeDirError exception is raised for all other OSes. """ #' if os.name == 'posix': return os.environ['HOME'] elif os.name == 'nt': # For some strange reason, win9x returns 'nt' for os.name. try: return os.path.join(os.environ['HOMEDRIVE'],os.environ['HOMEPATH']) except: try: # Use the registry to get the 'My Documents' folder. import _winreg as wreg key = wreg.OpenKey(wreg.HKEY_CURRENT_USER, "Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders") homedir = wreg.QueryValueEx(key,'Personal')[0] key.Close() return homedir except: return 'C:\\' elif os.name == 'dos': # Desperate, may do absurd things in classic MacOS. May work under DOS. return 'C:\\' else: raise HomeDirError,'support for your operating system not implemented.' All of this means that under win32, if $HOMEDRIVE\$HOMEPATH is not defined, then the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal is used. Whether this is a good idea or not, I don't know. I putzed around until I got somehting that returned reasonable-looking answers, and that was the end of it. I'm open to suggestions on better choices for this. Under posix, you just get $HOME, and you're done. Once this is answered, then ipython makes a .ipython/ subdir below this HOME directory, and that's where it looks for profiles (which must be named ipythonrc-FOO to be recognized by 'ipython -p FOO'). So the enthought profile should be a file called 'ipythonrc-enthought', located in HOME/.ipython/. FWIW on my friend's system, with a default install, this worked just right. I hope this helps, and please let me know if you guys need anything else on this. Cheers, f

1 0

Merged numarray branch
by Todd Miller 21 Jan '05

21 Jan '05

As part of an effort to make scipy work with numarray, I merged the numarray branch of CVS onto the main trunk about an hour ago. In theory, this has no effect on the operation of scipy using Numeric and will eventually enable operation based on numarray. As of today, the "numarray merge" mostly affects scipy_base so there are many updates that remain to be done to scipy as a whole before numarray is equally supported. Operation with Numeric is the default. To run using numarray, you "setenv NUMERIX numarray" and then start python and import scipy as usual. There is currently output on the console which indicates which array package you're getting at import time. There are still errors in the self-tests using numarray so this is mostly a curiosity announcement and head's up to be on the lookout for other problems. If you're curious, get numarray from CVS on source forge first. Regards, Todd

5 12

scipy.xplt <-> pygist
by Arnd Baecker 14 Jan '05

14 Jan '05

Hi, I just mailed with Michiel de Hoon, who takes care of pygist. He was able to fix some of the open issues. The latest version is 1.5.22 Some of the other points are more complicated and it is not clear when they will be resolved (he is too busy at the moment, tackling other problems). I think it would be great if 1.5.22 could be incorporated into scipy CVS (and I hope that these changes can still get into the next enthought edition for windows...). If I hear anything new about the other points, I will let you know. Many thanks, Arnd

2 1

Enthoughts Enhanced Python Distribution
by Nils Wagner 13 Jan '05

13 Jan '05

Hi all, I am curious about the status of a new release of Enthoughts enhanced Python distribution. Is there any plan for a new release in the near future ? Some additional packages (e.g. Numeric, f2py) are somehow outdated. Will matplotlib be included as a new component in future releases ? Nils http://www.enthought.com/downloads/downloads.htm#download

1 0

Re: Fundamental scipy testing changes
by Todd Miller 12 Jan '05

12 Jan '05

The discussion below relates to porting scipy to numarray, starting with some small changes to scipy_test.testing. The discussion began as private e-mail but has crossed over to scipy-dev at Pearu's suggestion. On Tue, 2004-12-07 at 16:16, Pearu Peterson wrote: > Hi Todd, > > On 7 Dec 2004, Todd Miller wrote: > > > I took a closer look at how my scipy_base changes affect scipy.test() > > and found a couple things in my scipy_base changes that needed fixing. > > Sorry I didn't think of this sooner. These fixes are committed now on > > the numarray branch in CVS. I also honed in on what I think should be > > the starting point for discussion: the changes I made to > > scipy_test/testing.py. > > Note that assert_equal, assert_almost_equal, assert_approx_equal > were not meant to be used with array arguments (I didn't implement them > but its obvious from reading the code). Thanks for pointing this out... I noticed the array versions only peripherally and didn't understand the distinction. > For checking the equality of > array arguments assert_array_equal or assert_array_almost_equal should be > used. If some scipy test suite uses assert_equal, etc with array > arguments then I think this is a bug of this particular test suite, > not of testing.py. So, using scipy_base.all in assert_equal, etc is not > necessary (unless we want to drop assert_array_* functions). Understood. Are we agreed that it is appropriate to use all() in the assert_array_* functions? > > In order to do the numarray scipy_base changes and pass > > scipy_base.test(), I modified scipy_test/testing.py in ways which I > > assert are good. Mostly, I used all() in contexts where an array result > > was being used as a truth value. In those contexts, the array > > __nonzero__() function is executed. NumArray.__nonzero__() raises an > > exception causing many tests to fail that should succeed. Using all() > > reduces the "truth array" to a single scalar value, so > > NumArray.__nonzero__() is never called. > > > > Where I think early agreement needs to happen is that my testing.py > > changes are good even though they expose a handful of latent scipy bugs > > or unit test bugs because Numeric's __nonzero__() has the meaning of > > any() and not all(). So, for say an equality test, if any of the > > values were equal, the test would succeed even if most of the arrays' > > values were *not* equal. Switching to all() as I am advocating exposes > > hidden problems like these. > > At the moment I have no comments on this as I haven't tried the numarray > branch of scipy yet. I think we should square away the scipy_test.testing changes before anyone messes with the numarray branch. > Btw, your discussion about the changes to scipy > sounds reasonable. However, why do you say that using alltrue is an error? > I thought all(x) is equivalent to alltrue(ravel(x)) and in assert_array_* > functions the arguments to alltrue are already ravel'ed. I looked at my diffs more carefully and see that you're right, the alltrues are not bugs because they're only fed 1D arrays. I have not reexamined all my scipy_base changes for instances of alltrue. > > If my testing.py changes are agreed upon and the exposed bugs are either > > fixed or acknowledged as known, we have a better basis for examining > > the rest of the numarray changes to scipy_base. > > > > I attached 3 files for you to look at: > > > > 1. testing.diffs (changes to -r HEAD of scipy_test/testing.py) > > > > 2. results.HEAD (scipy.test() results against the HEAD of CVS using > > Numeric) > > I got 4 failures and can't see the nightly scoreboard yet so I don't > > know if these are expected. > > > > 3. results.testing.changes (scipy.test() results with testing.diffs > > applied) > > I got 11 failures (including the original 4) most of which I believe are > > either bugs or unit test bugs. > > The failures, where you see almost equal arrays, may occur when using > Fortran blas; My scipy.test() does complain about not finding clapack so maybe I am using a Fortran blas too. > these errors should be fixed by using proper decimal > argument in assert_array_almost_equal call of the corresponding tests (I > thought I have fixed these errors in scipy HEAD already). As you said I think, the (incorrect) changes to assert_equal exposed (incorrect) uses of assert_equal in array contexts. > Other failures need more attention. > > > If any of you would rather not be included in my future numarray > > mailings, or you have suggestions for a better venue for them, please > > let me know. > > I suggest using scipy-dev. > > Thanks, > Pearu I re-attached the attachments in case anyone on scipy-dev wants to look as well; there's nothing new there. Thanks for looking it over, Todd

5 7

Re: [SciPy-dev] questions about adding new projects
by Joe Harrington 11 Jan '05

11 Jan '05

Others have suggested a different name from "topical" (for the listing page), and I agree. My initial intent with "topical" was to get discipline-specific software cataloged, since it can be harder to find than general packages. But, of course there is stuff that is cross-discipline that is not in the main package, like matplotlib. Some ideas: application Long. Is everything an application? No. addon probably the most general and accurate extras shades of Fedora contrib has a "not one of us, but along for the ride" connotation I like "addon", but better might still be out there. --jh--

1 0