Mailman 3 July 2005 - NumPy-Discussion

Reversing elements of array
by Egg July 18, 2005

July 18, 2005

Hi all, I would like to reverse the elements of an array (or vector). If it were a regular Python list, I could say L.reverse(). If it were in Matlab (ick), I could say U(4:-1:1). Can anyone give me a hint on doing this in Numeric (not Numarray)? Thx

3 2

ANN: numarray-1.3.3
by Todd Miller July 18, 2005

July 18, 2005

Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, arrays of heterogeneous records, string arrays, and in-place operation on memory mapped files. ========================================================================= Release Notes for numarray-1.3.3 I. ENHANCEMENTS None. 1.3.3 fixes a fatal problem with embedding numarray and loading it more than once. It also fixes some numarray memory leaks associated with restarting the Python interpreter. II. BUGS FIXED / CLOSED 1233431 Add 'type' to fromfunction() 1230490 Numarray: integer overflow in sum() is not detected 1216688 ufunc's ignoring complex operand 1213675 Problems embedding after 1.1.1 1209946 Mac OS-X --use_lapack 1212975 numarray.fromfunction(...) misbehavior 1209929 config.h and Python-2.2 1235278 Add -lm to numarray link lists See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.2 I. ENHANCEMENTS None. 1.3.2 fixes the problem with gcc4 on Mac OS-X 10.4 Tiger II. BUGS FIXED / CLOSED 1193125 Build failure on Mac OS 10.4 (Tiger) 1195370 numarray1.3.1 setup.py broken See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.1 I. ENHANCEMENTS None. 1.3.1 fixes the problem with gcc-3.4.3 II. BUGS FIXED / CLOSED 1152323 /usr/include/fenv.h:96: error: conflicting types for 'fegete 1185024 numarray-1.2.3 fails to compile with gcc-3.4.3 1187162 Numarray 1.3.0 installation failure See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.0 Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, arrays of heterogeneous records, string arrays, and in-place operation on memory mapped files. I. ENHANCEMENTS 1. Migration of NumArray.__del__ to C (tp_dealloc). Overall performance. 2. Removal of dictionary update from array view creation improves performance of view/slice/subarray creation. This should e.g. improve the performance of wxPython sequence protocol access to Nx2 arrays. Subclasses now need to do a.flags |= numarray.generic._UPDATEDICT to ensure that dictionary based attributes are inherited by views. NumArrays no longer do this by default. 2. Modifications to support scipy.special. 3. Removal of an unnecessary getattr() from ufunc calling sequence. Ufunc performance. II. BUGS FIXED / CLOSED 1179355 average() broken in numarray 1.2.3 1167184 Floating point exception in numarray's dot() 1151892 Bug in matrixmultiply with zero size arrays 1160184 RecArray reversal 1156172 Incorect error message for shape incompatability 1155538 Incorrect error message when multiplying arrays See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. III. CAUTIONS This release should be backward binary compatible with numarray-1.1.1 and 1.2.3. WHERE ----------- Numarray-1.3.0 windows executable installers, source code, and manual is here: http://sourceforge.net/project/showfiles.php?group_id=1369 Numarray is hosted by Source Forge in the same project which hosts Numeric: http://sourceforge.net/projects/numpy/ The web page for Numarray information is at: http://stsdas.stsci.edu/numarray/index.html Trackers for Numarray Bugs, Feature Requests, Support, and Patches are at the Source Forge project for NumPy at: http://sourceforge.net/tracker/?group_id=1369 REQUIREMENTS ------------------------------ numarray-1.3.0 requires Python 2.2.2 or greater. AUTHORS, LICENSE ------------------------------ Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science Institute. We'd like to acknowledge the assitance of Francesc Alted, Paul Dubois, Sebastian Haase, Chuck Harris, Tim Hochberg, Nadav Horesh, Edward C. Jones, Eric Jones, Jochen Kuepper, Travis Oliphant, Pearu Peterson, Peter Verveer, Colin Williams, Rory Yorke, and everyone else who has contributed with comments and feedback. Numarray is made available under a BSD-style License. See LICENSE.txt in the source distribution for details. -- Todd Miller jmiller(a)stsci.edu

