Mailman 3 November 2004 - NumPy-Discussion

ANN: PyTables-0.9 released
by Francesc Altet 05 Nov '04

05 Nov '04

Announcing PyTables 0.9 ----------------------- I'm pleased to announce the availability of the latest incarnation of PyTables. On this release you will find a series of quite exciting new features, being the most important the indexing capabilities, in-kernel selections, support for complex datatypes and the possibility to modify values in both tables *and* arrays (yeah, finally :). What is ------- PyTables is a hierarchical database package designed to efficiently manage extremely large amounts of data (supports full 64-bit file addressing). It features an object-oriented interface that, combined with C extensions for the peformance-critical parts of the code, makes it a very easy to use tool for high performance data saving and retrieving. It is built on top of the HDF5 library and the numarray package, and provides containers for both heterogeneous data (Tables) and homogeneous data (Array, EArray). It also sports a container for keeping lists of objects of variable length on a very efficient way (VLArray). A flexible support of filters allows you to compress your data on-the-flight by using different compressors and compression enablers. Moreover, its powerful browsing and searching capabilities allow you to do data selections over tables exceeding gigabytes of data in just tenths of second. Changes more in depth --------------------- New features: - Indexing of columns in tables. That allow to make data selections on tables up to 500 times faster than standard selections (for ex. doing a selection along an indexed column of 100 milion of rows takes less than 1 second on a modern CPU). Perhaps the most interesting thing about the indexing algorithm implemented by PyTables is that the time taken to index grows *lineraly* with the length of the data, so, making the indexation process to be *scalable* (quite differently to many relational databases). This means that it can index, in a relatively quick way, arbitrarily large table columns (for ex. indexing a column of 100 milion of rows takes just 100 seconds, i.e. at a rate of 1 Mrow/sec). See more detailed info about that in http://pytables.sourceforge.net/doc/SciPy04.pdf. - In-kernel selections. This feature allow to make data selections on tables up to 5 times faster than standard selections (i.e. pre-0.9 selections), without a need to create an index. As a hint of how fast these selections can be, they are up to 10 times faster than a traditional relational database. Again, see http://pytables.sourceforge.net/doc/SciPy04.pdf for some experiments on that matter. - Support of complex datatypes for all the data objects (i.e. Table, Array, EArray and VLArray). With that, the complete set of datatypes of Numeric and numarray packages are supported. Thanks to Tom Hedley for providing the patches for Array, EArray and VLArray objects, as well as updating the User's Manual and adding unit tests for the new functionality. - Modification of values. You can modifiy Table, Array, EArray and VLArray values. See Table.modifyRows, Table.modifyColumns() and the newly introduced __setitem__() method for Table, Array, EArray and VLArray entities in the Library Reference of User's Manual. - A new sub-package called "nodes" is there. On it, there will be included different modules to make more easy working with different entities (like images, files, ...). The first module that has been added to this sub-package is "FileNode", whose mission is to enable the creation of a database of nodes which can be used like regular opened files in Python. In other words, you can store a set of files in a PyTables database, and read and write it as you would do with any other file in Python. Thanks to Ivan Vilata i Balaguer for contributing this. Improvements: - New __len__(self) methods added in Arrays, Tables and Columns. This, in combination with __getitem__(self,key) allows to better emulate sequences. - Better capabilities to import generic HDF5 files. In particular, Table objects (in the HDF5_HL naming schema) with "holes" in their compound type definition are supported. That allows to read certain files produced by NASA (thanks to Stephen Walton for reporting this). - Much improved test units. More than 2000 different tests has been implemented which accounts for more than 13000 loc (this represents twice of the PyTables library code itself (!)). Backward-incompatible API changes: - The __call__ special method has been removed from objects File, Group, Table, Array, EArray and VLArray. Now, you should use walkNodes() in File and Group and iterrows in Table, Array, EArray and VLArray to get the same functionality. This would provide better compatibility with IPython as well. 'nctoh5', a new importing utility: - Jeff Whitaker has contributed a script to easily convert NetCDF files into HDF5 files using Scientific Python and PyTables. It has been included and documented as a new utility. Bug fixes: - A call to File.flush() now invoke a call to H5Fflush() so to effectively flushing all the file contents to disk. Thanks to Shack Toms for reporting this and providing a patch. - SF #1054683: Security hole in utils.checkNameValidity(). Reported in 2004-10-26 by ivilata - SF #1049297: Suggestion: new method File.delAttrNode(). Reported in 2004-10-18 by ivilata - SF #1049285: Leak in AttributeSet.__delattr__(). Reported in 2004-10-18 by ivilata - SF #1014298: Wrong method call in examples/tutorial1-2.py. Reported in 2004-08-23 by ivilata - SF #1013202: Cryptic error appending to EArray on RO file. Reported in 2004-08-21 by ivilata - SF #991715: Table.read(field="var1", flavor="List") fails. Reported in 2004-07-15 by falted - SF #988547: Wrong file type assumption in File.__new__. Reported in 2004-07-10 by ivilata Where PyTables can 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 --------- I'm using Linux (Intel 32-bit) as the main development platform, but PyTables should be easy to compile/install on many other UNIX machines. This package has also passed all the tests on a UltraSparc platform with Solaris 7 and Solaris 8. It also compiles and passes all the tests on a SGI Origin2000 with MIPS R12000 processors, with the MIPSPro compiler and running IRIX 6.5. It also runs fine on Linux 64-bit platforms, like AMD Opteron running GNU/Linux 2.4.21 Server, Intel Itanium (IA64) running GNU/Linux 2.4.21 or PowerPC G5 with Linux 2.6.x in 64bit mode. It has also been tested in MacOSX platforms (10.2 but should also work on newer versions). 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 me know of any bugs, suggestions, gripes, kudos, etc. you may have. Bon profit! -- Francesc Altet

