Mailman 3 May 2007 - NumPy-Discussion

Re: [Numpy-discussion] Do we still need support for Python 2.3?
by Nadav Horesh 21 May '07

21 May '07

The question should be: Are there members who rely on python 2.3 Nadav -----Original Message----- From: numpy-discussion-bounces(a)scipy.org on behalf of Pearu Peterson Sent: Mon 21-May-07 16:35 To: Discussion of Numerical Python Cc: Subject: [Numpy-discussion] Do we still need support for Python 2.3? Hi, I noticed that numpy revision 3794 introduces `set` but that is available starting from Python 2.4. Hence the question. Best regards, Pearu _______________________________________________ Numpy-discussion mailing list Numpy-discussion(a)scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

3 2

Memory leak when looking .flags
by Cyrille Rosset 21 May '07

21 May '07

Hi, I'm not sure this is the right mailing list for this, but it seems there's a memory leak when looking at flags : >>> from numpy import * >>> x=ones(50000000) #==> python use 25% of memory (ok) >>> del x #==> memory usage fall back to almost zero (as seen in top) Thqt's good. but if I look at flags before the del : >>> x=ones(50000000) >>> x.flags C_CONTIGUOUS : True F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False >>> del x >>> who() Upper bound on total bytes = 0 That looks nice, but the memory usage by python (in top) is still 25%... Isn't it a bug ? Cheers Cyrille Rosset.

2 3

[Pointer] [Doc-SIG] The docs, reloaded (fwd)
by Gael Varoquaux 20 May '07

20 May '07

Hi all, There is a very interesting discussion and python-dev and Doc-SIG about using reST to document python. I think that the ongoing effort to document numpy and friends with reST could benefit from interaction with these guys. Gaël ----- Forwarded message from Georg Brandl <g.brandl(a)gmx.net> ----- To: Doc-Sig(a)python.org From: Georg Brandl <g.brandl(a)gmx.net> Date: Sat, 19 May 2007 19:14:09 +0200 Cc: python-dev(a)python.org Subject: [Doc-SIG] The docs, reloaded Hi, over the last few weeks I've hacked on a new approach to Python's documentation. As Python already has an excellent documentation framework, the docutils, with a readable yet extendable markup format, reST, I thought that it should be possible to use those instead of the current LaTeX->latex2html toolchain. For the impatient: the result can be seen at <http://pydoc.gbrandl.de>. I've written a converter tool that handles most of the LaTeX markup and turns it into reST, as well as a builder tool that adds many custom directives and roles, and also features like index generation and cross-document linking. (What you can see at the URL is a completely statical version of the docs, as it would be shipped with the distribution. For the real online docs, I have more plans; I'll come to that later.) So why the effort? Here's a partial list of things that have already been improved: - the source is much more readable (for examples, try the "view source" links in the left navbar) - all function/class/module names are properly cross-referenced - the HTML pages are generated from templates, using a language similar to Django's template language - Python and C code snippets are syntax highlighted - for the offline version, there's a JavaScript enabled search function - the index is generated over all the documentation, making it easier to find stuff you need - the toolchain is pure Python, therefore can easily be shipped What more? If there is support for this approach, I have plans for things that can be added to the online version: - a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would redirect you to the matching location. - "interactive patching": provide an "propose edit" link, leading to a Wiki-like page where you can edit the source. From the result, a diff is generated, which can be accepted, edited or rejected by the development team. This is even more straightforward than plain old comments. - the same infrastructure could be used for developers, with automatic checkin into subversion. - of course, plain old comments can be useful too. Concluding, a small caveat: The conversion/build tools are, of course, not complete yet. There are a number of XXX comments in the text, most of them indicate that the converter could not handle a situation -- that would have to be corrected once after conversion is done. Waiting for comments! Cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. _______________________________________________ Doc-SIG maillist - Doc-SIG(a)python.org http://mail.python.org/mailman/listinfo/doc-sig ----- End forwarded message ----- -- Gael Varoquaux, Groupe d'optique atomique, Laboratoire Charles Fabry de l'Institut d'Optique Campus Polytechnique, RD 128 91127 Palaiseau cedex FRANCE Tel : 33 (0) 1 64 53 33 49 - Fax : 33 (0) 1 64 53 31 01 Labs: 33 (0) 1 64 53 33 63 - 33 (0) 1 64 53 33 62

