From 238624 at msn.com Fri Aug 8 19:45:05 2003 From: 238624 at msn.com (238624 at msn.com) Date: Fri Aug 8 19:45:05 2003 Subject: [Numpy-discussion] MUCH BIGGER PENIS? 238624 Message-ID: An HTML attachment was scrubbed... URL: From falted at openlc.org Thu Aug 14 07:20:07 2003 From: falted at openlc.org (Francesc Alted) Date: Thu Aug 14 07:20:07 2003 Subject: [Numpy-discussion] PyTables 0.7.1 is out Message-ID: <200308141245.13358.falted@openlc.org> 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 From eric at enthought.com Thu Aug 14 16:22:02 2003 From: eric at enthought.com (eric jones) Date: Thu Aug 14 16:22:02 2003 Subject: [Numpy-discussion] ANN: Job posting -- developer position available Message-ID: <010701c362c0$3b54ec50$a47ba8c0@ericlaptop> Hey group, We have a developer position open here at Enthought, and I thought I'd see if anyone is interested. The posting is below. There is also a tech writer and HCI opening listed on the website: http://www.enthought.com/careers.html thanks! eric Position: Python Developer Type: Full-Time Enthought, Inc. is a technology startup in the Austin, TX area that is looking for a motivated Python Developer to join our development team. Responsibilities include developing and deploying scientific applications within the Fortune 500. Our size and prospects provide significant opportunity for growth and advancement for Enthought employees. Candidates should have the following qualifications: - BS or MS in Computer Science or Engineering or other scientific field - 3+ years experience in the software industry - Experience developing solutions in the following languages: - Python - C/C++ - User interface design experience - Developing and deploying custom solutions for clients - Excellent verbal and written communication skills Ideal candidates will also demonstrate the following skills: - Use of the wxPython user interface library - Experience with Geophysics applications - Experience in the fields of statistics, linear algebra and calculus Please send resumes to jobs at enthought.com. From fperez at colorado.edu Thu Aug 14 16:38:01 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu Aug 14 16:38:01 2003 Subject: [Numpy-discussion] Why is weave.inline()/blitz++ code 3 times slower than innerproduct()? Message-ID: <3F3BFF28.7020900@colorado.edu> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: py_inner.tgz Type: application/unix-tar Size: 6059 bytes Desc: not available URL: From o.mekkaoui at free.fr Thu Aug 14 18:30:02 2003 From: o.mekkaoui at free.fr (o.mekkaoui) Date: Thu Aug 14 18:30:02 2003 Subject: [Numpy-discussion] numarray C API Message-ID: <3F3C2F2B.6070308@free.fr> 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. From jmiller at stsci.edu Fri Aug 15 06:19:01 2003 From: jmiller at stsci.edu (Todd Miller) Date: Fri Aug 15 06:19:01 2003 Subject: [Numpy-discussion] numarray C API In-Reply-To: <3F3C2F2B.6070308@free.fr> References: <3F3C2F2B.6070308@free.fr> Message-ID: <1060953310.6313.36.camel@halloween.stsci.edu> On Thu, 2003-08-14 at 20:54, o.mekkaoui wrote: > 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. The "Tester.merge" lines need to be documented. They're a result of running the tests twice in an attempt to detect cache related bugs. The total test counts vary from release to release. The leading zeros are good... they mean for instance, 0 out of 1037 tests failed. Thus, your test results show that numarray is installed and working. > > > 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. Make sure you included the header file "numarray.h" or "arrayobject.h". > > And if someone can send me I little C API example, I will be very grateful. If you have the numarray source distribution, try looking in the Examples directory for various ways to interface with numarray in C. Of the choices there, the best ones to start with are probably either the "High Level" API (Examples/convolve/high_levelmodule.c) or the Numeric compatible API (Examples/convolve/numpy_compatmodule.c). > Thanks in advance for your help. You're welcome. Good Luck! Todd -- Todd Miller jmiller at stsci.edu STSCI / ESS / SSB From o.mekkaoui at free.fr Fri Aug 15 09:44:02 2003 From: o.mekkaoui at free.fr (o.mekkaoui) Date: Fri Aug 15 09:44:02 2003 Subject: [Numpy-discussion] numarray C API In-Reply-To: <1060953310.6313.36.camel@halloween.stsci.edu> References: <3F3C2F2B.6070308@free.fr> <1060953310.6313.36.camel@halloween.stsci.edu> Message-ID: <3F3D0BA9.3040409@free.fr> Thanks for your help, I have tested a little example with including numarray.h and it don't work. However, if I include "libnumarray.h" instead "numarray.h", that work fine. Thanks. Omar Mekkaoui University of Cergy-Pontoise, France Todd Miller wrote: >On Thu, 2003-08-14 at 20:54, o.mekkaoui wrote: > > >>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. >> >> > >The "Tester.merge" lines need to be documented. They're a result of >running the tests twice in an attempt to detect cache related bugs. > >The total test counts vary from release to release. The leading zeros >are good... they mean for instance, 0 out of 1037 tests failed. Thus, >your test results show that numarray is installed and working. > > > >>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. >> >> > >Make sure you included the header file "numarray.h" or "arrayobject.h". > > > >>And if someone can send me I little C API example, I will be very grateful. >> >> > >If you have the numarray source distribution, try looking in the >Examples directory for various ways to interface with numarray in C. Of >the choices there, the best ones to start with are probably either the >"High Level" API (Examples/convolve/high_levelmodule.c) or the Numeric >compatible API (Examples/convolve/numpy_compatmodule.c). > > > >>Thanks in advance for your help. >> >> > >You're welcome. Good Luck! > >Todd > > > From verveer at embl-heidelberg.de Mon Aug 18 05:03:08 2003 From: verveer at embl-heidelberg.de (Peter Verveer) Date: Mon Aug 18 05:03:08 2003 Subject: [Numpy-discussion] bug? Message-ID: <200308181401.17137.verveer@embl-heidelberg.de> Consider conversion of a slice using the astype() method: >>> a = array([[1,2],[3,4]]) >>> b = a[1, ...] >>> print b [3 4] Conversion using the astype() method goes wrong: >>> print b.astype(Float32) [ 1. 2.] This fixes it: >>> print b.copy().astype(Float32) [ 3. 4.] A bug? Cheers, Peter -- Dr. Peter J. Verveer Cell Biology and Cell Biophysics Programme EMBL Meyerhofstrasse 1 D-69117 Heidelberg Germany Tel. : +49 6221 387245 Fax : +49 6221 387242 Email: Peter.Verveer at embl-heidelberg.de From jmiller at stsci.edu Mon Aug 18 05:28:09 2003 From: jmiller at stsci.edu (Todd Miller) Date: Mon Aug 18 05:28:09 2003 Subject: [Numpy-discussion] bug? In-Reply-To: <200308181401.17137.verveer@embl-heidelberg.de> References: <200308181401.17137.verveer@embl-heidelberg.de> Message-ID: <1061209492.3459.23.camel@localhost.localdomain> Hi Peter, What you're demonstrating below looks like a bug in numarray which was just recently solved: https://sourceforge.net/tracker/index.php?func=detail&aid=784866&group_id=1369&atid=450446 As you've shown, numarray's astype() fails for some slices, notably those which are offset from the base of the array and therefore have a non-zero _byteoffset. This is fixed in CVS now and will be "officially released" soon. On Mon, 2003-08-18 at 08:01, Peter Verveer wrote: > Consider conversion of a slice using the astype() method: > > >>> a = array([[1,2],[3,4]]) > >>> b = a[1, ...] > >>> print b > [3 4] > > Conversion using the astype() method goes wrong: > > >>> print b.astype(Float32) > [ 1. 2.] > > This fixes it: > > >>> print b.copy().astype(Float32) > [ 3. 4.] > > A bug? > > Cheers, Peter -- Todd Miller From cjw at sympatico.ca Mon Aug 18 06:37:04 2003 From: cjw at sympatico.ca (Colin J. Williams) Date: Mon Aug 18 06:37:04 2003 Subject: [Numpy-discussion] Possible bug In-Reply-To: <200308181401.17137.verveer@embl-heidelberg.de> References: <200308181401.17137.verveer@embl-heidelberg.de> Message-ID: <3F40D29E.2090308@sympatico.ca> # ta.py to check Int8, Int16 import numarray as _n import numarray.numerictypes as _nt b= _n.arange(4, type= _nt.Int8) print 'b, b._type:', b, b._type c= b*1001 # Grief here - type not updated print 'c, c._type:', c, c._type e= _n.array([1, -2, 3000, 4.6], type= _nt.Int8) # undocumented feature fraction discarded # and lowest eight bits retained as a signed # integer. print 'e, e._type:', e, e._type f= _n.array([1, 2, 3, 4.6], type= _nt.Int8) * 9.6 print 'f, f._type:', f, f._type g= (f.copy()*2000).astype(_nt.Int16) # undocumented - see e above print 'g, g._type:', g, g._type -------------------------------------------------------------------- PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mhammond at skippinet.com.au) - see 'Help/About PythonWin' for further copyright information. >>> b, b._type: [0 1 2 3] Int8 c, c._type: [ 0 -23 -46 -69] Int8 e, e._type: [ 1 -2 -72 4] Int8 f, f._type: [ 9.6 19.2 28.8 38.4] Float64 g, g._type: [ 19200 -27136 -7937 11264] Int16 Colin W. From jmiller at stsci.edu Mon Aug 18 06:59:02 2003 From: jmiller at stsci.edu (Todd Miller) Date: Mon Aug 18 06:59:02 2003 Subject: [Numpy-discussion] bug? In-Reply-To: <200308181431.30395.verveer@embl-heidelberg.de> References: <200308181401.17137.verveer@embl-heidelberg.de> <1061209492.3459.23.camel@localhost.localdomain> <200308181431.30395.verveer@embl-heidelberg.de> Message-ID: <1061213011.3459.123.camel@localhost.localdomain> 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 From cjw at sympatico.ca Mon Aug 18 12:45:09 2003 From: cjw at sympatico.ca (Colin J. Williams) Date: Mon Aug 18 12:45:09 2003 Subject: [Numpy-discussion] How are Booleans to be handled? Message-ID: <3F412CA7.6070707@sympatico.ca> This statement: z= _n.array([True, False, True, True], type= _nt.BooleanType) gives an exception: Traceback (most recent call last): File "", line 1, in ? File "C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 284, in array type = getTypeObject(sequence, type, typecode) File "C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 217, in getTypeObject return getType(type) File "C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 324, in getType raise TypeError("Not a numeric type") TypeError: Not a numeric type If we leave out the type parameter, the array is created with 32 bit words. Colin W. From jmiller at stsci.edu Mon Aug 18 12:54:03 2003 From: jmiller at stsci.edu (Todd Miller) Date: Mon Aug 18 12:54:03 2003 Subject: [Numpy-discussion] How are Booleans to be handled? In-Reply-To: <3F412CA7.6070707@sympatico.ca> References: <3F412CA7.6070707@sympatico.ca> Message-ID: <1061236370.3460.229.camel@localhost.localdomain> On Mon, 2003-08-18 at 15:44, Colin J. Williams wrote: > This statement: > z= _n.array([True, False, True, True], type= _nt.BooleanType) Use type=_nt.Bool here. BooleanType is the class of Bool. Todd -- Todd Miller From cjw at sympatico.ca Mon Aug 18 16:22:03 2003 From: cjw at sympatico.ca (Colin J. Williams) Date: Mon Aug 18 16:22:03 2003 Subject: [Numpy-discussion] How are Booleans to be handled? In-Reply-To: <1061236370.3460.229.camel@localhost.localdomain> References: <3F412CA7.6070707@sympatico.ca> <1061236370.3460.229.camel@localhost.localdomain> Message-ID: <3F415F97.2080303@sympatico.ca> Thanks, I made a guess and chose the wrong one. This is a lot closer to the optimum storage. Colin W. Todd Miller wrote: >On Mon, 2003-08-18 at 15:44, Colin J. Williams wrote: > > >>This statement: >> z= _n.array([True, False, True, True], type= _nt.BooleanType) >> >> > >Use type=_nt.Bool here. BooleanType is the class of Bool. > >Todd > > > From haase at msg.ucsf.edu Wed Aug 20 16:38:04 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Wed Aug 20 16:38:04 2003 Subject: [Numpy-discussion] Numarray web site and google Message-ID: <00e801c3676c$51e86720$421ee6a9@rodan> Hi, I'm not sure how much time you guys wants to spend on the numarray web site, but I find that a google search for 'numarray' still points to http://stsdas.stsci.edu/numarray/ saying numarray has moved! (OK it does bring me to the right page after some seconds) Anyway - doing some search on Usenet I found this http://groups.google.com/groups?threadm=vc3bh351prjbd8%40corp.supernews.com&rnum=8&prev=/groups%3Fq%3D%2522search%2Bengines%2522%2B%2522%252Bhas%2Bmoved%2522%2B%2Bhtml%2Bhead%26hl%3Den%26lr%3D%26ie%3DISO-8859-1%26safe%3Doff From: Guy Macon (guymacon+"_http://www.guymacon.com/_"03 at spamcop.net) Subject: Re: If I can't redirect to new url, how bad is forwarding it? Newsgroups: alt.internet.search-engines Date: 2003-05-13 19:48:05 PST he essentially says adding this to the html-page might fix it soon: http://www.example.com Just a thought ... Thanks for numarray - have a great day. Sebastian Haase From perry at stsci.edu Thu Aug 21 09:41:03 2003 From: perry at stsci.edu (Perry Greenfield) Date: Thu Aug 21 09:41:03 2003 Subject: [Numpy-discussion] Numarray web site and google In-Reply-To: <00e801c3676c$51e86720$421ee6a9@rodan> Message-ID: Thanks for pointing this out and particularly for doing research into how to fix the problem! We will give this a try (though it may take a few days). > -----Original Message----- > From: numpy-discussion-admin at lists.sourceforge.net > [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of > Sebastian Haase > Sent: Wednesday, August 20, 2003 6:42 PM > To: numpy-discussion at lists.sourceforge.net > Subject: [Numpy-discussion] Numarray web site and google > > > Hi, > I'm not sure how much time you guys wants to spend on the > numarray web site, > but I find that a google search for 'numarray' still points to > http://stsdas.stsci.edu/numarray/ > saying numarray has moved! > (OK it does bring me to the right page after some seconds) > Anyway - doing some search on Usenet I found this > http://groups.google.com/groups?threadm=vc3bh351prjbd8%40corp.supe rnews.com&rnum=8&prev=/groups%3Fq%3D%2522search%2Bengines%2522%2B%2522%252Bh as%> 2Bmoved%2522%2B%2Bhtml%2Bhead%26hl%3Den%26lr%3D%26ie%3DISO-8859-1% > 26safe%3Doff > From: Guy Macon (guymacon+"_http://www.guymacon.com/_"03 at spamcop.net) > Subject: Re: If I can't redirect to new url, how bad is forwarding it? > Newsgroups: alt.internet.search-engines > Date: 2003-05-13 19:48:05 PST > > he essentially says adding this to the html-page might fix it soon: > > > http://www.example.com > > > > > Just a thought ... > > Thanks for numarray - have a great day. > > Sebastian Haase > > > > ------------------------------------------------------- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > From fperez at colorado.edu Thu Aug 21 19:17:02 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu Aug 21 19:17:02 2003 Subject: [Numpy-discussion] Blitz++, NumArray... Message-ID: <3F4525A1.3040701@colorado.edu> Hi all, as some of you know, I'm a big fan of weave.inline() for the ease of development it offers. Essentially C++ becomes a scripting part of python, with only the occasional recompile overhead (but this is transparent to the users). inline() makes heavy use of the blitz++ library, to represent numpy arrays as blitz arrays and therefore index them as Arr(i,j,k...). This seems to me like a very sound decision, as the blitz library was specifically written to provide simultaneously fortran-like performance with high-level object orientation. With this in mind, I have a few questions: - Is there anything in Numarray's design which prevents this same trick from being used? The core of getting a Numpy array into a blitz one is simply a call to: // Convert a Numpy array to a blitz one, using the original's data (no copy) template static blitz::Array py_to_blitz(PyArrayObject *arr_obj) { blitz::TinyVector shape(0); blitz::TinyVector strides(0); for (int i=0;idimensions[i]; strides[i] = arr_obj->strides[i]/sizeof(T); } return blitz::Array((T*) arr_obj->data,shape,strides, blitz::neverDeleteData); } I would not be surprised if something much like this would work for Numarrays, but I'd like to know for sure. - If the above is indeed possible for Numarray, do you guys feel that blitz should be considered an integral part of python's low-level arsenal, or not? I view its advantages especially in the field of an extremely clean, simple syntax (compared to the low-level Numpy API, I'm not familiar with Numarray yet). I've seen examples where a numpy algorithm can be recoded using blitz in a _far_ smaller amount of code, and with performance gains to boot (in some cases, not all). Please note that I am NOT second-guessing any of the design decisions made by the Numarray crowd. I just want to clarify if it's possible to have a C++ API which gives access to numarray with the simplest, highest-level syntax and behavior which is reasonable. This is important for teams where not everyone is an expert on C pointer manipulation details, but they may be perfectly ok with writing loops over things which can be indexed as A(i,j,k). - If any of this seems worthy of more detailed discussion, I told Eric Jones that I'd be happy to coordinate something along these lines at Scipy'03. If there's time in the schedule I'd be glad to do it officially, otherwise we can just try to keep it in mind for a lunch/dinner meeting. Documenting a 'Best Practices for low-level numerical work in python' would probably be a beneficial thing to do for the community. Right now there are so many options that I'm sure I'm not the only one to feel a bit confused. - If Blitz++ is indeed deemed a worthy piece of this puzzle, I wonder if we could contact some of its developers to bring them into this discussion. I worry a bit that activity on its mailing lists seems rather slow, but I noticed that an apparently central guy, Julian C. Cummings, is at CACR/Caltech. Perhaps he could stop by and let us know what the future for blitz looks like. I can fire off an email to him if there is interest in the blitz thing. Anyway, I'm just trying to 'pre-soak' a few ideas for discussion at scipy'03 on these topics. Best regards, Fernando. From Chris.Barker at noaa.gov Fri Aug 22 09:50:39 2003 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Aug 22 09:50:39 2003 Subject: [Numpy-discussion] Blitz++, NumArray... References: <3F4525A1.3040701@colorado.edu> Message-ID: <3F464832.839785B5@noaa.gov> Fernando Perez wrote: > - Is there anything in Numarray's design which prevents this same trick from > being used? It's not entirely clear to me what you have in mind. ARE you proposing that Blitz++ arrays be the low-level implimentaiton of Numarray?, or just that there be an easy way to switch between them. In the first case, it was considered a coupl eof years ago, and rejected (as far as I could tell) mainly for reasons of portability: Blitz++ makes heavy use of templates, which are not well supported by the very wide variety of compilers that Python is supported on. One of the goals of Numarray is to make it into the Python standard library, and use of C++ and templates would preclude that, at least in the foreseeable future. Here's one discussion about it: http://www.geocrawler.com/mail/thread.php3?subject=%5BNumpy-discussion%5D+Meta%3A+too+many+numerical+libraries+doing+the&list=1329 If that url doesn't work, I found it by searching google for: Numpy-discussion blitz++ If you are proposing the second: that there could be an easy bridge between Numarray and Blitz++ (maybe using Boost Python somehow?) so that Blitz++ arrays could be used to write Numarray extensions, I'm all for it! I think the community would gain a great deal from an easier to use API for writing compiled Numarray functions. Besides making it easier for those of us that find the need for custom extensions, it would make it much easier for people to write and contibute high performance general purpose code--resulting in a much expanded library for Numarray and SciPy. -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 at noaa.gov From rzsiek at yahoo.com Fri Aug 22 10:13:05 2003 From: rzsiek at yahoo.com (Electrician) Date: Fri Aug 22 10:13:05 2003 Subject: [Numpy-discussion] Resume Message-ID: Resume from: Rich for Job or Service " no job too small " E L E C T R I C I A N Tel. (408) 482-2102 rysio3 at yahoo.com WIRING & INSTALLATION Hands on electrical installations perform fitting, mounting, laying cables on Commercial, Industrial, residential new & existing buildings. Electrical Power Supply for Lights, Plugs, Receptacles, Panels, & Fuse boxes, Emergency Generators wiring and testing, Transformers, Power Lines & conduit layout, bending and mounting, parking lighting, lamps, switches, SOLAR PROJECTS, posts and underground installations. Shopping Centers; grocery stories, hardware stories, restaurants & residential - housing areas, computer business & fast food units installation & buildings; Solar Panels, Sun Tracking, Flywheel Storage & electric cars systems modify, Natural Energy in Remote areas install. LOW VOLTAGE for Home & OFFICE 12 / 24 Volt audio & video equipment, Computer & data network wiring, data backup and UPS; Monitoring Video Control & backup tapes set up and mounting, electro-optical assemblies & subsystems. DC Power Supply, Switch & Motion sensors Alarm. Fire & safety systems install. Fiber Optics systems, PLC setup, Master Control Center, cable modems & cable TV install. Network, UPS Battery Backup mounting and charging systems; Power supply testing, troubleshooting, and analyzing to a components level. Electric Vehicles Design, Assembly & Installations. CC TV & Cameras, Security Systems & Sensors for Safety, Fire sprinklers and traffic Monitoring & Door Control. Telephones / Net move & install. TECHNICIAN Use lab & shop equipment, mechanical, electrical & electronic tools, measurement & testing equipment, video cameras & microscopes. Support scientists & electronic engineers. Mechanical & Electro-Mech. Design. OFFICE, ELECTRICAL AND MECHANICAL PROJECTS Electrical & Network Sketches, one line diagrams, and "as is" drawings update. Customizing Electronic and Electrical Components & Parts, Layouts electronic and electrical schematic, connectors and mechanical detailing. Quotes, supply, bids and job estimating. Customers contact, inspection, project mgmt & supervision of electricians & material handling; Use CAD, Windows and applications; ELECTRICAL & MAINTENANCE SERVICE US Citizen; open for travel . From fperez at colorado.edu Fri Aug 22 11:04:25 2003 From: fperez at colorado.edu (Fernando Perez) Date: Fri Aug 22 11:04:25 2003 Subject: [Numpy-discussion] Blitz++, NumArray... In-Reply-To: <3F464832.839785B5@noaa.gov> References: <3F4525A1.3040701@colorado.edu> <3F464832.839785B5@noaa.gov> Message-ID: <3F465A40.8080508@colorado.edu> Chris Barker wrote: > Fernando Perez wrote: > > >> - Is there anything in Numarray's design which prevents this same trick >> from being used? > > > It's not entirely clear to me what you have in mind. ARE you proposing that > Blitz++ arrays be the low-level implimentaiton of Numarray?, or just that > there be an easy way to switch between them. Well, it was a bit of both. I'm glad to have been ambiguous, since you answered both :) > In the first case, it was considered a coupl eof years ago, and rejected > (as far as I could tell) mainly for reasons of portability: Blitz++ makes > heavy use of templates, which are not well supported by the very wide > variety of compilers that Python is supported on. One of the goals of > Numarray is to make it into the Python standard library, and use of C++ and > templates would preclude that, at least in the foreseeable future. I sort of suspected this, so while this option sounds very nice in theory, I didn't expect it to be a realistic possibility. > If you are proposing the second: that there could be an easy bridge between > Numarray and Blitz++ (maybe using Boost Python somehow?) so that Blitz++ > arrays could be used to write Numarray extensions, I'm all for it! I think > the community would gain a great deal from an easier to use API for writing > compiled Numarray functions. Besides making it easier for those of us that > find the need for custom extensions, it would make it much easier for > people to write and contibute high performance general purpose > code--resulting in a much expanded library for Numarray and SciPy. This is more realistic, and in fact today it _is_ a reality. As I posted before, making a blitz array out of a numpy one is trivial, and you get fast, easy to read C++. I initially learned how to do it by reverse-engineering weave.inline's auto-generated C++ files, but once that got me off the ground, it was trivial to write my own extension modules. And now that I'm starting to learn a bit more about the capabilities of the blitz library, I'm very excited. To indirectly answer Perry's email in this same thread: after his comments, it seems to me that the Numarray->blitz operation would work just as easily as the example I showed for Numpy->blitz. Perry says that in memory, numarrays are very similar to Numpys, so this shouldn't be a problem. Which means we are already quite a ways there! I think to some extent, it's more a matter of making better known to people that this approach exists, and how easy to use it is. I only learned about it after being impressed with inline's super-simple syntax as compared to the horrors of handling numpy arrays by hand. But the more I read the blitz manual, the more I see that blitz arrays behave _a lot_ like numpy arrays even inside the C++ code. So the bridge approach, as long as the constructor call is very cheap, seems like a perfectly reasonable balance between aesthetic purity and real-world practicality to me. This doesn't mean that there are no issues to be discussed, so I'll try to outline the ones that come to mind (as per Perry's request). Perhaps others can add to this list. 1- Cheap constructors: For a rank-N array, the current constructor still requires the creation of 2 TinyVector blitz arrays of size N (shape and strides). It would be great if these copies could be avoided and the existing shape & strides data from the Numpy array could be used directly. The Numpy-> blitz functions would then be almost zero-overhead operations. 2- Access to fortran libraries: I don't know how easy it is to use say BLAS with objects defined in C++ (and with row-major memory layout). This is just my ignorance, but I'd like to clarify this point, since it would be nice to be able to use BLAS/LAPACK from within the C++ code with blitz arrays with no transposition overhead. 3- Benchmark: I think it would be valuable to draft a small but reasonable set of benchmarks comparing the raw numeric/numarray C api, the blitz version and fortran versions of some common algorithms. Blitz relies heavily on templates and C++ compilers are getting better, so it would be nice to know where things stand. I have a preliminary version of this, which I've posted here, but it only covers innerproduct(). As part of that testing, I found more numerical discrepancy than seemed reasonable to me. I would really need to understand the origin of this before feeling comfortable with the blitz approach for production codes. 4- Multiple precision: For a certain class of problems, beign able to work with Numerical arrays whose precision goes beyond double is critical. At http://crd.lbl.gov/~dhbailey/mpdist/index.html there is a good example of a modern, C++ library for extended precision which offers a very simple syntax. I wonder how easy (or not) it would be for Numarray to offer optional support for this kind of arrays. This last topic is a bit more ambitious than the others (which I think seem to be very reasonabl). However, I hope that we can at least discuss it, since there is a class of problems where it is a really important issue. There may be more things I can't think of now, but hopefully this may serve as a first outline for a discussion, both on the mailing list and in person, at scipy. Best, f From 238924 at bigfoot.com Sun Aug 24 17:37:29 2003 From: 238924 at bigfoot.com (238924 at bigfoot.com) Date: Sun Aug 24 17:37:29 2003 Subject: [Numpy-discussion] Now copy DVD's in 14 Languages! 238924 Message-ID: An HTML attachment was scrubbed... URL: From Justin.Worrall at morganstanley.com Fri Aug 29 01:05:05 2003 From: Justin.Worrall at morganstanley.com (Justin Worrall) Date: Fri Aug 29 01:05:05 2003 Subject: [Numpy-discussion] numarray.linear_algrebra > cholesky_decomposition problem Message-ID: <3F4F091B.F4AA75EF@morganstanley.com> Hi, I'm having problems using the cholesky decomposition function - perhaps someone could point out where I am going wrong. Many thanks, Justin dingy /ms/user/w/worrall 22$ python Python 2.3 (#1, Aug 19 2003, 16:53:06) [GCC 2.95.2 19991024 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from numarray import * >>> from numarray.linear_algebra import * >>> x=array([[1.0,0.0],[0.5,1.0]]) >>> x array([[ 1. , 0. ], [ 0.5, 1. ]]) >>> cholesky_decomposition(x) Traceback (most recent call last): File "", line 1, in ? File "/u/worrall/Python-2.3/numarray/linear_algebra/LinearAlgebra2.py", line 159, in cholesky_decomposition return copy.copy(num.transpose(mlab.triu(a,k=0))) File "/u/worrall/Python-2.3/numarray/linear_algebra/mlab.py", line 134, in triu svsp = m.spacesaver() AttributeError: 'NumArray' object has no attribute 'spacesaver' >>> -- This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation. Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments mentioned or may advise the issuers. This may refer to a research analyst/research report. Unless indicated, these views are the author?s and may differ from those of Morgan Stanley research or others in the Firm. We do not represent this is accurate or complete and we may not update this. Past performance is not indicative of future returns. For additional information, research reports and important disclosures, contact me or see https://secure.ms.com/servlet/cls. You should not use email to request, authorize or effect the purchase or sale of any security or instrument, to send transfer instructions, or to effect any other transactions. We cannot guarantee that any such requests received via email will be processed in a timely manner. This communication is solely for the addres -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmiller at stsci.edu Fri Aug 29 05:58:05 2003 From: jmiller at stsci.edu (Todd Miller) Date: Fri Aug 29 05:58:05 2003 Subject: [Numpy-discussion] numarray.linear_algrebra > cholesky_decomposition problem In-Reply-To: <3F4F091B.F4AA75EF@morganstanley.com> References: <3F4F091B.F4AA75EF@morganstanley.com> Message-ID: <1062161839.5965.101.camel@localhost.localdomain> It's a bug in the recent port of mlab.py. Numarray doesn't really support spacesaver, and it doesn't fake it yet either. I removed the spacesaver code for numarray-0.7. On Fri, 2003-08-29 at 04:04, Justin Worrall wrote: > Hi, > > I'm having problems using the cholesky decomposition function - > perhaps someone could point out where I am going wrong. Many thanks, > > Justin > > dingy /ms/user/w/worrall 22$ python > Python 2.3 (#1, Aug 19 2003, 16:53:06) > [GCC 2.95.2 19991024 (release)] on sunos5 > Type "help", "copyright", "credits" or "license" for more information. > >>> from numarray import * > >>> from numarray.linear_algebra import * > >>> x=array([[1.0,0.0],[0.5,1.0]]) > >>> x > array([[ 1. , 0. ], > [ 0.5, 1. ]]) > >>> cholesky_decomposition(x) > Traceback (most recent call last): > File "", line 1, in ? > File > "/u/worrall/Python-2.3/numarray/linear_algebra/LinearAlgebra2.py", > line 159, in cholesky_decomposition > return copy.copy(num.transpose(mlab.triu(a,k=0))) > File "/u/worrall/Python-2.3/numarray/linear_algebra/mlab.py", line > 134, in triu > svsp = m.spacesaver() > AttributeError: 'NumArray' object has no attribute 'spacesaver' > >>> > -- > This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation. Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments mentioned or may advise the issuers. This may refer to a research analyst/research report. Unless indicated, these views are the author?s and may differ from those of Morgan Stanley research or others in the Firm. We do not represent this is accurate or complete and we may not update this. Past performance is not indicative of future returns. For additional information, research reports and important disclosures, contact me or see https://secure.ms.com/servlet/cls. You should not use email to request, authorize or effect the purchase or sale of any security or instrument, to send transfer instructions, or to effect any other transactions. We cannot guarantee that any such reque > sts received via email will be processed in a timely manner. This communication is solely for the addres > -- Todd Miller From jmiller at stsci.edu Fri Aug 29 13:46:10 2003 From: jmiller at stsci.edu (Todd Miller) Date: Fri Aug 29 13:46:10 2003 Subject: [Numpy-discussion] ANN: numarray-0.7 Message-ID: <1062189903.5965.185.camel@localhost.localdomain> Release Notes for numarray-0.7 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, and improved type promotions. I. ENHANCEMENTS 1. Object Arrays numarray now has an object array facility. numarray.objects provides array indexing and ufuncs for fixed length collections of arbitrary Python objects. 2. Merger of NumArray/ComplexArray classes Numarray's NumArray and ComplexArray classes have been unified into a single class. Thus, a single base class can be used to derive array classes which operate on integer, real or complex numbers. Thanks to Colin Williams for this suggestion. 3. Indexing improvements The implementation of numarray's indexing has been simplified and improved. Ad-hoc logic for getting single array elements fast has been replaced by a full conversion to C of the top level of numarray's Python indexing code. The resulting code is simpler, prototyped in Python, and adds an additional kind of indexing which occurs entirely in C for speed: sub-arrays. Slicing and array indexing, however, still involve significant amounts of Python code. 4. IEEE Special Value Constants Standard constants for nan, plus_inf, minus_inf, and inf have been added to numarray.ieeespecial making it easier to assign IEEE special values to arrays in addition to finding or replacing special values. 5. Better Numeric interoperability (wxPyPlot port) numarray-0.7 addresses a couple compatibility and speed issues which hindered numarray's use with wxPyPlot. numarray now works fine with the wxPyPlot demos by changing "import Numeric" to "import numarray as Numeric". II. BUGS FIXED See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. 793421 PyArray_INCREF / PyArray_XDECREF deprecated 791354 Integer overflow bugs? 785458 Crash subclassing the NumArray class 784866 astype() fails sometimes 779755 Mac OS 10 installation problem 740035 Possible problem with dot III. CAUTIONS 1. numarray extension writers should note that the documented use of PyArray_INCREF and PyArray_XDECREF (in numarray) has been found to be incompatible with Numeric and has therefore been deprecated. numarray wrapper functions using PyArray_INCREF and PyArray_XDECREF should switch to ordinary Py_INCREF and Py_XDECREF. 2. Writers of numarray subclasses should note that the "protected" _getitem/_setitem interface for NDArray has changed. WHERE ----------- Numarray-0.7 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-0.7 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. Thanks go to Jochen Kupper of the University of North Carolina for his work on Numarray and for porting the Numarray manual to TeX format. Thanks also to Edward C. Jones, Francesc Alted, Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson, Colin Williams, and everyone 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 at stsci.edu From shuntim.luk at polyu.edu.hk Fri Aug 29 22:18:03 2003 From: shuntim.luk at polyu.edu.hk (LUK ShunTim) Date: Fri Aug 29 22:18:03 2003 Subject: [Numpy-discussion] numarray.linear_algrebra > cholesky_decomposition problem In-Reply-To: <1062161839.5965.101.camel@localhost.localdomain> References: <3F4F091B.F4AA75EF@morganstanley.com> <1062161839.5965.101.camel@localhost.localdomain> Message-ID: <3F5032A0.8050009@polyu.edu.hk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Todd Miller wrote: | It's a bug in the recent port of mlab.py. Numarray doesn't really | support spacesaver, and it doesn't fake it yet either. I removed | the spacesaver code for numarray-0.7. | | On Fri, 2003-08-29 at 04:04, Justin Worrall wrote: | |>Hi, |> |>I'm having problems using the cholesky decomposition function - |>perhaps someone could point out where I am going wrong. Many thanks, |> |>Justin |> |>dingy /ms/user/w/worrall 22$ python |>Python 2.3 (#1, Aug 19 2003, 16:53:06) |>[GCC 2.95.2 19991024 (release)] on sunos5 |>Type "help", "copyright", "credits" or "license" for more information. |> |>>>>from numarray import * |>>>>from numarray.linear_algebra import * |>>>>x=array([[1.0,0.0],[0.5,1.0]]) |>>>>x |> |>array([[ 1. , 0. ], |> [ 0.5, 1. ]]) |> |>>>>cholesky_decomposition(x) |> [snipped] A big Thanks for the *very* quick response. But I found it strange that Cholesky decomposition is used for an unsymmetric matrix and then I discover that in fact this goes through raising no error. Here's the code snippet from numarray import * import numarray.linear_algebra as la # Good x=array([[1.0,0.5],[0.5,1.0]]) print "\n", x al=la.cholesky_decomposition(x) print "\n", al print "\n", matrixmultiply(al,transpose(al)) # Bad x=array([[1.0,0],[0.5,1.0]]) print "\n", x al=la.cholesky_decomposition(x) print "\n", al print "\n", matrixmultiply(al,transpose(al)) and the results: H:\>python chol-numarray.py [[ 1. 0.5] ~ [ 0.5 1. ]] [[ 1. 0. ] ~ [ 0.5 0.8660254]] [[ 1. 0.5] ~ [ 0.5 1. ]] [[ 1. 0. ] ~ [ 0.5 1. ]] [[ 1. 0. ] ~ [ 0.5 0.8660254]] [[ 1. 0.5] ~ [ 0.5 1. ]] It appears that there is no checking (at least) for the symmetry of the matrix. Of course, the user's responsibilty, ultimately ... Regards, ST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQE/UDKdNmKlQkqct/IRAqIMAJ9T2xg/45Cf08SD4jvy5M4QBrNFvgCcDvrZ PVxuUjQmVmXfSmm0WGilFhE= =1aji -----END PGP SIGNATURE----- From haase at msg.ucsf.edu Sat Aug 30 14:05:02 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Sat Aug 30 14:05:02 2003 Subject: [Numpy-discussion] Numarray web site and google Message-ID: <04e601c36f3a$4a3b9170$421ee6a9@rodan> Hi all, It already worked - see for yourself. http://www.google.com/search?q=numarray See you all at SciPy'03 ;-) Sebastian Haase >----- Original Message ----- >From: "Perry Greenfield" >To: "Sebastian Haase" ; > >Sent: Thursday, August 21, 2003 5:47 AM >Subject: RE: [Numpy-discussion] Numarray web site and google > > > > Thanks for pointing this out and particularly for doing research > > into how to fix the problem! We will give this a try (though it may > > take a few days). > > > > > -----Original Message----- > > > From: numpy-discussion-admin at lists.sourceforge.net > > > [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of > > > Sebastian Haase > > > Sent: Wednesday, August 20, 2003 6:42 PM > > > To: numpy-discussion at lists.sourceforge.net > > > Subject: [Numpy-discussion] Numarray web site and google > > > > > > > > > Hi, > > > I'm not sure how much time you guys wants to spend on the > > > numarray web site, > > > but I find that a google search for 'numarray' still points to > > > http://stsdas.stsci.edu/numarray/ > > > saying numarray has moved! > > > (OK it does bring me to the right page after some seconds) > > > Anyway - doing some search on Usenet I found this > > > http://groups.google.com/groups?threadm=vc3bh351prjbd8%40corp.supe > > > rnews.com&rnum=8&prev=/groups%3Fq%3D%2522search%2Bengines%2522%2B%2522%252Bh > > as%> 2Bmoved%2522%2B%2Bhtml%2Bhead%26hl%3Den%26lr%3D%26ie%3DISO-8859-1% > > > 26safe%3Doff > > > From: Guy Macon (guymacon+"_http://www.guymacon.com/_"03 at spamcop.net) > > > Subject: Re: If I can't redirect to new url, how bad is forwarding it? > > > Newsgroups: alt.internet.search-engines > > > Date: 2003-05-13 19:48:05 PST > > > > > > he essentially says adding this to the html-page might fix it soon: > > > > > > > > > http://www.example.com > > > > > > > > > > > > > > > Just a thought ... > > > > > > Thanks for numarray - have a great day. > > > > > > Sebastian Haase > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by Dice.com. > > > Did you know that Dice has over 25,000 tech jobs available today? From > > > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > > > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > > > _______________________________________________ > > > Numpy-discussion mailing list > > > Numpy-discussion at lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: VM Ware > > With VMware you can run multiple operating systems on a single machine. > > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines > > at the same time. Free trial click > here:http://www.vmware.com/wl/offer/358/0 > > _______________________________________________ > > Numpy-discussion mailing list > > Numpy-discussion at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > From 238624 at msn.com Fri Aug 8 19:45:05 2003 From: 238624 at msn.com (238624 at msn.com) Date: Fri Aug 8 19:45:05 2003 Subject: [Numpy-discussion] MUCH BIGGER PENIS? 238624 Message-ID: An HTML attachment was scrubbed... URL: From falted at openlc.org Thu Aug 14 07:20:07 2003 From: falted at openlc.org (Francesc Alted) Date: Thu Aug 14 07:20:07 2003 Subject: [Numpy-discussion] PyTables 0.7.1 is out Message-ID: <200308141245.13358.falted@openlc.org> 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 From eric at enthought.com Thu Aug 14 16:22:02 2003 From: eric at enthought.com (eric jones) Date: Thu Aug 14 16:22:02 2003 Subject: [Numpy-discussion] ANN: Job posting -- developer position available Message-ID: <010701c362c0$3b54ec50$a47ba8c0@ericlaptop> Hey group, We have a developer position open here at Enthought, and I thought I'd see if anyone is interested. The posting is below. There is also a tech writer and HCI opening listed on the website: http://www.enthought.com/careers.html thanks! eric Position: Python Developer Type: Full-Time Enthought, Inc. is a technology startup in the Austin, TX area that is looking for a motivated Python Developer to join our development team. Responsibilities include developing and deploying scientific applications within the Fortune 500. Our size and prospects provide significant opportunity for growth and advancement for Enthought employees. Candidates should have the following qualifications: - BS or MS in Computer Science or Engineering or other scientific field - 3+ years experience in the software industry - Experience developing solutions in the following languages: - Python - C/C++ - User interface design experience - Developing and deploying custom solutions for clients - Excellent verbal and written communication skills Ideal candidates will also demonstrate the following skills: - Use of the wxPython user interface library - Experience with Geophysics applications - Experience in the fields of statistics, linear algebra and calculus Please send resumes to jobs at enthought.com. From fperez at colorado.edu Thu Aug 14 16:38:01 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu Aug 14 16:38:01 2003 Subject: [Numpy-discussion] Why is weave.inline()/blitz++ code 3 times slower than innerproduct()? Message-ID: <3F3BFF28.7020900@colorado.edu> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: py_inner.tgz Type: application/unix-tar Size: 6059 bytes Desc: not available URL: From o.mekkaoui at free.fr Thu Aug 14 18:30:02 2003 From: o.mekkaoui at free.fr (o.mekkaoui) Date: Thu Aug 14 18:30:02 2003 Subject: [Numpy-discussion] numarray C API Message-ID: <3F3C2F2B.6070308@free.fr> 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. From jmiller at stsci.edu Fri Aug 15 06:19:01 2003 From: jmiller at stsci.edu (Todd Miller) Date: Fri Aug 15 06:19:01 2003 Subject: [Numpy-discussion] numarray C API In-Reply-To: <3F3C2F2B.6070308@free.fr> References: <3F3C2F2B.6070308@free.fr> Message-ID: <1060953310.6313.36.camel@halloween.stsci.edu> On Thu, 2003-08-14 at 20:54, o.mekkaoui wrote: > 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. The "Tester.merge" lines need to be documented. They're a result of running the tests twice in an attempt to detect cache related bugs. The total test counts vary from release to release. The leading zeros are good... they mean for instance, 0 out of 1037 tests failed. Thus, your test results show that numarray is installed and working. > > > 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. Make sure you included the header file "numarray.h" or "arrayobject.h". > > And if someone can send me I little C API example, I will be very grateful. If you have the numarray source distribution, try looking in the Examples directory for various ways to interface with numarray in C. Of the choices there, the best ones to start with are probably either the "High Level" API (Examples/convolve/high_levelmodule.c) or the Numeric compatible API (Examples/convolve/numpy_compatmodule.c). > Thanks in advance for your help. You're welcome. Good Luck! Todd -- Todd Miller jmiller at stsci.edu STSCI / ESS / SSB From o.mekkaoui at free.fr Fri Aug 15 09:44:02 2003 From: o.mekkaoui at free.fr (o.mekkaoui) Date: Fri Aug 15 09:44:02 2003 Subject: [Numpy-discussion] numarray C API In-Reply-To: <1060953310.6313.36.camel@halloween.stsci.edu> References: <3F3C2F2B.6070308@free.fr> <1060953310.6313.36.camel@halloween.stsci.edu> Message-ID: <3F3D0BA9.3040409@free.fr> Thanks for your help, I have tested a little example with including numarray.h and it don't work. However, if I include "libnumarray.h" instead "numarray.h", that work fine. Thanks. Omar Mekkaoui University of Cergy-Pontoise, France Todd Miller wrote: >On Thu, 2003-08-14 at 20:54, o.mekkaoui wrote: > > >>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. >> >> > >The "Tester.merge" lines need to be documented. They're a result of >running the tests twice in an attempt to detect cache related bugs. > >The total test counts vary from release to release. The leading zeros >are good... they mean for instance, 0 out of 1037 tests failed. Thus, >your test results show that numarray is installed and working. > > > >>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. >> >> > >Make sure you included the header file "numarray.h" or "arrayobject.h". > > > >>And if someone can send me I little C API example, I will be very grateful. >> >> > >If you have the numarray source distribution, try looking in the >Examples directory for various ways to interface with numarray in C. Of >the choices there, the best ones to start with are probably either the >"High Level" API (Examples/convolve/high_levelmodule.c) or the Numeric >compatible API (Examples/convolve/numpy_compatmodule.c). > > > >>Thanks in advance for your help. >> >> > >You're welcome. Good Luck! > >Todd > > > From verveer at embl-heidelberg.de Mon Aug 18 05:03:08 2003 From: verveer at embl-heidelberg.de (Peter Verveer) Date: Mon Aug 18 05:03:08 2003 Subject: [Numpy-discussion] bug? Message-ID: <200308181401.17137.verveer@embl-heidelberg.de> Consider conversion of a slice using the astype() method: >>> a = array([[1,2],[3,4]]) >>> b = a[1, ...] >>> print b [3 4] Conversion using the astype() method goes wrong: >>> print b.astype(Float32) [ 1. 2.] This fixes it: >>> print b.copy().astype(Float32) [ 3. 4.] A bug? Cheers, Peter -- Dr. Peter J. Verveer Cell Biology and Cell Biophysics Programme EMBL Meyerhofstrasse 1 D-69117 Heidelberg Germany Tel. : +49 6221 387245 Fax : +49 6221 387242 Email: Peter.Verveer at embl-heidelberg.de From jmiller at stsci.edu Mon Aug 18 05:28:09 2003 From: jmiller at stsci.edu (Todd Miller) Date: Mon Aug 18 05:28:09 2003 Subject: [Numpy-discussion] bug? In-Reply-To: <200308181401.17137.verveer@embl-heidelberg.de> References: <200308181401.17137.verveer@embl-heidelberg.de> Message-ID: <1061209492.3459.23.camel@localhost.localdomain> Hi Peter, What you're demonstrating below looks like a bug in numarray which was just recently solved: https://sourceforge.net/tracker/index.php?func=detail&aid=784866&group_id=1369&atid=450446 As you've shown, numarray's astype() fails for some slices, notably those which are offset from the base of the array and therefore have a non-zero _byteoffset. This is fixed in CVS now and will be "officially released" soon. On Mon, 2003-08-18 at 08:01, Peter Verveer wrote: > Consider conversion of a slice using the astype() method: > > >>> a = array([[1,2],[3,4]]) > >>> b = a[1, ...] > >>> print b > [3 4] > > Conversion using the astype() method goes wrong: > > >>> print b.astype(Float32) > [ 1. 2.] > > This fixes it: > > >>> print b.copy().astype(Float32) > [ 3. 4.] > > A bug? > > Cheers, Peter -- Todd Miller From cjw at sympatico.ca Mon Aug 18 06:37:04 2003 From: cjw at sympatico.ca (Colin J. Williams) Date: Mon Aug 18 06:37:04 2003 Subject: [Numpy-discussion] Possible bug In-Reply-To: <200308181401.17137.verveer@embl-heidelberg.de> References: <200308181401.17137.verveer@embl-heidelberg.de> Message-ID: <3F40D29E.2090308@sympatico.ca> # ta.py to check Int8, Int16 import numarray as _n import numarray.numerictypes as _nt b= _n.arange(4, type= _nt.Int8) print 'b, b._type:', b, b._type c= b*1001 # Grief here - type not updated print 'c, c._type:', c, c._type e= _n.array([1, -2, 3000, 4.6], type= _nt.Int8) # undocumented feature fraction discarded # and lowest eight bits retained as a signed # integer. print 'e, e._type:', e, e._type f= _n.array([1, 2, 3, 4.6], type= _nt.Int8) * 9.6 print 'f, f._type:', f, f._type g= (f.copy()*2000).astype(_nt.Int16) # undocumented - see e above print 'g, g._type:', g, g._type -------------------------------------------------------------------- PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mhammond at skippinet.com.au) - see 'Help/About PythonWin' for further copyright information. >>> b, b._type: [0 1 2 3] Int8 c, c._type: [ 0 -23 -46 -69] Int8 e, e._type: [ 1 -2 -72 4] Int8 f, f._type: [ 9.6 19.2 28.8 38.4] Float64 g, g._type: [ 19200 -27136 -7937 11264] Int16 Colin W. From jmiller at stsci.edu Mon Aug 18 06:59:02 2003 From: jmiller at stsci.edu (Todd Miller) Date: Mon Aug 18 06:59:02 2003 Subject: [Numpy-discussion] bug? In-Reply-To: <200308181431.30395.verveer@embl-heidelberg.de> References: <200308181401.17137.verveer@embl-heidelberg.de> <1061209492.3459.23.camel@localhost.localdomain> <200308181431.30395.verveer@embl-heidelberg.de> Message-ID: <1061213011.3459.123.camel@localhost.localdomain> 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 From cjw at sympatico.ca Mon Aug 18 12:45:09 2003 From: cjw at sympatico.ca (Colin J. Williams) Date: Mon Aug 18 12:45:09 2003 Subject: [Numpy-discussion] How are Booleans to be handled? Message-ID: <3F412CA7.6070707@sympatico.ca> This statement: z= _n.array([True, False, True, True], type= _nt.BooleanType) gives an exception: Traceback (most recent call last): File "", line 1, in ? File "C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 284, in array type = getTypeObject(sequence, type, typecode) File "C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 217, in getTypeObject return getType(type) File "C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 324, in getType raise TypeError("Not a numeric type") TypeError: Not a numeric type If we leave out the type parameter, the array is created with 32 bit words. Colin W. From jmiller at stsci.edu Mon Aug 18 12:54:03 2003 From: jmiller at stsci.edu (Todd Miller) Date: Mon Aug 18 12:54:03 2003 Subject: [Numpy-discussion] How are Booleans to be handled? In-Reply-To: <3F412CA7.6070707@sympatico.ca> References: <3F412CA7.6070707@sympatico.ca> Message-ID: <1061236370.3460.229.camel@localhost.localdomain> On Mon, 2003-08-18 at 15:44, Colin J. Williams wrote: > This statement: > z= _n.array([True, False, True, True], type= _nt.BooleanType) Use type=_nt.Bool here. BooleanType is the class of Bool. Todd -- Todd Miller From cjw at sympatico.ca Mon Aug 18 16:22:03 2003 From: cjw at sympatico.ca (Colin J. Williams) Date: Mon Aug 18 16:22:03 2003 Subject: [Numpy-discussion] How are Booleans to be handled? In-Reply-To: <1061236370.3460.229.camel@localhost.localdomain> References: <3F412CA7.6070707@sympatico.ca> <1061236370.3460.229.camel@localhost.localdomain> Message-ID: <3F415F97.2080303@sympatico.ca> Thanks, I made a guess and chose the wrong one. This is a lot closer to the optimum storage. Colin W. Todd Miller wrote: >On Mon, 2003-08-18 at 15:44, Colin J. Williams wrote: > > >>This statement: >> z= _n.array([True, False, True, True], type= _nt.BooleanType) >> >> > >Use type=_nt.Bool here. BooleanType is the class of Bool. > >Todd > > > From haase at msg.ucsf.edu Wed Aug 20 16:38:04 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Wed Aug 20 16:38:04 2003 Subject: [Numpy-discussion] Numarray web site and google Message-ID: <00e801c3676c$51e86720$421ee6a9@rodan> Hi, I'm not sure how much time you guys wants to spend on the numarray web site, but I find that a google search for 'numarray' still points to http://stsdas.stsci.edu/numarray/ saying numarray has moved! (OK it does bring me to the right page after some seconds) Anyway - doing some search on Usenet I found this http://groups.google.com/groups?threadm=vc3bh351prjbd8%40corp.supernews.com&rnum=8&prev=/groups%3Fq%3D%2522search%2Bengines%2522%2B%2522%252Bhas%2Bmoved%2522%2B%2Bhtml%2Bhead%26hl%3Den%26lr%3D%26ie%3DISO-8859-1%26safe%3Doff From: Guy Macon (guymacon+"_http://www.guymacon.com/_"03 at spamcop.net) Subject: Re: If I can't redirect to new url, how bad is forwarding it? Newsgroups: alt.internet.search-engines Date: 2003-05-13 19:48:05 PST he essentially says adding this to the html-page might fix it soon: http://www.example.com Just a thought ... Thanks for numarray - have a great day. Sebastian Haase From perry at stsci.edu Thu Aug 21 09:41:03 2003 From: perry at stsci.edu (Perry Greenfield) Date: Thu Aug 21 09:41:03 2003 Subject: [Numpy-discussion] Numarray web site and google In-Reply-To: <00e801c3676c$51e86720$421ee6a9@rodan> Message-ID: Thanks for pointing this out and particularly for doing research into how to fix the problem! We will give this a try (though it may take a few days). > -----Original Message----- > From: numpy-discussion-admin at lists.sourceforge.net > [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of > Sebastian Haase > Sent: Wednesday, August 20, 2003 6:42 PM > To: numpy-discussion at lists.sourceforge.net > Subject: [Numpy-discussion] Numarray web site and google > > > Hi, > I'm not sure how much time you guys wants to spend on the > numarray web site, > but I find that a google search for 'numarray' still points to > http://stsdas.stsci.edu/numarray/ > saying numarray has moved! > (OK it does bring me to the right page after some seconds) > Anyway - doing some search on Usenet I found this > http://groups.google.com/groups?threadm=vc3bh351prjbd8%40corp.supe rnews.com&rnum=8&prev=/groups%3Fq%3D%2522search%2Bengines%2522%2B%2522%252Bh as%> 2Bmoved%2522%2B%2Bhtml%2Bhead%26hl%3Den%26lr%3D%26ie%3DISO-8859-1% > 26safe%3Doff > From: Guy Macon (guymacon+"_http://www.guymacon.com/_"03 at spamcop.net) > Subject: Re: If I can't redirect to new url, how bad is forwarding it? > Newsgroups: alt.internet.search-engines > Date: 2003-05-13 19:48:05 PST > > he essentially says adding this to the html-page might fix it soon: > > > http://www.example.com > > > > > Just a thought ... > > Thanks for numarray - have a great day. > > Sebastian Haase > > > > ------------------------------------------------------- > This SF.net email is sponsored by Dice.com. > Did you know that Dice has over 25,000 tech jobs available today? From > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > From fperez at colorado.edu Thu Aug 21 19:17:02 2003 From: fperez at colorado.edu (Fernando Perez) Date: Thu Aug 21 19:17:02 2003 Subject: [Numpy-discussion] Blitz++, NumArray... Message-ID: <3F4525A1.3040701@colorado.edu> Hi all, as some of you know, I'm a big fan of weave.inline() for the ease of development it offers. Essentially C++ becomes a scripting part of python, with only the occasional recompile overhead (but this is transparent to the users). inline() makes heavy use of the blitz++ library, to represent numpy arrays as blitz arrays and therefore index them as Arr(i,j,k...). This seems to me like a very sound decision, as the blitz library was specifically written to provide simultaneously fortran-like performance with high-level object orientation. With this in mind, I have a few questions: - Is there anything in Numarray's design which prevents this same trick from being used? The core of getting a Numpy array into a blitz one is simply a call to: // Convert a Numpy array to a blitz one, using the original's data (no copy) template static blitz::Array py_to_blitz(PyArrayObject *arr_obj) { blitz::TinyVector shape(0); blitz::TinyVector strides(0); for (int i=0;idimensions[i]; strides[i] = arr_obj->strides[i]/sizeof(T); } return blitz::Array((T*) arr_obj->data,shape,strides, blitz::neverDeleteData); } I would not be surprised if something much like this would work for Numarrays, but I'd like to know for sure. - If the above is indeed possible for Numarray, do you guys feel that blitz should be considered an integral part of python's low-level arsenal, or not? I view its advantages especially in the field of an extremely clean, simple syntax (compared to the low-level Numpy API, I'm not familiar with Numarray yet). I've seen examples where a numpy algorithm can be recoded using blitz in a _far_ smaller amount of code, and with performance gains to boot (in some cases, not all). Please note that I am NOT second-guessing any of the design decisions made by the Numarray crowd. I just want to clarify if it's possible to have a C++ API which gives access to numarray with the simplest, highest-level syntax and behavior which is reasonable. This is important for teams where not everyone is an expert on C pointer manipulation details, but they may be perfectly ok with writing loops over things which can be indexed as A(i,j,k). - If any of this seems worthy of more detailed discussion, I told Eric Jones that I'd be happy to coordinate something along these lines at Scipy'03. If there's time in the schedule I'd be glad to do it officially, otherwise we can just try to keep it in mind for a lunch/dinner meeting. Documenting a 'Best Practices for low-level numerical work in python' would probably be a beneficial thing to do for the community. Right now there are so many options that I'm sure I'm not the only one to feel a bit confused. - If Blitz++ is indeed deemed a worthy piece of this puzzle, I wonder if we could contact some of its developers to bring them into this discussion. I worry a bit that activity on its mailing lists seems rather slow, but I noticed that an apparently central guy, Julian C. Cummings, is at CACR/Caltech. Perhaps he could stop by and let us know what the future for blitz looks like. I can fire off an email to him if there is interest in the blitz thing. Anyway, I'm just trying to 'pre-soak' a few ideas for discussion at scipy'03 on these topics. Best regards, Fernando. From Chris.Barker at noaa.gov Fri Aug 22 09:50:39 2003 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Aug 22 09:50:39 2003 Subject: [Numpy-discussion] Blitz++, NumArray... References: <3F4525A1.3040701@colorado.edu> Message-ID: <3F464832.839785B5@noaa.gov> Fernando Perez wrote: > - Is there anything in Numarray's design which prevents this same trick from > being used? It's not entirely clear to me what you have in mind. ARE you proposing that Blitz++ arrays be the low-level implimentaiton of Numarray?, or just that there be an easy way to switch between them. In the first case, it was considered a coupl eof years ago, and rejected (as far as I could tell) mainly for reasons of portability: Blitz++ makes heavy use of templates, which are not well supported by the very wide variety of compilers that Python is supported on. One of the goals of Numarray is to make it into the Python standard library, and use of C++ and templates would preclude that, at least in the foreseeable future. Here's one discussion about it: http://www.geocrawler.com/mail/thread.php3?subject=%5BNumpy-discussion%5D+Meta%3A+too+many+numerical+libraries+doing+the&list=1329 If that url doesn't work, I found it by searching google for: Numpy-discussion blitz++ If you are proposing the second: that there could be an easy bridge between Numarray and Blitz++ (maybe using Boost Python somehow?) so that Blitz++ arrays could be used to write Numarray extensions, I'm all for it! I think the community would gain a great deal from an easier to use API for writing compiled Numarray functions. Besides making it easier for those of us that find the need for custom extensions, it would make it much easier for people to write and contibute high performance general purpose code--resulting in a much expanded library for Numarray and SciPy. -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 at noaa.gov From rzsiek at yahoo.com Fri Aug 22 10:13:05 2003 From: rzsiek at yahoo.com (Electrician) Date: Fri Aug 22 10:13:05 2003 Subject: [Numpy-discussion] Resume Message-ID: Resume from: Rich for Job or Service " no job too small " E L E C T R I C I A N Tel. (408) 482-2102 rysio3 at yahoo.com WIRING & INSTALLATION Hands on electrical installations perform fitting, mounting, laying cables on Commercial, Industrial, residential new & existing buildings. Electrical Power Supply for Lights, Plugs, Receptacles, Panels, & Fuse boxes, Emergency Generators wiring and testing, Transformers, Power Lines & conduit layout, bending and mounting, parking lighting, lamps, switches, SOLAR PROJECTS, posts and underground installations. Shopping Centers; grocery stories, hardware stories, restaurants & residential - housing areas, computer business & fast food units installation & buildings; Solar Panels, Sun Tracking, Flywheel Storage & electric cars systems modify, Natural Energy in Remote areas install. LOW VOLTAGE for Home & OFFICE 12 / 24 Volt audio & video equipment, Computer & data network wiring, data backup and UPS; Monitoring Video Control & backup tapes set up and mounting, electro-optical assemblies & subsystems. DC Power Supply, Switch & Motion sensors Alarm. Fire & safety systems install. Fiber Optics systems, PLC setup, Master Control Center, cable modems & cable TV install. Network, UPS Battery Backup mounting and charging systems; Power supply testing, troubleshooting, and analyzing to a components level. Electric Vehicles Design, Assembly & Installations. CC TV & Cameras, Security Systems & Sensors for Safety, Fire sprinklers and traffic Monitoring & Door Control. Telephones / Net move & install. TECHNICIAN Use lab & shop equipment, mechanical, electrical & electronic tools, measurement & testing equipment, video cameras & microscopes. Support scientists & electronic engineers. Mechanical & Electro-Mech. Design. OFFICE, ELECTRICAL AND MECHANICAL PROJECTS Electrical & Network Sketches, one line diagrams, and "as is" drawings update. Customizing Electronic and Electrical Components & Parts, Layouts electronic and electrical schematic, connectors and mechanical detailing. Quotes, supply, bids and job estimating. Customers contact, inspection, project mgmt & supervision of electricians & material handling; Use CAD, Windows and applications; ELECTRICAL & MAINTENANCE SERVICE US Citizen; open for travel . From fperez at colorado.edu Fri Aug 22 11:04:25 2003 From: fperez at colorado.edu (Fernando Perez) Date: Fri Aug 22 11:04:25 2003 Subject: [Numpy-discussion] Blitz++, NumArray... In-Reply-To: <3F464832.839785B5@noaa.gov> References: <3F4525A1.3040701@colorado.edu> <3F464832.839785B5@noaa.gov> Message-ID: <3F465A40.8080508@colorado.edu> Chris Barker wrote: > Fernando Perez wrote: > > >> - Is there anything in Numarray's design which prevents this same trick >> from being used? > > > It's not entirely clear to me what you have in mind. ARE you proposing that > Blitz++ arrays be the low-level implimentaiton of Numarray?, or just that > there be an easy way to switch between them. Well, it was a bit of both. I'm glad to have been ambiguous, since you answered both :) > In the first case, it was considered a coupl eof years ago, and rejected > (as far as I could tell) mainly for reasons of portability: Blitz++ makes > heavy use of templates, which are not well supported by the very wide > variety of compilers that Python is supported on. One of the goals of > Numarray is to make it into the Python standard library, and use of C++ and > templates would preclude that, at least in the foreseeable future. I sort of suspected this, so while this option sounds very nice in theory, I didn't expect it to be a realistic possibility. > If you are proposing the second: that there could be an easy bridge between > Numarray and Blitz++ (maybe using Boost Python somehow?) so that Blitz++ > arrays could be used to write Numarray extensions, I'm all for it! I think > the community would gain a great deal from an easier to use API for writing > compiled Numarray functions. Besides making it easier for those of us that > find the need for custom extensions, it would make it much easier for > people to write and contibute high performance general purpose > code--resulting in a much expanded library for Numarray and SciPy. This is more realistic, and in fact today it _is_ a reality. As I posted before, making a blitz array out of a numpy one is trivial, and you get fast, easy to read C++. I initially learned how to do it by reverse-engineering weave.inline's auto-generated C++ files, but once that got me off the ground, it was trivial to write my own extension modules. And now that I'm starting to learn a bit more about the capabilities of the blitz library, I'm very excited. To indirectly answer Perry's email in this same thread: after his comments, it seems to me that the Numarray->blitz operation would work just as easily as the example I showed for Numpy->blitz. Perry says that in memory, numarrays are very similar to Numpys, so this shouldn't be a problem. Which means we are already quite a ways there! I think to some extent, it's more a matter of making better known to people that this approach exists, and how easy to use it is. I only learned about it after being impressed with inline's super-simple syntax as compared to the horrors of handling numpy arrays by hand. But the more I read the blitz manual, the more I see that blitz arrays behave _a lot_ like numpy arrays even inside the C++ code. So the bridge approach, as long as the constructor call is very cheap, seems like a perfectly reasonable balance between aesthetic purity and real-world practicality to me. This doesn't mean that there are no issues to be discussed, so I'll try to outline the ones that come to mind (as per Perry's request). Perhaps others can add to this list. 1- Cheap constructors: For a rank-N array, the current constructor still requires the creation of 2 TinyVector blitz arrays of size N (shape and strides). It would be great if these copies could be avoided and the existing shape & strides data from the Numpy array could be used directly. The Numpy-> blitz functions would then be almost zero-overhead operations. 2- Access to fortran libraries: I don't know how easy it is to use say BLAS with objects defined in C++ (and with row-major memory layout). This is just my ignorance, but I'd like to clarify this point, since it would be nice to be able to use BLAS/LAPACK from within the C++ code with blitz arrays with no transposition overhead. 3- Benchmark: I think it would be valuable to draft a small but reasonable set of benchmarks comparing the raw numeric/numarray C api, the blitz version and fortran versions of some common algorithms. Blitz relies heavily on templates and C++ compilers are getting better, so it would be nice to know where things stand. I have a preliminary version of this, which I've posted here, but it only covers innerproduct(). As part of that testing, I found more numerical discrepancy than seemed reasonable to me. I would really need to understand the origin of this before feeling comfortable with the blitz approach for production codes. 4- Multiple precision: For a certain class of problems, beign able to work with Numerical arrays whose precision goes beyond double is critical. At http://crd.lbl.gov/~dhbailey/mpdist/index.html there is a good example of a modern, C++ library for extended precision which offers a very simple syntax. I wonder how easy (or not) it would be for Numarray to offer optional support for this kind of arrays. This last topic is a bit more ambitious than the others (which I think seem to be very reasonabl). However, I hope that we can at least discuss it, since there is a class of problems where it is a really important issue. There may be more things I can't think of now, but hopefully this may serve as a first outline for a discussion, both on the mailing list and in person, at scipy. Best, f From 238924 at bigfoot.com Sun Aug 24 17:37:29 2003 From: 238924 at bigfoot.com (238924 at bigfoot.com) Date: Sun Aug 24 17:37:29 2003 Subject: [Numpy-discussion] Now copy DVD's in 14 Languages! 238924 Message-ID: An HTML attachment was scrubbed... URL: From Justin.Worrall at morganstanley.com Fri Aug 29 01:05:05 2003 From: Justin.Worrall at morganstanley.com (Justin Worrall) Date: Fri Aug 29 01:05:05 2003 Subject: [Numpy-discussion] numarray.linear_algrebra > cholesky_decomposition problem Message-ID: <3F4F091B.F4AA75EF@morganstanley.com> Hi, I'm having problems using the cholesky decomposition function - perhaps someone could point out where I am going wrong. Many thanks, Justin dingy /ms/user/w/worrall 22$ python Python 2.3 (#1, Aug 19 2003, 16:53:06) [GCC 2.95.2 19991024 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from numarray import * >>> from numarray.linear_algebra import * >>> x=array([[1.0,0.0],[0.5,1.0]]) >>> x array([[ 1. , 0. ], [ 0.5, 1. ]]) >>> cholesky_decomposition(x) Traceback (most recent call last): File "", line 1, in ? File "/u/worrall/Python-2.3/numarray/linear_algebra/LinearAlgebra2.py", line 159, in cholesky_decomposition return copy.copy(num.transpose(mlab.triu(a,k=0))) File "/u/worrall/Python-2.3/numarray/linear_algebra/mlab.py", line 134, in triu svsp = m.spacesaver() AttributeError: 'NumArray' object has no attribute 'spacesaver' >>> -- This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation. Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments mentioned or may advise the issuers. This may refer to a research analyst/research report. Unless indicated, these views are the author?s and may differ from those of Morgan Stanley research or others in the Firm. We do not represent this is accurate or complete and we may not update this. Past performance is not indicative of future returns. For additional information, research reports and important disclosures, contact me or see https://secure.ms.com/servlet/cls. You should not use email to request, authorize or effect the purchase or sale of any security or instrument, to send transfer instructions, or to effect any other transactions. We cannot guarantee that any such requests received via email will be processed in a timely manner. This communication is solely for the addres -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmiller at stsci.edu Fri Aug 29 05:58:05 2003 From: jmiller at stsci.edu (Todd Miller) Date: Fri Aug 29 05:58:05 2003 Subject: [Numpy-discussion] numarray.linear_algrebra > cholesky_decomposition problem In-Reply-To: <3F4F091B.F4AA75EF@morganstanley.com> References: <3F4F091B.F4AA75EF@morganstanley.com> Message-ID: <1062161839.5965.101.camel@localhost.localdomain> It's a bug in the recent port of mlab.py. Numarray doesn't really support spacesaver, and it doesn't fake it yet either. I removed the spacesaver code for numarray-0.7. On Fri, 2003-08-29 at 04:04, Justin Worrall wrote: > Hi, > > I'm having problems using the cholesky decomposition function - > perhaps someone could point out where I am going wrong. Many thanks, > > Justin > > dingy /ms/user/w/worrall 22$ python > Python 2.3 (#1, Aug 19 2003, 16:53:06) > [GCC 2.95.2 19991024 (release)] on sunos5 > Type "help", "copyright", "credits" or "license" for more information. > >>> from numarray import * > >>> from numarray.linear_algebra import * > >>> x=array([[1.0,0.0],[0.5,1.0]]) > >>> x > array([[ 1. , 0. ], > [ 0.5, 1. ]]) > >>> cholesky_decomposition(x) > Traceback (most recent call last): > File "", line 1, in ? > File > "/u/worrall/Python-2.3/numarray/linear_algebra/LinearAlgebra2.py", > line 159, in cholesky_decomposition > return copy.copy(num.transpose(mlab.triu(a,k=0))) > File "/u/worrall/Python-2.3/numarray/linear_algebra/mlab.py", line > 134, in triu > svsp = m.spacesaver() > AttributeError: 'NumArray' object has no attribute 'spacesaver' > >>> > -- > This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation. Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments mentioned or may advise the issuers. This may refer to a research analyst/research report. Unless indicated, these views are the author?s and may differ from those of Morgan Stanley research or others in the Firm. We do not represent this is accurate or complete and we may not update this. Past performance is not indicative of future returns. For additional information, research reports and important disclosures, contact me or see https://secure.ms.com/servlet/cls. You should not use email to request, authorize or effect the purchase or sale of any security or instrument, to send transfer instructions, or to effect any other transactions. We cannot guarantee that any such reque > sts received via email will be processed in a timely manner. This communication is solely for the addres > -- Todd Miller From jmiller at stsci.edu Fri Aug 29 13:46:10 2003 From: jmiller at stsci.edu (Todd Miller) Date: Fri Aug 29 13:46:10 2003 Subject: [Numpy-discussion] ANN: numarray-0.7 Message-ID: <1062189903.5965.185.camel@localhost.localdomain> Release Notes for numarray-0.7 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, and improved type promotions. I. ENHANCEMENTS 1. Object Arrays numarray now has an object array facility. numarray.objects provides array indexing and ufuncs for fixed length collections of arbitrary Python objects. 2. Merger of NumArray/ComplexArray classes Numarray's NumArray and ComplexArray classes have been unified into a single class. Thus, a single base class can be used to derive array classes which operate on integer, real or complex numbers. Thanks to Colin Williams for this suggestion. 3. Indexing improvements The implementation of numarray's indexing has been simplified and improved. Ad-hoc logic for getting single array elements fast has been replaced by a full conversion to C of the top level of numarray's Python indexing code. The resulting code is simpler, prototyped in Python, and adds an additional kind of indexing which occurs entirely in C for speed: sub-arrays. Slicing and array indexing, however, still involve significant amounts of Python code. 4. IEEE Special Value Constants Standard constants for nan, plus_inf, minus_inf, and inf have been added to numarray.ieeespecial making it easier to assign IEEE special values to arrays in addition to finding or replacing special values. 5. Better Numeric interoperability (wxPyPlot port) numarray-0.7 addresses a couple compatibility and speed issues which hindered numarray's use with wxPyPlot. numarray now works fine with the wxPyPlot demos by changing "import Numeric" to "import numarray as Numeric". II. BUGS FIXED See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. 793421 PyArray_INCREF / PyArray_XDECREF deprecated 791354 Integer overflow bugs? 785458 Crash subclassing the NumArray class 784866 astype() fails sometimes 779755 Mac OS 10 installation problem 740035 Possible problem with dot III. CAUTIONS 1. numarray extension writers should note that the documented use of PyArray_INCREF and PyArray_XDECREF (in numarray) has been found to be incompatible with Numeric and has therefore been deprecated. numarray wrapper functions using PyArray_INCREF and PyArray_XDECREF should switch to ordinary Py_INCREF and Py_XDECREF. 2. Writers of numarray subclasses should note that the "protected" _getitem/_setitem interface for NDArray has changed. WHERE ----------- Numarray-0.7 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-0.7 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. Thanks go to Jochen Kupper of the University of North Carolina for his work on Numarray and for porting the Numarray manual to TeX format. Thanks also to Edward C. Jones, Francesc Alted, Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson, Colin Williams, and everyone 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 at stsci.edu From shuntim.luk at polyu.edu.hk Fri Aug 29 22:18:03 2003 From: shuntim.luk at polyu.edu.hk (LUK ShunTim) Date: Fri Aug 29 22:18:03 2003 Subject: [Numpy-discussion] numarray.linear_algrebra > cholesky_decomposition problem In-Reply-To: <1062161839.5965.101.camel@localhost.localdomain> References: <3F4F091B.F4AA75EF@morganstanley.com> <1062161839.5965.101.camel@localhost.localdomain> Message-ID: <3F5032A0.8050009@polyu.edu.hk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Todd Miller wrote: | It's a bug in the recent port of mlab.py. Numarray doesn't really | support spacesaver, and it doesn't fake it yet either. I removed | the spacesaver code for numarray-0.7. | | On Fri, 2003-08-29 at 04:04, Justin Worrall wrote: | |>Hi, |> |>I'm having problems using the cholesky decomposition function - |>perhaps someone could point out where I am going wrong. Many thanks, |> |>Justin |> |>dingy /ms/user/w/worrall 22$ python |>Python 2.3 (#1, Aug 19 2003, 16:53:06) |>[GCC 2.95.2 19991024 (release)] on sunos5 |>Type "help", "copyright", "credits" or "license" for more information. |> |>>>>from numarray import * |>>>>from numarray.linear_algebra import * |>>>>x=array([[1.0,0.0],[0.5,1.0]]) |>>>>x |> |>array([[ 1. , 0. ], |> [ 0.5, 1. ]]) |> |>>>>cholesky_decomposition(x) |> [snipped] A big Thanks for the *very* quick response. But I found it strange that Cholesky decomposition is used for an unsymmetric matrix and then I discover that in fact this goes through raising no error. Here's the code snippet from numarray import * import numarray.linear_algebra as la # Good x=array([[1.0,0.5],[0.5,1.0]]) print "\n", x al=la.cholesky_decomposition(x) print "\n", al print "\n", matrixmultiply(al,transpose(al)) # Bad x=array([[1.0,0],[0.5,1.0]]) print "\n", x al=la.cholesky_decomposition(x) print "\n", al print "\n", matrixmultiply(al,transpose(al)) and the results: H:\>python chol-numarray.py [[ 1. 0.5] ~ [ 0.5 1. ]] [[ 1. 0. ] ~ [ 0.5 0.8660254]] [[ 1. 0.5] ~ [ 0.5 1. ]] [[ 1. 0. ] ~ [ 0.5 1. ]] [[ 1. 0. ] ~ [ 0.5 0.8660254]] [[ 1. 0.5] ~ [ 0.5 1. ]] It appears that there is no checking (at least) for the symmetry of the matrix. Of course, the user's responsibilty, ultimately ... Regards, ST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQE/UDKdNmKlQkqct/IRAqIMAJ9T2xg/45Cf08SD4jvy5M4QBrNFvgCcDvrZ PVxuUjQmVmXfSmm0WGilFhE= =1aji -----END PGP SIGNATURE----- From haase at msg.ucsf.edu Sat Aug 30 14:05:02 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Sat Aug 30 14:05:02 2003 Subject: [Numpy-discussion] Numarray web site and google Message-ID: <04e601c36f3a$4a3b9170$421ee6a9@rodan> Hi all, It already worked - see for yourself. http://www.google.com/search?q=numarray See you all at SciPy'03 ;-) Sebastian Haase >----- Original Message ----- >From: "Perry Greenfield" >To: "Sebastian Haase" ; > >Sent: Thursday, August 21, 2003 5:47 AM >Subject: RE: [Numpy-discussion] Numarray web site and google > > > > Thanks for pointing this out and particularly for doing research > > into how to fix the problem! We will give this a try (though it may > > take a few days). > > > > > -----Original Message----- > > > From: numpy-discussion-admin at lists.sourceforge.net > > > [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of > > > Sebastian Haase > > > Sent: Wednesday, August 20, 2003 6:42 PM > > > To: numpy-discussion at lists.sourceforge.net > > > Subject: [Numpy-discussion] Numarray web site and google > > > > > > > > > Hi, > > > I'm not sure how much time you guys wants to spend on the > > > numarray web site, > > > but I find that a google search for 'numarray' still points to > > > http://stsdas.stsci.edu/numarray/ > > > saying numarray has moved! > > > (OK it does bring me to the right page after some seconds) > > > Anyway - doing some search on Usenet I found this > > > http://groups.google.com/groups?threadm=vc3bh351prjbd8%40corp.supe > > > rnews.com&rnum=8&prev=/groups%3Fq%3D%2522search%2Bengines%2522%2B%2522%252Bh > > as%> 2Bmoved%2522%2B%2Bhtml%2Bhead%26hl%3Den%26lr%3D%26ie%3DISO-8859-1% > > > 26safe%3Doff > > > From: Guy Macon (guymacon+"_http://www.guymacon.com/_"03 at spamcop.net) > > > Subject: Re: If I can't redirect to new url, how bad is forwarding it? > > > Newsgroups: alt.internet.search-engines > > > Date: 2003-05-13 19:48:05 PST > > > > > > he essentially says adding this to the html-page might fix it soon: > > > > > > > > > http://www.example.com > > > > > > > > > > > > > > > Just a thought ... > > > > > > Thanks for numarray - have a great day. > > > > > > Sebastian Haase > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by Dice.com. > > > Did you know that Dice has over 25,000 tech jobs available today? From > > > careers in IT to Engineering to Tech Sales, Dice has tech jobs from the > > > best hiring companies. http://www.dice.com/index.epl?rel_code=104 > > > _______________________________________________ > > > Numpy-discussion mailing list > > > Numpy-discussion at lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: VM Ware > > With VMware you can run multiple operating systems on a single machine. > > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines > > at the same time. Free trial click > here:http://www.vmware.com/wl/offer/358/0 > > _______________________________________________ > > Numpy-discussion mailing list > > Numpy-discussion at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > >