From aLast@mail.ru Tue Feb 15 14:48:47 2000 From: aLast@mail.ru (Zaur Shibzukhov) Date: Tue, 15 Feb 2000 14:48:47 +0000 Subject: [Matrix-SIG] Proposal: Move array_map and array_set into NumPy core References: Message-ID: <38A9674F.9FB832E6@mail.ru> Travis Oliphant wrote: > There are several useful utilities that would work nicely in the NumPy > core. The first is the array_set function from gist, which allows setting > elements of an array using the index. The second is an array_map method > which I recently wrote and placed in SpecialFunctions (cepes) that allows > "vectorizing" an arbitrary Python function -- i.e. it is a map that > implements the universal function broadcasting rules. It's a good idea! I am often regreted that NumPy have not array_map function and the function which was inverse to function take. Good luck. From pearu@ioc.ee Tue Feb 1 08:34:28 2000 From: pearu@ioc.ee (Pearu Peterson) Date: Tue, 1 Feb 2000 10:34:28 +0200 (EET) Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) Message-ID: OK, this is my second attempt for the subject as there was little response from the numpy-discussion list. I would like to hear from the experts why it 'is not possible to implement' the column-wise arrays or why it 'should not be implemented' in Python Numeric. If the reasons are other than 'it takes too much work' then I will not bother you again and will not try to do that myself. Regards, Pearu ---------- Forwarded message ---------- Date: Wed, 26 Jan 2000 19:00:31 +0200 (EET) From: Pearu Peterson To: numpy-discussion@lists.sourceforge.net Cc: Paul F. Dubois , Travis Oliphant Subject: [Numpy-discussion] Proclamation: column-wise arrays Hi! Problem: Using Fortran routines from Python C/API is "tricky" when multi-dimensional arrays are passed in. Cause: Arrays in Fortran are stored in column-wise order while arrays in C are stored in row-wise order. Standard solutions: 1) Create a new C array; copy the data from the old one in column-wise order; pass the new array to fortran; copy changed array back to old one in row-wise order; deallocate the array. 2) Change the storage order of an array in place: element-wise swapping; pass the array to fortran; change the storage order back with element-wise swapping Why standard solutions are not good? 1) Additional memory allocation, that is problem for large arrays; Element-wise copying is time consuming (2 times). 2) It is good as no extra memory is needed but element-wise swapping (2 times) is approx. equivalent with the element-wise copying (4 times). Proclamation: Introduce a column-wise array to Numeric Python where data is stored in column-wise order that can be used specifically for fortran routines. Proposal sketch: 1) Introduce a new flag `row_order'to PyArrayObject structure: row_order == 1 -> the data is stored in row-wise order (default, as it is now) row_order == 0 -> the data is stored in column-wise order Note that now the concept of contiguousness depends on this flag. 2) Introduce new array "constructors" such as PyArray_CW_FromDims, PyArray_CW_FromDimsAndData, PyArray_CW_ContiguousFromObject, PyArray_CW_CopyFromObject, PyArray_CW_FromObject, etc. that all return arrays with row_order=0 and data stored in column-wise order (that is in case of contiguous results, otherwise strides feature is employd). 3) In order to operations between arrays (possibly with different storage order) would work correctly, many internal functions of NumPy C/API need to be modifyied. 4) anything else? What is the good of this? 1) The fact is that there is a large number of very good scietific tools freely available written in Fortran (Netlib, for instance). And I don't mean only Fortran 77 codes but also Fortran 90/95 codes. 2) Having Numeric Python arrays with data stored in column-wise order, calling Fortran routines from Python becomes really efficient and space-saving. 3) There should be little performance hit if, say, two arrays with different storage order are multiplied (compared to the operations between non-contiguous arrays in the current implementation). 4) I don't see any reason why older C/API modules would broke because of this change if it is carried out carefully enough. So, back-ward compability should be there. 5) anything else? What are against of this? 1) Lots of work but with current experience it should not be a problem. 2) The size of the code will grow. 3) I suppose that most people using Numerical Python will not care of calling Fortran routines from Python. Possible reasons: too "tricky" or no need. In the first case, the answer is that there are tools such as PyFort, f2py that solve this problem. In the later case, there is no problem:-) 4) anything else? I understand that my proposal is quite radical but taking into account that we want to use Python for many years to come, the use would be more pleasing if one cause of (constant) confusion would be less during this time. Best regards, Pearu _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From dubois@users.sourceforge.net Tue Feb 1 16:24:29 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Tue, 1 Feb 2000 08:24:29 -0800 Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) In-Reply-To: Message-ID: I think there were two reasons for the sparse response. First, a lot of us were at IPC8. Second, I don't think anyone has any real problems with this idea except the worry that problems may arise when you try to implement it. As various people have said, the existing source is extremely hard to work with. Introducing such an extensive change will not be any fun. If you were going to try it I would urge that we set you up as a developer on SourceForge and that you do it on a branch. CVS is not real good at branching but this is a case where it would be called for because it would take a long time from when you started, and we wouldn't know if the performance, etc. would be ok until the end. It would take a lot of testing to be sure nothing was broken. The situation wrt using Fortran is, however, not completely as bleak as you picture it. For example, Pyfort produces an interface in which an array from Python is transposed on input but the output is not actually transposed back unless required by subsequent usage. In particular, if the result is passed into more Fortran the transposes cancel themselves without data movement. Also, data space for temporaries is not transposed. I don't know what f2py does, but at least in principle this much is possible. -----Original Message----- From: matrix-sig-admin@python.org [mailto:matrix-sig-admin@python.org]On Behalf Of Pearu Peterson Sent: Tuesday, February 01, 2000 12:34 AM To: matrix-sig@python.org Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) OK, this is my second attempt for the subject as there was little response from the numpy-discussion list. I would like to hear from the experts why it 'is not possible to implement' the column-wise arrays or why it 'should not be implemented' in Python Numeric. If the reasons are other than 'it takes too much work' then I will not bother you again and will not try to do that myself. Regards, Pearu ---------- Forwarded message ---------- Date: Wed, 26 Jan 2000 19:00:31 +0200 (EET) From: Pearu Peterson To: numpy-discussion@lists.sourceforge.net Cc: Paul F. Dubois , Travis Oliphant Subject: [Numpy-discussion] Proclamation: column-wise arrays Hi! Problem: Using Fortran routines from Python C/API is "tricky" when multi-dimensional arrays are passed in. Cause: Arrays in Fortran are stored in column-wise order while arrays in C are stored in row-wise order. Standard solutions: 1) Create a new C array; copy the data from the old one in column-wise order; pass the new array to fortran; copy changed array back to old one in row-wise order; deallocate the array. 2) Change the storage order of an array in place: element-wise swapping; pass the array to fortran; change the storage order back with element-wise swapping Why standard solutions are not good? 1) Additional memory allocation, that is problem for large arrays; Element-wise copying is time consuming (2 times). 2) It is good as no extra memory is needed but element-wise swapping (2 times) is approx. equivalent with the element-wise copying (4 times). Proclamation: Introduce a column-wise array to Numeric Python where data is stored in column-wise order that can be used specifically for fortran routines. Proposal sketch: 1) Introduce a new flag `row_order'to PyArrayObject structure: row_order == 1 -> the data is stored in row-wise order (default, as it is now) row_order == 0 -> the data is stored in column-wise order Note that now the concept of contiguousness depends on this flag. 2) Introduce new array "constructors" such as PyArray_CW_FromDims, PyArray_CW_FromDimsAndData, PyArray_CW_ContiguousFromObject, PyArray_CW_CopyFromObject, PyArray_CW_FromObject, etc. that all return arrays with row_order=0 and data stored in column-wise order (that is in case of contiguous results, otherwise strides feature is employd). 3) In order to operations between arrays (possibly with different storage order) would work correctly, many internal functions of NumPy C/API need to be modifyied. 4) anything else? What is the good of this? 1) The fact is that there is a large number of very good scietific tools freely available written in Fortran (Netlib, for instance). And I don't mean only Fortran 77 codes but also Fortran 90/95 codes. 2) Having Numeric Python arrays with data stored in column-wise order, calling Fortran routines from Python becomes really efficient and space-saving. 3) There should be little performance hit if, say, two arrays with different storage order are multiplied (compared to the operations between non-contiguous arrays in the current implementation). 4) I don't see any reason why older C/API modules would broke because of this change if it is carried out carefully enough. So, back-ward compability should be there. 5) anything else? What are against of this? 1) Lots of work but with current experience it should not be a problem. 2) The size of the code will grow. 3) I suppose that most people using Numerical Python will not care of calling Fortran routines from Python. Possible reasons: too "tricky" or no need. In the first case, the answer is that there are tools such as PyFort, f2py that solve this problem. In the later case, there is no problem:-) 4) anything else? I understand that my proposal is quite radical but taking into account that we want to use Python for many years to come, the use would be more pleasing if one cause of (constant) confusion would be less during this time. Best regards, Pearu _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion _______________________________________________ Matrix-SIG maillist - Matrix-SIG@python.org http://www.python.org/mailman/listinfo/matrix-sig From hinsen@cnrs-orleans.fr Tue Feb 1 17:02:56 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 1 Feb 2000 18:02:56 +0100 Subject: [Matrix-SIG] Zeros In-Reply-To: <14485.56272.978010.825744@buffalo.fnal.gov> (message from Charles G Waldman on Mon, 31 Jan 2000 13:00:32 -0600 (CST)) References: <3895AF0A.B9D9AF63@bell-labs.com> <14485.56272.978010.825744@buffalo.fnal.gov> Message-ID: <200002011702.SAA18275@chinon.cnrs-orleans.fr> > I would like to see even more support for non-numeric types, for the > following reason: I could use the same NumPy code to approach problems > from either a symbolic and a numerical approach. E.g. I would like to > create a symbolic "Polynomial" class, populate a matrix with these > objects, then call some Numeric functions to perform symbolic algebra. Me too. In fact, I have done precisely this (there's a Polynomial class in ScientificPython), and fortunately I did not run into any NumPy bug with object arrays in my rather small application. In another application I used object arrays with automatic differentiation (i.e. arrays containing the DerivVar objects defined in ScientificPython). And I could well imagine uses for arrays of rational numbers (available in a module called yarn from somewhere). I suspect that many uses for object arrays would appear once people consider them safe to use for real life. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen@dirac.cnrs-orleans.fr Tue Feb 1 17:03:16 2000 From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Tue, 1 Feb 2000 18:03:16 +0100 Subject: [Matrix-SIG] Zeros In-Reply-To: <14485.56272.978010.825744@buffalo.fnal.gov> (message from Charles G Waldman on Mon, 31 Jan 2000 13:00:32 -0600 (CST)) References: <3895AF0A.B9D9AF63@bell-labs.com> <14485.56272.978010.825744@buffalo.fnal.gov> Message-ID: <200002011703.SAA18278@chinon.cnrs-orleans.fr> > I would like to see even more support for non-numeric types, for the > following reason: I could use the same NumPy code to approach problems > from either a symbolic and a numerical approach. E.g. I would like to > create a symbolic "Polynomial" class, populate a matrix with these > objects, then call some Numeric functions to perform symbolic algebra. Me too. In fact, I have done precisely this (there's a Polynomial class in ScientificPython), and fortunately I did not run into any NumPy bug with object arrays in my rather small application. In another application I used object arrays with automatic differentiation (i.e. arrays containing the DerivVar objects defined in ScientificPython). And I could well imagine uses for arrays of rational numbers (available in a module called yarn from somewhere). I suspect that many uses for object arrays would appear once people consider them safe to use for real life. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen@dirac.cnrs-orleans.fr Tue Feb 1 17:14:43 2000 From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Tue, 1 Feb 2000 18:14:43 +0100 Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) In-Reply-To: (message from Pearu Peterson on Tue, 1 Feb 2000 10:34:28 +0200 (EET)) References: Message-ID: <200002011714.SAA18287@chinon.cnrs-orleans.fr> > OK, this is my second attempt for the subject as there was little response > from the numpy-discussion list. I have never seen the first posting! > I would like to hear from the experts why it 'is not possible to > implement' the column-wise arrays or why it 'should not be implemented' in It is definitely possible, so the question is whether such an option should be implemented. > Proposal sketch: > 1) Introduce a new flag `row_order'to PyArrayObject structure: > row_order == 1 -> the data is stored in row-wise order (default, as it is > now) > row_order == 0 -> the data is stored in column-wise order > Note that now the concept of contiguousness depends on this flag. Implementing column-wise arrays via a flag in the array structure is of course the easiest solution, but raises a serious compatibility problem: existing C code that works on arrays will happily accept the column-order arrays, but interpret them wrongly. Alternative: create a new Python object type. It could share most of the implementation with the current array type, but a routine that checks an argument for PyArray_Type would report an error, instead of producing wrong results. However, that leads to a confusing situation: there will be two data types that look the same to a Python programmer, but some extension module will accept one and some the other one, which makes combining libraries rather messy. > What is the good of this? > 1) The fact is that there is a large number of very good scietific > tools freely available written in Fortran (Netlib, for instance). And I > don't mean only Fortran 77 codes but also Fortran 90/95 codes. How much of this code really needs column-order arrays? It isn't needed for 1d arrays, nor for routines that can work on "transposed" arrays (like most of LAPACK). > 4) I don't see any reason why older C/API modules would broke > because of this change if it is carried out carefully enough. So, > back-ward compability should be there. I'd like to see how this could be done! > What are against of this? > 1) Lots of work but with current experience it should not be a > problem. > 2) The size of the code will grow. Perhaps it would be a good idea to clean up the current code before any such radical modification/addition. Otherwise there is a serious risk of bug inflation. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From amullhau@zen-pharaohs.com Fri Feb 4 01:45:45 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 3 Feb 2000 20:45:45 -0500 Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) References: <200002011714.SAA18287@chinon.cnrs-orleans.fr> Message-ID: <009801bf6eb1$8eac8180$5063cb0a@amullhau> > > How much of this code really needs column-order arrays? It isn't needed > for 1d arrays, nor for routines that can work on "transposed" arrays > (like most of LAPACK). That still bites it though, since the code then has to use transpose things that you don't mean to, and vice versa. The only thing that would bite it worse is having both sorts of arrays flying around in one language. It's too bad that anyone was ever allowed to do row-major stuff, but it happened long before Python existed. C multidimensional arrays are so crippled that it's better to take no notice of them, but it's too late for that now. Later, Andrew Mullhaupt From Barrett@stsci.edu Fri Feb 4 13:41:58 2000 From: Barrett@stsci.edu (Paul Barrett) Date: Fri, 4 Feb 2000 08:41:58 -0500 (EST) Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) Message-ID: <14490.54389.402267.647564@nem-srvr.stsci.edu> Andrew Mullhaupt writes: > ... It's too bad that anyone was ever allowed to do row-major stuff, > but it happened long before Python existed. C multidimensional > arrays are so crippled that it's better to take no notice of them, > but it's too late for that now. Please explain to me why column-major arrays are preferrable to row-major arrays, other than having to explicitly list every dimension whether its needed or not? Also, isn't this SIG dead and shouldn't this discussion be moved to SoureForge? -- Paul -- Dr. Paul Barrett Space Telescope Science Institute Phone: 410-516-6714 DESD/DPT FAX: 410-516-8615 Baltimore, MD 21218 From robin@jessikat.demon.co.uk Fri Feb 4 16:14:04 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Fri, 4 Feb 2000 16:14:04 +0000 Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) In-Reply-To: <14490.54389.402267.647564@nem-srvr.stsci.edu> References: <14490.54389.402267.647564@nem-srvr.stsci.edu> Message-ID: <6bYfRGAMrvm4Ew+1@jessikat.demon.co.uk> In article <14490.54389.402267.647564@nem-srvr.stsci.edu>, Paul Barrett writes > >Andrew Mullhaupt writes: >> ... It's too bad that anyone was ever allowed to do row-major stuff, >> but it happened long before Python existed. C multidimensional >> arrays are so crippled that it's better to take no notice of them, >> but it's too late for that now. > >Please explain to me why column-major arrays are preferrable to >row-major arrays, other than having to explicitly list every dimension >whether its needed or not? > >Also, isn't this SIG dead and shouldn't this discussion be moved to >SoureForge? > > -- Paul > I certainly hope to receive these things by email. If you move to Source Forge don't I have to sign-on and ask for mail in some way? -- Robin Becker From amullhau@zen-pharaohs.com Fri Feb 4 20:33:17 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Fri, 4 Feb 2000 15:33:17 -0500 Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) References: <14490.54389.402267.647564@nem-srvr.stsci.edu> Message-ID: <057b01bf6f4f$23917ce0$5063cb0a@amullhau> > Andrew Mullhaupt writes: > > ... It's too bad that anyone was ever allowed to do row-major stuff, > > Please explain to me why column-major arrays are preferrable to > row-major arrays, Because we write linear algebra texts in languages which are written horizontally, which means that vectors are column vectors. > other than having to explicitly list every dimension > whether its needed or not? I have no idea what you're getting at here. F95 and S are column major and has no such requirement, Python is the other way around and has no such requirement. > Also, isn't this SIG dead and shouldn't this discussion be moved to > SoureForge? I have no idea. Later, Andrew Mullhaupt From amullhau@zen-pharaohs.com Fri Feb 4 20:35:52 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Fri, 4 Feb 2000 15:35:52 -0500 Subject: [Matrix-SIG] Proclamation: column-wise arrays (fwd) References: <14490.54389.402267.647564@nem-srvr.stsci.edu> <6bYfRGAMrvm4Ew+1@jessikat.demon.co.uk> Message-ID: <058501bf6f4f$88a9eb80$5063cb0a@amullhau> > > I certainly hope to receive these things by email. Me too. Later, Andrew Mullhaupt From amullhau@zen-pharaohs.com Fri Feb 4 20:52:37 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Fri, 4 Feb 2000 15:52:37 -0500 Subject: [Matrix-SIG] I have working code that implements active-casting concept. References: Message-ID: <001c01bf6f51$c90d7640$5063cb0a@amullhau> > When a universal function involving NumPy arrays is encountered, if all > arrays are passive (active flag = 0) then the current coercion rules are > used. If any of the arguments to the function are active arrays, then the > active array with the largest typecode (enumerated types in arrayobject.h) > determines the output types. All other arrays are automatically cast > (even if it means loss of precision) to that type, before the operation > begins. The output arrays from the function are all active arrays. As long as there is a simple, completely global way for me to make sure this never happens - i.e. that I can turn off active arrays globally and permanently without regard to modules that get imported, etc., I'm OK. It's a real annoyance to detect, let alone have to track down an unexpected loss of precision bug when it's not in code you wrote. I can always hack my own source copy so that if active flag=1 is ever detected core gets dumped, but that seems a bit extreme. Later, Andrew Mullhaupt From da@ski.org Sat Feb 5 04:54:59 2000 From: da@ski.org (David Ascher) Date: Fri, 4 Feb 2000 20:54:59 -0800 Subject: [Matrix-SIG] SIG transition to SourceForge References: <14490.54389.402267.647564@nem-srvr.stsci.edu> <057b01bf6f4f$23917ce0$5063cb0a@amullhau> Message-ID: <028401bf6f95$28009400$0100000a@ski.org> > > Also, isn't this SIG dead and shouldn't this discussion be moved to > > SoureForge? > > I have no idea. Indeed it is. I think the announcement got a little lost on the list (it was discussed at IPC8, but of course not everyone could be there). The idea is to centralize all NumPy-related things on sourceforge, including the mailing list. Sourceforge has other nice features like the ability to conduct polls, which we'll be exercising at some point. Paul doesn't like to subscribe people automatically to new mailing lists for very reasonable reasons, so he asked (IIRC) that everyone who'se currently on matrix-sig and wants to participate in the future development of NumPy please subscribe to the sourceforge-hosted mailing list, see: http://lists.sourceforge.net/mailman/listinfo/numpy-discussion. The matrix-sig mailing list will be removed after a suitable period. See http://sourceforge.net/project/?group_id=1369 for an overview of the tools available for NumPy development. One of the nice features of SourceForge is that it will make it easier for Paul to delegate control, manage patches, bug reports, etc. --david ascher From dubois@users.sourceforge.net Sat Feb 5 05:34:25 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Fri, 4 Feb 2000 21:34:25 -0800 Subject: [Matrix-SIG] the mailing list Message-ID: After some initial misunderstanding on my part, Guido has empowered me to deal with the matrix-sig mailing list. I will subscribe all of you to the new one numpy-discussion@sourceforge.net and then turn the old one off. The software used for the mailing list is the same so you shouldn't have any difference in behavior. I'll send out mail when I get this done. From gpk@bell-labs.com Mon Feb 7 16:10:07 2000 From: gpk@bell-labs.com (Greg Kochanski) Date: Mon, 07 Feb 2000 11:10:07 -0500 Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #361 - 6 msgs References: <20000205170026.8169A1CD96@dinsdale.python.org> Message-ID: <389EEE5F.768BF208@bell-labs.com> I think Andrew Mullhaupt came up with a good point. Unexpected downcasting is one of those things that is hard to detect, hard to trace, and can give you subtly wrong answers. NumPy needs a mechanism that will optionally throw an exception when there is a downcast. I'd suggest a module scope flag called 'debug_precision' that is normally 0. When set to 1, NumPy would throw an exception if there is a downcast. When set to 2, NumPy would also throw an exception for integer/integer division. (The latter is one of my pet peeves of python. It's too easy to type x=0 when you mean x=0.0, so one ends up doing divisions like 3/4==0 when you really mean 3.0/4.0 == 0.75. That's another error that can be hard to track down...) The other thing is that there ought to be a statement in the documentation to the effect that "It is bad practice for functions to return an active array unless its inputs are active." > Subject: Re: [Matrix-SIG] I have working code that implements active-casting concept. > From: "Andrew P. Mullhaupt" > > > When a universal function involving NumPy arrays is encountered, if all > > arrays are passive (active flag = 0) then the current coercion rules are > > used. If any of the arguments to the function are active arrays, then the > > active array with the largest typecode (enumerated types in arrayobject.h) > > determines the output types. All other arrays are automatically cast > > (even if it means loss of precision) to that type, before the operation > > begins. The output arrays from the function are all active arrays. > > As long as there is a simple, completely global way for me to make sure this > never happens - i.e. that I can turn off active arrays globally and > permanently without regard to modules that get imported, etc., I'm OK. > > It's a real annoyance to detect, let alone have to track down an unexpected > loss of precision bug when it's not in code you wrote. From dubois@users.sourceforge.net Mon Feb 7 22:24:45 2000 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Mon, 7 Feb 2000 14:24:45 -0800 Subject: [Matrix-SIG] This mailing list will stop soon Message-ID: This mailing list will be deleted soon. Please visit http://numpy.sourceforge.net and follow the link to the Numerical Python page and subscribe to the list numpy-discussion@lists.sourceforge.net. I believe mailman is capable of allowing the administrator to do mass subscriptions (or at least that is what Guido thought I could do so that I didn't have to ask you to do this yourself) but the SourceForge interface to mailman doesn't seem to have this. So, I have to ask you each to do this yourself. You can set up your own password and whether you want regular or digest form. From Oliphant.Travis@mayo.edu Tue Feb 8 00:08:43 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Mon, 7 Feb 2000 18:08:43 -0600 (CST) Subject: [Matrix-SIG] An Experiment in code-cleanup. Message-ID: I wanted to let users of the community know (so they can help if they want, or offer criticism or comments) that over the next several months I will be experimenting with a branch of the main Numerical source tree and endeavoring to "clean-up" the code for Numerical Python. I have in mind a few (in my opinion minor) alterations to the current code-base which necessitates a branch. Guido has made some good suggestions for improving the code base, and both David Ascher and Paul Dubois have expressed concerns over the current state of the source code and given suggestions as to how to improve it. That said, I should emphasize that my work is not authorized, or endorsed, by any of the people mentioned above. It is simply my little experiment. My intent is not to re-create Numerical Python --- I like most of the current functionality --- but to merely, clean-up the code, comment it, and change the underlying structure just a bit and add some features I want. One goal I have is to create something that can go into Python 1.7 at some future point, so this incarnation of Numerical Python may not be completely C-source compatible with current Numerical Python (but it will be close). This means C-extensions that access the underlying structure of the current arrayobject may need some alterations to use this experimental branch if it every becomes useful. I don't know how long this will take me. I'm not promising anything. The purpose of this announcement is just to invite interested parties into the discussion. These are the (somewhat negotiable) directions I will be pursuing. 1) Still written in C but heavily (in my opinion) commented. 2) Addition of bit-types and unsigned integer types. 3) Facility for memory-mapped dataspace in arrays. 4) Slices become copies with the addition of methods for current strict referencing behavior. 5) Handling of sliceobjects which consist of sequences of indices (so that setting and getting elements of arrays using their index is possible). 6) Rank-0 arrays will not be autoconverted to Python scalars, but will still behave as Python scalars whenever Python allows general scalar-like objects in it's operations. Methods will allow the user-controlled conversion to the Python scalars. 7) Addition of attributes so that different users can configure aspects of the math behavior, to their hearts content. If their is anyone interested in helping in this "unofficial branch work" let me know and we'll see about setting up someplace to work. Be warned, however, that I like actual code or code-templates more than just great ideas (truly great ideas are never turned away however ;-) ) If something I do benefits the current NumPy source in a non-invasive, backwards compatible way, I will try to place it in the current CVS tree, but that won't be a priority, as my time does have limitations, and I'm scratching my own itch at this point. Best regards, Travis Oliphant From amullhau@zen-pharaohs.com Tue Feb 8 00:45:32 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Mon, 7 Feb 2000 19:45:32 -0500 Subject: [Matrix-SIG] An Experiment in code-cleanup. References: Message-ID: <074901bf71cd$ced89cc0$5063cb0a@amullhau> > > These are the (somewhat negotiable) directions I will be pursuing. > > 3) Facility for memory-mapped dataspace in arrays. An excellent idea! > 5) Handling of sliceobjects which consist of sequences of indices (so that > setting and getting elements of arrays using their index is possible). The other shoe. Great ideas. These two have the potential to make Numerical Python a top-shelf tool. Later, Andrew Mullhaupt From hinsen@cnrs-orleans.fr Tue Feb 8 17:12:56 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 8 Feb 2000 18:12:56 +0100 Subject: [Matrix-SIG] An Experiment in code-cleanup. In-Reply-To: (message from Travis Oliphant on Mon, 7 Feb 2000 18:08:43 -0600 (CST)) References: Message-ID: <200002081712.SAA03158@chinon.cnrs-orleans.fr> > 3) Facility for memory-mapped dataspace in arrays. I'd really like to have that... > 4) Slices become copies with the addition of methods for current strict > referencing behavior. This will break a lot of code, and in a way that will be difficult to debug. In fact, this is the only point you mention which would be reason enough for me not to use your modified version; going through all of my code to check what effect this might have sounds like a nightmare. I see the point of having a copying version as well, but why not implement the copying behaviour as methods and leave indexing as it is? > 5) Handling of sliceobjects which consist of sequences of indices (so that > setting and getting elements of arrays using their index is possible). Sounds good as well... > 6) Rank-0 arrays will not be autoconverted to Python scalars, but will > still behave as Python scalars whenever Python allows general scalar-like > objects in it's operations. Methods will allow the > user-controlled conversion to the Python scalars. I suspect that full behaviour-compatibility with scalars is impossible, but I am willing to be proven wrong. For example, Python scalars are immutable, arrays aren't. This also means that rank-0 arrays can't be used as keys in dictionaries. How do you plan to implement mixed arithmetic with scalars? If the return value is a rank-0 array, then a single library returning a rank-0 array somewhere could mess up a program well enough that debugging becomes a nightmare. > 7) Addition of attributes so that different users can configure aspects of > the math behavior, to their hearts content. You mean global attributes? That could be the end of universally usable library modules, supposing that people actually use them. > If their is anyone interested in helping in this "unofficial branch > work" let me know and we'll see about setting up someplace to work. Be I don't have much time at the moment, but I could still help out with testing etc. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen@dirac.cnrs-orleans.fr Tue Feb 8 17:13:20 2000 From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Tue, 8 Feb 2000 18:13:20 +0100 Subject: [Matrix-SIG] An Experiment in code-cleanup. In-Reply-To: (message from Travis Oliphant on Mon, 7 Feb 2000 18:08:43 -0600 (CST)) References: Message-ID: <200002081713.SAA03161@chinon.cnrs-orleans.fr> > 3) Facility for memory-mapped dataspace in arrays. I'd really like to have that... > 4) Slices become copies with the addition of methods for current strict > referencing behavior. This will break a lot of code, and in a way that will be difficult to debug. In fact, this is the only point you mention which would be reason enough for me not to use your modified version; going through all of my code to check what effect this might have sounds like a nightmare. I see the point of having a copying version as well, but why not implement the copying behaviour as methods and leave indexing as it is? > 5) Handling of sliceobjects which consist of sequences of indices (so that > setting and getting elements of arrays using their index is possible). Sounds good as well... > 6) Rank-0 arrays will not be autoconverted to Python scalars, but will > still behave as Python scalars whenever Python allows general scalar-like > objects in it's operations. Methods will allow the > user-controlled conversion to the Python scalars. I suspect that full behaviour-compatibility with scalars is impossible, but I am willing to be proven wrong. For example, Python scalars are immutable, arrays aren't. This also means that rank-0 arrays can't be used as keys in dictionaries. How do you plan to implement mixed arithmetic with scalars? If the return value is a rank-0 array, then a single library returning a rank-0 array somewhere could mess up a program well enough that debugging becomes a nightmare. > 7) Addition of attributes so that different users can configure aspects of > the math behavior, to their hearts content. You mean global attributes? That could be the end of universally usable library modules, supposing that people actually use them. > If their is anyone interested in helping in this "unofficial branch > work" let me know and we'll see about setting up someplace to work. Be I don't have much time at the moment, but I could still help out with testing etc. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From Oliphant.Travis@mayo.edu Tue Feb 8 17:38:26 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Tue, 8 Feb 2000 11:38:26 -0600 (CST) Subject: [Matrix-SIG] An Experiment in code-cleanup. In-Reply-To: <200002081712.SAA03158@chinon.cnrs-orleans.fr> Message-ID: > > 3) Facility for memory-mapped dataspace in arrays. > > I'd really like to have that... This is pretty easy to add but it does require some changes to the underlying structure, So you can expect it. > > > 4) Slices become copies with the addition of methods for current strict > > referencing behavior. > > This will break a lot of code, and in a way that will be difficult to > debug. In fact, this is the only point you mention which would be > reason enough for me not to use your modified version; going through > all of my code to check what effect this might have sounds like a > nightmare. I know this will be a sticky point. I'm not sure what to do exactly, but the current behavior and implementation makes the semantics for slicing an array using a sequence problematic since I don't see a way to represent a reference to a sequence of indices in the underlying structure of an array. So such slices would have to be copies and not references, which makes for an inconsistent code. > > I see the point of having a copying version as well, but why not > implement the copying behaviour as methods and leave indexing as it > is? I want to agree with you, but I think we may need to change the behavior eventually so when is it going to happen? > > > 5) Handling of sliceobjects which consist of sequences of indices (so that > > setting and getting elements of arrays using their index is possible). > > Sounds good as well... This facility is already embedded in the underlying structure. My plan is to go with the original idea that Jim Hugunin and Chris Chase had for slice objects. The sliceobject in python is already general enough for this to work. > > > 6) Rank-0 arrays will not be autoconverted to Python scalars, but will > > still behave as Python scalars whenever Python allows general scalar-like > > objects in it's operations. Methods will allow the > > user-controlled conversion to the Python scalars. > > I suspect that full behaviour-compatibility with scalars is > impossible, but I am willing to be proven wrong. For example, Python > scalars are immutable, arrays aren't. This also means that rank-0 > arrays can't be used as keys in dictionaries. > > How do you plan to implement mixed arithmetic with scalars? If the > return value is a rank-0 array, then a single library returning > a rank-0 array somewhere could mess up a program well enough that > debugging becomes a nightmare. > Mixed arithmetic in general is another sticky point. I went back and read the discussion of this point which occured 1995-1996. It was very interesting reading and a lot of points were made. Now we have several years of experience and we should apply what we've learned (of course we've all learned different things :-) ). Konrad, you had a lot to say on this point 4 years ago. I've had a long discussion with a colleague who is starting to "get in" to Numerical Python and he has really been annoyed with the current mixed arithmetic rules. The seem to try to outguess the user. The spacesaving concept helps, but it still seem's like a hack to me. I know there are several opinions, so I'll offer mine. We need simple rules that are easy to teach a newcomer. Right now the rule is farily simple in that coercion always proceeds up. But, mixed arithmetic with a float and a double does not produce something with double precision -- yet that's our rule. I think any automatic conversion should go the other way. Konrad, 4 years ago, you talked about unexpected losses of precision if this were allowed to happen, but I couldn't understand how. To me, it is unexpected to have double precision arrays which are really only carrying single-precision results. My idea of the coercion hierchy is shown below with conversion always happening down when called for. The Python scalars get mapped to the "largest precision" in their category and then normal coercions rules take place. The casual user will never use single precision arrays and so will not even notice they are there unless they request them. If they do request them, they don't want them suddenly changing precision. That is my take anyway. Boolean Character Unsigned long int short Signed long int short Real /* long double */ double float Complex /* __complex__ long double */ __complex__ double __complex__ float Object > > 7) Addition of attributes so that different users can configure aspects of > > the math behavior, to their hearts content. > > You mean global attributes? That could be the end of universally > usable library modules, supposing that people actually use them. I thought I did, but I've changed my mind after reading the discussion in 1995. I don't like global attributes either, so I'm not going there. > > > If their is anyone interested in helping in this "unofficial branch > > work" let me know and we'll see about setting up someplace to work. Be > > I don't have much time at the moment, but I could still help out with > testing etc. Konrad you were very instrumental in getting NumPy off the ground in the first place and I will always appreciate your input. From hinsen@cnrs-orleans.fr Tue Feb 8 19:56:21 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 8 Feb 2000 20:56:21 +0100 Subject: [Matrix-SIG] An Experiment in code-cleanup. In-Reply-To: (message from Travis Oliphant on Tue, 8 Feb 2000 11:38:26 -0600 (CST)) References: Message-ID: <200002081956.UAA03241@chinon.cnrs-orleans.fr> > I know this will be a sticky point. I'm not sure what to do exactly, but > the current behavior and implementation makes the semantics for slicing an > array using a sequence problematic since I don't see a way to represent a You are right there. But is it really necessary to extend the meaning of slices? Of course everyone wants the functionality of indexing with a sequence, but I'd be perfectly happy to have it implemented as a method. Indexing would remain as it is (by reference), and a new method would provide copying behaviour for element extraction and also permit more generalized sequence indices. In addition to backwards compatibility, there is another argument for keeping indexing behaviour as it is: compatibility with other Python sequence types. If you have a list of lists, which in many ways behaves like a 2D array, and extract the third element (which is thus a list), then this data is shared with the full nested list. > > How do you plan to implement mixed arithmetic with scalars? If the > > return value is a rank-0 array, then a single library returning > > a rank-0 array somewhere could mess up a program well enough that > > debugging becomes a nightmare. > > > > Mixed arithmetic in general is another sticky point. I went back and read > the discussion of this point which occured 1995-1996. It was very What I meant was not mixed-precision arithmetic, but arithmetic in which one operand is a scalar and the other one a rank-0 array. Which reminds me: rank-0 arrays are also incompatible with the nested-list view of arrays. The elements of a list of numbers are numbers, not number-like sequence objects. But back to precision, which is also a popular subject: > discussion with a colleague who is starting to "get in" to Numerical > Python and he has really been annoyed with the current mixed arithmetic > rules. The seem to try to outguess the user. The spacesaving concept > helps, but it still seem's like a hack to me. I wouldn't say that the current system tries to outguess the user. It simply gives precision a higher priority than memory space. That might not coincide with what a particular user wants, but it is consistent and easy to understand. > I know there are several opinions, so I'll offer mine. We need > simple rules that are easy to teach a newcomer. Right now the rule is > farily simple in that coercion always proceeds up. But, mixed arithmetic Like in Python (for scalars), C, Fortran, and all other languages that I can think of. > Konrad, 4 years ago, you talked about unexpected losses of precision if > this were allowed to happen, but I couldn't understand how. To me, it is > unexpected to have double precision arrays which are really only > carrying single-precision results. My idea of the coercion hierchy is I think this is a confusion of two different meanings of "precision". In numerical algorithms, precision refers to the deviation between an ideal and a real numerical value. In programming languages, it refers to the *maximum* precision that can be stored in a given data type (and is in fact often combined with a difference in range). The upcasting rule thus ensures that 1) No precision is lost accidentally. If you multiply a float by a double, the float might contain the exact number 2, and thus have infinite precision. The language can't know this, so it acts conservatively and chooses the "bigger" type. 2) No overflow occurs unless it is unavoidable (the range problem). > The casual user will never use single precision arrays and so will not > even notice they are there unless they request them. If they do request There are many ways in which single-precision arrays can creep into a program without a user's attention. Suppose you send me some data in a pickled array, which happens to be single-precision. Or I call a library routine that does some internal calculation on huge data arrays, which it keeps at single precision, and (intentionally or by error) returns a single-precision result. I think your "active flag" solution is a rather good solution to the casting problem, because it gives access to a different behaviour in a very explicit way. So unless future experience points out problems, I'd propose to keep it. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From beausol@exch.hpl.hp.com Tue Feb 8 21:31:30 2000 From: beausol@exch.hpl.hp.com (Beausoleil, Raymond) Date: Tue, 8 Feb 2000 13:31:30 -0800 Subject: [Matrix-SIG] An Experiment in code-cleanup. Message-ID: <34E36C05935CD311AE5000A0C9B6B0BF07D16D@hplex3.hpl.hp.com> I've been reading the posts on this topic with considerable interest. For a moment, I want to emphasize the "code-cleanup" angle more literally than the functionality mods suggested so far. Several months ago, I hacked my personal copy of the NumPy distribution so that I could use the Intel Math Kernel Library for Windows. The IMKL is (1) freely available from Intel at http://developer.intel.com/vtune/perflibst/mkl/index.htm; (2) basically BLAS and LAPACK, with an FFT or two thrown in for good measure; (3) optimized for the different x86 processors (e.g., generic x86, Pentium II & III); (4) configured to use 1, 2, or 4 processors; and (5) configured to use multithreading. It is an impressive, fast implementation. I'm sure there are similar native libraries available on other platforms. Probably due to my inexperience with both Python and NumPy, it took me a couple of days to successfully tear out the f2c'd stuff and get the IMKL linking correctly. The parts I've used work fine, but there are probably other features that I haven't tested yet that still aren't up to snuff. In any case, the resulting code wasn't very pretty. As long as the NumPy code is going to be commented and cleaned up, I'd be glad to help make sure that the process of using a native BLAS/LAPACK distribution (which was probably compiled using Fortran storage and naming conventions) is more straightforward. Among the more tedious issues to consider are: (1) The extent of the support for LAPACK. Do we want to stick with LAPACK Lite? (2) The storage format. If we've still got row-ordered matrices under the hood, and we want to use native LAPACK libraries that were compiled using column-major format, then we'll have to be careful to set all of the flags correctly. This isn't going to be a big deal, _unless_ NumPy will support more of LAPACK when a native library is available. Then, of course, there are the special cases: the IMKL has both a C and a Fortran interface to the BLAS. (3) Through the judicious use of header files with compiler-dependent flags, we could accommodate the various naming conventions used when the FORTRAN libraries were compiled (e.g., sgetrf_ or SGETRF). The primary output of this effort would be an expansion of the "Compilation Notes" subsection of Section 15 of the NumPy documentation, and some header files that made the recompilation easier than it is now. Regards, Ray ============================ Ray Beausoleil Hewlett-Packard Laboratories mailto:beausol@hpl.hp.com Vox: 425-883-6648 Fax: 425-883-2535 HP Telnet: 957-4951 ============================ From Oliphant.Travis@mayo.edu Tue Feb 8 21:32:57 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Tue, 8 Feb 2000 15:32:57 -0600 (CST) Subject: [Matrix-SIG] Come take an informal survey. In-Reply-To: <200002082004.MAA26529@lists.sourceforge.net> Message-ID: In an effort to try and get data about what users' attitudes are toward Numerical Python, I'm conducting a survey at sourceforge.net If you would like to participate in the survey, please go to http://www.sourceforge.net, log-in with your sourceforge id and go to the numpy page: http://sourceforge.net/project/?group_id=1369 In the Public Survey section there is a short survey you can fill out. Thank you, Travis Oliphant NumPy Developer From phil@geog.ubc.ca Tue Feb 8 23:33:18 2000 From: phil@geog.ubc.ca (Phil Austin) Date: Tue, 8 Feb 2000 15:33:18 -0800 (PST) Subject: [Matrix-SIG] An Experiment in code-cleanup. In-Reply-To: References: Message-ID: <14496.42942.5355.849670@brant.geog.ubc.ca> Travis Oliphant writes: > > 3) Facility for memory-mapped dataspace in arrays. > For the NumPy users who are as ignorant about mmap, msync, and madvise as I am, I've put a couple of documents on my web site: 1) http://www.geog.ubc.ca/~phil/mmap/mmap.pdf A pdf version of Kevin Sheehan's paper: "Why aren't you using mmap yet?" (19 page Frame postscript orginal, page order back to front). He gives a good discusion of the SV4 VM model, with some mmap examples in C. 2) http://www.geog.ubc.ca/~phil/mmap/threads.html An archived email exchange (initially on the F90 mailing list) between Kevin (who is an independent Solaris consultant) and Brian Sumner (SGI) about the pros and cons of using mmap. Executive summary: i) mmap on Solaris can be a very big win (see bottom of http://www.geog.ubc.ca/~phil/mmap/msg00003.html) when used in combination with WILLNEED/WONTNEED madvise calls to guide the page prefetching. ii) IRIX and some other Unices (Linux 2.2 in particular), haven't implemented madvise, and naive use of mmap without madvise can produce lots of page faulting and much slower io than, say, asynchronous io calls on IRIX. (http://www.geog.ubc.ca/~phil/mmap/msg00009.html) So I'd love to see mmap in Numpy, but we may need to produce a tutorial outlining the tradeoffs, and giving some examples of madvise/msync/mmap used together (with a few benchmarks). Any mmap module would need to include member functions that call madvise/msync for the mmapped array (but these may be no-ops on several popular OSes.) Regards, Phil From jrwebb@goodnet.com Tue Feb 8 06:03:42 2000 From: jrwebb@goodnet.com (James R. Webb) Date: Mon, 7 Feb 2000 23:03:42 -0700 Subject: [Matrix-SIG] An Experiment in code-cleanup. References: <34E36C05935CD311AE5000A0C9B6B0BF07D16D@hplex3.hpl.hp.com> Message-ID: <001801bf71fa$41f681a0$01f936d1@janus> There is now a linux native BLAS available through links at http://www.cs.utk.edu/~ghenry/distrib/ courtesy of the ASCI Option Red Project. There is also ATLAS (http://www.netlib.org/atlas/). Either library seems to link into NumPy without a hitch. ----- Original Message ----- From: "Beausoleil, Raymond" To: Cc: Sent: Tuesday, February 08, 2000 2:31 PM Subject: RE: [Matrix-SIG] An Experiment in code-cleanup. > I've been reading the posts on this topic with considerable interest. For a > moment, I want to emphasize the "code-cleanup" angle more literally than the > functionality mods suggested so far. > > Several months ago, I hacked my personal copy of the NumPy distribution so > that I could use the Intel Math Kernel Library for Windows. The IMKL is > (1) freely available from Intel at > http://developer.intel.com/vtune/perflibst/mkl/index.htm; > (2) basically BLAS and LAPACK, with an FFT or two thrown in for good > measure; > (3) optimized for the different x86 processors (e.g., generic x86, Pentium > II & III); > (4) configured to use 1, 2, or 4 processors; and > (5) configured to use multithreading. > It is an impressive, fast implementation. I'm sure there are similar native > libraries available on other platforms. > > Probably due to my inexperience with both Python and NumPy, it took me a > couple of days to successfully tear out the f2c'd stuff and get the IMKL > linking correctly. The parts I've used work fine, but there are probably > other features that I haven't tested yet that still aren't up to snuff. In > any case, the resulting code wasn't very pretty. > > As long as the NumPy code is going to be commented and cleaned up, I'd be > glad to help make sure that the process of using a native BLAS/LAPACK > distribution (which was probably compiled using Fortran storage and naming > conventions) is more straightforward. Among the more tedious issues to > consider are: > (1) The extent of the support for LAPACK. Do we want to stick with LAPACK > Lite? > (2) The storage format. If we've still got row-ordered matrices under the > hood, and we want to use native LAPACK libraries that were compiled using > column-major format, then we'll have to be careful to set all of the flags > correctly. This isn't going to be a big deal, _unless_ NumPy will support > more of LAPACK when a native library is available. Then, of course, there > are the special cases: the IMKL has both a C and a Fortran interface to the > BLAS. > (3) Through the judicious use of header files with compiler-dependent flags, > we could accommodate the various naming conventions used when the FORTRAN > libraries were compiled (e.g., sgetrf_ or SGETRF). > > The primary output of this effort would be an expansion of the "Compilation > Notes" subsection of Section 15 of the NumPy documentation, and some header > files that made the recompilation easier than it is now. > > Regards, > > Ray > > ============================ > Ray Beausoleil > Hewlett-Packard Laboratories > mailto:beausol@hpl.hp.com > Vox: 425-883-6648 > Fax: 425-883-2535 > HP Telnet: 957-4951 > ============================ > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig > From amullhau@zen-pharaohs.com Wed Feb 9 06:51:09 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Wed, 9 Feb 2000 01:51:09 -0500 Subject: [Matrix-SIG] An Experiment in code-cleanup. References: <200002081956.UAA03241@chinon.cnrs-orleans.fr> Message-ID: <03f401bf72ca$0e0608e0$5063cb0a@amullhau> > I'd be perfectly happy to have it implemented as a > method. Indexing would remain as it is (by reference), and a new > method would provide copying behaviour for element extraction and also > permit more generalized sequence indices. I think I can live with that, as long as it _syntactically_ looks like indexing. This is one case where the syntax is more important than functionality. There are things you want to index with indices, etc., and the composition with parenthesis-like (Dyck language) syntax has proved to be one of the few readable ways to do it. > In addition to backwards compatibility, there is another argument for > keeping indexing behaviour as it is: compatibility with other Python > sequence types. If you have a list of lists, which in many ways > behaves like a 2D array, and extract the third element (which is thus > a list), then this data is shared with the full nested list. _Avoiding_ data sharing will eventually be more important that supporting data sharing since memory continues to get cheaper but memory bandwidth and latency do not improve at the same rate. Locality of reference is hard to control when there is a lot of default data sharing, and performance suffers, yet it becomes important on more and more scales as memory systems become more and more hierarchical. Ultimately, the _semantics_ we like will be implemented efficiently by emulating references and copies in code which copies and references as it sees fit and keeps track of which copies are "really" references and which references are really "copies". I've thought this through for the "everything gets copied" languages and it isn't too mentally distressing - you simply reference count fake copies. The "everything is a reference" languages are less clean, but the database people have confronted that problem. > Which reminds me: rank-0 arrays are also incompatible with the > nested-list view of arrays. There are ways out of that trap. Most post-ISO APLs provide examples of how to cope. > > I know there are several opinions, so I'll offer mine. We need > > simple rules that are easy to teach a newcomer. Right now the rule is > > farily simple in that coercion always proceeds up. But, mixed arithmetic > > Like in Python (for scalars), C, Fortran, and all other languages that > I can think of. And that is not a bad thing. But which way is "up"? (See example below.) > > Konrad, 4 years ago, you talked about unexpected losses of precision if > > this were allowed to happen, but I couldn't understand how. To me, it is > > unexpected to have double precision arrays which are really only > > carrying single-precision results. Most people always hate, and only sometimes detect, when that happens. It specifically contravenes the Geneva conventions on programming mental hygiene. > The upcasting rule thus ensures that > > 1) No precision is lost accidentally. More or less. More precisely, it depends on what you call an accident. What happens when you add the IEEE single precision floating point value 1.0 to the 32-bit integer 2^30? A _lot_ of people don't expect to get the IEEE single precision floating point value 2.0^30, but that is what happens in some languages. Is that an "upcast"? Would the 32 bit integer 2^30 make more sense? Now what about the case where the 32 bit integer is signed and adding one to it will "wrap around" if the value remains an integer? Because these two examples might make double precision or a wider integer (if available) seem the correct answer, suppose it's only one element of a gigantic array? Let's now talk about complex values.... There's plenty of rough edges like this when you mix numerical types. It's guaranteed that everybody's ox will get gored somewhere. > 2) No overflow occurs unless it is unavoidable (the range problem). > > > The casual user will never use single precision arrays and so will not > > even notice they are there unless they request them. If they do request > > There are many ways in which single-precision arrays can creep into a > program without a user's attention. Absolutely. > Suppose you send me some data in a > pickled array, which happens to be single-precision. Or I call a > library routine that does some internal calculation on huge data > arrays, which it keeps at single precision, and (intentionally or by > error) returns a single-precision result. And the worst one is when the accuracy of the result is single precision, but the _type_ of the result is double precision. There is a function in S-plus which does this (without documenting it, of course) and man was that a pain in the neck to sort out. Today, I just found another bug in one of the S-plus functions - turns out that that if you hand a complex triangular matrix and a real right hand side to the triangular solver (backsubstitution) it doesn't cast the right hand side to complex and uses whatever values are subsequent in memoty to the right hand side as if they were part of the vector. Obviously, when testing the function, they didn't try this mixed type case. But interpreters are really convenient for writing code so that you _don't_ have to think about types all the time and do your own casting. Which is why stubbing your head on an unexpected cast is so unlooked for. > I think your "active flag" solution is a rather good solution to the > casting problem, because it gives access to a different behaviour in a > very explicit way. So unless future experience points out problems, > I'd propose to keep it. Is there a simple way to ensure that no active arrays are ever activated at any time when I use Numerical Python? Later, Andrew Mullhaupt From amullhau@zen-pharaohs.com Wed Feb 9 07:17:39 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Wed, 9 Feb 2000 02:17:39 -0500 Subject: [Matrix-SIG] An Experiment in code-cleanup. References: <14496.42942.5355.849670@brant.geog.ubc.ca> Message-ID: <03fe01bf72cd$c040d640$5063cb0a@amullhau> > Travis Oliphant writes: > > > > 3) Facility for memory-mapped dataspace in arrays. > > For the NumPy users who are as ignorant about mmap, msync, > and madvise as I am, I've put a couple of documents on > my web site: I have Kevin's "Why Aren't You Using mmap() Yet?" on my site. Kevin is working on a new (11th anniversary edition? 1xth anniversary edition?). By the way, Uresh Vahalia's book on Unix Internals is a very good idea for anyone not yet familiar with modern operating systems, especially Unices. Kevin is extremely knowledgable on this subject, and several others. > Executive summary: > > i) mmap on Solaris can be a very big win Orders of magnitude. > (see bottom of > http://www.geog.ubc.ca/~phil/mmap/msg00003.html) when > used in combination with WILLNEED/WONTNEED madvise calls to > guide the page prefetching. And with the newer versions of Solaris, madvise() is a good way to go. madvise is _not_ SVR4 (not in SVID3) but it _is_ in the OSF/1 AES which means it is _not_ vendor specific. But the standard part of madvise is that it is a "hint". However everything it actually _does_ when you hint the kernel with madvise is specific usually to some versions of an operating system. There are tricks to get around madvise not doing everything you want (WONTNEED didn't work in Solaris for a long time. Kevin found a trick that worked really well instead. Kevin knows people at Sun, since he was one of the very earliest employees there, and so now the trick Kevin used to suggest has now been found to be the implementation of WONTNEED in Solaris.) And that trick is well worth understanding. It happens that msync() is a good call to know. It has an undocumented behavior on Solaris that when you msync a memory region with MS_INVALIDATE | MS_ASYNC, what happens is the dirty pages are queued for writing and backing store is available immediately, or if dirty, as soon as written out. This means that the pager doesn't have to run at all to scavenge the pages. Linux didn't do this last time I looked. I suggested it to the kernel guys and the idea got some positive response, but I don't know if they did it. > ii) IRIX and some other Unices (Linux 2.2 in particular), haven't > implemented madvise, and naive use of mmap without madvise can produce > lots of page faulting and much slower io than, say, asynchronous io > calls on IRIX. (http://www.geog.ubc.ca/~phil/mmap/msg00009.html) IRIX has an awful implementation of mmap. And SGI people go around badmouthing mmap; not that they don't have cause, but they are usually very surprised to see how big the win is with a good implementation. Of course, the msync() trick doesn't work on IRIX last I looked, which leads to the SGI people believing that mmap() is brain damaged because it runs the pager into the ground. It's a point of view that is bound to come up. HP/UX was really wacked last time I looked. They had a version (10) which supported the full mmap() on one series of workstations (700, 7000, I forget, let's say 7e+?) and didn't support it except in the non-useful SVR3.2 way on another series of workstations (8e+?). The reason was that the 8e+? workstations were multiprocessor and they hadn't figured out how to get the newer kernel flying on the multiprocessors. I know Konrad had HP systems at one point, maybe he has the scoop on those. > So I'd love to see mmap in Numpy, but we may need to produce a > tutorial outlining the tradeoffs, and giving some examples of > madvise/msync/mmap used together (with a few benchmarks). Any mmap > module would need to include member functions that call madvise/msync > for the mmapped array (but these may be no-ops on several popular OSes.) I don't know if you want a separate module; maybe what you want is the normal allocation of memory for all Numerical Python objects to be handled in a way that makes sense for each operating system. The approach I took when I was writing portable code for this sort of thing was to write a wrapper for the memory operation semantics and then implement the operations as a small library that would be OS specific, although not _that_ specific. It was possible to write single source code for SVID3 and OSF/AES1 systems with sparing use of conditional defines. Unfortunately, that code is the intellectual property of another firm, or else I'd donate it as an example for people who want to learn stuff about mmap. As it stands, there was some similar code I was able to produce at some point. I forget who here has a copy, maybe Konrad, maybe David Ascher. Later, Andrew Mullhaupt From gpk@bell-labs.com Wed Feb 9 16:13:42 2000 From: gpk@bell-labs.com (Greg Kochanski) Date: Wed, 09 Feb 2000 11:13:42 -0500 Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #364 - 9 msgs References: <20000209064911.9404C1CD3C@dinsdale.python.org> Message-ID: <38A19236.51D1879F@bell-labs.com> > From: "Andrew P. Mullhaupt" > > The upcasting rule thus ensures that > > > > 1) No precision is lost accidentally. > > More or less. > > More precisely, it depends on what you call an accident. What happens when > you add the IEEE single precision floating point value 1.0 to the 32-bit > integer 2^30? A _lot_ of people don't expect to get the IEEE single > precision floating point value 2.0^30, but that is what happens in some > languages. Is that an "upcast"? Would the 32 bit integer 2^30 make more > sense? Now what about the case where the 32 bit integer is signed and adding > one to it will "wrap around" if the value remains an integer? Because these > two examples might make double precision or a wider integer (if available) > seem the correct answer, suppose it's only one element of a gigantic array? > Let's now talk about complex values.... > It's most important that the rules be simple, and (preferably) close to common languages. I'd suggest C. In my book, anyone who carelessly mixes floats and ints deserves whatever punishment the language metes out. I've done numeric work in languages where casting was by request _only_ (e.g., Limbo, for Inferno), and I found, to my surprise, that automatic type casting these type casting is only a mild convenience. Writing code with manual typecasting is surprisingly easy. Since automatic typecasting only buys a small improvement in ease of use, I'd want to be extremely sure that it doesn't cause many problems. It's very easy to write some complicated set of rules that wastes more time (in the form of unexpected, untraceable bugs) than it saves. By the way, automatic downcasting has a hidden problems if python is ever set to trap underflow errors. I had a program that would randomly crash every 10th (or so) time I ran it with a large dataset (1000x1000 linear algebra). After days of hair-pulling, I found that the matrix was being converted from double to float at one step, and about 1 in 10,000,000 of the entries was too small to represent as a single precision number. That very rare event would underflow, be trapped, and crash the program with a floating point exception. From skaller@maxtal.com.au Wed Feb 9 16:12:49 2000 From: skaller@maxtal.com.au (skaller) Date: Thu, 10 Feb 2000 03:12:49 +1100 Subject: [Matrix-SIG] An Experiment in code-cleanup. References: <200002081956.UAA03241@chinon.cnrs-orleans.fr> Message-ID: <38A19201.8A43EC01@maxtal.com.au> Konrad Hinsen wrote: > But back to precision, which is also a popular subject: but one which even numerical programmers don't seem to understand ... > The upcasting rule thus ensures that > > 1) No precision is lost accidentally. If you multiply a float by > a double, the float might contain the exact number 2, and thus > have infinite precision. The language can't know this, so it > acts conservatively and chooses the "bigger" type. > > 2) No overflow occurs unless it is unavoidable (the range problem). .. which is all wrong. It is NOT safe to convert floating point from a lower to a higher number of bits. ALL such conversions should be removed for this reason: any conversions should have to be explicit. The reason is that whether a conversion to a larger number is safe or not is context dependent (and so it should NEVER be done silently). Consider a function k0 = 100 k = 99 while k < k0: .. k0 = k k = ... which refines a calculation until the measure k stops decreasing. This algorithm may terminate when k is a float, but _fail_ when k is a double -- the extra precision may cause the algorithm to perform many useless iterations, in which the precision of the result is in fact _lost_ due to rounding error. What is happening is that the real comparison is probably: k - k0 < epsilon where epsilon was 0.0 in floating point, and thus omitted. My point is that throwing away information is what numerical programming is all about. Numerical programmers need to know how big numbers are, and how much significance they have, and optimise calculations accordingly -- sometimes by _using_ the precision of the working types to advantage. to put this another way, it is generally bad to keep more digits (bits) or precision than you actually have: it can be misleading. So a language should not assume that it is OK to add more precision. It may not be. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 homepage: http://www.maxtal.com.au/~skaller download: ftp://ftp.cs.usyd.edu/au/jskaller From skaller@maxtal.com.au Wed Feb 9 16:22:53 2000 From: skaller@maxtal.com.au (skaller) Date: Thu, 10 Feb 2000 03:22:53 +1100 Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #364 - 9 msgs References: <20000209064911.9404C1CD3C@dinsdale.python.org> <38A19236.51D1879F@bell-labs.com> Message-ID: <38A1945D.FA0A68A4@maxtal.com.au> Greg Kochanski wrote: > By the way, automatic downcasting has a hidden problems if python > is ever set to trap underflow errors. I had a program that would > randomly crash every 10th (or so) time I ran it with a large dataset > (1000x1000 linear algebra). After days of hair-pulling, I found that > the matrix was being converted from double to float at one step, > and about 1 in 10,000,000 of the entries was too small to represent > as a single precision number. That very rare event would underflow, > be trapped, and crash the program with a floating point exception. And conversely, IF the programmer deliberately trapped underflows to terminate an iteration, _upcasting_ can be seen to be unsafe, since the values may oscillate near zero rather than underflow as expected. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 homepage: http://www.maxtal.com.au/~skaller download: ftp://ftp.cs.usyd.edu/au/jskaller From hinsen@cnrs-orleans.fr Wed Feb 9 17:17:30 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Wed, 9 Feb 2000 18:17:30 +0100 Subject: [Matrix-SIG] An Experiment in code-cleanup. In-Reply-To: <38A19201.8A43EC01@maxtal.com.au> (message from skaller on Thu, 10 Feb 2000 03:12:49 +1100) References: <200002081956.UAA03241@chinon.cnrs-orleans.fr> <38A19201.8A43EC01@maxtal.com.au> Message-ID: <200002091717.SAA10604@chinon.cnrs-orleans.fr> > silently). Consider a function > > k0 = 100 > k = 99 > while k < k0: > .. > k0 = k > k = ... > > which refines a calculation until the measure k stops decreasing. > This algorithm may terminate when k is a float, but _fail_ when > k is a double -- the extra precision may cause the algorithm I'd call this a buggy implementation. Convergence criteria should be explicit and not rely on the internal representation of data types. Neither Python nor C guarantees you any absolute bounds for precision and value range, and even languages that do (such as Fortran 9x) only promise to give you a data type that is *at least* as big as your specification. > programming is all about. Numerical programmers need to know > how big numbers are, and how much significance they have, > and optimise calculations accordingly -- sometimes by _using_ > the precision of the working types to advantage. If you care at all about portability, you shouldn't even think about this. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From amullhau@zen-pharaohs.com Wed Feb 9 17:21:37 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Wed, 9 Feb 2000 12:21:37 -0500 Subject: [Matrix-SIG] An Experiment in code-cleanup. References: <200002081956.UAA03241@chinon.cnrs-orleans.fr> <38A19201.8A43EC01@maxtal.com.au> Message-ID: <054301bf7322$23cbbbe0$5063cb0a@amullhau> > Konrad Hinsen wrote: > > > But back to precision, which is also a popular subject: > > but one which even numerical programmers don't seem to > understand ... Some do, some don't. > It is NOT safe to convert floating point from a lower to a higher > number > of bits. It is usually safe. Extremely safe. Safe enough that code in which it is _not_ safe is badly designed. > ALL such conversions should be removed for this reason: any > conversions should have to be explicit. I really hope not. A generic function with six different arguments becomes an interesting object in a language without automatic conversions. Usually, a little table driven piece of code has to cast the arguments into conformance, and then multiple versions of similar code are applied. > which refines a calculation until the measure k stops decreasing. > This algorithm may terminate when k is a float, but _fail_ when > k is a double -- the extra precision may cause the algorithm > to perform many useless iterations, in which the precision > of the result is in fact _lost_ due to rounding error. This is a classic bad programming practice and _it_ is what should be eliminated. It is a good, (and required, if you work for me), practice that: 1. All iterations should have termination conditions which are correct; that is, prevent extra iterations. This is typically precision sensitive. But that is simply something that has to be taken into account when writing the termination condition. 2. All iterations should be protected against an unexpectedly large number of iterates taking place. There are examples of iterations which are intrinsically stable in lower precision and not in higher precision (Brun's algorithm) but those are quite rare in practice. (Note that the Fergueson-Forcade algorithm, as implemented by Lenstra, Odlyzko, and others, has completely supplanted any need to use Brun's algorithm as well.) When an algorithm converges because of lack of precision, it is because the rounding error regularizes the problem. This is normally referred to in the trade as "idiot regularization". It is in my experience, invariably better to actually choose a regularization that is specific to the computation than to rely on rounding effects which might be different from machine to machine. In particular, your type of example is in for serious programmer enjoyment hours on Intel or AMD machines, which have 80 bit wide registers for all the floating point arithmetic. Supporting needless machine dependency is not something to argue for, either, since the Cray style floating point arithmetic has a bad error model. Even Cray has been beaten into submission on this, finally releasing IEEE compliant processors, but only just recently. > to put this another way, it is generally bad to keep more digits (bits) > or precision than you actually have I couldn't agree less. The exponential function and inner product accumulation are famous examples of why extra bits are important in intermediate computations. It's almost impossible to have an accurate exponential function without using extra precision - which is one reason why so many machines have extra bits in their FPUs and there is an IEEE "extended" precision type. The storage history effects which result from temporarily increased precision are well understood, mild in that they violate no common error models used in numerical analysis. And for those few cases where testing for equality is needed for debugging purposes, many systems permit you to impose truncation and eliminate storage history issues. Later, Andrew Mullhaupt From hinsen@cnrs-orleans.fr Wed Feb 9 18:39:46 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Wed, 9 Feb 2000 19:39:46 +0100 Subject: [Matrix-SIG] An Experiment in code-cleanup. In-Reply-To: <34E36C05935CD311AE5000A0C9B6B0BF07D16D@hplex3.hpl.hp.com> (beausol@exch.hpl.hp.com) References: <34E36C05935CD311AE5000A0C9B6B0BF07D16D@hplex3.hpl.hp.com> Message-ID: <200002091839.TAA10737@chinon.cnrs-orleans.fr> > (1) The extent of the support for LAPACK. Do we want to stick with LAPACK > Lite? There has been a full LAPACK interface for a long while, of which LAPACK Lite is just the subset that is needed for supporting the high-level routines in the module LinearAlgebra. I seem to have lost the URL to the full version, but it's on my disk, so I can put it onto my FTP server if there is a need. > (2) The storage format. If we've still got row-ordered matrices under the > hood, and we want to use native LAPACK libraries that were compiled using > column-major format, then we'll have to be careful to set all of the flags > correctly. This isn't going to be a big deal, _unless_ NumPy will support > more of LAPACK when a native library is available. Then, of course, there The low-level interface routines don't take care of this. It's the high-level Python code (module LinearAlgebra) that sets the transposition argument correctly. That looks like a good compromise to me. > (3) Through the judicious use of header files with compiler-dependent flags, > we could accommodate the various naming conventions used when the FORTRAN > libraries were compiled (e.g., sgetrf_ or SGETRF). That's already done! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From skaller@maxtal.com.au Wed Feb 9 22:04:13 2000 From: skaller@maxtal.com.au (skaller) Date: Thu, 10 Feb 2000 09:04:13 +1100 Subject: [Matrix-SIG] An Experiment in code-cleanup. References: <200002081956.UAA03241@chinon.cnrs-orleans.fr> <38A19201.8A43EC01@maxtal.com.au> <200002091717.SAA10604@chinon.cnrs-orleans.fr> Message-ID: <38A1E45D.6E0EF317@maxtal.com.au> Konrad Hinsen wrote: > > > silently). Consider a function > > > > k0 = 100 > > k = 99 > > while k < k0: > > .. > > k0 = k > > k = ... > > > > which refines a calculation until the measure k stops decreasing. > > This algorithm may terminate when k is a float, but _fail_ when > > k is a double -- the extra precision may cause the algorithm > > I'd call this a buggy implementation. Convergence criteria should be > explicit and not rely on the internal representation of data > types. > If you care at all about portability, you shouldn't even think about > this. But sometimes you DON'T care about portability. Sometimes, you want the best result the architecture can support, and so you need to perform a portable computation of an architecture dependent value. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 homepage: http://www.maxtal.com.au/~skaller download: ftp://ftp.cs.usyd.edu/au/jskaller From da@ski.org Wed Feb 9 23:50:03 2000 From: da@ski.org (David Ascher) Date: Wed, 9 Feb 2000 15:50:03 -0800 Subject: [Numpy-discussion] Re: [Matrix-SIG] An Experiment in code-cleanup. References: <14496.42942.5355.849670@brant.geog.ubc.ca> <03fe01bf72cd$c040d640$5063cb0a@amullhau> Message-ID: <037d01bf7358$630b8980$0100000a@ski.org> > it as an example for people who want to learn stuff about mmap. As it > stands, there was some similar code I was able to produce at some point. I > forget who here has a copy, maybe Konrad, maybe David Ascher. > > Later, > Andrew Mullhaupt I did have some of that code, but it was almost 3 years ago and five computers ago. In other words, it's *somewhere*. I'll start a grep, but don't hold your breath... --da From da@ski.org Wed Feb 16 05:28:17 2000 From: da@ski.org (David Ascher) Date: Tue, 15 Feb 2000 21:28:17 -0800 Subject: [Matrix-SIG] Deadline looming for the O'Reilly Open Source Convention Abstract submissions! Message-ID: <04b601bf783e$a17f8e60$0100000a@ski.org> If you've been considering submitting a talk proposal for the ORA conference, please submit it soon! Facts worth knowing: - Instructions are at: http://conferences.oreilly.com/oscon2000/call.html - An abstract is all you need to submit -- no need for full paper submissions. - Speakers get free access to the convention and 50% off tutorials. - Deadline for abstract submission is February 18, 2000. - Conference is July 17-20, 2000 in Monterey, CA. Cheers, --david ascher (Python track program chair) From roitblat@hawaii.edu Thu Feb 24 06:51:06 2000 From: roitblat@hawaii.edu (Herbert L. Roitblat) Date: Wed, 23 Feb 2000 20:51:06 -1000 Subject: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array Message-ID: <019901bf7e93$8771d5e0$8fd6afcf@0gl1u.pixi.com> Hey folks: Here's my problem. I am trying to transfer some programs to our Linux Alpha box from our NT box. In doing so, we have apparently updated versions of things. Here is something new for us to contend with. A short program is shown below: (Numeric version 15.2 running on Linux on an Alpha Processor) >>> from Numeric import * >>> kwd=3 >>> jwd=3 >>> a=zeros((5,5),'b') >>> a[kwd,kwd]=4 >>> a[kwd,kwd]=8 >>> temp=a[kwd,kwd] >>> temp 8 >>> temp=temp+3 >>> temp 11 >>> a[kwd,kwd]=temp Traceback (innermost last): File "", line 1, in ? TypeError: Array can not be safely cast to required type >>> type(temp) >>> temp.shape () We get the type error from trying to set the matrix element with a matrix element (apparently). In the old version (1.9) on our NT box, temp=a[kwd,kwd] results in temp being an int type. How can we either cast the temp to an int or enable what we really want, which is to add an int to a[kwd,kwd], as in a[kwd,kwd] = a[kwd,kwd] + jwd ? Do we have a bad version of Numeric? Thanks very much, Herb Herbert L. Roitblat PS: How'd we get from Numeric version 1.9 to 15.2 so fast? From jhauser@ifm.uni-kiel.de Thu Feb 24 20:58:27 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Thu, 24 Feb 2000 21:58:27 +0100 (CET) Subject: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array In-Reply-To: <019901bf7e93$8771d5e0$8fd6afcf@0gl1u.pixi.com> References: <019901bf7e93$8771d5e0$8fd6afcf@0gl1u.pixi.com> Message-ID: <20000224205827.31980.qmail@lisboa.ifm.uni-kiel.de> Also I can not reproduce this error (older NumPY version) you can try to do an active cast. >>> a[kwd,kwd]=temp.astype('b')[0] As a side note, if you want to know the type you can use the typecode() method on arrays. temp.typecode() HTH, __Janko From roitblat@hawaii.edu Thu Feb 24 21:32:07 2000 From: roitblat@hawaii.edu (Herbert L. Roitblat) Date: Thu, 24 Feb 2000 11:32:07 -1000 Subject: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array Message-ID: <021901bf7f0e$9c29fb90$8fd6afcf@0gl1u.pixi.com> Thanks, I did decide to do an active cast as a temporary Kluge, but it makes a slow process even SLOWER. It seems to me that one ought to be able to add an array element to itself without having to do an active cast. Herb -----Original Message----- From: Janko Hauser To: Herbert L. Roitblat Cc: Matrix-Sig Date: Thursday, February 24, 2000 11:02 AM Subject: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array >Also I can not reproduce this error (older NumPY version) you can try >to do an active cast. > >>>> a[kwd,kwd]=temp.astype('b')[0] > >As a side note, if you want to know the type you can use the >typecode() method on arrays. temp.typecode() > >HTH, > >__Janko > > > > >_______________________________________________ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From jhauser@ifm.uni-kiel.de Fri Feb 25 07:21:22 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Fri, 25 Feb 2000 08:21:22 +0100 (CET) Subject: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array In-Reply-To: <021901bf7f0e$9c29fb90$8fd6afcf@0gl1u.pixi.com> References: <021901bf7f0e$9c29fb90$8fd6afcf@0gl1u.pixi.com> Message-ID: <14518.11634.150855.226124@ifm.uni-kiel.de> Herbert L. Roitblat writes: > Thanks, I did decide to do an active cast as a temporary Kluge, but it makes > a slow process even SLOWER. It seems to me that one ought to be able to add > an array element to itself without having to do an active cast. > Yes that's right, but you do need to make a cast somewhere, if you add an integer ('i') to a short ('b') element. And from the example you gave, you do not add an element to itself. So this would also not change, even after the proposed changes to the casting rules. __Janko From hinsen@cnrs-orleans.fr Fri Feb 25 12:26:58 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Fri, 25 Feb 2000 13:26:58 +0100 Subject: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array In-Reply-To: <019901bf7e93$8771d5e0$8fd6afcf@0gl1u.pixi.com> (roitblat@hawaii.edu) References: <019901bf7e93$8771d5e0$8fd6afcf@0gl1u.pixi.com> Message-ID: <200002251226.NAA14777@chinon.cnrs-orleans.fr> > We get the type error from trying to set the matrix element with a matrix > element (apparently). In the old version (1.9) on our NT box, > temp=a[kwd,kwd] results in temp being an int type. How can we either cast > the temp to an int or enable what we really want, which is to add an int to > a[kwd,kwd], as in a[kwd,kwd] = a[kwd,kwd] + jwd ? > > Do we have a bad version of Numeric? Maybe an experimental version. If you check the archives of this mailing list, you can find a recent discussion about proposed modifications. One of them was to eliminate the automatic conversion of rank-0 arrays to scalars, in order to prevent type promotion. Perhaps this proposal was implemented in the version you have. Note to the NumPy maintainers: please announce all new releases on this list, mentioning changes, especially those that affect backward compatibility. As a maintainer of code that makes heavy use of NumPy, I keep getting questions and bug reports caused by some new NumPy release that I haven't even heard of. A recent example is the change of location of the header files; C modules using arrays now have to include Numeric/arrayobject.h instead of simply arrayobject.h. I can understand this change (although I am not sure it's important enough to break compatibility), but I'd have preferred to learn about it directly and as early as possible. It's really no fun working through a 2 KB bug report sent by someone with zero knowledge of C. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From roitblat@hawaii.edu Fri Feb 25 17:17:47 2000 From: roitblat@hawaii.edu (Herbert L. Roitblat) Date: Fri, 25 Feb 2000 07:17:47 -1000 Subject: [Matrix-SIG] Adding to matrix Message-ID: <027901bf7fb4$3ca52540$8fd6afcf@0gl1u.pixi.com> I inadvertantly deleted Konrad Hinson's email before replying to it. I agree with what he said, but there is an additional problem. The problem stems not from adding an integer to a 'b' type array, it comes from an inability to add an element from a 'b' type array to an element from a 'b' type array. Whatever version of Numeric we are talking about, I cannot see how inability to add an array element to the same array should result in an error. That should not be a casting problem. HLR From Oliphant.Travis@mayo.edu Fri Feb 25 19:21:45 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Fri, 25 Feb 2000 13:21:45 -0600 (CST) Subject: [Matrix-SIG] This SIG is retired. Message-ID: This is just a reminder that this SIG is retired. Further posts should be to numpy-discussion@lists.sourceforge.net -Travis