4 3

FW: RE: Linux numpy 1.0.1 install failed
by Gong, Shawn (Contractor) 18 May '07

18 May '07

Sorry Robert, My email sent to mail-list bounced back 5 times. Shawn _____________________________________________ From: Gong, Shawn (Contractor) Sent: Friday, May 18, 2007 5:05 PM To: 'numpy-discussion-request(a)scipy.org' Subject: RE: [Numpy-discussion] Linux numpy 1.0.1 install failed Hi Robert, I added ref to site.cfg, but still getting the same error message: see "out.txt" file. It seems that install can't find the libraries in /usr/local/lib/atlas/ (see the "out.txt" file Line 14: libraries lapack,blas not found in /usr/local/lib/atlas) Shawn <<out.txt>> <<site.cfg>>

2 1

Linux numpy 1.0.1 install failed
by Gong, Shawn (Contractor) 18 May '07

18 May '07

Hi List, I am trying to install numpy 1.0.1 on Linux. (Numeric and numarray have been fine) System info: Redhat Linux kernel 2.4 with gcc 3.2.3 but no separate FORTRAN compiler. It has a Fortran 77 compiler (the one which comes as part of gcc) My questions: 1) install can't find ATLAS (*.a) that I specify. Do they have to be *.so files? Do the *.a file sizes look right? Where can I get libblas.so liblapack.so files? 2) do I need a FORTRAN compiler? Will Fortran 77 compiler do? Thanks, Shawn Followings are error messages: ----------------------------- When I type "python setup.py install > numpy.out", I get: Screen display as follows: ----------------------------- Running from numpy source directory. /home/sgong/dev/numpy-1.0.1/numpy/distutils/system_info.py:934: UserWarning: ********************************************************************* Lapack library (from ATLAS) is probably incomplete: size of /usr/lib/liblapack.so is 3676k (expected >4000k) Follow the instructions in the KNOWN PROBLEMS section of the file numpy/INSTALL.txt. ********************************************************************* I then asked system admin people to install a complete ATLAS onto /usr/local/lib/atlas -rw-r--r-- 1 root root 8049172 May 15 08:49 libatlas.a -rw-r--r-- 1 root root 279016 May 15 08:49 libcblas.a -rw-r--r-- 1 root root 342062 May 15 08:49 libf77blas.a -rw-r--r-- 1 root root 5314268 May 15 08:49 liblapack.a -rw-r--r-- 1 root root 279590 May 15 08:49 libptcblas.a -rw-r--r-- 1 root root 342430 May 15 08:49 libptf77blas.a -rw-r--r-- 1 root root 320316 May 15 08:49 libtstatlas.a System admin people said that he doesn't know how to get/install *.so. He can only get *.a library. I also changed site.cfg to enter "library_dirs = /usr/local/lib/atlas/" Please find the numpy.out.txt file. Some of the lines are: -------------------------------- F2PY Version 2_3473 blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in /home/sgong/dev/dist/lib libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries lapack,blas not found in /usr/local/lib/atlas libraries lapack,blas not found in /usr/local/lib/atlas/ libraries lapack,blas not found in /home/sgong/dev/dist/lib libraries lapack,blas not found in /usr/local/lib/atlas libraries lapack,blas not found in /usr/local/lib Setting PTATLAS=ATLAS Setting PTATLAS=ATLAS FOUND: libraries = ['lapack', 'blas'] library_dirs = ['/usr/lib'] language = c Could not locate executable gfortran Could not locate executable f95 customize GnuFCompiler customize GnuFCompiler customize GnuFCompiler using config compiling '_configtest.c': /* This file is generated from numpy_distutils/system_info.py */ void ATL_buildinfo(void); int main(void) { ATL_buildinfo(); return 0; } C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-c' gcc: _configtest.c gcc _configtest.o -L/usr/lib -llapack -lblas -o _configtest _configtest.o(.text+0x15): In function `main': /home/sgong/dev/numpy-1.0.1/_configtest.c:5: undefined reference to `ATL_buildinfo' /usr/lib/liblapack.so: undefined reference to `e_wsfe' /usr/lib/liblapack.so: undefined reference to `z_abs' /usr/lib/liblapack.so: undefined reference to `c_sqrt' /usr/lib/liblapack.so: undefined reference to `s_cmp' /usr/lib/liblapack.so: undefined reference to `z_exp' /usr/lib/liblapack.so: undefined reference to `c_exp' /usr/lib/liblapack.so: undefined reference to `etime_' /usr/lib/liblapack.so: undefined reference to `do_fio' /usr/lib/liblapack.so: undefined reference to `z_sqrt' /usr/lib/liblapack.so: undefined reference to `s_cat' /usr/lib/liblapack.so: undefined reference to `s_stop' /usr/lib/liblapack.so: undefined reference to `c_abs' /usr/lib/liblapack.so: undefined reference to `s_wsfe' /usr/lib/liblapack.so: undefined reference to `s_copy' collect2: ld returned 1 exit status _configtest.o(.text+0x15): In function `main': /home/sgong/dev/numpy-1.0.1/_configtest.c:5: undefined reference to `ATL_buildinfo'

2 7

Getting ield lenghts in extension module
by Erin Sheldon 18 May '07

18 May '07

Hi all - I'm writing an extension module and I have a PyArrayObject with fields created with PyArray_Zeros from a PyArray_Descr object. In other words, this is an array of non-homogeneous data records, for example: dtype([('x', '<f8'), ('y', '<i4', 2)]) I need to fill the fields with numbers from a file. The fields of the array are only a subset of the fields of the file, so I can't just read it as one chunk with fromfile() or some equivalent. Rather I need to get the field lengths from these objects. How can I get the length of each field in bytes? Thanks, Erin

1 0

Documentation
by Charles R Harris 18 May '07

18 May '07

Hi All, I've been trying out epydoc to see how things look. Apart from all the error messages, it does run. However, I didn't like the appearance of the documentation structured as suggested in numpy/doc, either in the terminal or in the generated html. In particular, I didn't like the consolidated lists and the interpreted variable names. I can see where these might be useful down the road, but for now I stuck to definition lists with italicized headings and plain old variable names. Another problem we might want to address are the doctest blocks. Numpy inserts blank lines when it is printing out multidimensional arrays and because blank lines indicate the end of the block that screws up the formatting. It would also be nice to make the SeeAlso entries links to relevant functions. Anyway, I've attached the html file generated from fromnumeric.py for your flamage and suggestions. The routines I restructured are sort, argsort, searchsorted, diagonal, std, var, and mean. Chuck

6 27

NumPy 1.0.3 release next week
by Travis Oliphant 18 May '07

18 May '07

Hi all, I'd like to relase NumPy 1.0.3 next week (on Tuesday) along with a new release of SciPy. Please let me know of changes that you are planning on making before then. Best, -Travis

10 20

NumPy 1.0.3 for Tuesday, May 22
by Travis Oliphant 18 May '07

18 May '07

Hi all, Thank you to the many people who have contributed to cleaning up the tickets in preparation for NumPy 1.0.3 and to the people who have reported bugs and problems. In order to attend to more of the issues and to test out some of Pearu's new changes to numpy.distutils, I've delayed putting out 1.0.3 by about one week to next Tuesday. Best regards, -Travis P.S. I will also be busy this weekend attending to the funeral of my wife's grandmother, Blanche Hansen. She died on May 15th after a short illness. She lived a full and productive life of almost 96 years. If you've never spoken to someone who remembers World War I, then you are missing out on remarkable insight to our changing global society.

1 0

best way for storing extensible data?
by dmitrey 18 May '07

18 May '07

hi all, what is best way for storing data in numpy array? (amount of memory for preallocating is unknown) Currently I use just a Python list, i.e. r = [] for i in xrange(N)#N is very big ... r.append(some_value) Thx, D.

4 3