1 0

Re: [Numpy-discussion] vector cross product
by Gary Ruben 05 Nov '04

05 Nov '04

Hi David, Sorry about the slow reply - I was studying for an exam :-) but it's over now. Thanks for letting me know about your vector class. Just a quick explanation of why it's probably not useful in my case: I'm pretty much Windows based, so at a glance pyrex doesn't seem too much help for this specific purpose - I'm thinking I'd probably be better off trying to get weave going if I want to get some extra speed out of my existing code. Also, my code was written as part of a now completed project. It may undergo further development by others, so I'd also like to be able to minimise any extra package requirements that they might need. Profiling revealed Konrad's Vector class as the biggest current bottleneck, so I just thought I'd see what others thought about the usefulness of adding Vectors to numpy. If others don't think it's appropriate for numpy, maybe the scipy is the place to suggest it instead. Gary -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: [Numpy-discussion] Counting array elements
by Chris Barker 05 Nov '04

05 Nov '04

Todd Miller wrote: >> What I was suggesting is that >>there should be an API for accessing the elements of an array that >>doesn't rely on the standard strides approach. I guess I'm expressing my >>disappointment that PyArrays don't follow one of the axioms of Object >>Oriented Programming: Encapsulation. I should be able to get element >>(i,j) of an array without knowing the data structures used to store the >>data. > > (I think) numarray has what you're talking about: the "element-wise > API". It's documented in the manual but AFIK is fairly slow and > probably not widely used. > Well, the "fairly slow" is the issue. Along with the not widely used. >>If we had that, then there could be a 1-d "flat" array that >>supported discontiguous arrays in a different way than the strides >>approach, while sharing the same data block as the parent N-d array. > > > The numarray "element-wise" API makes use of strides internally in order > to access array elements; it does, however, hide what it's doing. I'm no C wiz, but by being macros, it looks to me like they very much depend on the PyArrayObject that is passed in storing it's data with strides, etc. anyway, so they couldn't be used with an object with a different storage scheme. > I > don't understand the approach you're suggesting here though. Can you > elaborate? What I'm getting at is classic OO polymorphism: An Array class that has a GetElement1d(i) method that returns the element. This class could then be replaced with another class that uses a completely different internal storage mechanism, but still has a GetElement1d(i) method. I know we're working with C, rather than C++ here, but I think this kind of thing could be faked with enough typecasting. On the other hand, I don't know what the heck I'm talking about. I'm no C wiz. Your comment about performance above is key, however. If this approach has worse performance than doing pointer arithmetic by hand with Array->strides et al, then it wouldn't get used universally, and we'd be back were we started. I know even less C++ than C, but I think perhaps the only way to get this with adequate performance would be to do a lot of C++ template magic, like Blitz++. In the early days of numarray development, there was discussion about using Blitz++ (or other nifty C++ template based arrays) as the basis for numarray. I think it all really boiled down to the template magic required was not well supported by enough compilers, so it couldn't be used. I think that's a shame, as while I haven't used C++ much, templates an iterators and all look very appealing, and much better than all the hassles of pointer arithmetic an static typing of C. >>Anyway, I'm just dreaming, I suppose, we're pretty committed to the >>current approach! > > Good ideas have a way of getting adopted, so dream on... > Well, yes, but the core API of numarray is pretty well established by now. >>Very cool! I'm still using Numeric, but I think next time I need to >>write my own Ufunc extension, this may be what converts me! By the way, the two reasons I still use numeric, other than inertia, are: 1) slower small array performance: I use arrays a lot for the convenience, rather than just when I have large arrays and need the performance. 2) Much slower performance when passing arrays into wxPython, due to wxPython using the generic sequence interface, which is apparently much slower with numarray than Numeric. Has this changed? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

2 1

Re: Hello
by Numpy-discussion 03 Nov '04

03 Nov '04

1 0

floating point exception weirdness
by Andrew Straw 03 Nov '04

03 Nov '04

Hi All, I've isolated numarray.ieeespecial as the cause of a strange error which I posted on c.l.py: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=41198B29.709… My non-expert guess as to an explanation: some statements early in numarray.ieeespecial (e.g. _na.array(1.0)/_na.array(0.0)) result in a floating point exception being set which lies dormant until I call certain functions in the Intel IPP library (e.g. ippiAddWeighted_8u32f_C1IR), at which point the latent exception bit my Python program is killed while the console says "Floating point exception". I've come to this tentative conclusion based on 3 minimal Pyrex programs: ---------------------------------------------------- Version 1: import numarray.numarrayall as _na plus_inf = inf = _na.array(1.0)/_na.array(0.0) cimport avg avg.work() # calls IPP, terminates with "Floating point exception". ---------------------------------------------------- Version 2: import numarray.numarrayall as _na # Define *ieee special values* _na.Error.pushMode(all="ignore") plus_inf = inf = _na.array(1.0)/_na.array(0.0) _na.Error.popMode() cimport avg avg.work() # calls IPP, terminates with "Floating point exception". ---------------------------------------------------- Version 3: import numarray.numarrayall as _na cimport avg avg.work() # calls IPP, terminates normally In the short term, I'll try and work around this problem by not importing numarray.ieeespecial, but in the long term, I think we should try and fix this. I'm happy to try to debug further if someone gives me advice on where to go from here. Cheers! Andrew

2 6

failure notice
by MAILER-DAEMON＠mx.teleo.net 03 Nov '04

03 Nov '04

Hi. This is the qmail-send program at mx.teleo.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <patrick.phalen(a)gmail.com>: 64.233.171.27 failed after I sent the message. Remote host said: 552 5.7.0 Illegal Attachment --- Below this line is a copy of the message.

1 0

Re: [Numpy-discussion] vector cross product
by Gary Ruben 02 Nov '04

02 Nov '04

I guess from the lack of enthusiastic responses that there aren't many out there who think this is of interest. So, perhaps Todd could just add it to the bottom of the list of possible ideas I imagine he maintains, so that if it comes up again in the future, it is at least noted. thanks, Gary ----- Original Message ----- From: "Gary Ruben" <gazzar(a)email.com> To: numpy-discussion(a)lists.sourceforge.net Subject: [Numpy-discussion] vector cross product Date: Sun, 31 Oct 2004 22:18:56 +1000 > > Not that I have a really urgent need, but is there a reason that nice, fast C-based vector operations aren't implemented in Numeric or numarray? I notice Fernando Perez has a cross product as a useful SciPy weave example on his site. I've also seen comments elsewhere about Numpy's lack of a cross product. eg. <http://mail.python.org/pipermail/python-list/2004-March/213878.html> > I'm using Konrad Hinsen's Scientific Python for the convenience value of his Vector class, which also provides a nice angle() method but it bothers me that it's implemented in native Python. The Vector type in vpython probably does it 'properly', but I don't use it just for the convenience since it adds an extra dependency to my code. > > comments? > Gary R. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: [Numpy-discussion] Counting array elements
by Todd Miller 02 Nov '04

02 Nov '04

I have returned from our astronomical data systems conference and I am going to take a short cut and summarize what I saw as the key developments of this thread. I apologize for not responding sooner and individually but the web-mail system I use isn't effective for conducting any kind of discussion. You guys did a great job sorting this out this week. I marked my key points with **. The rest is probably only for people with a lot of patience. ** I've finally come to terms with the fact that functions are the right way to do numarray rather than methods. The arguments in the Numeric manual are no more persuasive now than they ever were, but Stephen Walton's remarks about method explosion finally convinced me what the "real" reason for doing functions is that using methods combines every new feature under the umbrella of a single namespace, the NumArray class. Using functions lets us partition things into modules which can be used selectively and makes a more extensible and understandable system. Thanks Stephen. A couple people remarked that using .flat might solve everything with something like a.flat.sum() or sum(ravel(a). This gets to the original motivation for the sum() method, which was the codification of a simple and storage efficient technique for reducing noncontiguous arrays. The first point is that a non-contiguous array cannot generally be reshaped without making a copy. The basic idea of the sum() method is to do *two* reductions, the first, along a single axis, results in a smaller contiguous array. In the case of astronomical images which are generally square or at least non-degenerate, the reduction result is a *much* smaller array. The second reduction handles all the remaining dimensions since .flat is guaranteed to work because the array is contiguous. The end result is a complete sum() without righting additional ufuncs or making an array copy. There was understandable confusion about why .flat is sometimes allowed to fail. Since it is an attribute, we thought it inappropriate to make it return a copy of the source array and chose instead to raise an exception. In contrast, it is reasonable for the ravel() function to return a completely different array, so it always works. (I just noticed that ravel() is not named flat()). Some of our more contemporary thinkers suggested using iterators to produce a .flat which always works. If anyone has an idea how to make this work with good performance, please let me know; I don't. ** Tim Hochberg pointed out that we can overload the reduction (and not accumulation?) axis parameter with an "all" or a tuple describing a sequence of axes to reduce along. My perception was that there was a consensus behind this and in any case I'm in agreement with Tim. Alan Isaac pointed out that None might be better here than "all" and I agree. At this point, I think sumAll() is dead, the sum() method will be deprecated, and the reductions should be expanded as Tim suggested. ** Peter Verveer made some comments about the expectations of a naive user regarding reductions, namely that "all" should be the default. My own experience bears this out, and I am torn about what to do here. Chris Barker pointed out the need for backward compatibility with Numeric, and given the current numarray goal of supporting SciPy, this need is growing stronger and more complex. SciPy uses yet another axis convention. If anyone has any ideas how to handle these multiple conventions with elegance, let me know. A number of people commented on our naming conventions, an issue which we have side stepped for the moment with sumAll(). My impression is that, for better or worse, numarray uses the lowerUpper() version of Camel case. I think this is very much a matter of personal taste and don't claim to have any. My guess is that numarray is probably inconsistent at the moment, in part because lowerUpper() often degenerates into merely lower() which degenerates into confusion. Regards, Todd

5 7

Re: floating point exception weirdness (Andrew Straw)
by Steve Chaplin 01 Nov '04

01 Nov '04

> Just a small addendum, (which I hope will spur on bug-fixing once Todd > et al. are back from the conference -- let me know if I should file a > sourceforge bug report): I've not read all this thread so I don't know the full background. But I had a floating point / SSE problem using numarray. It turned out to be a glibc not numarray problem and was solved by upgrading glibc. http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 There was also a SourceForge bug report but I can't locate it. Regards Steve

2 2

Promote Your Marketing
by Tim 01 Nov '04

01 Nov '04

1 0