2 2

problem with poisson generators
by Flavio Coelho July 16, 2005

July 16, 2005

Hi, I am having problems with the poisson random number generators of both Numarray and Numeric. I can't replicate it when calling the function from the python cosonle, but it has consistently malfunctioned when used within one of my scripts. What happens is that it frequently return a value greater than zero when called with zero mean: poisson(0.0) Unfortunately My program is too big to send attached but I have confirmed the malfunction by printing both the mean and the result whenever it spits out a wrong result. This is very weird indeed, I have run poisson millions of times by itsel on the python console, without any problems... I hope it is some stupid mistake, but when I replace the poisson function call within my program by the R equivalent command (rpois) via the rpy wrapper, everything works just fine... any Ideas? -- Flávio Codeço Coelho registered Linux user # 386432 --------------------------- Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence. Albert Einstein

8 15

RE: [Numpy-discussion] problem with poisson generators
by Sebastien.deMentendeHorne＠electrabel.com July 15, 2005

July 15, 2005

Hi Flavio, Could you give us every call to poisson or negative_binomial (ie all functions related to random numbers) preceeded with the seed ? Adding before your declaration of stepSEIR_s code like: randoutput = file("randoutput.py", "w") old_poisson = poisson def poisson(m): print >> randoutput, "print get_seed(), poisson(%s)"%m result = old_poisson(m) print >> randoutput, "# result = %s"%result return result old_negative_binomial = negative_binomial def negative_binomial(i,p): print >> randoutput, "print get_seed(), negative_binomial(%s,%s)"%(i,p) result = old_negative_binomial(i,p) print >> randoutput, "# result = %s"%result return result will ouput every call. We can then easily try on our machines what it gives. Best, Sebastien > -----Original Message----- > From: numpy-discussion-admin(a)lists.sourceforge.net > [mailto:numpy-discussion-admin@lists.sourceforge.net]On Behalf Of Todd > Miller > Sent: vendredi 15 juillet 2005 12:54 > To: Flavio Coelho > Cc: Bruce Southey; Sebastian Haase; numpy-discussion > Subject: Re: [Numpy-discussion] problem with poisson generators > > > On Wed, 2005-07-13 at 12:13 -0300, Flavio Coelho wrote: > > > > > > 2005/7/13, Bruce Southey <bsouthey(a)gmail.com>: > > Hi, > > What is the seed used? > > > > I am not setting the seed. > > > > > > It is really important that you set the seed? > > > > No. > > > > > > Did you build Python and numarray from source? > > > > > > Yes, I use Gentoo. I build everything from source. > > > > > > Can you reduce your code to a few lines that have > the problem? > > > > > > Not really, poisson and binomial are the only two functions from > > Numeric that I use but they are called inside a rather > complex object > > oriented code environment (objects within objetcs, being called > > recursively...) Bellow is the function within which poisson > is called: > > > > def > stepSEIR_s(self,inits=(0,0,0),par=(0.001,1,1,0.5,1,0,0,0),theta=0, > > npass=0,dist='poisson'): > > """ > > Defines an stochastic model SEIR: > > - inits = (E,I,S) > > - par = (Beta, alpha, E,r,delta,B,w,p) see docs. > > - theta = infectious individuals from neighbor sites > > """ > > E,I,S = inits > > N = self.parentSite.totpop > > beta,alpha,e,r,delta,B,w,p = par > > Lpos_esp = beta*S*((I+theta)/(N+npass))**alpha > #Number of new > > cases > > > > if dist == 'poisson': > > Lpos = poisson(Lpos_esp) > > ## if theta == 0 and Lpos_esp == 0 and Lpos > 0: > > ## print > > Lpos,Lpos_esp,S,I,theta,N,self.parentSite.sitename > > elif dist == 'negbin': > > prob = I/(I+Lpos_esp) #convertin between > parameterizations > > Lpos = negative_binomial(I,prob) > > self.parentSite.totalcases += Lpos #update number > of cases > > Epos = (1-e)*E + Lpos > > Ipos = e*E + (1-r)*I > > Spos = S + B - Lpos > > Rpos = N-(Spos+Epos+Ipos) > > #self.parentSite.totpop = Spos+Epos+Ipos+Rpos > > self.parentSite.incidence.append(Lpos) > > if not self.parentSite.infected: > > if Lpos > 0: > > self.parentSite.infected = > > self.parentSite.parentGraph.simstep > > self.parentSite.parentGraph.epipath.append > > > ((self.parentSite.parentGraph.simstep,self.parentSite,self.par > entSite.infector)) > > > > > > return [Epos,Ipos,Spos] > > > > Having this code is a good start to solving the problem. I think the > next step is to simplify your example to make it runnable and provide > known inputs for all the parameters which lead to a failure for you. > > Being really literal (spelling out every single damn thing) > cuts down on > speculation and inefficiency on our end. > > It would also be good to express the condition (or it's inverse) you > think is an error as an assertion, so something like this > might be what > we need: > > from numarray.random_array import poisson > > E, I, S = (0,0,0) > beta,alpha,e,r,delta,B,w,p = (0.001,1,1,0.5,1,0,0,0) > theta = 0 > npass = 0 > N = 100 # total guess here for me > Lpos_esp = beta*S*((I+theta)/(N+npass))**alpha #Number of new cases > Lpos = poisson(Lpos_esp) > assert not (theta == 0 and Lpos_esp == 0 and Lpos > 0) > > The problem is, the above works for me. Make it sane and get it to > expose the error for you and I'll look into this some more. > > Regards, > Todd > > > > > I wonder if called by itself it would trigger the problem... The > > commented Lines Is where I catch the errors: when poisson returns a > > greater than zero number, when called with mean 0. > > > > > > > > Ranlib uses static floats so it may relate to numerical > > precision (as > > well as the random uniform random number generator). Really > > the only > > way is for you to debug the ranlib.c file > > > > I'll see what I can do. > > > > > > Note that R provides a standalone math library in C that > > includes the > > random number generators so you could you those > instead. SWIG > > handles > > it rather well. > > > > > > I think thats what Rpy already does...is it not? > > > > thanks Bruce, > > > > Flávio > > > > > > Regards > > Bruce > > > > On 7/13/05, Flavio Coelho <fccoelho(a)gmail.com> wrote: > > > Well, > > > I am definetly glad that someone has also stumbled onto > > the same problem. > > > > > > But it is nevertheless intriguing, that you can > run poisson > > a million times > > > with mean zero or negative(it assumes zero mean inthis > > case) without any > > > problems by itself. But when I call it within my code, the > > rate of error is > > > very high (I would say it returns a wrong result > every time, > > but I haven't > > > checked every answer). > > > > > > Meanwhile, my solution will be: > > > > > > import rpy > > > > > > n = rpy.r.rpois(n,mean) > > > > > > I don't feel I can trust poisson while this "funny" > > behavior is still > > > there... > > > If someone has any Idea of how I could trace this bug > > please tell me, and > > > I'll hunt it down. At least I can reproduce it in a very > > specific context. > > > > > > thanks, > > > > > > Flávio > > > > > > 2005/7/12, Sebastian Haase <haase(a)msg.ucsf.edu>: > > > > Hi Flavio! > > > > I had reported this long time ago and this list (about > > numarray). > > > > Somehow this got more or less dismissed. If I recall > > correctly the > > > argument > > > > was that nobody could reproduce it (I ran this on Debian > > Woody , py2.2, > > > (with > > > > CVS numarray at the time). > > > > > > > > I ended up writting my own wrapper(s): > > > > def poissonArr(shape=defshape, mean=1): > > > > from numarray import random_array as ra > > > > if mean == 0: > > > > return zeroArrF(shape) > > > > elif mean < 0: > > > > raise "poisson not defined for mean < 0" > > > > else: > > > > return ra.poisson(mean, shape).astype > > (na.UInt16) > > > > > > > > def poissonize(arr): > > > > from numarray import random_array as ra > > > > return na.where(arr<=0, 0, > ra.poisson(arr)).astype > > ( na.UInt16) > > > > > > > > (I use the astype( na.UInt16) because of some > OpenGL code) > > > > > > > > Just last week had this problem on a windows98 computer > > (python2.4). > > > > > > > > This should get sorted out ... > > > > > > > > Thanks for reporting this problem. > > > > Sebastian Haase > > > > > > > > > > > > > > > > > > > > On Tuesday 12 July 2005 13:32, Flavio Coelho wrote: > > > > > Hi, > > > > > > > > > > I am having problems with the poisson random number > > generators of both > > > > > Numarray and Numeric. > > > > > I can't replicate it when calling the > function from the > > python cosonle, > > > but > > > > > it has consistently malfunctioned when used within one > > of my scripts. > > > > > > > > > > What happens is that it frequently return a value > > greater than zero when > > > > > called with zero mean: poisson( 0.0) > > > > > > > > > > Unfortunately My program is too big to send > attached but > > I have > > > confirmed > > > > > the malfunction by printing both the mean and > the result > > whenever it > > > spits > > > > > out a wrong result. > > > > > > > > > > This is very weird indeed, I have run poisson millions > > of times by itsel > > > on > > > > > the python console, without any problems... > > > > > > > > > > I hope it is some stupid mistake, but when I > replace the > > poisson > > > function > > > > > call within my program by the R equivalent command > > (rpois) via the rpy > > > > > wrapper, everything works just fine... > > > > > > > > > > any Ideas? > > > > > > > > > > > > > > > > -- > > > > > > Flávio Codeço Coelho > > > registered Linux user # 386432 > > > --------------------------- > > > Great spirits have always found violent opposition from > > mediocrities. The > > > latter cannot understand it when a man does not > > thoughtlessly submit to > > > hereditary prejudices but honestly and > courageously uses his > > intelligence. > > > Albert Einstein > > > > > > > > > > > -- > > Flávio Codeço Coelho > > registered Linux user # 386432 > > --------------------------- > > Great spirits have always found violent opposition from > mediocrities. > > The > > latter cannot understand it when a man does not thoughtlessly submit > > to > > hereditary prejudices but honestly and courageously uses his > > intelligence. > > Albert Einstein > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > ======================================================= This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Electrabel may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks. http://www.electrabel.be/homepage/general/disclaimer_EN.asp =======================================================

