Mailman 3 August 2003 - NumPy-Discussion

Re: [Numpy-discussion] bug?
by Todd Miller Aug. 18, 2003

Aug. 18, 2003

On Mon, 2003-08-18 at 08:31, Peter Verveer wrote: > Hi Todd, > > Yes its the same bug, next time I will check the bug tracker before sounding > the alarm... > > BTW what is the preferred way of submitting a bug? Through the sourceforge > page, or the mailing list? It actually took me a few minutes to sort this question out. The tracker is definitely *easier* for me, but that's not a good discriminator. More importantly, if you use the tracker, the bug report won't get *lost*, and thus the chances are improved that the problem will actually get fixed. For more serious stuff (like the astype() slicing bug), it's good to post to numpy-discussion-list also. Thanks again for the report, Todd -- Todd Miller <jmiller(a)stsci.edu>

1 0

numarray C API
by o.mekkaoui Aug. 15, 2003

Aug. 15, 2003

Hi, I would like to use numarray. I use Python2.2 and I have installed numarray0.6.1. I have to problem: 1) when I test numarray, I got this >>> import numarray.testall as testall >>> testall.test() *** Tester.merge: 'numarray.numtest' in both testers; summing outcomes. *** Tester.merge: 'numarray.numtest.dtp' in both testers; summing outcomes. *** Tester.merge: 'numarray.numtest.test' in both testers; summing outcomes. *** Tester.merge: 'numarray.numtest.ratioarr' in both testers; summing outcomes.*** Tester.merge: 'numarray.numtest.comparr' in both testers; summing outcomes. *** Tester.merge: 'numarray.numtest.dummy' in both testers; summing outcomes. numeric: (0, 1037) records: (0, 48) strings: (0, 168) memmap: (0, 75) which differ from that given in numarray documentation. 2) writting a little C API program using numrray don't work too: I got for example Traceback (most recent call last): File "Test_num.py", line 3, in ? from test_num import departure ImportError: ./test_num.so: undefined symbol: import_libnumarray I don't understand why the MACRO import_libnumarray() is not imported. And if someone can send me I little C API example, I will be very grateful. Thanks in advance for your help.

2 2

Why is weave.inline()/blitz++ code 3 times slower than innerproduct()?
by Fernando Perez Aug. 14, 2003

Aug. 14, 2003

Hi all, I think one of the strongest points in favor of python for scientific computing is the ability to write low-level code, when necessary, which can perform on-par with hand-rolled Fortran. In the past, I've been very pleased using weave's inline() tool, which relies on blitz for manipulating Numpy arrays with an very clean and convenient syntax. This is important, because manipulating multidimensional Numeric arrays in C is rather messy, and the resulting code isn't exactly an example of readability. Blitz arrays end up looking just like regular arrays, using (i,j,k) instead of [i][j][k] for indexing. Recently, I needed to do an operation which turned out to be pretty much what Numpy's innerproduct() does. I'd forgotten about innerproduct(), so I just wrote my own using inline(). Later I saw innerproduct(), and decided to compare the results. I'm a little worried by what I found, and I'd like to hear some input from the experts on this problem. I've attached all the necessary code to run my tests, in case someone is willing to do it and take a look. In summary, I found some things which concern me (a README is included in the .tgz with more info): - the blitz code, whether via inline() or a purely hand-written extension, is ~2.5 to 3 times slower than innerproduct(). Considering that this code is specialized to a few sizes and data types, this comes as a big surprise. If the only way to get maximum performance with Numpy arrays is to write by hand to the full low-level api, I know that many people will shy away from python for a certain class of projects. I truly hope I'm missing something here. - There is a significant numerical discrepancy between the two approaches (blitz vs numpy). In an innerproduct operation over 7000 entries, the discrepancy is O(1e-10) (in l2 norm). This is more than I'm comfortable with, but perhaps I'm being naive or optimistic. I view the ability to get blitzed code which performs on par with Fortran as a very important aspect of python's suitability for large-scale project where every last bit of performance matters, but where one still wants to have the ability to work with a reasonably clean syntax. I hope I'm just misusing some tools and not faced with a fundamental limitation. By the way, I'll come to Scipy'03 with many more questions/concerns along these lines, and I think it would be great to have some discussions on these issues there with the experts. Thanks in advance. Cheers, f.

1 0

PyTables 0.7.1 is out
by Francesc Alted Aug. 14, 2003

Aug. 14, 2003

PyTables 0.7.1 is out! ---------------------- This is a mainly a bug-fixing release, where the next problems has been addressed: - Fixed several memory leaks. After that, the memory consumption when using large object trees has dropped sensibly. However, there remains some small leaks, but hopefully they are not very important unless you use *huge* object trees. - Fixed a bug that make the __getitem__ special method in table to fail when the stop parameter in a extended slice was not specified. That is, table[10:] now correctly returns table[10:table.nrows+1], and not table[10:11]. - The removeRows() method in Table did not update the NROWS attribute in Table objects, giving place to errors after doing further updating operations (removing or adding more rows) in the same table. This has been fixed now. Apart of these fixes, a new lazy reading algorithm for attributes has been activated by default. With that, the opening of objects with large hierarchies has been improved by 60% (you can obtain another additional 10% if using python 2.3 instead of python 2.2). The documentation has been updated as well, specially a more detailed instructions on the compression (zlib) libraries installation. Also, a stress test has been conducted in order to see if PyTables can *really* work not only with large data tables, but also with large object trees. On it, it has been generated and checked a file with more than 1 TB of size and more than 100 thousand tables on it!. See http://pytables.sourceforge.net/doc/stress-test.html for details. Let me know of any bugs, suggestions, etc. you may have. -- Francesc Alted

1 0

MUCH BIGGER PENIS? 238624
by 238624＠msn.com Aug. 8, 2003

Aug. 8, 2003

1 0