1 0

ANN: PyTables 1.1 released
by Francesc Altet July 15, 2005

July 15, 2005

========================= Announcing PyTables 1.1 ========================= The PyTables development team is happy to announce the availability of a new version of PyTables package. On this version you will find support for a nice set of new features, like nested datatypes, enumerated datatypes, nested iterators (for reading only), support for native HDF5 multidimensional attributes, a new object for dealing with compressed, non-enlargeable arrays (CArray), bzip2 compression support and more. Many bugs has been addressed as well. Go to the PyTables web site for downloading the beast: http://pytables.sourceforge.net/ Or keep reading for more info about the new features and bugs fixed. Changes more in depth ===================== Improvements: - Support for nested datatypes is in place. You can now made columns of tables that host another columns for an unlimited depth (well, theoretically, in practice until the python recursive limit would be reached). Convenient NestedRecArray objects has been implemented as data containers. Cols and Description accessors has been improved so you can navigate on the type hierarchy very easily (natural naming is has been implemented for the task). - ``Table``, ``EArray`` and ``VLArray`` objects now support enumerated types. ``Array`` objects support opening existing HDF5 enumerated arrays. Enumerated types are restricted sets of ``(name, value)`` pairs. Use the ``Enum`` class to easily define new enumerations that will be saved along with your data. - Now, the HDF5 library is responsible to do data conversions when the datasets are written in a machine with different byte-ordering than the machine that reads the dataset. With this, all the data is converted on-the-fly and you always get native datatypes in memory. I think this approach to be more convenient in terms of CPU consumption when using these datasets. Right now, this only works for tables, though. - Added support for native HDF5 multidimensional attributes. Now, you can load native HDF5 files that contains fully multidimensional attributes; these attributes will be mapped to NumArray objects. Also, when you save NumArray objects as attributes, they get saved as native HDF5 attributes (before, NumArray attributes where pickled). - A brand-new class, called CArray, has been introduced. It's mainly like an Array class (i.e. non-enlargeable), but with compression capabilities enabled. The existence of CArray also allows PyTables to read native HDF5 chunked, non-enlargeable datasets. - Bzip2 compressor is supported. Such a support was already in PyTables 1.0, but forgot to announce it. - New LZO2 (http://www.oberhumer.com/opensource/lzo/lzonews.php) compressor is supported. The installer now recognizes whether LZO1 or LZO2 is installed, and adapts automatically to it. If both are installed in your system, then LZO2 is chosen. LZO2 claims to be fully compatible (both backward and forward) with LZO1, so you should not experience any problem during this transition. - The old limit of 256 columns in a table has been released. Now, you can have tables with any number of columns, although if you try to use a too high number (i.e. > 1024), you will start to consume a lot of system resources. You have been warned!. - The limit in the length of column names has been released also. - Nested iterators for reading in tables are supported now. - A new section in tutorial about how to modify values in tables and arrays has been added to the User's Manual. Backward-incompatible changes: - None. Bug fixes: - VLArray now correctly updates the number of rows internal counter when opening an existing VLArray object. Now you can add new rows to existing VLA's without problems. - Tuple flavor for VLArrays now works as intended, i.e. reading VLArray objects will always return tuples even in the case of multidimensional Atoms. Before, this operations returned a mix of tuples and lists. - If a column was not able to be indexed because it has too few entries, then _whereInRange is called instead of _whereIndexed. Fixes #1203202. - You can call now Row.append() in the middle of Table iterators without resetting loop counters. Fixes #1205588. - PyTables used to give a segmentation fault when removing the last row out of a table with the table.removeRows() method. This is due to a limitation in the HDF5 library. Until this get fixed in HDF5, a NotImplemented error is raised when trying to do that. Address #1201023. - You can safely break a loop over an iterator returned by Table.where(). Fixes #1234637. - When removing a Group with hidden child groups, those are effectively closed now. - Now, there is a distinction between shapes 1 and (1,) in tables. The former represents a scalar, and the later a 1-D array with just one element. That follows the numarray convention for records, and makes more sense as well. Before 1.1, shapes 1 and (1,) were represented by an scalar on disk. Known bugs: - Classes inheriting from IsDescription subclasses do not inherit columns defined in the super-class. See SF bug #1207732 for more info. - Time datatypes are non-portable between big-endian and little-endian architectures. This is ultimately a consequence of a HDF5 limitation. See SF bug #1234709 for more info. Known issues: - UCL compressor seems to work badly on MacOSX platforms. Until the problem would be isolated and eventually solved, UCL will not be compiled by default on MacOSX platforms, even if the installer finds it in the system. However, if you still want to get UCL support on MacOSX, you can use the --force-ucl flag in setup.py. Important note for Python 2.4 and Windows users =============================================== If you are willing to use PyTables with Python 2.4 in Windows platforms, you will need to get the HDF5 library compiled for MSVC 7.1, aka .NET 2003. It can be found at: ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/current/bin/windows/5-164-win-net.ZIP Users of Python 2.3 on Windows will have to download the version of HDF5 compiled with MSVC 6.0 available in: ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/current/bin/windows/5-164-win.ZIP What it is ========== **PyTables** is a package for managing hierarchical datasets and designed to efficiently cope with extremely large amounts of data (with support for full 64-bit file addressing). It features an object-oriented interface that, combined with C extensions for the performance-critical parts of the code, makes it a very easy-to-use tool for high performance data storage and retrieval. Perhaps its more interesting feature is that it optimizes memory and disk resources so that data take much less space (between a factor 3 to 5, and more if the data is compressible) than other solutions, like for example, relational or object oriented databases. Besides, PyTables I/O for table objects is buffered, implemented in C and carefully tuned so that you can reach much better performance with PyTables than with your own home-grown wrappings to the HDF5 library. PyTables sports indexing capabilities as well, allowing doing selections in tables exceeding one billion of rows in just seconds. Where can PyTables be applied? ============================== PyTables is not designed to work as a relational database competitor, but rather as a teammate. If you want to work with large datasets of multidimensional data (for example, for multidimensional analysis), or just provide a categorized structure for some portions of your cluttered RDBS, then give PyTables a try. It works well for storing data from data acquisition systems (DAS), simulation software, network data monitoring systems (for example, traffic measurements of IP packets on routers), very large XML files, or for creating a centralized repository for system logs, to name only a few possible uses. What is a table? ================ A table is defined as a collection of records whose values are stored in fixed-length fields. All records have the same structure and all values in each field have the same data type. The terms "fixed-length" and "strict data types" seem to be quite a strange requirement for a language like Python that supports dynamic data types, but they serve a useful function if the goal is to save very large quantities of data (such as is generated by many scientific applications, for example) in an efficient manner that reduces demand on CPU time and I/O resources. What is HDF5? ============= For those people who know nothing about HDF5, it is a general purpose library and file format for storing scientific data made at NCSA. HDF5 can store two primary objects: datasets and groups. A dataset is essentially a multidimensional array of data elements, and a group is a structure for organizing objects in an HDF5 file. Using these two basic constructs, one can create and store almost any kind of scientific data structure, such as images, arrays of vectors, and structured and unstructured grids. You can also mix and match them in HDF5 files according to your needs. Platforms ========= We are using Linux on top of Intel32 as the main development platform, but PyTables should be easy to compile/install on other UNIX machines. This package has also been successfully compiled and tested on a FreeBSD 5.4 with Opteron64 processors, a UltraSparc platform with Solaris 7 and Solaris 8, a SGI Origin3000 with Itanium processors running IRIX 6.5 (using the gcc compiler), Microsoft Windows and MacOSX (10.2 although 10.3 should work fine as well). In particular, it has been thoroughly tested on 64-bit platforms, like Linux-64 on top of an Intel Itanium, AMD Opteron (in 64-bit mode) or PowerPC G5 (in 64-bit mode) where all the tests pass successfully. Regarding Windows platforms, PyTables has been tested with Windows 2000 and Windows XP (using the Microsoft Visual C compiler), but it should also work with other flavors as well. Web site ======== Go to the PyTables web site for more details: http://pytables.sourceforge.net/ To know more about the company behind the PyTables development, see: http://www.carabos.com/ Share your experience ===================== Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. ---- **Enjoy data!** -- The PyTables Team

1 0

numarray 1.3.3 build question
by Russell E. Owen July 14, 2005

July 14, 2005

I'm on MacOS X 10.3.9 and am getting mysterious warnings when building numarray 1.3.3 which I've never seen before. Building for the unix/x11 version yields: [dhcp-254:~/Archives\342\200\242/PythonPackages/numarray-1.3.3] rowen% python setup.py config build --gencode Running sitecustomize.pyc Using EXTRA_COMPILE_ARGS = ['-Ddarwin'] Running sitecustomize.pyc Running sitecustomize.pyc generating new API module 'libnumarray' .c & .h generating new API module 'libteacup' .c & .h generating new API module 'libnumeric' .c & .h Using external BLAS and LAPACK running config Wrote config.h ... Packages/LinearAlgebra2/Src/lapack_litemodule.c:851: warning: function declaration isn't a prototype Packages/LinearAlgebra2/Src/lapack_litemodule.c:848: warning: `lapack_liteError' defined but not used gcc: -framework: linker input file unused because linking not done gcc: vecLib: linker input file unused because linking not done Should I worry? I haven't figured out how to run the self-tests w/out installing and I'm reluctant to install w/out knowing if the warnings are a problem. also: - why do we need --gencode? Is there some way to make that the default so we can leave it off? - why do we need "config"? That's new to 1.3.3 isn't it? -- Russell P.S. I have two completely different versions of python installed: - the normal built-in Python 2.3.0, which I run using 'pythonw' - a pure unix/x11 python that I installed from source using an x11 version of tcl/tk. This is run using "python" (which runs /usr/local/python). However, the errors occur while building with either version (much to my surprised -- I expected the framework complain to go away when building with pythonw, the framework python).

2 1

Re: [Numpy-discussion] bug or feature?
by Perry Greenfield July 14, 2005

July 14, 2005

On Jul 11, 2005, at 2:38 PM, Curzio Basso wrote: >> An array used as an index produces a new copy (if you think about it, >> given the possibilities, there isn't much else that can be done). So >> the entity on the left of your expression is modified, but since >> nothing refers to it, it is discarded immediately thereafter. The >> array >> 'a' itself was never changed. I'd say that it isn't either a bug or >> feature. > > ok. on the other hand: > >>>> a[[0,2],0] = 1 >>>> print a > array([[ 1, 1, 2, 3], > [ 4, 5, 6, 7], > [ 1, 9, 10, 11]]) > > I have some problem understanding the difference at the implementation > level between the two cases. I would have assumed that at end they > would operate on a similar way... > > curzio I was sloppy in my description. For array indexing, assignment does modify the original array (as your case above illustrates), but once you sliced the array-indexed array, it changed the context of the indexing. I.e., (to take a simpler, 1-d array x) x[[0,2]] = 1 # modifies x This form results in __setitem__ being called on x x[[0,2]][:4] = 1 # doesn't modify x This form results in __getitem__ being called on x (and thus producing a new copy of the array) for the array indexing and __setitem__ being called for the slice. At least that's what I think is happening. Todd or someone more recently familiar with how Python handles this can correct me if I'm wrong. Perry

2 1

bug or feature?
by Curzio Basso July 11, 2005

July 11, 2005

Hi all, I noticed the following (unexpected for me) behaviour: >>> a = NA.arange(12) >>> a.shape = (3,4) >>> a[[0,2]][:,:2] = a[[0,2]][:,2:] >>> print a array([[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]]) rather than array([[ 2, 3, 2, 3], [ 4, 5, 6, 7], [ 10, 11, 10, 11]]) as I was expecting. This happens only if I try to combine indices lists with slices. Is it by design or I ran into a bug? curzio

2 1

Online Banking - Verify Your Account Information
by Chevy Chase Bank July 11, 2005

July 11, 2005

1 0

Re: [Numpy-discussion] ANN: numarray-1.3.3
by Todd Miller July 10, 2005

July 10, 2005

On Sun, 2005-07-10 at 11:43 -0400, Les Schaffer wrote: > Todd Miller wrote: > > >numarray-1.3.3 is a "maintenance release" which solves a couple esoteric > >(embedded Python + numarray) but serious (core dumping) problems. > > > > > > > cool > > >I think there's a good chance of adding something for the next release > >but I don't think it will be called keys() because that's a dictionary > >cue and RecArrays aren't dictionaries. > > > > > > tho as column spaces, they essentially act as dicts. > > >I'm in favor of adding .names to make _names public. > > > > > that would work, at least it tells outsiders .names is public and stable > attribute. > > and even better is help us subclass easily by making the constructor > functions fromarray, fromrecord, and array take an optional argument > which is the RecArray class to use. as it stands RecArray cannot be > subclasses without re-doing all those constructor functions. > > i would be happy to contribute code if i knew it would be used. What you want to do sounds reasonable so chances are good a patch would be used. I would: 1. Make .names another reference to ._names 2. Either convert the functions you want to be subclassable into "class functions" (and add backward compatible globals) or else add a "kind" parameter for passing in the subclass (see strings.py) to the current functions. I'm not sure which approach is better. Regards, Todd

1 0