From pascucci@cs.utexas.edu Sun Jan 2 09:51:37 2000 From: pascucci@cs.utexas.edu (pascucci) Date: Sun, 02 Jan 2000 03:51:37 -0600 Subject: [Matrix-SIG] numpy interface References: Message-ID: <386F1FA9.BD2B7119@cs.utexas.edu> Hi, I am new in this list. I would like to access NumericPython arrays in my own C/C++ library. Does anyone have a piece of SWIG interface that can be used at this end? thanks Valerio From roitblat@hawaii.edu Sun Jan 2 00:41:36 2000 From: roitblat@hawaii.edu (Herbert L. Roitblat) Date: Sat, 1 Jan 2000 14:41:36 -1000 Subject: [Matrix-SIG] Limited size arrays with cPickle Message-ID: <027601bf54ba$2036dd60$8fd6afcf@0gl1u.pixi.com> Help Please: I have run into this problem before and I have a workaround for it now, but it seems like something that would be good to fix. I have a very large array (19741 x 53566) stored as 8-bit unsigned. I want to cPickle it into a file and then cPickle it back when I want to use it. I have a 2 GB machine, so memory is not immediately the problem, rather it seems to be the routine that translates the array into a string for cPickle. It reports a memory error. I suppose that it could take up that much more memory to translate this array into a string, but it seems that there ought to be a more efficient way to store arrays that would not take any more memory than the amount taken by the array. The actual routine that does the translation is in multiarray.pyd, so I cannot get to it with my limited skills. I'm running NT on a Pentium II 450MHz machine. My Numeric is dated July 13, 1999, but I think that this is the date I downloaded it. I believe that it is the latest release of Numeric. The pdf manual is copyright 1999. Thank you. Herbert L. Roitblat, Ph.D. Department of Psychology University of Hawaii 2430 Campus Road Honolulu, HI 96822 From da@ski.org Sun Jan 2 03:46:19 2000 From: da@ski.org (David Ascher) Date: Sat, 1 Jan 2000 19:46:19 -0800 Subject: [Matrix-SIG] Limited size arrays with cPickle References: <027601bf54ba$2036dd60$8fd6afcf@0gl1u.pixi.com> Message-ID: <005f01bf54d4$27b55b60$e355cfc0@ski.org> Did you make sure to use "binary" pickle to a file opened in 'wb' mode? --david ----- Original Message ----- From: Herbert L. Roitblat To: Sent: Saturday, January 01, 2000 4:41 PM Subject: [Matrix-SIG] Limited size arrays with cPickle > Help Please: > > I have run into this problem before and I have a workaround for it now, but > it seems like something that would be good to fix. > I have a very large array (19741 x 53566) stored as 8-bit unsigned. I want > to cPickle it into a file and then cPickle it back when I want to use it. I > have a 2 GB machine, so memory is not immediately the problem, rather it > seems to be the routine that translates the array into a string for cPickle. > It reports a memory error. I suppose that it could take up that much more > memory to translate this array into a string, but it seems that there ought > to be a more efficient way to store arrays that would not take any more > memory than the amount taken by the array. The actual routine that does the > translation is in multiarray.pyd, so I cannot get to it with my limited > skills. > > I'm running NT on a Pentium II 450MHz machine. My Numeric is dated July 13, > 1999, but I think that this is the date I downloaded it. I believe that it > is the latest release of Numeric. The pdf manual is copyright 1999. > > Thank you. > Herbert L. Roitblat, Ph.D. > Department of Psychology > University of Hawaii > 2430 Campus Road > Honolulu, HI 96822 > > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig > From roitblat@hawaii.edu Sun Jan 2 04:55:58 2000 From: roitblat@hawaii.edu (Herbert L. Roitblat) Date: Sat, 1 Jan 2000 18:55:58 -1000 Subject: [Matrix-SIG] Limited size arrays with cPickle Message-ID: <028601bf54dd$a91f2740$8fd6afcf@0gl1u.pixi.com> Yes, I did. I have made that mistake in the past. It does work with smaller arrays, but this is the biggest one I have tried to do. Thank you for asking. -----Original Message----- From: David Ascher To: Herbert L. Roitblat ; matrix-SIG@python.org Date: Saturday, January 01, 2000 5:50 PM Subject: Re: [Matrix-SIG] Limited size arrays with cPickle >Did you make sure to use "binary" pickle to a file opened in 'wb' mode? > >--david > >----- Original Message ----- >From: Herbert L. Roitblat >To: >Sent: Saturday, January 01, 2000 4:41 PM >Subject: [Matrix-SIG] Limited size arrays with cPickle > > >> Help Please: >> >> I have run into this problem before and I have a workaround for it now, >but >> it seems like something that would be good to fix. >> I have a very large array (19741 x 53566) stored as 8-bit unsigned. I >want >> to cPickle it into a file and then cPickle it back when I want to use it. >I >> have a 2 GB machine, so memory is not immediately the problem, rather it >> seems to be the routine that translates the array into a string for >cPickle. >> It reports a memory error. I suppose that it could take up that much more >> memory to translate this array into a string, but it seems that there >ought >> to be a more efficient way to store arrays that would not take any more >> memory than the amount taken by the array. The actual routine that does >the >> translation is in multiarray.pyd, so I cannot get to it with my limited >> skills. >> >> I'm running NT on a Pentium II 450MHz machine. My Numeric is dated July >13, >> 1999, but I think that this is the date I downloaded it. I believe that >it >> is the latest release of Numeric. The pdf manual is copyright 1999. >> >> Thank you. >> Herbert L. Roitblat, Ph.D. >> Department of Psychology >> University of Hawaii >> 2430 Campus Road >> Honolulu, HI 96822 >> >> >> _______________________________________________ >> Matrix-SIG maillist - Matrix-SIG@python.org >> http://www.python.org/mailman/listinfo/matrix-sig >> > > >_______________________________________________ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From guido@CNRI.Reston.VA.US Mon Jan 3 17:37:59 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 03 Jan 2000 12:37:59 -0500 Subject: [Matrix-SIG] Python Conference -- Early Bird Registration ends Jan 5! Message-ID: <200001031737.MAA24342@eric.cnri.reston.va.us> This is the last warning. The conference is getting booked full, don't wait till the last moment! If you haven't registered and paid by January 5, you will paying full price... So, be smart and register NOW. Also don't forget to book your hotel room by January 3 to qualify for the conference rate! Some highlights from the conference program: - 8 tutorials on topics ranging from JPython to Fnorb; - a keynote by Open Source evangelist Eric Raymond; - another by Randy Pausch, father of the Alice Virtual Reality project; - a separate track for Zope developers and users; - live demonstrations of important Python applications; - refereed papers, and short talks on current topics; - a developers' day where the feature set of Python 2.0 is worked out. Our motto, due to Bruce Eckel, is: "Life's better without braces." Come and join us at the Key Bridge Marriott in Rosslyn (across the bridge from Georgetown), January 24-27 in 2000. Make the Python conference the first conference you attend in the new millennium! The early bird registration deadline is January 5. More info: http://www.python.org/workshops/2000-01/ The program is now complete with the titles of all presentations. There is still space in the demo session and in the short talks session. --Guido van Rossum (home page: http://www.python.org/~guido/) From robin@jessikat.demon.co.uk Mon Jan 3 19:18:11 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Mon, 3 Jan 2000 19:18:11 +0000 Subject: [Matrix-SIG] invalid floats Message-ID: Is there any nice way to allow unset elements in Numeric arrays? I know I can do array([1e308],'d')*1e308 and get 1.#INF, but is there any concept of an unset other than using some special value? -- Robin Becker From hinsen@cnrs-orleans.fr Thu Jan 6 13:58:53 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Thu, 6 Jan 2000 14:58:53 +0100 Subject: [Matrix-SIG] extending an array In-Reply-To: <385AC679.FF1AE134@cs.utexas.edu> (message from pascucci on Fri, 17 Dec 1999 17:25:45 -0600) References: <385AC679.FF1AE134@cs.utexas.edu> Message-ID: <200001061358.OAA13484@chinon.cnrs-orleans.fr> > Is it possible to extend an array "in place"? No. > Reshape does not do that but resize creates always a copy. > Is there something that behaves like a C realloc? Even C realloc doesn't guarantee an extension in place; it might as well allocate a new memory block and copy the data. I suppose one could somehow provide access to the realloc operation in NumPy, but I am not sure that it makes much sense. 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 Thu Jan 6 13:59:11 2000 From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Thu, 6 Jan 2000 14:59:11 +0100 Subject: [Matrix-SIG] extending an array In-Reply-To: <385AC679.FF1AE134@cs.utexas.edu> (message from pascucci on Fri, 17 Dec 1999 17:25:45 -0600) References: <385AC679.FF1AE134@cs.utexas.edu> Message-ID: <200001061359.OAA13488@chinon.cnrs-orleans.fr> > Is it possible to extend an array "in place"? No. > Reshape does not do that but resize creates always a copy. > Is there something that behaves like a C realloc? Even C realloc doesn't guarantee an extension in place; it might as well allocate a new memory block and copy the data. I suppose one could somehow provide access to the realloc operation in NumPy, but I am not sure that it makes much sense. 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 Fri Jan 7 02:08:36 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Thu, 6 Jan 2000 20:08:36 -0600 (CST) Subject: [Matrix-SIG] Numerical Python update? Message-ID: Does anybody have any idea when the next Numerical Python update will be? It has been a long time since I have heard any news about this. Perhaps moving NumPy to an open development location like SourceForge would be a good idea so that anyone who is interested can keep on top of any changes? Thanks, Travis From da@ski.org Fri Jan 7 05:12:37 2000 From: da@ski.org (David Ascher) Date: Thu, 6 Jan 2000 21:12:37 -0800 Subject: [Matrix-SIG] Numerical Python update? References: Message-ID: <002701bf58cd$d185cc90$e655cfc0@ski.org> > Does anybody have any idea when the next Numerical Python update will be? > It has been a long time since I have heard any news about this. Perhaps > moving NumPy to an open development location like SourceForge would be a > good idea so that anyone who is interested can keep on top of any changes? I am hereby promising to do a release before IPC8. The release will basically be a backtrack from the extensionclass idea back to the architecture of release 12, but with the bug fixes in the current beta. In fact I'm going to get to work on it as soon as I figure out how to undo the damage I just did by installing Office2000... For future development, SourceForge might be a good idea. The problem however has not been lack of technical solutions but lack of time and volunteers. If you want to become more directly involved, I'm sure that can be arranged -- Talk to Paul DuBois about it. --david From dubois1@llnl.gov Fri Jan 7 15:05:38 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Fri, 7 Jan 2000 07:05:38 -0800 Subject: [Matrix-SIG] Numerical Python update? In-Reply-To: <002701bf58cd$d185cc90$e655cfc0@ski.org> Message-ID: I have been thinking lately that we have fallen into the Cathedral rather than the Bazaar and we need to get out of that mode, so Travis' letter is timely. We also have had a problem in that LLNL's new security regime has made it difficult, and I really do need to move the sources somewhere. I am ignorant of SourceForge. I am open to suggestions as to what to do after David cuts his release. From Oliphant.Travis@mayo.edu Sat Jan 8 21:58:33 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Sat, 8 Jan 2000 15:58:33 -0600 (CST) Subject: [Matrix-SIG] Numerical python on SourceForge? Message-ID: SourceForge is a community site run by VA Linux that provides CVS and web space to many open projects. http://sourceforge.net From the site: SourceForge is a free service to Open Source developers offering easy access to the best in CVS, mailing lists, bug tracking, message boards/forums, task management, site hosting, permanent file archival, full backups, and total web-based administration. I think it is an ideal site to allow community involvement in Numerical Python development. One of the outstanding issues that needs addressing quickly is how to integrate Numerical Python into the core. Guido has expressed enough interest that it would be a real shame not to get it in by Python 1.6 There are issues that need deciding however: * Will Python still retain other Numeric Types or will rank-0 arrays and Python Numeric objects become equivalent? * How will FFTpack and LAPACK get distributed if NumPy is now in the core? to name just a couple. It is straightforward to get an account on SourceForge and I for one would heartily support such a move. Travis From jhauser@ifm.uni-kiel.de Sat Jan 8 23:18:39 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Sun, 9 Jan 2000 00:18:39 +0100 (CET) Subject: [Matrix-SIG] Numerical python on SourceForge? In-Reply-To: References: Message-ID: <20000108231840.27054.qmail@lisboa.ifm.uni-kiel.de> If a restructuring of the development model is considered, I would like to raise some more questions. I agree with Travis that a decision regarding the inclusion of parts of NumPy into python should be made. Questions under this topic are: - What parts? Is it important to be compatible with jpython or viper? If nD-arrays go into the core, become they part of the language? - I think all the higher level stuff (fft, lapack) should remain an external module. - Can these modules be separated in a similar form to other modules. I mean, is it achievable to integrate e.g. the cephes module at the same level as Numeric? Or deintegrate e.g. fft on the other hand? - Should there be provisions made for the inclusion of new packages into the source tree? This inflicts with the progress of the distutils package. - Should the documentation be made compatible to the normal python module documentation? I would volunteer to reformat the documentation. - Are our needs fulfilled by sourceforge? I mean a first step would be a public CVS (anonymous checkout, restricted checkin) - Will gist be also part of this ``outsourcing''? - Can some parts be restructured? I think about the array_map from Travis and some code from the arrayfns module. - Is it possible to include also some more IO stuff at the ``basic'' module level? Stop! Just as a side note, our perl counterpart pdl is already at sourceforge :-) __Janko From Oliphant.Travis@mayo.edu Sun Jan 9 01:44:33 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Sat, 8 Jan 2000 19:44:33 -0600 (CST) Subject: [Matrix-SIG] Numerical python on SourceForge? In-Reply-To: <20000108231840.27054.qmail@lisboa.ifm.uni-kiel.de> Message-ID: > > - What parts? Is it important to be compatible with jpython or viper? > If nD-arrays go into the core, become they part of the language? My vote is to eliminate Python Numeric Types and make them all rank-0 arrays. This would possibly involve changing rank-0 arrays in Numeric so that don't have so much overhead. At the very least, arrays and ufuncs should become standard types and umath and multiarray in the standard library. > > - I think all the higher level stuff (fft, lapack) should remain an > external module. I agree. > > - Can these modules be separated in a similar form to other modules. I > mean, is it achievable to integrate e.g. the cephes module at the > same level as Numeric? Or deintegrate e.g. fft on the other hand? I don't understand what you mean. Are you talking about distributing cephes in a "standard" package or tying it more closely to Numeric. All of this depends on what goes in to Python itself and what stays a separate package. > > - Should there be provisions made for the inclusion of new packages > into the source tree? This inflicts with the progress of the > distutils package. I think a separate project could handle "new packages" and take the Python core and extend it with all kinds of Math goodies. > > - Should the documentation be made compatible to the normal python > module documentation? I would volunteer to reformat the > documentation. Yes, definitely if it is going to be part of the language. > > - Are our needs fulfilled by sourceforge? I mean a first step would > be a public CVS (anonymous checkout, restricted checkin) I'm not sure. Lot's of people seem to be using sourceforge and it sure looks nice. Certainly a CVS server would be a start with multiple people allowed to check changes in. > > - Will gist be also part of this ``outsourcing''? Gist is very nice but should definitely be an add-on, > > - Can some parts be restructured? I think about the array_map from > Travis and some code from the arrayfns module. What do you mean restructured? Do you mean that array_map and other functions from arrayfns should go into the Python core along with the basic modules? If so then I think that would be useful. > > - Is it possible to include also some more IO stuff at the ``basic'' > module level? I agree. If the NumPy type is in the Python core then we need something like numpyiomodule to get data into arrays quickly. > > Stop! Please don't, let's keep going and get the ball rolling again. > > Just as a side note, our perl counterpart pdl is already at > sourceforge :-) From skaller@maxtal.com.au Sun Jan 9 14:44:02 2000 From: skaller@maxtal.com.au (skaller) Date: Mon, 10 Jan 2000 01:44:02 +1100 Subject: [Matrix-SIG] Numerical python on SourceForge? References: <20000108231840.27054.qmail@lisboa.ifm.uni-kiel.de> Message-ID: <38789EB2.A6AFD121@maxtal.com.au> Janko Hauser wrote: > > If a restructuring of the development model is considered, I would > like to raise some more questions. I agree with Travis that a > decision regarding the inclusion of parts of NumPy into python should > be made. Questions under this topic are: > > - What parts? Is it important to be compatible with jpython or viper? > If nD-arrays go into the core, become they part of the language? There is _currently_ no risk at all of an incompatibility with Viper, since Viper does not even support the array module. Viper doesn't have any array handling at all. My problem is that NumPy doesn't _quite_ provide the technology required for Fish, which is the best array handling around. In particular, incorporation of Fish 1 style arrays into Viper, if it is possible, would provide it with the fastest array handling in the world. Fish generates, compiles, and executes optimal code for array algorithms. This is MUCH faster than any subroutine library could ever be. Fish is also suitable for both vectorisation and distributed parallel processing. So there is an opportunity, perhaps, to make Python/Viper the premier _industrial_ array processing language (outperforming normal usage of fortran and C). The style of Fish array handling integrated with Python would be to use Python syntax to write array algorithms, NOT subroutines for things like componentwise addition. The reason is that such code can be 'inlined' and optimised in a way that is impossible with 'opaque' routines. Of course, some standard routines like componentwise addition would be provided, and have the same syntax (probably) as used by NumPy. Fish currently uses an ML like front end, and it is not clear that a Python like syntax can be used instead. If NumPy has a problem, it is that the 'type' of arrays is deficient: it is NOT enough to support just some numeric cases and PyObject: it is _essential_ that the type be recursive -- that is, NumPy arrays be allowed as well. I'd like to see the 'type-code' used in NumPy be replaced by a proper object representing an array shape: floats, PyObjects, etc, are degenerate cases of this. I'm not sure this change can be made compatible with NumPy -- but it sound feasible [the existing type codes are a special encoding of degenerate cases of the more general types. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller voice: 61-2-9660-0850 From skaller@maxtal.com.au Sun Jan 9 15:42:04 2000 From: skaller@maxtal.com.au (skaller) Date: Mon, 10 Jan 2000 02:42:04 +1100 Subject: [Matrix-SIG] Numerical python on SourceForge? References: Message-ID: <3878AC4C.276F69D@maxtal.com.au> Travis Oliphant wrote: > > > > > - What parts? Is it important to be compatible with jpython or viper? > > If nD-arrays go into the core, become they part of the language? > > My vote is to eliminate Python Numeric Types and make them all rank-0 > arrays. This would possibly involve changing rank-0 arrays in Numeric so > that don't have so much overhead. No. This is wrong. From the Fish tutorial, where #= means 'same shape': --------- array shape combinators --------------- zerodim sh #= {:sh} undim {:int_shape } #= int_shape succdim 7 {6:sh} #= {7,6:sh} lendim {3,2:sh } = 3 preddim {3,2:sh } #= {2:sh} numdim {4,3:sh} = 2 --------------------------------------------------- Here, 'fill .. with' is used to initialise an array: --------------------------------------------------- >-|> let a3 = fill {:int_shape} with [5];; a3 : [int] #a3 = { : int_shape } defines a zero dimensional array. Just as a one dimensional array can be thought of as a line segment, or vector, a zero dimensional array can be construed a point with a single associated value. Such arrays should not be confused with the value of its unique entry (which has a different type) nor with the vector of length one, namely >-|> let a4 = fill {1:int_shape} with [5];; a4 : [int] #a4 = { 1 : int_shape } ----------------------------------------------------- PLEASE NOTE: a scalar is NOT a rank zero array. Fish provides a 'get' function to get the single value of a zero dimensional array. The point is: there is no need to identify python floats with a rank 0 array of float, in fact such identification is WRONG. There is a distinct difference between these two types, even though they are isomorphic (and also isomorphic to a rank 1 array of dimension 1) It is very important to get the shape calculus exactly right. The Fish type/shape system was developed by one of the worlds leading categories-in-computing theorists, Barry Jay. In particular, the fears that the overhead of rank-0 NumPy arrays are too high to identify them with Python numeric scalars are unfounded, because the identification itself is incorrect. The right way to do this is as follows: in Python, every 'scalar' type has a type object. We need a corresponding 'shape' object -- we can probably use the type object for this. For arrays, the shape must consist of a list of lists of integers and a scalar shape: mk_shape([[7,6],[3,4]],FloatType) or, mk_shape(([7,6],[3,4]], "F") # "F" for float or, alternatively, a list of integers and any shape: mk_shape([7,6], mk_shape([3,4], FloatShape)) Note that the second form would require scalar shape objects, whereas the first will work with ordinary type objects or perhaps a string code. ------------------------------------------ See http://www-staff.mcs.uts.edu.au/~cbj/FISh/ for more information on Fish and array shape calculus. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller voice: 61-2-9660-0850 From Oliphant.Travis@mayo.edu Mon Jan 10 04:43:34 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Sun, 9 Jan 2000 22:43:34 -0600 (CST) Subject: [Matrix-SIG] Numerical python on SourceForge? In-Reply-To: <38789EB2.A6AFD121@maxtal.com.au> Message-ID: > > There is _currently_ no risk at all of an incompatibility with > Viper, since Viper does not even support the array module. > Viper doesn't have any array handling at all. > > My problem is that NumPy doesn't _quite_ provide the > technology required for Fish, which is the best array handling around. > In particular, incorporation of Fish 1 style arrays into Viper, > if it is possible, would provide it with the fastest array > handling in the world. Best is a pretty subjective measure. Fish may be fast but is it convenient to use in an interactive setting? This is a more difficult balance to achieve. > > Fish generates, compiles, and executes optimal code for array > algorithms. This is MUCH faster than any subroutine library could > ever be. Fish is also suitable for both vectorisation and > distributed parallel processing. What does it mean to generate and compile optimal code? Everytime I do an array operation the compiler is called? How does that work in an interactive session. What kinds of cross-platform issues are there? > > So there is an opportunity, perhaps, to make Python/Viper > the premier _industrial_ array processing language (outperforming > normal usage of fortran and C). That sounds very good, but it would sound even better if it would not require drastic changes to the basic NumPy syntax. > > The style of Fish array handling integrated with Python > would be to use Python syntax to write array algorithms, > NOT subroutines for things like componentwise addition. > > The reason is that such code can be 'inlined' > and optimised in a way that is impossible with 'opaque' routines. > Of course, some standard routines like componentwise addition > would be provided, and have the same syntax (probably) as used > by NumPy. > > Fish currently uses an ML like front end, and it is not > clear that a Python like syntax can be used instead. > ML-like front ends have a hard time capturing the attention of many scientists and engineers for day to day Numeric work. I have not had much experience with them, but there is a reason that MATLAB is popular. > If NumPy has a problem, it is that the 'type' of > arrays is deficient: it is NOT enough to support just > some numeric cases and PyObject: it is _essential_ that > the type be recursive -- that is, NumPy arrays be allowed > as well. > NumPy arrays are allowed currently. They are just another object that can be placed in an array. What do you mean? > I'd like to see the 'type-code' used in NumPy > be replaced by a proper object representing an array shape: > floats, PyObjects, etc, are degenerate cases of this. > I'm not sure what you mean here either. Could you sketch your idea of what the C structure of the NumPy array should look like? > I'm not sure this change can be made compatible > with NumPy -- but it sound feasible [the existing type > codes are a special encoding of degenerate cases of the > more general types. Again an example would help me see what you mean. Travis From Oliphant.Travis@mayo.edu Mon Jan 10 05:03:18 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Sun, 9 Jan 2000 23:03:18 -0600 (CST) Subject: [Matrix-SIG] Numerical python on SourceForge? In-Reply-To: <3878AC4C.276F69D@maxtal.com.au> Message-ID: > > PLEASE NOTE: a scalar is NOT a rank zero array. > Fish provides a 'get' function to get the single value > of a zero dimensional array. > > The point is: there is no need to identify python > floats with a rank 0 array of float, in fact such identification > is WRONG. There is a distinct difference between > these two types, even though they are isomorphic > (and also isomorphic to a rank 1 array of dimension 1) > > It is very important to get the shape calculus exactly right. > The Fish type/shape system was developed by one of the worlds > leading categories-in-computing theorists, Barry Jay. Well, I appreciate your insight, but frankly I don't really care whether or not we are pedantic about the difference between a zero dimensional array and a scalar. It may be an important disctinction for certain algorithms; for me I do not see why it would make an algorithmic difference for the current syntax. What I do care about is that the current difference between rank-0 arrays and Python basic types and the practice of always returning rank-0 arrays as Python basic types means that it is an unnecessary pain to write code that keeps all data in single precision. I have a colleague I'm trying to convince to join us in the Python world who is very put off by this little inconvenience. I wonder how many others there are like him. Perhaps if arrays get into the core then even with the distinction between NumPy arrays and basic types there will not be the problems there are currently. > > The right way to do this is as follows: in Python, > every 'scalar' type has a type object. We need a corresponding > 'shape' object -- we can probably use the type object for this. > For arrays, the shape must consist of a list of lists of integers > and a scalar shape: > > mk_shape([[7,6],[3,4]],FloatType) > > or, > > mk_shape(([7,6],[3,4]], "F") # "F" for float > > or, alternatively, a list of integers and > any shape: > > mk_shape([7,6], mk_shape([3,4], FloatShape)) > I've looked at the FISh web pages and it does look impressive. I'm missing how it could by applied to an interactive environment with Python syntax? I know you've tried to explain FISh in the past. But I need a little more help understanding how it would work with Python. Thanks for your help, Travis From dubois1@llnl.gov Mon Jan 10 16:46:29 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Mon, 10 Jan 2000 08:46:29 -0800 Subject: [Matrix-SIG] LLNLDistribution13 In-Reply-To: Message-ID: Dear Matrix-SIGERS, ftp-icf.llnl.gov/pub/python/LLNLDistribution13.tgz is available for testing. David and I have tested it on Linux and Windows. Starting with this release, this distribution ONLY contains Numerical. It includes the PDF version of the documentation and the tutorial in directory "Doc". Here are my plans: 1. Move the sources to an open server. Recent and planned LLNL security measures have made LLNL a poor choice for locating open source software sources. I will do this as soon as I can, probably right after IPC8, where I can talk to some of you about the best way to do this. 2. In the next release, switch to using Distutils for building and installing. 3. Set up the sources so that all other packages (both LLNL and yours) are contributed separately. This will eventually include the ones now contained in the Numerical distribution itself. The reasons are that there are competing packages in some of these areas, and in fact I do not test or modify those packages so dragging them along with the core is misleading. The standards for packages will include documentation and Distutils requirements, so that the user has an absolutely cookbook "python setup.py build install" procedure for each package. 4. I do not intend to supply Windows installers. Once the sources are in an open spot, I expect a champion to step forward who will do this. Start now. The inertia of having to make Windows binary releases is a major cause for my slow releases. I want to switch to Bazaar mode. From turner@blueskystudios.com Mon Jan 10 17:08:29 2000 From: turner@blueskystudios.com (John A. Turner) Date: Mon, 10 Jan 2000 12:08:29 -0500 (EST) Subject: [Matrix-SIG] LLNLDistribution13 In-Reply-To: References: Message-ID: <14458.4621.490623.886653@waterloo.blueskystudios.com> >>>>> "PFD" == Paul F Dubois writes: PFD> 1. Move the sources to an open server. Recent and planned LLNL security PFD> measures have made LLNL a poor choice for locating open source PFD> software sources. I will do this as soon as I can, probably right PFD> after IPC8, where I can talk to some of you about the best way to PFD> do this. I realize that there are Python-oriented sites like Starship, but another excellent alternative is the site VA Linux recently set up for hosting open source projects, SourceForge: http://sourceforge.net/ In addition to just hosting a site and providing disk space, it can provide CVS access, bug-tracking system, etc. - full list of services here: http://sourceforge.net/docs/site/services.php Anyway, something to think about, maybe... -John Turner From dubois1@llnl.gov Mon Jan 10 17:12:33 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Mon, 10 Jan 2000 09:12:33 -0800 Subject: [Matrix-SIG] LLNLDistribution13 In-Reply-To: <14458.4621.490623.886653@waterloo.blueskystudios.com> Message-ID: I just failed in four attempts to set up the project at SourceForge. No doubt this is due to my dreaded use of Internet Explorer... Ah, well, I'll keep trying. -----Original Message----- From: John A. Turner [mailto:turner@blueskystudios.com] Sent: Monday, January 10, 2000 9:08 AM To: dubois1@llnl.gov Cc: matrix-sig@python.org; williams13@llnl.gov; guido@python.org Subject: Re: [Matrix-SIG] LLNLDistribution13 >>>>> "PFD" == Paul F Dubois writes: PFD> 1. Move the sources to an open server. Recent and planned LLNL security PFD> measures have made LLNL a poor choice for locating open source PFD> software sources. I will do this as soon as I can, probably right PFD> after IPC8, where I can talk to some of you about the best way to PFD> do this. I realize that there are Python-oriented sites like Starship, but another excellent alternative is the site VA Linux recently set up for hosting open source projects, SourceForge: http://sourceforge.net/ In addition to just hosting a site and providing disk space, it can provide CVS access, bug-tracking system, etc. - full list of services here: http://sourceforge.net/docs/site/services.php Anyway, something to think about, maybe... -John Turner From dubois1@llnl.gov Mon Jan 10 17:42:17 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Mon, 10 Jan 2000 09:42:17 -0800 Subject: [Matrix-SIG] File corrected Message-ID: I fixed the LLNLDistribution13.tgz at 9:35 a.m. PST The Include directory was omitted from the first tar. This turned out to be because my source control system had messed up. I'm trying to run it down an SSH tunnel because some unannounced security changes here blew me out of the water, and all sorts of weird things are happening...sorry for the mistake. It is very secure, though. Nobody can get my stuff, including me. As I said in a previous message, my attempt to set up the project on Source Forge has failed and I await their reply. (This was going to be an attempt to see if I liked it, not a final decision to do it that way). From pauldubois@home.com Mon Jan 10 19:31:40 2000 From: pauldubois@home.com (Paul F. Dubois) Date: Mon, 10 Jan 2000 11:31:40 -0800 Subject: [Matrix-SIG] This time for sure Message-ID: As Bullwinkle says, "This time for sure." At 11:30 a.m. PST 1/10/00 I tried to make a tar file that really does have the whole thing in it. If you are missing Include and/or Lib, refetch LLNLDistribution13.tgz from: ftp-icf.llnl.gov/pub/python I'm going to go hide under a rock for the rest of the day. From Barrett@stsci.edu Mon Jan 10 19:46:13 2000 From: Barrett@stsci.edu (Paul Barrett) Date: Mon, 10 Jan 2000 14:46:13 -0500 (EST) Subject: [Matrix-SIG] Numerical python on SourceForge? In-Reply-To: References: <38789EB2.A6AFD121@maxtal.com.au> Message-ID: <14458.7958.737985.342132@nem-srvr.stsci.edu> In the same vein of this discussion, I would also like to see several fundamental enhancements to Numerical python: 1) I've yet to become competent using the Object type in Numeric. I've seen the example in the documentation of creating an array of Objects by ingesting a list of tuples, but have yet to understand how to create such an array from a string or file, which appears to me to be a more common - and faster - way of ingesting the data. As a result I've implemented my own C-type called 'record' which is basically a generalization of the struct module to arrays. The record module enables quick and efficient access to sub-arrays and subfields of the record. The implementation - though pretty basic at this time - is very similar to Numeric. Instead of specifying a single type code, you specify a list of type codes. Therefore it would seem logical to merge my record module into Numeric, assuming Numeric cannot do what my module can. I'm hoping that this is what Max Skaller is suggesting. 2) The issue of up-casting of types has been mentioned in the Matrix SIG many moons ago. This is still a very important issue for me and others in the astronomical community. Astronomical images of 16 million pixels and larger are now routinely being taken. The analysis of such images - at least on a first look basis - are not very complicated, therefore simple array manipulation methods are quite satisfactory. Yet the problem that we have is storing and manipulating this images in memory. We're talking 128 MB of RAM for just storing a double precision 16M pixel image, when 64 MB or less will do. I see two solution here: 1) add an option to prevent up-casting, 2) memory mapping of these large arrays, or 3) both. I will likely have to implement my own Numeric module if this issue is not implemented satisfactorily. 3) Enable Numeric arrays to accept another array as an array argument. This would enable a more efficient implementation of scatter/gather behavior. This issue appears to be more of a Python language syntax issue that an implementation issue, I believe. I'm open to other suggestions on these issues as long as they give similar results and the syntax is not overly cumbersome. I've had little time to work on these issues in the past, but hope to find some time in the next few months to investigate these issues in greater detail. To reiterate, for Numerical Python to be useful to the astronomical community, these issues will have to be dealt with and the soon they are, the better. -- Paul -- Dr. Paul Barrett Space Telescope Science Institute Phone: 410-516-6714 ESS/DPT FAX: 410-516-8615 Baltimore, MD 21218 From skaller@maxtal.com.au Mon Jan 10 20:20:49 2000 From: skaller@maxtal.com.au (skaller) Date: Tue, 11 Jan 2000 07:20:49 +1100 Subject: [Matrix-SIG] Numerical python on SourceForge? References: <38789EB2.A6AFD121@maxtal.com.au> <14458.7958.737985.342132@nem-srvr.stsci.edu> Message-ID: <387A3F21.5E9B88AF@maxtal.com.au> Paul Barrett wrote: > Instead of specifying a > single type code, you specify a list of type codes. Therefore it > would seem logical to merge my record module into Numeric, assuming > Numeric cannot do what my module can. I'm hoping that this is what > Max Skaller is suggesting. No: I'm suggesting arrays be generalised to allow the type of element to be either a number or an array; more generally, _any_ data type. By using 'PyObjectType', this would make an array equivalent to a tuple, but this isn't really the intent, so much as making arrays of arrays of arrays of floats available (where _each_ array can separately be arbitrary rank) The reason for doing this is that by manipulating the shape of an array of arrays of float, we can decide where the 'data' sits, which affects how we can apply functions like 'map' to the arrays. Note that the _storage_ for an array of arrays of floats does NOT store any PyObjects: its just maps the shape onto a linear array of floats. (Same as NumPy does now). -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller download: ftp://ftp.cs.usyd.edu/au/jskaller voice: 61-2-9660-0850 From dubois1@llnl.gov Mon Jan 10 20:22:24 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Mon, 10 Jan 2000 12:22:24 -0800 Subject: [Matrix-SIG] thoughts about the future In-Reply-To: <14458.7958.737985.342132@nem-srvr.stsci.edu> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BF5B65.5A1AE600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There are two separate concepts and NumPy attempts to do both of them: 1. Provide an "array" object that can store a large number of items of one type in as small a space as possible. 2. Provide for rapid operations and fancy subscripting and shapes, etc. I believe (1) belongs in the Python core. I think they should be 1-D only with basic math operations. Both Python and C APIs would allow you to create such arrays and to create ones that do not "own" the memory in question, similar to the options in NumPy. Along with this the : notation would be allowed outside of square brackets, so that r= 3:1000:10 would be a "range" object. This allows these subscripts as function arguments, enabling Fortran-like syntax and many other interesting applications. It is a design question whether there is one array type with a variable data type or different array types. I think it is really a generic parameter to the class but Python lacks such a concept. One or more facilities can then be build on top of (1) that satisfy different needs. I'm convinced that no one design will ever satisfy everyone. Those who need blinding speed and no upcasting are unlikely to ever get along with the "safe and easy to use for my customers" group. But for a start we could reproduce the semantics we have now. An illustration of my reasoning is the number of "bug reports" I receive about the fact that NumPy crashes with this or that bad input. The original designer did not test for bad input in order not to compromise performance. Considering this from a Design by Contract perspective, most NumPy operators have strong preconditions. This would be fine except they aren't stated using assertions so there is no "debug mode". We should go through NumPy and add the assertions. Another illustration is the x[i:j] question: is this a copy or a reference? For non-speed users, the present "reference" semantics are terrible. But you can hide that in a (2) facility. For reference I attach a copy of a "missing value" class (not completely done yet) that illustrates the approach. There are also many schools of thought about shape facilities and subscripting in general. I have my own opinions and I'm sure each of you does too. I grant that it will be a pity to have more than one competing high-level package, but if all packages share the common core array as their storage mechanisms it ought not to be too bad to pass things back and forth. ------=_NextPart_000_0000_01BF5B65.5A1AE600 Content-Type: text/plain; name="MA.py" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="MA.py" """MA facility Copyright 1999 Regents of the University of California. Released for unlimited redistribution; see file Legal.htm in Numerical = distribution.""" __version__ =3D 2.0 #This version gives up on the Extension Class stuff import Numeric from Precision import * import string, types class MAError (Exception): def __init__ (self, args=3DNone): self.args =3D args def __str__(self): return str(self.args) __MaxElements =3D 300 #Maximum size for printing def setMaxElements (m): "Set the maximum # of elements for printing arrays. " global __MaxElements n =3D int(m) if n <=3D 0: raise ValueError, "setMaxElements requires positive = argument." __MaxElements =3D n def getMaxElements (): "Get the maximum # of elements for printing arrays. " global __MaxElements return __MaxElements def getmask (a): "Mask of values in a, if any; None otherwise." if isMA(a):=20 return a.mask() else:=20 return None def getmaskarray (a): "Mask of values in a, ones if none." m =3D getmask(a) if m is None: return Numeric.ones(shape(a)) else: return m def mask_or (m1, m2): "Logical or of the masks m1 and m2, treating None as false." if m1 is None: return m2 if m2 is None: return m1 return Numeric.logical_or(m1, m2) def filled (a, value =3D None): """ a as a Numeric array with any masked areas replaced by value" No data copied if no masked area and data is already an array. """ if isMA(a): return a.filled(value) else: return Numeric.array(a, copy=3D0) class masked_unary_operation: def __init__ (self, aufunc, fill=3D0): self.f =3D aufunc self.fill =3D fill def __call__ (self, a): m =3D getmask(a) d1 =3D filled(a) if m is None: return self.f(d1) else: return MA(self.f(d1), m) class masked_binary_operation: def __init__ (self, aufunc, fill=3D0): self.f =3D aufunc self.fill =3D fill def __call__ (self, a, b): d1 =3D filled(a, self.fill) d2 =3D filled(b, self.fill) m =3D mask_or(getmask(a), getmask(b)) if m is None: return self.f(d1, d2) else: return MA(self.f(d1,d2), m) def reduce (self, target, axis=3D0): m =3D getmask(target) if m is None: return self.f.reduce (target, axis) else: t =3D target.filled(self.fill) tr =3D self.f.reduce(t, axis) m =3D Numeric.logical_and.reduce(m, axis) return MA(tr, m) class comparison: "A comparison function that returns a plain mask after doing the = comparison" def __init__ (self, f, fill1, fill2): self.f =3D f self.fill1 =3D fill1 self.fill2 =3D fill2 def __call__ (self, a, b): return self.f(filled(a, self.fill1), filled(b, self.fill2)) # class MA =20 # the use of filled in the constructor # makes sure we don't get MA's in data or mask=20 # This prevents recursion # and we can assume these are array objects (or None for mask). # Note current implementation assumes mask is 1's and 0's # so that we can use Numeric.choose in filled. class MA: "Arrays with possibly masked values." default_real_fill_value =3D 0.0 default_complex_fill_value =3D 0.0 + 0.0j default_character_fill_value =3D ' ' default_integer_fill_value =3D 0 default_unsigned_integer_fill_value =3D 0 default_object_fill_value =3D None def __init__(self, data, mask=3DNone, **keys): """MA(data, mask=3DNone)""" self.__data =3D filled(data) if mask is None: self.__mask =3D None else: self.__mask =3D filled(mask, 1) def __getattr__ (self, name): if name =3D=3D 'shape': return self.get_shape() else: return self.__dict__[name] def __setattr__ (self, name, value): if name =3D=3D 'shape': self.set_shape(value) else: self.__dict__[name] =3D value def __str__(self): return str(self.filled()) def __repr__(self): if self.__mask is None: return "MA(" + repr(filled(self)) + ")" else: return "MA(" + repr(filled(self)) + ", \n " + \ repr(self.__mask) + ")" def __float__(self): return MA (float(self.filled(0.0)), self.__mask) def __int__(self): return MA(int(self.filled(0)), self.__mask) # Note copy semantics here differ from Numeric =20 def __getitem__(self, i):=20 m =3D self.__mask if m is None: return Numeric.array(self.__data[i]) else: return MA(Numeric.array(self.__data[i]), = Numeric.array(m[i])) def __getslice__(self, i, j):=20 m =3D self.__mask if m is None: return Numeric.array(self.__data[i:j]) else: return MA(Numeric.array(self.__data[i:j]), = Numeric.array(m[i:j])) # -------- def __setitem__(self, index, value): self.__data[index] =3D filled(value) self.__mask =3D mask_or(self.__mask, getmask(value)) =20 def __setslice__(self, i, j, value): self.__data[i:j] =3D filled(value) m =3D getmask(value) if m is not None: sm =3D getmaskarray(self) sm[i:j] =3D mask_or(sm[i:j], m) self.__mask =3D sm def __len__ (self): "Return total number of elements in array." return self.size() def __cmp__ (self, other): raise MAError, "Cannot use comparison operators on MA = instances." =20 def __abs__(self):=20 return masked_unary_operation(Numeric.absolute)(self) def __neg__(self):=20 return masked_unary_operation(Numeric.negative)(self) def __add__(self, other):=20 return masked_binary_operation(Numeric.add)(self, other) =20 __radd__ =3D __add__ def __sub__(self, other):=20 return masked_binary_operation(Numeric.subtract,0)(self, other) def __rsub__(self, other):=20 return masked_binary_operation(Numeric.subtract,0)(other, self) def __mul__(self, other):=20 return masked_binary_operation(Numeric.multiply,0)(self, other) =20 __rmul__ =3D __mul__ def __div__(self, other):=20 return divide(self, other) def __rdiv__(self, other):=20 return divide(other, self) def __pow__(self,other, third=3DNone):=20 if third is not None:=20 raise MAException, "3 arg power unspoorted" return masked_binary_operation(Numeric.power, 1)(self, other) def __sqrt__(self):=20 return masked_unary_operation(Numeric.sqrt,0)(self) def default_fill_value (self): "Function to calculate default fill value for an array." x =3D self.typecode() if x in typecodes['Float']: return MA.default_real_fill_value if x in typecodes['Integer']: return MA.default_integer_fill_value if x in typecodes['Complex']: return MA.default_complex_fill_value if x in typecodes['Character']: return MA.default_character_fill_value if x in typecodes['UnsignedInteger']: return Numeric.absolute(MA.default_integer_fill_value) else: return MA.default_object_fill_value def set_fill_value (self, v): "Set the fill value to v." self.fill_value =3D v def filled (self, value=3DNone): """ Self with masked data replaced by value. If value is None, self.fill_value used. self.default_fill_value () used if value is None. Not a copy if no masked data. Result is romised to be a Numeric.array. """ if self.__mask is None: return self.__data else: if value is None: if hasattr(self, 'fill_value'): v =3D self.fill_value else: v =3D self.default_fill_value () self.fill_value =3D v else: v =3D value return Numeric.choose(self.__mask, (self.__data, v)) def get_shape(self): "Return the tuple giving the current shape." return self.__data.shape def ids (self): """Return the ids of the data and mask areas""" return (id(self.__data), id(self.__mask)) def mask(self): "Return the data mask, or None." return self.__mask =20 def set_shape (self, *sizes): """shape(n, m, ...) sets the shape.""" self.__data.shape =3D sizes if self.__mask is not None: self.__mask.shape =3D sizes =20 def size (self, axis =3D None): "Number of elements in array, or in a particular axis." s =3D self.shape if axis is None: return reduce(Numeric.multiply, s, 1) else: return s[axis] =20 def typecode(self): return self.__data.typecode() # these are disgusting def is_contiguous (self): return self.data.is_contiguous() def byte_swapped(self): return self.data.byte_swapped() =20 def isMA (x): "Is x an instance of MA?" return isinstance(x, MA) def masked_array (data, masked_value, typecode=3DNone, copy=3D1, = atol=3D1.e-8, rtol=3D1.e-8, notest=3D0): """Create a masked array for numerical data; no mask unless = necessary or if notest !=3D 0 """ abs =3D Numeric.absolute d =3D Numeric.array(data, typecode=3Dtypecode, copy=3Dcopy) dm =3D Numeric.less(abs(d-masked_value), atol+rtol*abs(d)) if notest or Numeric.sometrue(Numeric.ravel(dm)): result =3D MA(d, dm) else: result =3D MA(d) result.set_fill_value(masked_value) return result =20 def masked_object (data, masked_value, copy=3D1): "Create a masked array of places where exactly equal to masked = value" dm =3D Numeric.equal(data, masked_value, copy=3Dcopy) return MA(data, dm) =20 def rank (a): "Get the rank of a" return len(shape(a)) =20 def shape (a): "Get the shape of a" if isMA (a): return a.get_shape() else: return Numeric.shape(a) def size (a, axis=3DNone): "Get the number of elements in a, or along a certain axis." if isMA (a): return a.size(axis) else: s =3D Numeric.shape(a) if axis is None: return reduce(Numeric.multiply, s, 1) else: return s[axis] def count (a, axis =3D None): "Count of the non-masked elements." =20 m =3D getmask(a) if m is None: return size(a, axis) else: n1 =3D size(a, axis) n2 =3D sum (m, axis) return n1 - n2 def sum (a, axis =3D None): "Sum of all elements, or along a certain axis" if axis is None: return Numeric.add.reduce(Numeric.ravel(filled(a, 0))) else: return Numeric.add.reduce(filled(a, 0), axis) =20 def product (a, axis =3D None): "Product of all elements, or along a certain axis." if axis is None: return Numeric.add.reduce(Numeric.ravel(filled(a, 0))) else: return Numeric.add.reduce(filled(a, 0), axis) def average(a, axis=3DNone): "Average of the nonmasked elements of a" c =3D 1.0 * count(a, axis) a =3D sum(a, axis)=20 return divide(a, c) =20 NewAxis =3D Numeric.NewAxis arange =3D Numeric.arange ones =3D Numeric.ones zeros =3D Numeric.zeros array =3D Numeric.array #minimum, maximum? #searchsorted? sqrt =3D masked_unary_operation(Numeric.sqrt, 0.0) sin =3D masked_unary_operation(Numeric.sin, 0.0) cos =3D masked_unary_operation(Numeric.cos, 0.0) absolute =3D masked_unary_operation(Numeric.absolute, 0) negative =3D masked_unary_operation(Numeric.negative, 0) absolute =3D masked_unary_operation(Numeric.absolute, 0) nonzero =3D masked_unary_operation(Numeric.nonzero, 0) add =3D masked_binary_operation(Numeric.add, 0) subtract =3D masked_binary_operation(Numeric.subtract, 0) multiply =3D masked_binary_operation(Numeric.multiply, 1) power =3D masked_binary_operation(Numeric.power, 1) sometrue =3D masked_unary_operation(Numeric.sometrue, 0) alltrue =3D masked_unary_operation(Numeric.alltrue, 1) # all these comparisons return false where masks are true =20 equal =3D comparison(Numeric.equal, 0, 1) not_equal =3D comparison(Numeric.not_equal, 0, 0) less_equal =3D comparison(Numeric.less_equal, 1, 0) greater_equal =3D comparison(Numeric.greater_equal, 0, 1) less =3D comparison(Numeric.less, 1, 0) greater =3D comparison(Numeric.greater, 0, 1) def choose (condition, t): "Shaped like condition, values t[0] where condition true, t[1] = otherwise" d =3D Numeric.choose(filled(condition,0), map(filled, t)) m =3D Numeric.choose(filled(condition,0), map(getmaskarray, t)) return MA(d, m) def where (condition, x, y): return choose(Numeric.not_equal(condition, 0), (y, x)) def reshape (a, newshape): "Copy of a with a new shape." m =3D getmask(a) d =3D Numeric.reshape(filled(a), newshape) if m is None: return d else: return MA(d, Numeric.reshape(m, newshape)) def ravel (a): "a as one-dimensional, may share data and mask" m =3D getmask(a) d =3D Numeric.ravel(filled(a)) =20 if m is None: return d else: return MA(d, Numeric.ravel(m)) def concatenate (somearrays, axis=3D0): "concatenate the arrays along the given axis" d =3D Numeric.concatenate(map(filled, somearrays), axis) dm =3D Numeric.concatenate(map(getmaskarray, somearrays), axis) return MA(d, dm) def take (a, indices, axis=3D0): m =3D getmask(a) d =3D filled(a) if m is None: return Numeric.take(d, indices, axis) else: return MA(Numeric.take(d, indices, axis),=20 Numeric.take(m, indices, axis)) =20 def divide (x, y): "a/b, masked where b was masked or zero" a =3D filled(x, 0) b =3D filled(y, 1) bad_elements =3D equal(b, 0) c_mask =3D mask_or(mask_or(getmask(a), getmask(b)), bad_elements) return MA(Numeric.divide(a, b), c_mask) =20 # This section is stolen from a post about how to limit array printing. def limitedArrayRepr(a, max_line_width =3D None, precision =3D None, = suppress_small =3D None): global __MaxElements s =3D a.shape elems =3D Numeric.multiply.reduce(s) if elems > __MaxElements: if len(s) > 1: return 'array (%s) , type =3D %s, has %d elements' % \ (string.join(map(str, s), ","), a.typecode(), elems) else: return Numeric.array2string (a[:__MaxElements], = max_line_width, precision, suppress_small,',',0) + \ ('\n + %d more elements' % (elems - __MaxElements)) else: return Numeric.array2string (a, max_line_width, precision,=20 suppress_small,',',0) # replace the default with a smarter function for huge arrays original_array_repr =3D Numeric.array_repr original_array_str =3D Numeric.array_str Numeric.array_repr =3D limitedArrayRepr Numeric.array_str =3D limitedArrayRepr # fixup multiarray, as well. import multiarray multiarray.set_string_function(limitedArrayRepr, 0) multiarray.set_string_function(limitedArrayRepr, 1) if __name__ =3D=3D '__main__': import MAtest ------=_NextPart_000_0000_01BF5B65.5A1AE600-- From skaller@maxtal.com.au Mon Jan 10 21:05:02 2000 From: skaller@maxtal.com.au (skaller) Date: Tue, 11 Jan 2000 08:05:02 +1100 Subject: [Matrix-SIG] thoughts about the future References: Message-ID: <387A497E.C314991F@maxtal.com.au> "Paul F. Dubois" wrote: > > There are two separate concepts and NumPy attempts to do both of them: > > 1. Provide an "array" object that can store a large number of items of one > type in as small a space as possible. > > 2. Provide for rapid operations and fancy subscripting and shapes, etc. Probably, this is right, but Python _already_ provides an array module for linear arrays of a particular type. -- 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 jhauser@ifm.uni-kiel.de Mon Jan 10 21:17:18 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Mon, 10 Jan 2000 22:17:18 +0100 (CET) Subject: [Matrix-SIG] thoughts about the future In-Reply-To: References: <14458.7958.737985.342132@nem-srvr.stsci.edu> Message-ID: <20000110211719.7911.qmail@lisboa.ifm.uni-kiel.de> --myGD1QTv+O Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Content-Description: message body text Regarding ``range objects''. Partly we have already such things with the slice object. So you can write: var=ones((50,10,20)) a=RangeObject[:30,0,:-10] var[a] It's written by Konrad Hinsen. I append the class which he calls ``indexing''. This needs to be extended if something like gathering is implemented. Despites his comment it does work with: [...],[:,3],[3,-3,...] __Janko --myGD1QTv+O Content-type: application/octet-stream Content-transfer-encoding: base64 Content-Disposition: attachment; filename="indexing.py" IyBBIG5pY2VyIHdheSB0byBidWlsZCB1cCBpbmRleCB0dXBsZXMgZm9yIGFycmF5cy4KIwoj IFlvdSBjYW4gZG8gYWxsIHRoaXMgd2l0aCBzbGljZSgpIHBsdXMgYSBmZXcgc3BlY2lhbCBv YmplY3RzLAojIGJ1dCB0aGVyZSdzIGEgbG90IHRvIHJlbWVtYmVyLiBUaGlzIHZlcnNpb24g aXMgc2ltcGxlciBiZWNhdXNlCiMgaXQgdXNlcyB0aGUgc3RhbmRhcmQgYXJyYXkgaW5kZXhp bmcgc3ludGF4LgojCiMgRm9yIGFueSBpbmRleCBjb21iaW5hdGlvbiwgaW5jbHVkaW5nIHNs aWNpbmcgYW5kIGF4aXMgaW5zZXJ0aW9uLAojIGFbaW5kaWNlc10gaXMgdGhlIHNhbWUgYXMg YVtpbmRleF9leHByZXNzaW9uW2luZGljZXNdXS4gSG93ZXZlciwKIyBpbmRleF9leHByZXNz aW9uW2luZGljZXNdIGNhbiBiZSB1c2VkIGFueXdoZXJlIGluIFB5dGhvbiBjb2RlCiMgYW5k IHJldHVybnMgYSB0dXBsZSBvZiBpbmRleGluZyBvYmplY3RzIHRoYXQgY2FuIGJlIHVzZWQg aW4gdGhlCiMgY29uc3RydWN0aW9uIG9mIGNvbXBsZXggaW5kZXggZXhwcmVzc2lvbnMuCiMK IyBTb2xlIHJlc3RyaWN0aW9uOiBTbGljZXMgbXVzdCBiZSBzcGVjaWZpZWQgaW4gdGhlIGRv dWJsZS1jb2xvbgojIGZvcm0sIGkuZS4gYVs6Ol0gaXMgYWxsb3dlZCwgd2hlcmVhcyBhWzpd IGlzIG5vdC4KIwojIFdyaXR0ZW4gYnkgS29ucmFkIEhpbnNlbiA8aGluc2VuQGlicy5pYnMu ZnI+CiMgbGFzdCByZXZpc2lvbjogMTk5Ni0xMS0yNQojCgpjbGFzcyBfaW5kZXhfZXhwcmVz c2lvbl9jbGFzczoKCiAgICBpbXBvcnQgc3lzCiAgICBtYXhpbnQgPSBzeXMubWF4aW50Cgog ICAgZGVmIF9fZ2V0aXRlbV9fKHNlbGYsIGl0ZW0pOgogICAgICAgIGlmIHR5cGUoaXRlbSkg IT0gdHlwZSgoKSk6CiAgICAgICAgICAgIHJldHVybiAoaXRlbSwpCiAgICAgICAgZWxzZToK ICAgICAgICAgICAgcmV0dXJuIGl0ZW0KCiAgICBkZWYgX19sZW5fXyhzZWxmKToKCXJldHVy biBzZWxmLm1heGludAoKICAgIGRlZiBfX2dldHNsaWNlX18oc2VsZiwgc3RhcnQsIHN0b3Ap OgoJaWYgc3RvcCA9PSBzZWxmLm1heGludDoKCSAgICBzdG9wID0gTm9uZQoJcmV0dXJuIHNl bGZbc3RhcnQ6c3RvcDpOb25lXQoKc2xfb3AgPSBfaW5kZXhfZXhwcmVzc2lvbl9jbGFzcygp Cg== --myGD1QTv+O-- From pauldubois@home.com Mon Jan 10 22:01:10 2000 From: pauldubois@home.com (Paul F. Dubois) Date: Mon, 10 Jan 2000 14:01:10 -0800 Subject: [Matrix-SIG] Release 14 Message-ID: ftp-icf.llnl.gov/pub/python/Numerical-14.tgz is available for download. This version is identical to 13 except that the installation procedure is changed to use Distutils. Thanks to the Distutils gang for the already-working setup.py file. No more versions are planned for today. (:->. Paul From skaller@maxtal.com.au Tue Jan 11 08:33:23 2000 From: skaller@maxtal.com.au (skaller) Date: Tue, 11 Jan 2000 19:33:23 +1100 Subject: [Matrix-SIG] Numerical python on SourceForge? References: Message-ID: <387AEAD3.DFE43D41@maxtal.com.au> Travis Oliphant wrote: > > It is very important to get the shape calculus exactly right. > > The Fish type/shape system was developed by one of the worlds > > leading categories-in-computing theorists, Barry Jay. > > Well, I appreciate your insight, but frankly I don't really care whether > or not we are pedantic about the difference between a zero dimensional > array and a scalar. > What I do care about is that the current difference between rank-0 arrays > and Python basic types and the practice of always returning rank-0 arrays > as Python basic types means that it is an unnecessary pain to write code > that keeps all data in single precision. So you DO care :-) > Perhaps if arrays get into the core then even with the distinction between > NumPy arrays and basic types there will not be the problems there are > currently. Well, arrays will get into the Viper core. The reason they're not available at the moment is precisely because I care a lot for numerical programming. So whatever Guido does, there _will_ be a pythonic numerical programming environment available: the issue for me at the moment is whether to just stick with NumPy as is, or go for the broke, and provide the best high performance system available. > I've looked at the FISh web pages and it does look impressive. I worked on Fish, and I'm impressed too. That doesn't happen very often :-) > I'm missing how it could by applied to an interactive environment with Python > syntax? I know you've tried to explain FISh in the past. But I need a > little more help understanding how it would work with Python. you are asking two questions, about interactivity, and about syntax. Interactivity is not a problem: for _small_ problems, Fish will be slower than even plain Python, but as the size of the problems grows, it will begin to shine. The existing Fish front end is already interactive, in fact, I did some work to make it more suitable for _batch_ processing :-) The syntax issue is _much_ harder: I do not know the answer. What Fish does is as follows: 1a) Parse the Fish language, and ML like syntax with Algol like semantics 2) Partially evaluate the resultant Abstract Syntax Tree, reducing Fish language terms to a special sublanguage called Turbot: this includes type and shape inference. 3) Translate the Turbot code into Fortran or C, compile it, and execute it. A large part of the work is done in the partial evaluator: it does things like function inlining (beta reduction). NumPy has various builtin operations which correspond in a fairly obvious way to loops, folds, maps, and other things which _could_ be written in Fish, so it seems possible to translate it into Fish terms, and submit them to partial evaluation: the hard bit is converting Python functions applied to NumPy arrays, nor the actual array handling. -- 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 robin@jessikat.demon.co.uk Tue Jan 11 13:39:04 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Tue, 11 Jan 2000 13:39:04 +0000 Subject: [Matrix-SIG] Numerical python on SourceForge? In-Reply-To: <387AEAD3.DFE43D41@maxtal.com.au> References: <387AEAD3.DFE43D41@maxtal.com.au> Message-ID: In article <387AEAD3.DFE43D41@maxtal.com.au>, skaller writes ... the idea of Python having to have a C/Fortran compiler sitting around to work is a bit disturbing. Doesn't Fish/Turbot have an idealised machine which could be built in C just once? If so python could compile/submit code for it. NumPy is just about good enough for my problems. Presumably a FishPy (?) extension could also be added. -- Robin Becker From hinsen@cnrs-orleans.fr Tue Jan 11 14:25:39 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 11 Jan 2000 15:25:39 +0100 Subject: [Matrix-SIG] File corrected In-Reply-To: References: Message-ID: <200001111425.PAA24139@chinon.cnrs-orleans.fr> > I fixed the LLNLDistribution13.tgz at 9:35 a.m. PST So which is now the most current NumPy version, LLNLDistribution13.tgz or Numerical-14.tgz? Both have a date stamp of Jan 10. As for the ongoing discussion about distribution strategies and inclusion of arrays in the Python distribution, I wonder if anyone knows Guido's opinion about this. After all, we can discuss forever what he should do, but in the end it doesn't matter... Perhaps the main problem we need to discuss before anything can become part of the Python disttribution is whether we are happy with NumPy as it is, or at least with some subset. It seems that almost everyone is unhappy about something, but we can't agree about what. Upcasting: A while ago there was a lengthy discussion about this, and there were some proposals that looked as if they could be acceptable to everyone. Has anyone ever tried implementing them? It doesn't seem worth continuing the discussion without some hands-on experience. Rank 0 arrays: There are various philosophies as to whether rank-0 arrays should be the same as scalars or not. NumPy has followed the APL tradition in which there is no difference, and I see no reason to change this. So if NumPy arrays become part of Python, it would be preferable to minimize any existing differences. This doesn't mean that the implementation should be the same; the array overhead is after all quite significant. But providing the basic array attributes (shape, real, etc.) for Python scalars would be enough to remove the distinction as seen by the Python programmer, and at the C extension level the need for unification is much less obvious. Another annoying difference, the different conventions for modulo calculations, should be fixed in NumPy in my opinion. Perhaps one could add a single-precision float scalar type to Python to increase compatibility even further. 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@cnrs-orleans.fr Tue Jan 11 14:27:38 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 11 Jan 2000 15:27:38 +0100 Subject: [Matrix-SIG] thoughts about the future In-Reply-To: <20000110211719.7911.qmail@lisboa.ifm.uni-kiel.de> (message from Janko Hauser on Mon, 10 Jan 2000 22:17:18 +0100 (CET)) References: <14458.7958.737985.342132@nem-srvr.stsci.edu> <20000110211719.7911.qmail@lisboa.ifm.uni-kiel.de> Message-ID: <200001111427.PAA24143@chinon.cnrs-orleans.fr> > Regarding ``range objects''. Partly we have already such things with > the slice object. So you can write: > > var=ones((50,10,20)) > a=RangeObject[:30,0,:-10] > > var[a] > > It's written by Konrad Hinsen. I append the class which he calls > ``indexing''. This needs to be extended if something like gathering is This module is also part of ScientificPython, available at http://starship.python.net/crew/hinsen/scientific.html 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 pauldubois@home.com Tue Jan 11 18:04:06 2000 From: pauldubois@home.com (Paul F. Dubois) Date: Tue, 11 Jan 2000 10:04:06 -0800 Subject: [Matrix-SIG] Pyfort-3.0 Message-ID: Pyfort 3.0, the Python-Fortran connection tool, is available at ftp://ftp-icf.llnl.gov/pub/python/Pyfort-3.0.tgz. Documentation is included. News: Pyfort uses Distutils (www.python.org/sigs/distutils-sig) both to install itself and to build and install extensions built with Pyfort. There are many new features to control the behavior of the tool, including provisions for optional automatic transposing, reversed-shape Fortran arrays, and valued scalars. A valued scalar is an integer argument to a Fortran routine that determines all or part of the shape of another argument. This fact can now be declared in the input. For example, if Fortran routine foo has arguments foo (n, x), where x is a real array of length n, you have the option to declare this as: subroutine foo (n, x) integer n = size(x) real x(n) end (size is the F90 intrinsic, and can take a second argument to indicate the dimension if x has more than one) Then the Python user would call foo as foo(x), and not need to specifiy the redundant information that n is x's length. Some persons do not want any of the features mentioned. They may rest assured that declaring all arguments intent(inout) will result in what some have called a "raw" interface. REFERENCE:

Pyfort 3.0 - Fortran / Python Connection Tool. (11-Jan-2000) From skaller@maxtal.com.au Tue Jan 11 20:04:42 2000 From: skaller@maxtal.com.au (skaller) Date: Wed, 12 Jan 2000 07:04:42 +1100 Subject: [Matrix-SIG] Numerical python on SourceForge? References: <387AEAD3.DFE43D41@maxtal.com.au> Message-ID: <387B8CDA.E8DEFD9@maxtal.com.au> Robin Becker wrote: > the idea of Python having to have a C/Fortran compiler sitting around to > work is a bit disturbing. Why? It is true it is an external tool, invoked by the shell, which is very sloppy linkage. But then, Python hooks the file system too, when importing modules. :-) > Doesn't Fish/Turbot have an idealised machine > which could be built in C just once? Sure: the idealised machine is you native hardware. -- 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 Oliphant.Travis@mayo.edu Wed Jan 12 18:17:11 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Wed, 12 Jan 2000 12:17:11 -0600 (CST) Subject: [Matrix-SIG] Altering NumPy in lieu of unifying Python scalars. In-Reply-To: Message-ID: Guido and others interested, Just a quick note to let you know that I started to implement a unified scalar object and got far enough to convince myself that it was possible to do without any real disruption, but then I started to realize that it may only have asthetic value. My intent was to have a correspondence between Python scalar types and NumPy array types, but this is a lot of extra code to handle the rarely used single-precision-scalar cases. NumPy rank-0 arrays currently do very well as single-precision-scalars --- they just have quite a bit of overhead. My colleague and I have decided instead to alter NumPy sufficiently to fix our biggest woes. If Paul likes these changes then he is free to add them to the main distribution. Otherwise, this is important enough to me and others in the community that a minor fork is justified. 1) We will change the behavior so that rank-0 NumPy are only converted to Python scalars with PyArray_Return if there is an exact correspondence in the precision with the current Python scalars. 2) We will fill in the slots in the PyNumberMethods table for the arrayobject corresponding to nb_int, nb_float, nb_long, nb_oct, and nb_hex, so that rank-0 arrays can be converted to Python scalars using the builtin functions int(), float(), long(), oct(), and hex() and at other places within Python where it checks to see if the type knows how to be an int. We just wanted to let you and others know our plans in case somebody has useful feedback or wants to offer their support. Thanks, Travis Oliphant From Oliphant.Travis@mayo.edu Wed Jan 12 19:49:57 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Wed, 12 Jan 2000 13:49:57 -0600 (CST) Subject: [Matrix-SIG] Patches for improved single precision handling in NumPy Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811840-820702757-947706597=:3782 Content-Type: TEXT/PLAIN; charset=US-ASCII For anyone interested I'm attaching a patch against Numerical-14 which changes NumPy to alleviate some of the difficulty with single precision work. I implemented the changes I proposed previously plus altered array_compare so that comparisons of rank-0 arrays work as expected. I've tested the change and it appears to work nicely. With this change, I can use single precision rank-0 arrays and not worry about operations with them returning double precision scalars automatically. The rank-0 scalars also act nicely in other contexts. If anyone has comments or suggestions, I'd appreciate them. Travis ---1463811840-820702757-947706597=:3782 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mypatch.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Patch against Numerical-14 for single precision improvement Content-Disposition: attachment; filename="mypatch.diff" ZGlmZiAtY3IgTnVtZXJpY2FsLTE0Lm9yaWcvU3JjL2FycmF5b2JqZWN0LmMg TnVtZXJpY2FsLTE0L1NyYy9hcnJheW9iamVjdC5jDQoqKiogTnVtZXJpY2Fs LTE0Lm9yaWcvU3JjL2FycmF5b2JqZWN0LmMJTW9uIEphbiAxMCAxNjo0NTow MyAyMDAwDQotLS0gTnVtZXJpY2FsLTE0L1NyYy9hcnJheW9iamVjdC5jCVdl ZCBKYW4gMTIgMTM6NDI6NDEgMjAwMA0KKioqKioqKioqKioqKioqDQoqKiog NDQ0LDQ1MSAqKioqDQogIAkJaWYgKG1wICE9IE5VTEwpIFB5X0RFQ1JFRiht cCk7DQogIAkJcmV0dXJuIE5VTEw7DQogIAl9DQohIAlpZiAobXAtPm5kID09 IDApIHsNCiEgCQlvcCA9IGFycmF5X2l0ZW0obXAsIDApOw0KICAJCVB5X0RF Q1JFRihtcCk7DQogIAkJcmV0dXJuIG9wOw0KICAJfSBlbHNlIHsNCi0tLSA0 NDQsNDUxIC0tLS0NCiAgCQlpZiAobXAgIT0gTlVMTCkgUHlfREVDUkVGKG1w KTsNCiAgCQlyZXR1cm4gTlVMTDsNCiAgCX0NCiEgCWlmIChtcC0+bmQgPT0g MCAmJiAobXAtPmRlc2NyLT50eXBlX251bSA9PSBQeUFycmF5X0xPTkcgfHwg bXAtPmRlc2NyLT50eXBlX251bSA9PSBQeUFycmF5X0RPVUJMRSB8fCBtcC0+ ZGVzY3ItPnR5cGVfbnVtID09IFB5QXJyYXlfQ0RPVUJMRSkpIHsNCiEgICAg ICAgIAkgICAgICAgIG9wID0gbXAtPmRlc2NyLT5nZXRpdGVtKG1wLT5kYXRh KTsNCiAgCQlQeV9ERUNSRUYobXApOw0KICAJCXJldHVybiBvcDsNCiAgCX0g ZWxzZSB7DQoqKioqKioqKioqKioqKioNCioqKiA5NzYsOTgxICoqKioNCi0t LSA5NzYsMTA5MiAtLS0tDQogIH0NCiAgDQogIA0KKyAvKiBtZXRob2RzIGFk ZGVkIGJ5IFRyYXZpcyBPbGlwaGFudCwgSmFuIDIwMDAgKi8NCisgc3RhdGlj IFB5T2JqZWN0ICphcnJheV9pbnQoUHlBcnJheU9iamVjdCAqdikgeyAgICAg ICAgDQorICAgICAgICAgUHlPYmplY3QgKnB2LCAqcHYyOw0KKyAgICAgICAg IGlmICh2LT5uZCAhPSAwKSB7DQorIAkgICAgICAgIFB5RXJyX1NldFN0cmlu ZyhQeUV4Y19UeXBlRXJyb3IsICJPbmx5IHJhbmstMCBhcnJheXMgY2FuIGJl IGNvbnZlcnRlZCB0byBQeXRob24gc2NhbGFycy4iKTsNCisgCQlyZXR1cm4g TlVMTDsNCisgCX0NCisgCXB2ID0gdi0+ZGVzY3ItPmdldGl0ZW0odi0+ZGF0 YSk7DQorIAlpZiAocHYgPT0gTlVMTCkgcmV0dXJuIE5VTEw7DQorIAlpZiAo cHYtPm9iX3R5cGUtPnRwX2FzX251bWJlciA9PSAwKSB7DQorIAkgICAgICAg IFB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3IsICJjYW5ub3QgY29u dmVydCB0byBhbiBpbnQsIHNjYWxhciBvYmplY3QgaXMgbm90IGEgbnVtYmVy LiIpOw0KKyAJCVB5X0RFQ1JFRihwdik7DQorICAgICAgICAgICAgICAgICBy ZXR1cm4gTlVMTDsNCisgCX0NCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNf bnVtYmVyLT5uYl9pbnQgPT0gMCkgew0KKyAJICAgICAgICBQeUVycl9TZXRT dHJpbmcoUHlFeGNfVHlwZUVycm9yLCAiZG9uJ3Qga25vdyBob3cgdG8gY29u dmVydCBzY2FsYXIgbnVtYmVyIHRvIGludCIpOw0KKyAJCVB5X0RFQ1JFRihw dik7DQorICAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsNCisgCX0NCisg DQorIAlwdjIgPSBwdi0+b2JfdHlwZS0+dHBfYXNfbnVtYmVyLT5uYl9pbnQo cHYpOw0KKyAJUHlfREVDUkVGKHB2KTsNCisgCXJldHVybiBwdjI7ICAgICAg ICANCisgfQ0KKyANCisgc3RhdGljIFB5T2JqZWN0ICphcnJheV9mbG9hdChQ eUFycmF5T2JqZWN0ICp2KSB7ICAgICAgICANCisgICAgICAgICBQeU9iamVj dCAqcHYsICpwdjI7DQorICAgICAgICAgaWYgKHYtPm5kICE9IDApIHsNCisg CSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJvciwgIm9u bHkgcmFuay0wIGFycmF5cyBjYW4gYmUgY29udmVydGVkIHRvIFB5dGhvbiBz Y2FsYXJzLiIpOw0KKyAJCXJldHVybiBOVUxMOw0KKyAJfQ0KKyAJcHYgPSB2 LT5kZXNjci0+Z2V0aXRlbSh2LT5kYXRhKTsNCisgCWlmIChwdiA9PSBOVUxM KSByZXR1cm4gTlVMTDsNCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNfbnVt YmVyID09IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhj X1R5cGVFcnJvciwgImNhbm5vdCBjb252ZXJ0IHRvIGFuIGludCwgc2NhbGFy IG9iamVjdCBpcyBub3QgYSBudW1iZXIuIik7DQorIAkJUHlfREVDUkVGKHB2 KTsNCisgICAgICAgICAgICAgICAgIHJldHVybiBOVUxMOw0KKyAJfQ0KKyAJ aWYgKHB2LT5vYl90eXBlLT50cF9hc19udW1iZXItPm5iX2Zsb2F0ID09IDAp IHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJv ciwgImRvbid0IGtub3cgaG93IHRvIGNvbnZlcnQgc2NhbGFyIG51bWJlciB0 byBmbG9hdCIpOw0KKyAJCVB5X0RFQ1JFRihwdik7DQorICAgICAgICAgICAg ICAgICByZXR1cm4gTlVMTDsNCisgCX0NCisgCXB2MiA9IHB2LT5vYl90eXBl LT50cF9hc19udW1iZXItPm5iX2Zsb2F0KHB2KTsNCisgCVB5X0RFQ1JFRihw dik7DQorIAlyZXR1cm4gcHYyOyAgICAgICAgDQorIH0NCisgDQorIHN0YXRp YyBQeU9iamVjdCAqYXJyYXlfbG9uZyhQeUFycmF5T2JqZWN0ICp2KSB7ICAg ICAgICANCisgICAgICAgICBQeU9iamVjdCAqcHYsICpwdjI7DQorICAgICAg ICAgaWYgKHYtPm5kICE9IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3Ry aW5nKFB5RXhjX1R5cGVFcnJvciwgIm9ubHkgcmFuay0wIGFycmF5cyBjYW4g YmUgY29udmVydGVkIHRvIFB5dGhvbiBzY2FsYXJzLiIpOw0KKyAJCXJldHVy biBOVUxMOw0KKyAJfQ0KKyAJcHYgPSB2LT5kZXNjci0+Z2V0aXRlbSh2LT5k YXRhKTsNCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNfbnVtYmVyID09IDAp IHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJv ciwgImNhbm5vdCBjb252ZXJ0IHRvIGFuIGludCwgc2NhbGFyIG9iamVjdCBp cyBub3QgYSBudW1iZXIuIik7DQorICAgICAgICAgICAgICAgICByZXR1cm4g TlVMTDsNCisgCX0NCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNfbnVtYmVy LT5uYl9sb25nID09IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5n KFB5RXhjX1R5cGVFcnJvciwgImRvbid0IGtub3cgaG93IHRvIGNvbnZlcnQg c2NhbGFyIG51bWJlciB0byBsb25nIik7DQorICAgICAgICAgICAgICAgICBy ZXR1cm4gTlVMTDsNCisgCX0NCisgCXB2MiA9IHB2LT5vYl90eXBlLT50cF9h c19udW1iZXItPm5iX2xvbmcocHYpOw0KKyAJUHlfREVDUkVGKHB2KTsNCisg CXJldHVybiBwdjI7ICAgICAgICANCisgfQ0KKyANCisgc3RhdGljIFB5T2Jq ZWN0ICphcnJheV9vY3QoUHlBcnJheU9iamVjdCAqdikgeyAgICAgICAgDQor ICAgICAgICAgUHlPYmplY3QgKnB2LCAqcHYyOw0KKyAgICAgICAgIGlmICh2 LT5uZCAhPSAwKSB7DQorIAkgICAgICAgIFB5RXJyX1NldFN0cmluZyhQeUV4 Y19UeXBlRXJyb3IsICJvbmx5IHJhbmstMCBhcnJheXMgY2FuIGJlIGNvbnZl cnRlZCB0byBQeXRob24gc2NhbGFycy4iKTsNCisgCQlyZXR1cm4gTlVMTDsN CisgCX0NCisgCXB2ID0gdi0+ZGVzY3ItPmdldGl0ZW0odi0+ZGF0YSk7DQor IAlpZiAocHYtPm9iX3R5cGUtPnRwX2FzX251bWJlciA9PSAwKSB7DQorIAkg ICAgICAgIFB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3IsICJjYW5u b3QgY29udmVydCB0byBhbiBpbnQsIHNjYWxhciBvYmplY3QgaXMgbm90IGEg bnVtYmVyLiIpOw0KKyAgICAgICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQor IAl9DQorIAlpZiAocHYtPm9iX3R5cGUtPnRwX2FzX251bWJlci0+bmJfb2N0 ID09IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5 cGVFcnJvciwgImRvbid0IGtub3cgaG93IHRvIGNvbnZlcnQgc2NhbGFyIG51 bWJlciB0byBvY3QiKTsNCisgICAgICAgICAgICAgICAgIHJldHVybiBOVUxM Ow0KKyAJfQ0KKyAJcHYyID0gcHYtPm9iX3R5cGUtPnRwX2FzX251bWJlci0+ bmJfb2N0KHB2KTsNCisgCVB5X0RFQ1JFRihwdik7DQorIAlyZXR1cm4gcHYy OyAgICAgICAgDQorIH0NCisgDQorIHN0YXRpYyBQeU9iamVjdCAqYXJyYXlf aGV4KFB5QXJyYXlPYmplY3QgKnYpIHsgICAgICAgIA0KKyAgICAgICAgIFB5 T2JqZWN0ICpwdiwgKnB2MjsNCisgICAgICAgICBpZiAodi0+bmQgIT0gMCkg ew0KKyAJICAgICAgICBQeUVycl9TZXRTdHJpbmcoUHlFeGNfVHlwZUVycm9y LCAib25seSByYW5rLTAgYXJyYXlzIGNhbiBiZSBjb252ZXJ0ZWQgdG8gUHl0 aG9uIHNjYWxhcnMuIik7DQorIAkJcmV0dXJuIE5VTEw7DQorIAl9DQorIAlw diA9IHYtPmRlc2NyLT5nZXRpdGVtKHYtPmRhdGEpOw0KKyAJaWYgKHB2LT5v Yl90eXBlLT50cF9hc19udW1iZXIgPT0gMCkgew0KKyAJICAgICAgICBQeUVy cl9TZXRTdHJpbmcoUHlFeGNfVHlwZUVycm9yLCAiY2Fubm90IGNvbnZlcnQg dG8gYW4gaW50LCBzY2FsYXIgb2JqZWN0IGlzIG5vdCBhIG51bWJlci4iKTsN CisgICAgICAgICAgICAgICAgIHJldHVybiBOVUxMOw0KKyAJfQ0KKyAJaWYg KHB2LT5vYl90eXBlLT50cF9hc19udW1iZXItPm5iX2hleCA9PSAwKSB7DQor IAkgICAgICAgIFB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3IsICJk b24ndCBrbm93IGhvdyB0byBjb252ZXJ0IHNjYWxhciBudW1iZXIgdG8gaGV4 Iik7DQorICAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsNCisgCX0NCisg CXB2MiA9IHB2LT5vYl90eXBlLT50cF9hc19udW1iZXItPm5iX2hleChwdik7 DQorIAlQeV9ERUNSRUYocHYpOw0KKyAJcmV0dXJuIHB2MjsgICAgICAgIA0K KyB9DQorIA0KKyAvKiBlbmQgb2YgbWV0aG9kcyBhZGRlZCBieSBUcmF2aXMg T2xpcGhhbnQgKi8NCisgDQorIA0KICBzdGF0aWMgUHlOdW1iZXJNZXRob2Rz IGFycmF5X2FzX251bWJlciA9IHsNCiAgCShiaW5hcnlmdW5jKWFycmF5X2Fk ZCwgLypuYl9hZGQqLw0KICAJKGJpbmFyeWZ1bmMpYXJyYXlfc3VidHJhY3Qs IC8qbmJfc3VidHJhY3QqLw0KKioqKioqKioqKioqKioqDQoqKiogOTk1LDEw MDUgKioqKg0KICAJKGJpbmFyeWZ1bmMpYXJyYXlfYml0d2lzZV94b3IsCQkv Km5iX3hvciovDQogIAkoYmluYXJ5ZnVuYylhcnJheV9iaXR3aXNlX29yLAkJ LypuYl9vciovDQogIAkoY29lcmNpb24pYXJyYXlfY29lcmNlLCAvKm5iX2Nv ZXJjZSovDQohIAkwLCAvKm5iX2ludCovDQohIAkwLCAvKm5iX2xvbmcqLw0K ISAJMCwgLypuYl9mbG9hdCovDQohIAkwLAkJLypuYl9vY3QqLw0KISAJMCwJ CS8qbmJfaGV4Ki8NCiAgfTsNCiAgDQogIHN0YXRpYyBQeVNlcXVlbmNlTWV0 aG9kcyBhcnJheV9hc19zZXF1ZW5jZSA9IHsNCi0tLSAxMTA2LDExMTYgLS0t LQ0KICAJKGJpbmFyeWZ1bmMpYXJyYXlfYml0d2lzZV94b3IsCQkvKm5iX3hv ciovDQogIAkoYmluYXJ5ZnVuYylhcnJheV9iaXR3aXNlX29yLAkJLypuYl9v ciovDQogIAkoY29lcmNpb24pYXJyYXlfY29lcmNlLCAvKm5iX2NvZXJjZSov DQohIAkodW5hcnlmdW5jKWFycmF5X2ludCwgLypuYl9pbnQqLw0KISAJKHVu YXJ5ZnVuYylhcnJheV9sb25nLCAvKm5iX2xvbmcqLw0KISAJKHVuYXJ5ZnVu YylhcnJheV9mbG9hdCwgLypuYl9mbG9hdCovDQohIAkodW5hcnlmdW5jKWFy cmF5X29jdCwJLypuYl9vY3QqLw0KISAJKHVuYXJ5ZnVuYylhcnJheV9oZXgs CS8qbmJfaGV4Ki8NCiAgfTsNCiAgDQogIHN0YXRpYyBQeVNlcXVlbmNlTWV0 aG9kcyBhcnJheV9hc19zZXF1ZW5jZSA9IHsNCioqKioqKioqKioqKioqKg0K KioqIDEzMTgsMTMyNyAqKioqDQogIAlyZXR1cm4gUHlBcnJheV9Db3B5KHNl bGYpOw0KICB9DQogIA0KICBpbnQgYXJyYXlfY29tcGFyZShQeUFycmF5T2Jq ZWN0ICpzZWxmLCBQeU9iamVjdCAqb3RoZXIpIHsNCiEgCVB5RXJyX1NldFN0 cmluZyhQeUV4Y19UeXBlRXJyb3IsDQohIAkJIkNvbXBhcmlzb24gb2YgbXVs dGlhcnJheSBvYmplY3RzIGlzIG5vdCBpbXBsZW1lbnRlZC4iKTsNCiEgCXJl dHVybiAtMTsNCiAgfQ0KICANCiAgDQotLS0gMTQyOSwxNDU3IC0tLS0NCiAg CXJldHVybiBQeUFycmF5X0NvcHkoc2VsZik7DQogIH0NCiAgDQorIA0KKyAv KiBDaGFuZ2VkIGJ5IFRyYXZpcyBPbGlwaGFudCBKYW4sIDIwMDAgKi8NCiAg aW50IGFycmF5X2NvbXBhcmUoUHlBcnJheU9iamVjdCAqc2VsZiwgUHlPYmpl Y3QgKm90aGVyKSB7DQohICAgICAgICAgUHlBcnJheU9iamVjdCAqYW90aGVy Ow0KISAgICAgICAgIFB5T2JqZWN0ICpvMSwgKm8yOw0KISAgICAgICAgIGlu dCB2YWwsIHJlc3VsdDsNCiEgICAgICAgICBhb3RoZXIgPSAoUHlBcnJheU9i amVjdCAqKW90aGVyOw0KISAgICAgICAgIGlmIChzZWxmLT5uZCAhPSAwIHx8 IGFvdGhlci0+bmQgIT0gMCkgew0KISAJICAgICAgICBQeUVycl9TZXRTdHJp bmcoUHlFeGNfVHlwZUVycm9yLA0KISAJCSAiQ29tcGFyaXNvbiBvZiBtdWx0 aWFycmF5IG9iamVjdHMgb3RoZXIgdGhhbiByYW5rLTAgYXJyYXlzIGlzIG5v dCBpbXBsZW1lbnRlZC4iKTsNCiEgCSAgICAgICAgcmV0dXJuIC0xOw0KISAJ fQ0KISAgICAgICAgIG8xID0gc2VsZi0+ZGVzY3ItPmdldGl0ZW0oc2VsZi0+ ZGF0YSk7DQohIAlvMiA9IGFvdGhlci0+ZGVzY3ItPmdldGl0ZW0oYW90aGVy LT5kYXRhKTsNCiEgCWlmIChvMSA9PSBOVUxMIHx8IG8yID09IE5VTEwpIHJl dHVybiAtMTsNCiEgICAgICAgICB2YWwgPSBQeU9iamVjdF9DbXAobzEsbzIs JnJlc3VsdCk7DQohIAlQeV9ERUNSRUYobzEpOw0KISAgICAgICAgIFB5X0RF Q1JFRihvMik7DQohICAgICAgICAgaWYgKHZhbCA8IDApIHsNCiEgCSAgUHlF cnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJvciwgIm9iamVjdHMgY2Fubm90 IGJlIGNvbXBhcmVkLiIpOw0KISAgICAgICAgICAgcmV0dXJuIC0xOw0KISAJ fQ0KISAJcmV0dXJuIHJlc3VsdDsNCiAgfQ0KICANCg== ---1463811840-820702757-947706597=:3782-- From Oliphant.Travis@mayo.edu Thu Jan 13 01:55:17 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Wed, 12 Jan 2000 19:55:17 -0600 (CST) Subject: [Matrix-SIG] New i386 and SRC RPM's for Numerical Python Version 14 Message-ID: This is just a quick note to announce the availability of RPM's for Numerical Python Version 14 at http://oliphant.netpedia.net In this release Gist and RNG have been separated out. I have applied some patches to the LLNL Version 14 Release which alleviate some of the single-precision difficulties and fix a segmentation fault bug. The patch is also available here: http://oliphant.netpedia.net/packages/Numerical-14.patch --Travis From hoel@germanlloyd.org Thu Jan 13 14:54:16 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Thu, 13 Jan 2000 15:54:16 +0100 Subject: [Matrix-SIG] pyfort for Windows NT? Message-ID: <387DE718.C15117C6@GermanLloyd.org> Hello, Has anyone made the neccessary changes to use pyfort under Windows NT? Cheers Berthold -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From hoel@germanlloyd.org Thu Jan 13 14:57:43 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Thu, 13 Jan 2000 15:57:43 +0100 Subject: [Matrix-SIG] small pyfort fix Message-ID: <387DE7E7.639AE4E7@GermanLloyd.org> Hello, There are really C compiler that reject newlines in string constants (which is correct IMHO). I changed the function "fixup" in "generator.py" of Pyfort3 to overcome problems resulting from this when Pyfort is generating doc strings: def fixup (acomment): "Fix the comment so it can be a C string literal." out = string.replace (acomment, '"', r'\"') out = string.join(string.split(out, "\n"), "\\n\\\n") return out Cheers Berthold (I accidentially send this to matrix-sig-admin@python.org before) -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From cgw@fnal.gov Thu Jan 13 22:34:00 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Thu, 13 Jan 2000 16:34:00 -0600 (CST) Subject: [Matrix-SIG] Numeric.__version__ Message-ID: <14462.21208.709591.811265@buffalo.fnal.gov> I just downloaded and installed the recently-announced Numerical-14.tgz and find that Numeric.__version__ and Numeric.__LLNLDistribution__ both say "11". From dubois1@llnl.gov Thu Jan 13 23:21:22 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Thu, 13 Jan 2000 15:21:22 -0800 Subject: [Matrix-SIG] Numeric.__version__ In-Reply-To: <14462.21208.709591.811265@buffalo.fnal.gov> Message-ID: Proves the folly of this sort of thing. Thanks for reporting it. -----Original Message----- From: matrix-sig-admin@python.org [mailto:matrix-sig-admin@python.org]On Behalf Of Charles G Waldman Sent: Thursday, January 13, 2000 2:34 PM To: matrix-sig@python.org Subject: [Matrix-SIG] Numeric.__version__ I just downloaded and installed the recently-announced Numerical-14.tgz and find that Numeric.__version__ and Numeric.__LLNLDistribution__ both say "11". _______________________________________________ Matrix-SIG maillist - Matrix-SIG@python.org http://www.python.org/mailman/listinfo/matrix-sig From da@ski.org Thu Jan 13 23:34:06 2000 From: da@ski.org (David Ascher) Date: Thu, 13 Jan 2000 15:34:06 -0800 Subject: [Matrix-SIG] Numeric.__version__ In-Reply-To: Message-ID: <000401bf5e1e$aed22260$c355cfc0@ski.org> > Proves the folly of this sort of thing. Thanks for reporting it. Any suggestion for how to help people identify the version? I'm not defending the wisdom of having it in a runtime file, but I think folks like to be able to find out from a binary installation what version they're using. --da From pauldubois@home.com Fri Jan 14 05:26:01 2000 From: pauldubois@home.com (Paul F. Dubois) Date: Thu, 13 Jan 2000 21:26:01 -0800 Subject: [Matrix-SIG] We gotta web site. Message-ID: Web site up with required logo. http://numpy.sourceforge.net From skaller@maxtal.com.au Fri Jan 14 14:48:38 2000 From: skaller@maxtal.com.au (skaller) Date: Sat, 15 Jan 2000 01:48:38 +1100 Subject: [Matrix-SIG] Numeric.__version__ References: <000401bf5e1e$aed22260$c355cfc0@ski.org> Message-ID: <387F3746.1FD543FC@maxtal.com.au> David Ascher wrote: > > > Proves the folly of this sort of thing. Thanks for reporting it. > > Any suggestion for how to help people identify the version? I'm not > defending the wisdom of having it in a runtime file, but I think folks like > to be able to find out from a binary installation what version they're > using. Sure: My suggestion is that this question be referred to the experts in the field: Dist-SIG. -- 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 jhauser@ifm.uni-kiel.de Fri Jan 14 19:25:05 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Fri, 14 Jan 2000 20:25:05 +0100 (CET) Subject: [Matrix-SIG] Anonymous co working? Message-ID: <20000114192505.18703.qmail@lisboa.ifm.uni-kiel.de> Is the anonymous checkout at sourceforge already working? Then I noted that there is a probably obsolete module numpy in the repository. __Janko From dubois1@llnl.gov Fri Jan 14 19:28:12 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Fri, 14 Jan 2000 11:28:12 -0800 Subject: [Matrix-SIG] Anonymous co working? In-Reply-To: <20000114192505.18703.qmail@lisboa.ifm.uni-kiel.de> Message-ID: Should be working. The numpy tree is empty. It was the result of a first attempt at following confusing directions. One I saw what it did I was able to do it right, but I am unclear how to blow numpy away. When I have control of the repository locally I just go remove the directory but I don't have that capability on SF. If anybody knows how, give a holler, please. It would be nice if I just RTFM but there are a lot of M's. I last used CVS about four years ago and I'm rusty. -----Original Message----- From: matrix-sig-admin@python.org [mailto:matrix-sig-admin@python.org]On Behalf Of Janko Hauser Sent: Friday, January 14, 2000 11:25 AM To: Matrix-Sig Subject: [Matrix-SIG] Anonymous co working? Is the anonymous checkout at sourceforge already working? Then I noted that there is a probably obsolete module numpy in the repository. __Janko _______________________________________________ Matrix-SIG maillist - Matrix-SIG@python.org http://www.python.org/mailman/listinfo/matrix-sig From acornet@emory.edu Sun Jan 16 00:30:17 2000 From: acornet@emory.edu (Ben Cornett) Date: Sat, 15 Jan 2000 16:30:17 -0800 Subject: [Matrix-SIG] Irix 6.5 build problems Message-ID: <38811119.86C5E023@emory.edu> Hello, I am trying to build Numeric on an SGI Octane running Irix 6.5.6m. I run 'python setup.py build install' as instructed in the 'README' and everthing appears to compile without problems. However, when I try to import Numeric I get a core dump. I would greatly appreciate any suggestions anyone can give me. Thanks, Best, Ben From acornet@emory.edu Sun Jan 16 02:09:43 2000 From: acornet@emory.edu (Ben Cornett) Date: Sat, 15 Jan 2000 18:09:43 -0800 Subject: [Matrix-SIG] Irix 6.5 build problems References: Message-ID: <38812867.A7ECE4AF@emory.edu> That did it. Many thanks, that would have taken me a good while to figure out on my own. Ben "Harrison, Robert J" wrote: > > Run python under the debugger and see where the > failure happens. If it is code to do with setting up complex > arithmetic, try compiling complexobject.c in the Python tree > without any optimization. This fixed the import problem for me. > > It's on the Python platform bugs list. > > Robert > > -----Original Message----- > From: Ben Cornett [mailto:acornet@emory.edu] > Sent: Saturday, January 15, 2000 4:30 PM > To: matrix-sig@python.org > Subject: [Matrix-SIG] Irix 6.5 build problems > > Hello, > > I am trying to build Numeric on an SGI Octane running Irix 6.5.6m. I run > 'python setup.py build install' as instructed in the 'README' and > everthing appears to compile without problems. However, when I try to > import Numeric I get a core dump. I would greatly appreciate any > suggestions anyone can give me. > Thanks, > > Best, > > Ben > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig From Oliphant.Travis@mayo.edu Sun Jan 16 05:56:57 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Sat, 15 Jan 2000 23:56:57 -0600 (CST) Subject: [Matrix-SIG] Proposal for further single-precision clean-up. Message-ID: Recently I submitted patches that in my view alleviate some of the difficulties encountered when working with single precision arrays. I am now submitting a proposal for immediate changes that could be made to Numerical Python to further improve single precision work. For the future I am in support of modifying Python so that scalars are the same as rank-0 arrays, but any move in that direction is certainly several months or even years away. Instead of waiting for something to happen, we should establish a consistent usage that allows single-precision work in Numerical Python to proceed. The problem has always been that Python does not define single-precision scalars. I suggest, that as far as NumPy is concerned, we define single-precision scalars to be the corresponding rank-0 array. This is the direction I was going with the recent patches to NumPy. I'm now proposing that we finish the job so that for any operation on a single-precision array that returns a scalar for which no Python scalar of equivalent precision exists, NumPy returns a rank-0 array. Some have expressed concerns that rank-0 arrays won't behave correctly as scalars and will therefore be useless as return values. Because of Python's abstract object interface, rank-0 arrays can be defined to act like Python scalars in nearly every way (the only exception I can think of right now is list indexing -- and that could be fixed in Python). Some have also objected that rank-0 arrays are not scalars so that equating them will cause confusion. I can respect those concerns but feel that in the current state of Numerical Python the association between rank-0 arrays and scalars is valid and useful. At its core, my proposal requires changes to the getitem function of single-precision types in arraytypes.c and then a careful checking to make sure that everytime that function is used, the following code accepts the philosophy that the returned objects are either rank-0 arrays or Python scalars of the corresponding precision. In my mind, this fix is not ideal, but I think it will help single-precision users and establish a practical consistency for the time being. I can fix the code and patch the source tree after receiving approval from Paul who will listen to the responses on this list. So, if you can think of example code that such a change would break, or if you agree with these changes please post to the list. Thanks, Travis From Oliphant.Travis@mayo.edu Sun Jan 16 06:48:29 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Sun, 16 Jan 2000 00:48:29 -0600 (CST) Subject: [Matrix-SIG] Proposal: Move array_map and array_set into NumPy core Message-ID: 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. Comments? Travis From ransom@cfa.harvard.edu Sun Jan 16 15:44:27 2000 From: ransom@cfa.harvard.edu (Scott M. Ransom) Date: Sun, 16 Jan 2000 15:44:27 +0000 Subject: [Matrix-SIG] Proposal for further single-precision clean-up. References: Message-ID: <3881E75B.B4380AFF@cfa.harvard.edu> Travis Oliphant wrote: > Instead of waiting for something to happen, we should establish a > consistent usage that allows single-precision work in Numerical Python to > proceed. The problem has always been that Python does not define > single-precision scalars. I suggest, that as far as NumPy is concerned, we > define single-precision scalars to be the corresponding rank-0 array. As an astronomer, I would love to increase my use of NumPy -- but have proceded very slowly due to the "single precision" problems. I often need to access _huge_ arrays of single precision floats (generated by Fortran or C code), and the upcasting to double is a killer for my appliations. Since I am not terribly familiar with the NumPy code base (and I'm sure that many on this list aren't either), I would like to request that someone more knowlegable please post a summary of the pros and cons for treating single precision scalars as rank-0 arrays (or as something different -- i.e. a new Python intrinsic). I am really interested to learn what the differences in functionality and performance would be when using the various different implementations on NumPy arrays -- using ufuncs, the Python math module, matrix operations, casting, etc. I am highly encouraged by the recent interest in moving NumPy forward, and with the correct changes, I think the user base among Scientists will increase dramatically. Thanks in advance, Scott -- Scott M. Ransom Phone: (781) 320-9867 Address: 75 Sanderson Ave. email: ransom@cfa.harvard.edu Dedham, MA 02026 PGP Fingerprint: D2 0E D0 10 CD 95 06 DA EF 78 FE 2B CB 3A D3 53 From Oliphant.Travis@mayo.edu Sun Jan 16 16:21:41 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Sun, 16 Jan 2000 10:21:41 -0600 (CST) Subject: [Matrix-SIG] Proposal for further single-precision clean-up. In-Reply-To: <3881E75B.B4380AFF@cfa.harvard.edu> Message-ID: > > As an astronomer, I would love to increase my use of NumPy -- but have > proceded very slowly due to the "single precision" problems. I often > need to access _huge_ arrays of single precision floats (generated by > Fortran or C code), and the upcasting to double is a killer for my > appliations. It would benefit me if you could post an explanation and/or examples of what you think the "single precision" problem is. I have been thinking of ways to improve the situation according to the difficulties, I've encountered in my own work, but it would be beneficial if others posted example code. With the latest changes to NumPy (Release 15.X) one can define single precision scalars as NumPy arrays of rank-0 and they will not be converted behind the scenes to double-precision Python scalars, somewhere along the line causing an upcast. The one problem remaining that I see (let me know if you see others), is that retrieving an element from a single precision array still returns a double-precision Python scalar. This would still cause upcasting. I think this could be fixed and is what I proposed to do in my previous post. Another idea I've tossed around with a colleague is to introduce the concept of passive casting. The idea is to introduce another flag that allows the user to specify that an array is passive in it's casting requirements. So, if a passive-casting array operates with an active-casting array, the active-casting array always determines the type. If two passive-casting arrays operate on each other, the normal rules apply and a passive-casting array is returned. The other piece that would make this useful is to make all Python scalars automatically passive-casting (since their precision cannot be specified). > > Since I am not terribly familiar with the NumPy code base (and I'm sure > that many on this list aren't either), I would like to request that > someone more knowlegable please post a summary of the pros and cons for > treating single precision scalars as rank-0 arrays (or as something > different -- i.e. a new Python intrinsic). Python allows you to define new types that behave in nearly all respects just like Python scalars. Much of C-code in Python is written so that if the C-routine expects say a Python integer it checks to see if the object is an integer and if not it checks to see if the object can act like an integer (i.e. it returns a Python Integer if you say in Python int(object)). There are a few places in the code where this is not followed and the code must have a Python integer (list indexing is an example --- I don't know why this couldn't be changed, however). Because Python does not itself define the concept of single-precision scalars, we can and should decide on a Numerical Python definition of them. Right now rank-0 arrays fit as a definition for single-precision scalars very well and with a few changes could be a consisten view throughout the current code. There is significant, unnecessary overhead for rank-0 arrays, however, that could be a practical argument for a separate scalar type that supports the concept of single-precision. This would probably also make some folks happy to separate the concepts of scalars and rank-0 arrays. Such a type could later become a unifying concept for all of Python's scalars (it would necessarily have more overhead than curent implementation of Integers though which may make it hard for Guido to buy into) But, defining a new type would mean more code---very easy to write code---but time consuming. This code would also increase the size of Numerical Python. I don't mind that but I'm not sure of others' opinions > > I am really interested to learn what the differences in functionality > and performance would be when using the various different > implementations on NumPy arrays -- using ufuncs, the Python math module, > matrix operations, casting, etc. Currently, all Python scalars are converted to rank-0 arrays before any operations are done in NumPy, so there are no real performance issues. The Python math module only works with Python scalars so you would have to convert any single-precision array to a Python scalar (using int(), float(), etc.) before using one of those). Of course the Python math module is faster for a scalar than ufuncs are for a scalar computation (there is more overhead for the ufunc). > I am highly encouraged by the recent interest in moving NumPy forward, > and with the correct changes, I think the user base among Scientists > will increase dramatically. I'm glad to hear that. I would like to see the user base increase, too. Travis From pearu@ioc.ee Sun Jan 16 16:48:22 2000 From: pearu@ioc.ee (Pearu Peterson) Date: Sun, 16 Jan 2000 18:48:22 +0200 (EET) Subject: [Matrix-SIG] Release 14 In-Reply-To: Message-ID: I just installed Numerical-14 and I noticed that the new installation procedure does not install arrayobject.h and other header files. I copied them by hand to the required place but shouldn't it be done by setup.py? Pearu On Mon, 10 Jan 2000, Paul F. Dubois wrote: > ftp-icf.llnl.gov/pub/python/Numerical-14.tgz is available for download. > > This version is identical to 13 except that the installation procedure is > changed to use Distutils. > Thanks to the Distutils gang for the already-working setup.py file. > > No more versions are planned for today. (:->. > > Paul > > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig > From pauldubois@home.com Sun Jan 16 20:43:53 2000 From: pauldubois@home.com (Paul F. Dubois) Date: Sun, 16 Jan 2000 12:43:53 -0800 Subject: [Matrix-SIG] Numerical Python Project Message-ID: The Numerical Python Project is in the process of establishing itself at SourceForge, http://numpy.sourceforge.net. To register as a user of SourceForge go to http://sourceforge.net. Use the Numerical Python webpage above to get to the Numerical Python Project page at SourceForge. On that page you will find links to current releases, the CVS repository, bug tracking facility, etc. We are just getting up and running but you can check out the sources using anonymous CVS by following directions given in the CVS link. (Note: unlike FTP, the anonymous password required is blank -- just use the Enter key. They say this but up above the lines that catch your eye). The project developers are David Ascher, Travis Oliphant, and myself. Once we are settled in we will entertain requests to become codevelopers. However, for now we would like to keep it simple. The remainder of the LLNL-distributed packages will be relocated as well during the next two months. The current web server, xfiles.llnl.gov, is both unstable and about to disappear behind a firewall. The ftp site ftp-icf.llnl.gov will be redirected to a new machine at that time. The situation now is: Numerical only is located at SourceForge; other packages haven't been updated and so the LLNLDistribution11.tgz file is the "latest" for those. Due to the new firewall plans, it is better not to try to distribute this software from LLNL itself, and by some miracle SourceForge has appeared in the nick of time and offers us a truly superior location. This switch does not represent any diminution of LLNL's participation or interest in the Python scene. Parties willing to make and install binary releases for Windows and Mac will be needed. For the moment, only source is available at the SourceForge site. From robin@jessikat.demon.co.uk Mon Jan 17 10:52:06 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Mon, 17 Jan 2000 10:52:06 +0000 Subject: [Matrix-SIG] Numerical Python Project In-Reply-To: References: Message-ID: In article , Paul F. Dubois writes >The Numerical Python Project is in the process of establishing itself at >SourceForge, http://numpy.sourceforge.net. > >To register as a user of SourceForge go to http://sourceforge.net. > >Use the Numerical Python webpage above to get to the Numerical Python >Project page at SourceForge. On that page you will find links to current ... I'm trying to build 15 with win32 vc++ 6.0 distutils 0.1.2 I get the following output which is messed up by my lack of a proper shell. The upshot is that it fails to find libpython15.lib which is obviously a unixism since I do have python15.lib in my libs area. Is this a Numerical setup error or is it in distutils? (Numerical-15.1) 1 % python setup.py build _numpymodule.c arrayobject.c ufuncobject.c LINK : fatal error LNK1181: cannot open input file "libpython15.lib" running build running build_py creating build creating build\lib copying Lib\ArrayPrinter.py -> build\lib copying Lib\FFT.py -> build\lib copying Lib\LinearAlgebra.py -> build\lib copying Lib\MLab.py -> build\lib copying Lib\Matrix.py -> build\lib copying Lib\Numeric.py -> build\lib copying Lib\Precision.py -> build\lib copying Lib\RandomArray.py -> build\lib copying Lib\UserArray.py -> build\lib running build_ext C:\PROGRA~1\MICROS~1\VC98\BIN\cl.exe /nologo -IC:\PYTHON\include\python1.5 -IC:\PYTHON\include - IInclude /c /FoSrc/_numpymodule.obj /TcSrc/_numpymodule.c C:\PROGRA~1\MICROS~1\VC98\BIN\cl.exe /nologo -IC:\PYTHON\include\python1.5 -IC:\PYTHON\include - IInclude /c /FoSrc/arrayobject.obj /TcSrc/arrayobject.c C:\PROGRA~1\MICROS~1\VC98\BIN\cl.exe /nologo -IC:\PYTHON\include\python1.5 -IC:\PYTHON\include - IInclude /c /FoSrc/ufuncobject.obj /TcSrc/ufuncobject.c creating build\platlib C:\PROGRA~1\MICROS~1\VC98\BIN\link.exe /DLL /nologo /LIBPATH:C:\PYTHON\libs libpython15.lib Src/_numpymodule.obj Src/arrayobject.obj Src/ufuncobject.obj /OUT:build\platlib\_numpy.dll /DEF:Src\_numpy.def Traceback (innermost last): File "setup.py", line 29, in ? ext_modules = [('_numpy', File "C:\PYTHON\distutils\core.py", line 96, in setup dist.run_commands () File "C:\PYTHON\distutils\core.py", line 442, in run_commands self.run_command (cmd) File "C:\PYTHON\distutils\core.py", line 491, in run_command cmd_obj.run () File "C:\PYTHON\distutils\command\build.py", line 52, in run self.run_peer ('build_ext') File "C:\PYTHON\distutils\core.py", line 802, in run_peer self.distribution.run_command (command) File "C:\PYTHON\distutils\core.py", line 491, in run_command cmd_obj.run () File "C:\PYTHON\distutils\command\build_ext.py", line 146, in run self.build_extensions (self.extensions) File "C:\PYTHON\distutils\command\build_ext.py", line 243, in build_extensions extra_postargs=extra_args) File "C:\PYTHON\distutils\msvccompiler.py", line 180, in link_shared_object self.spawn ( [ self.link ] + ld_args ) File "C:\PYTHON\distutils\ccompiler.py", line 421, in spawn spawn (cmd, verbose=self.verbose, dry_run=self.dry_run) File "C:\Python\distutils\spawn.py", line 37, in spawn _spawn_nt (cmd, search_path, verbose, dry_run) File "C:\Python\distutils\spawn.py", line 68, in _spawn_nt raise DistutilsExecError("command failed: %d" % rc) distutils.errors.DistutilsExecError: command failed: 1181 -- Robin Becker From robin@jessikat.demon.co.uk Mon Jan 17 11:35:55 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Mon, 17 Jan 2000 11:35:55 +0000 Subject: [Matrix-SIG] bugs in MSVCCompiler ? Message-ID: <6qBjnFAb6vg4Ewt2@jessikat.demon.co.uk> I've just found what appears to be a bug in 0.1.2 in the MSVCCompiler class. at line 267 the library_filename functions should look like def library_filename (self, libname): """Return the static library filename corresponding to the specified library name.""" return "%s%s" %( libname, self._static_lib_ext ) def shared_library_filename (self, libname): """Return the shared library filename corresponding to the specified library name.""" return "%s%s" %( libname, self._shared_lib_ext ) the original format strings were "lib%s%s" leading to errors such as trying to use libpython15.lib during the build. -- Robin Becker From robin@jessikat.demon.co.uk Mon Jan 17 11:49:29 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Mon, 17 Jan 2000 11:49:29 +0000 Subject: [Matrix-SIG] Numerical Python Project In-Reply-To: References: Message-ID: The 15.1 numpy.pdf file seems to be broken. -- Robin Becker From robin@jessikat.demon.co.uk Mon Jan 17 11:37:42 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Mon, 17 Jan 2000 11:37:42 +0000 Subject: [Matrix-SIG] Numerical Python Project In-Reply-To: References: Message-ID: <962iTAAG8vg4Ewts@jessikat.demon.co.uk> In article , Paul F. Dubois writes I have now found a bug in my version of distutils and after fixing have managed to build all the way through. What should I do to help the cause? -- Robin Becker From gward@cnri.reston.va.us Mon Jan 17 20:31:32 2000 From: gward@cnri.reston.va.us (Greg Ward) Date: Mon, 17 Jan 2000 15:31:32 -0500 Subject: [Matrix-SIG] Re: [Distutils] bugs in MSVCCompiler ? In-Reply-To: <6qBjnFAb6vg4Ewt2@jessikat.demon.co.uk>; from robin@jessikat.demon.co.uk on Mon, Jan 17, 2000 at 11:35:55AM +0000 References: <6qBjnFAb6vg4Ewt2@jessikat.demon.co.uk> Message-ID: <20000117153131.B9793@cnri.reston.va.us> On 17 January 2000, Robin Becker said: > I've just found what appears to be a bug in 0.1.2 in the MSVCCompiler > class. > > at line 267 the library_filename functions should look like > > def library_filename (self, libname): > """Return the static library filename corresponding to the > specified library name.""" > return "%s%s" %( libname, self._static_lib_ext ) > > def shared_library_filename (self, libname): > """Return the shared library filename corresponding to the > specified library name.""" > return "%s%s" %( libname, self._shared_lib_ext ) > > > the original format strings were "lib%s%s" leading to errors such as > trying to use libpython15.lib during the build. Yep, someone else already caught that -- fixed now. Greg From cgw@fnal.gov Mon Jan 17 23:15:33 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Mon, 17 Jan 2000 17:15:33 -0600 (CST) Subject: [Matrix-SIG] Bugfix for instantiation of type 'O' arrays Message-ID: <14467.41621.438874.379779@buffalo.fnal.gov> The bug: Python 1.5.2+ (#7, Jan 13 2000, 16:18:27) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Numeric import * >>> x=array(["abc","def","ghi"],'O') >>> x array([[abc , abc , abc ], [def , def , def ], [ghi , ghi , ghi ]],'O') >>> The fix: Index: Src/arrayobject.c =================================================================== RCS file: /cvsroot/numpy/Numerical/Src/arrayobject.c,v retrieving revision 1.2 diff -u -r1.2 arrayobject.c --- Src/arrayobject.c 2000/01/14 18:53:24 1.2 +++ Src/arrayobject.c 2000/01/17 23:10:33 @@ -1778,7 +1778,7 @@ PyErr_SetString(PyExc_ValueError,"expect source sequence"); return NULL; } - if (!((nd=discover_depth(s,99, type == PyArray_OBJECT)) > 0)) { + if (!((nd=discover_depth(s,99, type == PyArray_OBJECT || type == 'O')) > 0)) { PyErr_SetString(PyExc_ValueError, "invalid input sequence"); return NULL; } And, while we're at it, a typo fix: Index: README =================================================================== RCS file: /cvsroot/numpy/Numerical/README,v retrieving revision 1.1.1.1 diff -r1.1.1.1 README 56c56 < UserArray.py: changed indentation to all spaces for consistency. Fixed many bugs in UserArray.py and Matrix.py (Charles Wadman) --- > UserArray.py: changed indentation to all spaces for consistency. Fixed many bugs in UserArray.py and Matrix.py (Charles Waldman) From vanandel@ucar.edu Tue Jan 18 16:12:22 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Tue, 18 Jan 2000 09:12:22 -0700 Subject: [Matrix-SIG] Proposal for further single-precision clean-up. References: Message-ID: <388490E6.A6DCA53@atd.ucar.edu> Travis: you asked for examples of the 'single precision problem'. I am also working with huge arrays of single precision variables. I really can not afford the extra memory to have any intermediate calculations stored in double precision. I use statements like: summedOutput = SameSizeAs(weight[i],out)*out # from David Ascher's Numeric Python Tutorial def SameSizeAs(input, ref): return Numeric.array(input, ref.typecode()) This is pretty ugly and not at all intuitive. I'm glad that I can "get by" with this solution in the short term, but I certainly hope that Numeric Python can be changed to make this sort of kludge unnecessary. These sort of kludges are barrier to understanding the code and tends to prevent other scientists and programmers from adopting Numeric Python. Having passive casting be a (default) option for Numeric arrays sounds like a fine solution. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From Oliphant.Travis@mayo.edu Wed Jan 19 05:19:17 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Tue, 18 Jan 2000 23:19:17 -0600 (CST) Subject: [Matrix-SIG] I have working code that implements active-casting concept. Message-ID: I'm pleased to relate that I've been able to successfully implement the active-casting concept briefly discussed in a previous post, using the current Numerical Python. Preliminary testing shows it to work quite well and seems to "remove the single-precision problem." if used. I can patch the current tree as soon as I receive approval from Paul Dubois, but he will likely want to hear opinions from this list, so speak up if you hate the idea or love the idea. If no-one responds I will assume that means a show of favor :-) Here is the idea that I implemented: Every array has an active attribute that defaults to 0, but can be set in Python to 1 (if approved I would change code so the flag could be set as a keyword to array()). 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. Example: a = array([1,2,3,4],'f') b = a*4 # default casting rules make b double a.active = 1 c = a*4 # now a governs the casting and c is float The changes are not extensive, and should not break any old code, so the only real question is does this provide a suitable fix? Comments, critiques are welcome, Travis From rlw@stsci.edu Wed Jan 19 14:29:56 2000 From: rlw@stsci.edu (Rick White) Date: Wed, 19 Jan 2000 09:29:56 -0500 (EST) Subject: [Matrix-SIG] I have working code that implements active-casting concept. Message-ID: <200001191429.JAA09201@sundog.stsci.edu> Travis Oliphant writes: >I'm pleased to relate that I've been able to successfully implement the >active-casting concept briefly discussed in a previous post, using the >current Numerical Python. Preliminary testing shows it to work quite well >and seems to "remove the single-precision problem." if used. > >I can patch the current tree as soon as I receive approval from Paul >Dubois, but he will likely want to hear opinions from this list, so speak >up if you hate the idea or love the idea. If no-one responds I will >assume that means a show of favor :-) I think this is great -- I'm delighted to see Travis moving this forward! For my work, at least, his proposal will make Numeric much more useful. If I could add one thing, it would be nice to have some standard convenience functions (in Numeric.py) for creating active arrays. Certainly it is not a big deal, but I'm sure people that create active arrays will write their own such functions, so we might as well standardize them. Travis's changes (including moving array_set into the Numeric module, etc.) are big steps toward removing the major shortcomings of Numeric for our work (astronomical data analysis and image processing). Rick ---- Richard L. White rlw@stsci.edu http://sundog.stsci.edu/rick/ Space Telescope Science Institute Baltimore, MD From ransom@cfa.harvard.edu Wed Jan 19 14:53:06 2000 From: ransom@cfa.harvard.edu (Scott M. Ransom) Date: Wed, 19 Jan 2000 14:53:06 +0000 Subject: [Matrix-SIG] I have working code that implements active-casting concept. References: <200001191429.JAA09201@sundog.stsci.edu> Message-ID: <3885CFD2.C63F056A@cfa.harvard.edu> Rick White wrote: > > Travis's changes (including moving array_set into the Numeric module, > etc.) are big steps toward removing the major shortcomings of Numeric > for our work (astronomical data analysis and image processing). Hear! Hear! I completely agree. And I would like to thank Travis for stepping up to the plate and making the changes. With these changes, I will almost certainly become a more active member of the NumPy community -- and will attempt to spread the NumPy gospel among my astronomer colleagues. (Down with IDL!) As for a request for particular "single precision problems", I think Travis' current changes have addressed them completely (at least in my case). The main problem came from passing single precision arrays to/from NumPy from/to C (or Fortran) library functions. While this was certainly possible in the past, it became a royal pain if you wanted to manipulate these arrays in Python before or after calling the library functions -- the arrays were up-cast to double (I got around this before by writing a simple C function to downcast double precision NumPy arrays to single precision). Hopefully this is now a problem of the past. Thanks again Travis, Scott -- Scott M. Ransom Address: Harvard-Smithsonian CfA Phone: (617) 495-4142 60 Garden St. MS 10 email: ransom@cfa.harvard.edu Cambridge, MA 02138 PGP Fingerprint: D2 0E D0 10 CD 95 06 DA EF 78 FE 2B CB 3A D3 53 From Oliphant.Travis@mayo.edu Wed Jan 19 17:21:58 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Wed, 19 Jan 2000 11:21:58 -0600 (CST) Subject: [Matrix-SIG] Active arrays Message-ID: If active arrays were to become part of Numerical Python, I've been thinking of a couple of ways to make them easy to use. Of course there is the attribute setting approach as explained before. I've thought of two other possibilities: (1) An attribute that returns an active version of the array (pointing to the same data) so that (for example) b.asactive returns a reference to the data in b as an active array. (2) An argument to the general array() command along with another command, e.g. activearray() which sets this argument. One final request: If someone as a better idea as to what to call this property instead of active, I'm open to suggestions. Thanks, Travis From hinsen@cnrs-orleans.fr Wed Jan 19 18:05:57 2000 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Wed, 19 Jan 2000 19:05:57 +0100 Subject: [Matrix-SIG] I have working code that implements active-casting concept. In-Reply-To: (message from Travis Oliphant on Tue, 18 Jan 2000 23:19:17 -0600 (CST)) References: Message-ID: <200001191805.TAA27409@chinon.cnrs-orleans.fr> > I can patch the current tree as soon as I receive approval from Paul > Dubois, but he will likely want to hear opinions from this list, so speak > up if you hate the idea or love the idea. If no-one responds I will > assume that means a show of favor :-) It definitely sounds as if it would 1) solve the problems 2) not cause problems for those who had none before. I suggest you prepare a beta release that will let everyone interested test the idea and the implementation before inclusion in an "official" release. 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 n8gray@earthlink.net Wed Jan 19 18:40:24 2000 From: n8gray@earthlink.net (Nathaniel Gray) Date: Wed, 19 Jan 2000 10:40:24 -0800 Subject: [Matrix-SIG] Active arrays References: Message-ID: <38860518.DEF74DFC@earthlink.net> Travis Oliphant wrote: > > One final request: If someone as a better idea as to what to call this > property instead of active, I'm open to suggestions. > It would be nice to see something a bit more descriptive than 'active', although I can't think of anything better off the top of my head. Since the issue at hand (I believe) is controlling precision, something along the lines of 'precise' or 'strongPrecision' would be more informative. Maybe 'strongCasting' would be better, since casting is the process being controlled. In any case, I would like to suggest that some thought be given to the name -- there are already too many 'active' doodads in computing today. -- Nathaniel A. Gray -- "But the sun is going down!" "No, no, you're all confused. The horizon is moving up." -The Firesign Theatre -- PGP Key: http://certserver.pgp.com:11371/pks/lookup?op=get&search=0x95345747 For PGP: http://www.pgpi.com/ From minxu@scisun.sci.ccny.cuny.edu Wed Jan 19 19:23:41 2000 From: minxu@scisun.sci.ccny.cuny.edu (Min Xu) Date: Wed, 19 Jan 2000 14:23:41 -0500 (EST) Subject: [Matrix-SIG] Active arrays Message-ID: <200001191923.OAA21391@scisun.sci.ccny.cuny.edu> Hi, Is it better to call as: stick? We have: a.stick=1 b = a.asstick() c = stick(a) etc. Min Xu From n8gray@earthlink.net Wed Jan 19 19:30:53 2000 From: n8gray@earthlink.net (Nathaniel Gray) Date: Wed, 19 Jan 2000 11:30:53 -0800 Subject: [Matrix-SIG] Active arrays References: <200001191923.OAA21391@scisun.sci.ccny.cuny.edu> Message-ID: <388610ED.4B1858D8@earthlink.net> Min Xu wrote: > > Hi, > > Is it better to call as: stick? > Maybe 'sticky' or 'stickyCasting'. -- Nathaniel A. Gray -- "But the sun is going down!" "No, no, you're all confused. The horizon is moving up." -The Firesign Theatre -- PGP Key: http://certserver.pgp.com:11371/pks/lookup?op=get&search=0x95345747 For PGP: http://www.pgpi.com/ From da@ski.org Wed Jan 19 21:20:31 2000 From: da@ski.org (David Ascher) Date: Wed, 19 Jan 2000 13:20:31 -0800 Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: Message-ID: <003e01bf62c3$041f7b20$c355cfc0@ski.org> > > Never tried DocBook. > > > > Me neither, but lots of people use it. It is SGML at it's core, though. As I'm sure Travis knows but maybe Paul and others don't, Docbook is an XML/SGML markup, it's not an editor. I would hate to have to write tables with it. Serious writing w/ docbook requires a serious SGML/XML editor, although I suppose most users are just using emacs. I also suspect that DocBook is overkill for NumPy doc, if it's overkill for Python's main doc (in the opinion of Fred Drake, IIRC). > So what is it about Frame that keeps people from munging the basic > structure? It is hard to write documentation with multiple people > involved using a binary-only file. Aren't the problems you encountered > with LaTeX the same as those encountered with any group alteration of a > source? The same thing could happen with the C and Python code, too. LaTeX allows people to define macros and makes writers think like programmers. Bad idea. =) Many many folks don't know LaTeX but would be able to pick up a WYSIWYG editor easily. > I'm not convinced that LaTeX or DocBook wouldn't be a more useful group > documentation format. I use LaTeX an awful lot, and really like it. > Admitedly, the only multiple-author writing I've done is a paper where we > both knew and loved LaTeX. It worked great :-) I refuse to use LaTeX. Can't even justify why, it's a gut reaction after writing too many papers, a several-hundred page dissertation with it, spending waaaayy too many hours debugging poorly written LaTeX macros, fussing with DVI, PS, EPS, bounding boxes, BibTeX, fussy installations, missing fonts, bad HTML conversion, etc. That said, I don't like Frame on the PC either, after having written the current document. The UI was designed for the mac, and it works much better on the mac (I've typeset two significant books with very complex tagging and hundreds of plates on the Mac about 4 years ago, and it was far easier than producing the NumPy doc). As it stands FrameMaker's UI violates many of the assumptions of the average Windows user (I can't remember what keystroke sequence that I use all the time in other software causes a line to be deleted w/o any possibility to recover) Overall I think that the state of the world is pretty rotten when it comes to collaborative authorship outside of the world of Microsoft, which I realize we can't use. DocBook or other XML/SGML markup is probably the way to go, but I'm still quite frustrated with the authoring tools. Whenever I have to match tags I feel like i'm back on the IBM VM/CMS machine on a 3278 terminal. There's a *reason* we have megapixel displays! There's *a point* to the megabytes of memory being used by graphics subsystems! There's *value* in the decades of work in user interfaces. There's *truth* to the feeling my mom has that the Mac is easier to use than Unix. . Sorry, I had to get that off my chest. Finally, there's StarOffice, but it seemed quite immature the last time I checked. It is available free for Unix and Windows. http://www.sun.com/staroffice/ I propose that this discussion be shelved until Developer Day at the conference, and that we figure out in the DOC-SIG section what Python's going to do for its core doc, and follow along. Synergy. --david From KRodgers@ryanaero.com Wed Jan 19 21:35:21 2000 From: KRodgers@ryanaero.com (Rodgers, Kevin) Date: Wed, 19 Jan 2000 13:35:21 -0800 Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) Message-ID: <0D8C1A50C283D311ABB800508B612E5354B334@ryanaero.com> David Ascher wrote: [deleted] >sequence that I use all the time in other software causes a line to be >deleted w/o any possibility to recover) Overall I think that the state of >the world is pretty rotten when it comes to collaborative authorship outside >of the world of Microsoft, which I realize we can't use. Far and away the best tool I've ever used for this sort of thing is Interleaf. It was designed from the ground up to be an environment for production of long, structured documents by many authors collaborating. It works on Windows and Unix (I don't know about Mac). It is pretty expensive, though. True story: my former company was putting together a technical proposal in 1996, using Word. They had lots of problems, and called up Microsoft. M$ said something along the lines of, "You idiots, Word wasn't intended to do large, structured documents! Use Interleaf, or something like that!" I suspect one of the main points against FrameMaker (and Interleaf, Word, etc) is that they COST MONEY. I tend to agree that it's kinda icky to use expensive proprietary tools to document an open source collaborative effort (the Python Reference Manual is a different story, since Guido is more or less solely responsible for that). But I don't have any solutions either. Since I won't be at the Conference, I'll be looking forward to anything that materializes there. Kevin Rodgers krodgers@ryanaero.com From Oliphant.Travis@mayo.edu Wed Jan 19 21:38:17 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Wed, 19 Jan 2000 15:38:17 -0600 (CST) Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org> Message-ID: > As I'm sure Travis knows but maybe Paul and others don't, Docbook is an > XML/SGML markup, it's not an editor. I would hate to have to write tables > with it. Serious writing w/ docbook requires a serious SGML/XML editor, > although I suppose most users are just using emacs. I also suspect that > DocBook is overkill for NumPy doc, if it's overkill for Python's main doc > (in the opinion of Fred Drake, IIRC). > Probably, true, but what is Fred using for Python's documentation :-)? > > LaTeX allows people to define macros and makes writers think like > programmers. Bad idea. =) Many many folks don't know LaTeX but would be > able to pick up a WYSIWYG editor easily. > Not necessarily. You don't have to write macros. In fact, I rarely do. Actually, I would suggest trying LyX (although it probably doesn't run on the MaC). I use it constantly and I've really grown to like it. It is a WYSIWYM (What you see is what you mean) editor where you enter text in a format that looks a lot like it will print --- it just doesn't try to perfectly typeset as you go. It is very easy to pick up, and entering math is beautiful. I'm actually able to derive complicated expressions using this tool which has saved lot's of scratch paper :-) For me it works great, but different people have different needs, of course. > > DocBook or other XML/SGML markup is probably the way to go, but I'm still > quite frustrated with the authoring tools. Whenever I have to match tags I > feel like i'm back on the IBM VM/CMS machine on a 3278 terminal. There's a > *reason* we have megapixel displays! There's *a point* to the megabytes of > memory being used by graphics subsystems! There's *value* in the decades of > work in user interfaces. There's *truth* to the feeling my mom has that the > Mac is easier to use than Unix. . Sorry, I had to get that > off my chest. > > Finally, there's StarOffice, but it seemed quite immature the last time I > checked. It is available free for Unix and Windows. > http://www.sun.com/staroffice/ I've used it and it works like Word (which is why I don't use it :-) ), equations are a pain to enter and it want's me to fuss with how the final format is going to look when I just want to fuss with the content. > > I propose that this discussion be shelved until Developer Day at the > conference, and that we figure out in the DOC-SIG section what Python's > going to do for its core doc, and follow along. Synergy. No problem. Fill me in on how the discussion goes. Travis From cspence@sarnoff.com Wed Jan 19 22:31:46 2000 From: cspence@sarnoff.com (Clay Spence x3039) Date: Wed, 19 Jan 2000 17:31:46 -0500 Subject: [Matrix-SIG] Build problem under Solaris 2.6 Message-ID: <38863B52.B0B12747@sarnoff.com> Hi, I'm having a problem building release 14 under Solaris 2.6 with Sun's C compiler. The following occurs: cholla 332% python setup.py build install running build Src/_numpymodule.c: "Src/_numpymodule.c", line 48: undefined symbol: PyArray_FromDimsAndDataAndDescr_NUM "Src/_numpymodule.c", line 48: undefined symbol: PyArray_FromDimsAndDataAndDescr cc: acomp failed for Src/_numpymodule.c It does not seem to be a limitation on preprocessor symbol names. I can define PyArray_FromDimsAndDataAndDescr_NUM myself in a very short test program and it compiles with no problem. However, the following file gives the same error: ----------- #include #include "Python.h" #define _ARRAY_MODULE #include "arrayobject.h" int main() { printf("%d\n", PyArray_Type_NUM); printf("%d\n", PyArray_FromDimsAndDataAndDescr_NUM); return 0; } ----------- It doesn't complain about PyArray_Type_NUM. The presence or absence of "#define _ARRAY_MODULE" doesn't affect the error. Older versions (I think 11 was the last I tried) compiled fine. Any ideas? Thanks, Clay From zow@pensive.llnl.gov Wed Jan 19 23:28:23 2000 From: zow@pensive.llnl.gov (Zow Terry Brugger) Date: Wed, 19 Jan 2000 15:28:23 -0800 Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: Message from "Rodgers, Kevin" of "Wed, 19 Jan 2000 13:35:21 PST." <0D8C1A50C283D311ABB800508B612E5354B334@ryanaero.com> Message-ID: <200001192327.SAA15242@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii > Far and away the best tool I've ever used for this sort of thing is > Interleaf. It was designed from the ground up to be an environment for > production of long, structured documents by many authors collaborating. It Whoa! They used Interleaf for the documentation at the last company I worked with and their experience with it was enough to sway me away from it permanently. The documentation department was just two people, but both were highly intelligent, competent people (so I'm ruling out user error). First of all, Interleaf is very expensive and very complicated. To use it for the NumPy documentation would be like suggesting we use ClearCase for the revision control. It would require a large amount of outlay of cash and training for everyone involved, which is obviously not feasible. Secondly, Interleaf was going down-hill last I heard (about two years ago) - bugs were going unfixed for years at a time, new functionality wasn't being added, etc. The theory was that too much of their customer base was moving to more cost-effective solutions, like Frame Maker, which is what that company was doing when I left. I'm left with the impression that Interleaf is probably still a good solution if you have tens or hundreds of people working on the same documents and a full time staff devoted to maintaining Interleaf, but for a distributed, collaborative project, I don't think there's any way it could work. I think what we really need to do is examine exactly what we're looking for a documentation tool. Maybe some of the simpler word processors like Star Office or Abi Word do everything we really need. Or maybe HTML is sufficient for our needs: anyone can edit it and most people have an HTML editor they're very comfortable with. Everyone has an HTML viewer they're happy with, and most of those can generate very acceptable printed pages. On the flip side, I can just see the wars starting over, "You're Frontpage completely ruined the formating of this document!" "Well, I had to do that because I don't want to be bothered with the tags like you are in vi!" Food for thought. Terry -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBOIZIk6fuGVwXgOQkEQLDcgCfR6O5tFr42dKyqWazzIXWBsiAgY4AoOZz WUaXNqnCAyKrIg1zYTy3HgrJ =KWap -----END PGP SIGNATURE----- From jhauser@ifm.uni-kiel.de Wed Jan 19 23:51:01 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Thu, 20 Jan 2000 00:51:01 +0100 (CET) Subject: [Matrix-SIG] Active arrays In-Reply-To: References: Message-ID: <20000119235102.11212.qmail@lisboa.ifm.uni-kiel.de> Two, no three things I want to add to the discussion. 1. I welcome the addition of the new casting machinery to Numpy. It seems, as this needs to go into the core, so some files needs to be changed. It's totally different than the older proposals (typing like the longs in standard python), but it seems to be suitable for the problems one had until now. I would suggest to have a new flag to asarray(), like a=ones((10,8)) b=asarray(a, nocast=1) # nocast is not an optimal name. The current idea with asarray is to guarantee something, without doing a copy if not wanted or necessary. asarray is probably used in many functions already, where one wants that a given parameter fulfills some constraints. Then a way is needed to ask for this property, and perhaps I have missed it but nobody mentioned the removing of this property. It would be good to do this without a copy of the data. 2. As we see with this addition to NumPy we need a policy for the cvs-development. Should this be added in a branch, what happens if two people work on the same files, but with different branches. How can interested people easily get an overview about the different developments and check out a complete ``cutting edge'' version? The piddle folks are already working at such a policy, although they have a more modular code base with different main developers for every module. Perhaps we should look into this. 3. I would also like to include array_map and array_set into the main code base. But in an own util module. array_set is not the complete solution to the gather/... thing. So it should be made clear, that perhaps there will be some other more general way to do this. Also with array_map. I really like this, but I need to build constructs to use it with lower dimensional functions. Like applying a one dimensional spline interpolation to every vertical profile in my three dimensional temperature field. These are involving globals, and I actually haven't really timed it, but it seems to work well. So what I mean, these things are evolving, perhaps changing, so we should make them accessible but keep them separate, at least for some time. Then some names for this `active' thingy. typed keeptype hold holdtype rulez :-) # Heh NumPy rulez __Janko From dubois1@llnl.gov Wed Jan 19 23:36:35 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Wed, 19 Jan 2000 15:36:35 -0800 Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) References: <200001192327.SAA15242@python.org> Message-ID: <00011915515100.00571@almanac> I started this as a private thread between David and Travis and I, so thi= s public discussion is missing the following background: The current doc for Numerical is in Frame. I made this choice because it = is a WSYWIG tool that can make HTML and PDF if needed. Also, Frame is relative= ly easy to learn, and is the only choice for books really. And Numerical Pyt= hon the Manual could easily become Numerical Python the Book. It has 17 chapt= ers already.=20 I have done collaborative manuals before in LateX (disaster) and a similar product LLNL had (disaster). ANY document system that used struc= tures edited by humans invariably results in the structures being screwed up by somebody and the next poor person who actually tries to make the output e= nds up searching by bisection for the errors. Latex in particular suffered from non-portability between authors who had slightly different installations,= as someone else mentioned. While I am quite open to change, the only thing really wrong with Frame i= s that it costs money and doesn't run on Linux for one. But it does run on Mac, Windows, and Solaris, which enables a lot of people. Anyway, I hardly think any other solution that involves money would be an= y better. I disagree that HTML is ok; even if everyone uses a WYSIWIG, the language is sufficiently inexpressive that it is a problem (especially fo= r writing about a language in which indentation counts). Besides, I want to= ols that help me make and maintain the index and TOC. From jhauser@ifm.uni-kiel.de Wed Jan 19 23:54:05 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Thu, 20 Jan 2000 00:54:05 +0100 (CET) Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org> References: <003e01bf62c3$041f7b20$c355cfc0@ski.org> Message-ID: <20000119235405.11218.qmail@lisboa.ifm.uni-kiel.de> We need to separate the documentation. We need a technical documentation explaining the functions, classes and the parameters. I would keep this in the same format like the standard python library documentation. There will be tools to parse these files and extract the info directly at the interpreter prompt, or link to them in a help browser of the system. This info can have internal and external links and put into many different output formats. This has also the benefit, that module writers can do this kind of documentation much easier (from a authoring perspective) than a complete and right mathematical documentation. If we mix these two kinds together it will take longer to document everything. The pure module documentation (let's call it reference) can also be included into the CVS. The tutorial and the mathematical rich documents can be authored externally (and will probably only by the actual author) with more suitable tools and will probably only be available as PDF's. Just some suggestions, __Janko (who likes LaTeX a lot :-) From jhauser@ifm.uni-kiel.de Thu Jan 20 00:03:44 2000 From: jhauser@ifm.uni-kiel.de (Janko Hauser) Date: Thu, 20 Jan 2000 01:03:44 +0100 (CET) Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: <00011915515100.00571@almanac> References: <200001192327.SAA15242@python.org> <00011915515100.00571@almanac> Message-ID: <20000120000345.11248.qmail@lisboa.ifm.uni-kiel.de> Just a note about Framemaker. There is a beta downloadable for linux, although I have it not running. On the other side, I have mixed feelings about fmaker, because they stopped to support the digital alpha platform. Or have said, they will not provide a version for the new TrueAlpha releases. __Janko From turner@blueskystudios.com Thu Jan 20 00:15:37 2000 From: turner@blueskystudios.com (John A. Turner) Date: Wed, 19 Jan 2000 19:15:37 -0500 (EST) Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org> References: <003e01bf62c3$041f7b20$c355cfc0@ski.org> Message-ID: <14470.21417.858962.47725@denmark.blueskystudios.com> >>>>> "DA" == David Ascher writes: DA> Finally, there's StarOffice, but it seemed quite immature the last DA> time I checked. It is available free for Unix and Windows. DA> http://www.sun.com/staroffice/ well, if "Unix" is defined to be "Solaris and Linux" >>>>> "PFD" == Paul F Dubois writes: PFD> Anyway, I hardly think any other solution that involves money PFD> would be any better. I disagree that HTML is ok; even if everyone PFD> uses a WYSIWIG, the language is sufficiently inexpressive that it PFD> is a problem (especially for writing about a language in which PFD> indentation counts). agreed PFD> Besides, I want tools that help me make and maintain the index PFD> and TOC. for me, the name of that tool is spelled "LaTeX" -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 381-8400 From vanandel@ucar.edu Thu Jan 20 00:32:25 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Wed, 19 Jan 2000 17:32:25 -0700 Subject: [Matrix-SIG] Active arrays References: <20000119235102.11212.qmail@lisboa.ifm.uni-kiel.de> Message-ID: <38865799.188493B0@atd.ucar.edu> -- Then some names for this `active' thingy. >typed >keeptype >hold >holdtype How about 'promote', set to '0' if promotion to double is not wanted? Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From roitblat@hawaii.edu Thu Jan 20 01:02:55 2000 From: roitblat@hawaii.edu (Herbert L. Roitblat) Date: Wed, 19 Jan 2000 15:02:55 -1000 Subject: [Matrix-SIG] Active arrays Message-ID: <02d201bf62e2$167ee890$8fd6afcf@0gl1u.pixi.com> Are we talking about fixed precision? Maybe use fixed or some variant? -----Original Message----- From: Joe Van Andel To: Janko Hauser Cc: Matrix-Sig Date: Wednesday, January 19, 2000 2:34 PM Subject: Re: [Matrix-SIG] Active arrays > >-- Then some names for this `active' thingy. > >>typed >>keeptype >>hold >>holdtype > >How about 'promote', set to '0' if promotion to double is not wanted? > > >Joe VanAndel >National Center for Atmospheric Research >http://www.atd.ucar.edu/~vanandel/ >Internet: vanandel@ucar.edu > >_______________________________________________ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From ransom@cfa.harvard.edu Thu Jan 20 01:39:10 2000 From: ransom@cfa.harvard.edu (Scott M. Ransom) Date: Thu, 20 Jan 2000 01:39:10 +0000 Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) References: <003e01bf62c3$041f7b20$c355cfc0@ski.org> <14470.21417.858962.47725@denmark.blueskystudios.com> Message-ID: <3886673E.7418F058@cfa.harvard.edu> "John A. Turner" wrote: > > PFD> Anyway, I hardly think any other solution that involves money > PFD> would be any better. I disagree that HTML is ok; even if everyone > PFD> uses a WYSIWIG, the language is sufficiently inexpressive that it > PFD> is a problem (especially for writing about a language in which > PFD> indentation counts). > > agreed > > PFD> Besides, I want tools that help me make and maintain the index > PFD> and TOC. > > for me, the name of that tool is spelled "LaTeX" I would have to agree that CVS'd LaTeX is the lesser of all of the evils. It has the advantage of being free and available in one form or another on virtually every system out there. If a simple document class is chosen (and all required style files are included in CVS) I don't see why this would lead to a disaster. I have successfully managed to use CVS LaTeX in a collaborative manner before -- it is not the easiest thing to manage, but it is not difficult either. Other benefits include automatic TOC and Indices as well as exporting to about any format you can think of. Other problems could be minimized by a couple page "Author's Guide" to the NumPy documentation. Just my two bits, Scott -- Scott M. Ransom Phone: (781) 320-9867 Address: 75 Sanderson Ave. email: ransom@cfa.harvard.edu Dedham, MA 02026 PGP Fingerprint: D2 0E D0 10 CD 95 06 DA EF 78 FE 2B CB 3A D3 53 From ffjhl@uaf.edu Thu Jan 20 03:34:23 2000 From: ffjhl@uaf.edu (Jonah Lee) Date: Wed, 19 Jan 2000 18:34:23 -0900 (AKST) Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: <3886673E.7418F058@cfa.harvard.edu> Message-ID: On Thu, 20 Jan 2000, Scott M. Ransom wrote: > > I would have to agree that CVS'd LaTeX is the lesser of all of the > evils. It has the advantage of being free and available in one form or > another on virtually every system out there. > > If a simple document class is chosen (and all required style files are > included in CVS) I don't see why this would lead to a disaster. > > I have successfully managed to use CVS LaTeX in a collaborative manner > before -- it is not the easiest thing to manage, but it is not difficult > either. I've used LyX to do the same (on several unix variants) and find it to work quite well in a collaborative manner (using CVS). LyX is at a little bit higher level than LaTeX so may have less problems in compatibility among cvs users. One potential downside is that it may not be as easy to install on non-Unix platforms. I never tried LyX on non-unix platforms, but the installation instructions for LyX on those platforms seem somewhat involved. > > Other problems could be minimized by a couple page "Author's Guide" to > the NumPy documentation. This is a good idea. Regards, Jonah From pavlos@gaaros.com Thu Jan 20 05:25:18 2000 From: pavlos@gaaros.com (Pavlos Christoforou) Date: Thu, 20 Jan 2000 00:25:18 -0500 (EST) Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org> Message-ID: On Wed, 19 Jan 2000, David Ascher wrote: > > I refuse to use LaTeX. Can't even justify why, it's a gut reaction after > writing too many papers, a several-hundred page dissertation with it, > spending waaaayy too many hours debugging poorly written LaTeX macros, > fussing with DVI, PS, EPS, bounding boxes, BibTeX, fussy installations, > missing fonts, bad HTML conversion, etc. Hmmm maybe you got carried away with too many macros. In my department nobody writes macros and the latest latex distributions (at least the default Red Hat Linux one) seem to be quite complete. Afew people are laso using LyX which is not bad. Just a comment Pavlos From rob@hooft.net Thu Jan 20 06:52:18 2000 From: rob@hooft.net (Rob W. W. Hooft) Date: Thu, 20 Jan 2000 07:52:18 +0100 (MET) Subject: [Matrix-SIG] I have working code that implements active-casting concept. In-Reply-To: References: Message-ID: <14470.45218.362848.247846@vleet.chem.uu.nl> >>>>> "TO" == Travis Oliphant writes: TO> When a universal function involving NumPy arrays is encountered, TO> if all arrays are passive (active flag = 0) then the current TO> coercion rules are used. If any of the arguments to the function TO> are active arrays, then the active array with the largest TO> typecode (enumerated types in arrayobject.h) determines the Ah, so not the one with the greatest activity... TO> output types. All other arrays are automatically cast (even if TO> it means loss of precision) to that type, before the operation TO> begins. The output arrays from the function are all active TO> arrays. This is a great idea, and it will certainly simplify my code. However, I'd like to raise one point of concern: I am using some functions that use 2 arrays: a small one, used repeatedly and a big one that changes on every invocation. If the small array is passive-d and the big one is active-f, this will cast the small one to 'f' on every invocation. Without the active/passive patch, I'd find out about this inefficiency because the result would be of type 'd'. Would there be any way of warning the programmer for this kind of inefficient casting with the new code? Regards, Rob Hooft -- ===== rob@hooft.net http://www.xs4all.nl/~hooft/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From Oliphant.Travis@mayo.edu Thu Jan 20 07:08:32 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Thu, 20 Jan 2000 01:08:32 -0600 (CST) Subject: [Matrix-SIG] Space-saving arrays and authoring tools. Message-ID: Well, the changes to NumPy to provide space-saving (I used to call them active) are in CVS. Anyone who wants to try them out can check out the current source tree from sourceforge.net Three new syntax items: 1) array() now takes a savespace keyword (default is 0) which if non-zero specifies that the constructed array be a "spacesaver" array. This has two effects: first, construction from Python (nested) lists and scalars produces single-precision arrays, and second, the new array has the savespace flag set so that it will control the casting in ufunc operations. Suppose a is a NumPy array 2) a.savespace(flag=value) sets the savespace flag to value (1 or 0) 3) a.spacesaver() queries the flag. Currently, the behavior if two spacesaving arrays are found in an operation is to cast to the largest precision spacesaving array. However, when a similar proposal was made several months ago by Michael Hudson, several people said that it would be better to throw an exception under such circumstances. I would like more opinions on this. I haven't had enough experience to decide which is better, but I'm leaning towards the throwing-the-exception option. **** Proposal buried in the next paragraph **** Eventually we have to fix this rank-0 array/ scalar question. Right now rank-0 arrays are sort of scalars and sort of not which makes things messy both from a users point of view and a programmers point of view. I think rank-0 arrays should be given their rightful existence and be the return type for all indexing operations, math operations, etc. (basically, get rid of Pyarray_Return). Because Python allows you to define methods to determine how your types are interpreted as numbers, the rank-0 arrays will behave rather nicely. We could even use them to index into NumPy arrays with little trouble. Then, we define a method .toscalar() that gets the appropriate Python scalar for those times when you really need it. The truth is NumPy arrays are not Python numbers, lists, or dictionaries, even though they can act like them (often seemlessly) sometimes. I don't think it is confusing to separate the concepts for the user (since the differences will get you someday if you don't understand them). About authoring tools. I find it interesting that 5 people have said that a controlled LaTeX or LyX would be a good option for documentation (and I know of another 2 as well). Are David and Paul the only ones that don't like the idea of using LaTeX or are the rest of you remaining silent? There are important points to consider regarding the opposition to LaTeX: 1) LyX reduces the learning curve to LaTeX dramatically. 2) LaTeX installations have matured: teTeX is standard package that contains what you really need. From Oliphant.Travis@mayo.edu Thu Jan 20 07:17:27 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Thu, 20 Jan 2000 01:17:27 -0600 (CST) Subject: [Matrix-SIG] I have working code that implements active-castingconcept. In-Reply-To: <14470.45218.362848.247846@vleet.chem.uu.nl> Message-ID: > > This is a great idea, and it will certainly simplify my code. However, > I'd like to raise one point of concern: > > I am using some functions that use 2 arrays: a small one, used repeatedly > and a big one that changes on every invocation. If the small array is > passive-d and the big one is active-f, this will cast the small one > to 'f' on every invocation. Without the active/passive patch, I'd find > out about this inefficiency because the result would be of type 'd'. Would > there be any way of warning the programmer for this kind of inefficient > casting with the new code? Let me see if I understand: You want to be able to catch that you are casting the passive array on every function call (presumably so you can change it and cast once)? Right now you have to check the output type, correct? With the current changes in CVS, the result would be of type 'active-f' which is not the type of the small input array, so you could just check to make sure the types are the same. What am I missing? Another person wanted two "active" arrays of different types to raise an exception, so with that change you would make both arrays active and if they were not the same type an error would occur. What do you think? Travis From rob@hooft.net Thu Jan 20 09:24:37 2000 From: rob@hooft.net (Rob W. W. Hooft) Date: Thu, 20 Jan 2000 10:24:37 +0100 (MET) Subject: [Matrix-SIG] I have working code that implements active-castingconcept. In-Reply-To: References: <14470.45218.362848.247846@vleet.chem.uu.nl> Message-ID: <14470.54357.484569.958626@vleet.chem.uu.nl> >>>>> "TO" == Travis Oliphant writes: >> I am using some functions that use 2 arrays: a small one, used >> repeatedly and a big one that changes on every invocation. If the >> small array is passive-d and the big one is active-f, this will >> cast the small one to 'f' on every invocation. Without the >> active/passive patch, I'd find out about this inefficiency because >> the result would be of type 'd'. Would there be any way of warning >> the programmer for this kind of inefficient casting with the new >> code? TO> Let me see if I understand: You want to be able to catch that you TO> are casting the passive array on every function call (presumably TO> so you can change it and cast once)? TO> Right now you have to check the output type, correct? Right now I know I have a problem when the program slows down to 0 Kelvin. Then I start looking for a d-array that makes everything go d. TO> With the current changes in CVS, the result would be of type TO> 'active-f' which is not the type of the small input array, so you TO> could just check to make sure the types are the same. What am I TO> missing? You're speaking about the program checking, I used to detect the problems using "wall-clock-profiling". TO> Another person wanted two "active" arrays of different types to TO> raise an exception, so with that change you would make both TO> arrays active and if they were not the same type an error would TO> occur. What do you think? That would be one way to do it, but most tricks require me to think whenever I use a new array, and if I am thinking, I can just as well add ",'f'" to the instantiation in the first place..... I'm trying to catch thinkos. Dumb alternative suggestions: - active=-1 means complain if you need to down-cast another array (i.e. non-scalar). - in some sort of debugging mode, keep a count of the number of times each array is down-casted, and raise InefficientCode("Frequent down-cast") if this happens often. Don't get me wrong here: I really think your code is a great improvement, and the point I'm raising is really of secondary importance (even to me). Rob -- ===== rob@hooft.net http://www.xs4all.nl/~hooft/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! ========= From rlw@stsci.edu Thu Jan 20 15:26:34 2000 From: rlw@stsci.edu (Rick White) Date: Thu, 20 Jan 2000 10:26:34 -0500 (EST) Subject: [Matrix-SIG] Space-saving arrays and authoring tools. Message-ID: <200001201526.KAA12848@sundog.stsci.edu> Travis Oliphant writes: >Currently, the behavior if two spacesaving arrays are found in an >operation is to cast to the largest precision spacesaving array. However, >when a similar proposal was made several months ago by Michael Hudson, >several people said that it would be better to throw an exception under >such circumstances. I would like more opinions on this. I haven't had >enough experience to decide which is better, but I'm leaning towards the >throwing-the-exception option. My 2-cents worth: *please* don't make raising an exception the only behavior. The standard promotion rules (within the savespace hierarchy) will be useful for most applications for the same reason they are useful for normal scalar expressions. And for dynamically typed languages like Python, it just does not make sense to me to start throwing exceptions when the types disagree. In our applications (image processing) we use a variety of types (1, 2, & 4-byte integers, single & double precision floats). A typical operation is to start with raw data from a detector in an integer format and to divide it by the detector's 'flat-field' response to correct for sensitivity variations. The image gets converted to floating-point in the process. If the Numeric code is raising exceptions for mixed type expressions, I'm going to be forced to write very ugly-looking code to test myself for the types of the input quantities and explicitly promote them to the right output types. Then I'll lose many of the advantages of having dynamically typed variables. Personally I'd be happy if the only behavior was Travis's original version that promotes within the savespace hierarchy. But if some people really want the exception-throwing behavior then I think Rob Hooft's proposal of allowing savespace=-1 sounds like a possible solution. That sufficiently complicates the behavior that I'd do without it if it were up to me. Rick --- Richard L. White rlw@stsci.edu http://sundog.stsci.edu/rick/ Space Telescope Science Institute Baltimore, MD From vanandel@ucar.edu Thu Jan 20 16:30:20 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Thu, 20 Jan 2000 09:30:20 -0700 Subject: [Matrix-SIG] patch to arrayfnsmodule.c Message-ID: <3887381C.EB0DAADA@atd.ucar.edu> This is a multi-part message in MIME format. --------------F0B944AE7954161E2C4B63D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've attached a patch to LLNL/Graphics/Arrayfcns/Src/arrayfnsmodule.c that 1) Allows interp() to operate on multi-dimensional arrays 2) Provides interpf(), to return a single precision array Could someone apply this patch to the standard LLNL distribution? Thanks much. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu --------------F0B944AE7954161E2C4B63D6 Content-Type: text/plain; charset=us-ascii; name="arrayfnsmodule.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="arrayfnsmodule.diff" *** arrayfnsmodule.c 1999/04/14 22:58:32 1.1 --- arrayfnsmodule.c 1999/08/12 23:27:28 *************** *** 6,11 **** --- 6,13 ---- #include #include + #define MAX_INTERP_DIMS 6 + static PyObject *ErrorObject; /* Define 2 macros for error handling: *************** *** 34,39 **** --- 36,43 ---- #define A_DIM(a,i) (((PyArrayObject *)a)->dimensions[i]) #define GET_ARR(ap,op,type,dim) \ Py_Try(ap=(PyArrayObject *)PyArray_ContiguousFromObject(op,type,dim,dim)) + #define GET_ARR2(ap,op,type,min,max) \ + Py_Try(ap=(PyArrayObject *)PyArray_ContiguousFromObject(op,type,min,max)) #define ERRSS(s) ((PyObject *)(PyErr_SetString(ErrorObject,s),0)) #define SETERR(s) if(!PyErr_Occurred()) ERRSS(errstr ? errstr : s) #define DECREF_AND_ZERO(p) do{Py_XDECREF(p);p=0;}while(0) *************** *** 571,576 **** --- 575,613 ---- return result ; } + static int + binary_searchf(float dval, float dlist [], int len) + { + /* binary_search accepts three arguments: a numeric value and + * a numeric array and its length. It assumes that the array is sorted in + * increasing order. It returns the index of the array's + * largest element which is <= the value. It will return -1 if + * the value is less than the least element of the array. */ + /* self is not used */ + int bottom , top , middle, result; + + if (dval < dlist [0]) + result = -1 ; + else { + bottom = 0; + top = len - 1; + while (bottom < top) { + middle = (top + bottom) / 2 ; + if (dlist [middle] < dval) + bottom = middle + 1 ; + else if (dlist [middle] > dval) + top = middle - 1 ; + else + return middle ; + } + if (dlist [bottom] > dval) + result = bottom - 1 ; + else + result = bottom ; + } + + return result ; + } static char arr_interp__doc__[] = "" ; *************** *** 597,609 **** Py_DECREF(ay); Py_DECREF(ax); return NULL ;} ! GET_ARR(az,oz,PyArray_DOUBLE,1); lenz = A_SIZE (az); dy = (double *) A_DATA (ay); dx = (double *) A_DATA (ax); dz = (double *) A_DATA (az); ! Py_Try (_interp = (PyArrayObject *) PyArray_FromDims (1, &lenz, ! PyArray_DOUBLE)); dres = (double *) A_DATA (_interp) ; slopes = (double *) malloc ( (leny - 1) * sizeof (double)) ; for (i = 0 ; i < leny - 1; i++) { --- 634,647 ---- Py_DECREF(ay); Py_DECREF(ax); return NULL ;} ! GET_ARR2(az,oz,PyArray_DOUBLE,1,MAX_INTERP_DIMS); lenz = A_SIZE (az); dy = (double *) A_DATA (ay); dx = (double *) A_DATA (ax); dz = (double *) A_DATA (az); ! /* create output array with same size as 'Z' input array */ ! Py_Try (_interp = (PyArrayObject *) PyArray_FromDims ! (A_NDIM(az), az->dimensions, PyArray_DOUBLE)); dres = (double *) A_DATA (_interp) ; slopes = (double *) malloc ( (leny - 1) * sizeof (double)) ; for (i = 0 ; i < leny - 1; i++) { *************** *** 627,632 **** --- 665,724 ---- return PyArray_Return (_interp); } + /* return float, rather than double */ + + static PyObject * + arr_interpf(PyObject *self, PyObject *args) + { + /* interp (y, x, z) treats (x, y) as a piecewise linear function + * whose value is y [0] for x < x [0] and y [len (y) -1] for x > + * x [len (y) -1]. An array of floats the same length as z is + * returned, whose values are ordinates for the corresponding z + * abscissae interpolated into the piecewise linear function. */ + /* self is not used */ + PyObject * oy, * ox, * oz ; + PyArrayObject * ay, * ax, * az , * _interp; + float * dy, * dx, * dz , * dres, * slopes; + int leny, lenz, i, left ; + + Py_Try(PyArg_ParseTuple(args, "OOO", &oy, &ox, &oz)); + GET_ARR(ay,oy,PyArray_FLOAT,1); + GET_ARR(ax,ox,PyArray_FLOAT,1); + if ( (leny = A_SIZE (ay)) != A_SIZE (ax)) { + SETERR ("interp: x and y are not the same length."); + Py_DECREF(ay); + Py_DECREF(ax); + return NULL ;} + GET_ARR2(az,oz,PyArray_FLOAT,1,MAX_INTERP_DIMS); + lenz = A_SIZE (az); + dy = (float *) A_DATA (ay); + dx = (float *) A_DATA (ax); + dz = (float *) A_DATA (az); + /* create output array with same size as 'Z' input array */ + Py_Try (_interp = (PyArrayObject *) PyArray_FromDims + (A_NDIM(az), az->dimensions, PyArray_FLOAT)); + dres = (float *) A_DATA (_interp) ; + slopes = (float *) malloc ( (leny - 1) * sizeof (float)) ; + for (i = 0 ; i < leny - 1; i++) { + slopes [i] = (dy [i + 1] - dy [i]) / (dx [i + 1] - dx [i]) ; + } + for ( i = 0 ; i < lenz ; i ++ ) + { + left = binary_searchf (dz [i], dx, leny) ; + if (left < 0) + dres [i] = dy [0] ; + else if (left >= leny - 1) + dres [i] = dy [leny - 1] ; + else + dres [i] = slopes [left] * (dz [i] - dx [left]) + dy [left]; + } + + free (slopes); + Py_DECREF(ay); + Py_DECREF(ax); + Py_DECREF(az); + return PyArray_Return (_interp); + } static int incr_slot_ (float x, double *bins, int lbins) { int i ; *************** *** 1295,1300 **** --- 1387,1393 ---- {"array_set", arr_array_set, 1, arr_array_set__doc__}, {"index_sort", arr_index_sort, 1, arr_index_sort__doc__}, {"interp", arr_interp, 1, arr_interp__doc__}, + {"interpf", arr_interpf, 1, arr_interp__doc__}, {"digitize", arr_digitize, 1, arr_digitize__doc__}, {"zmin_zmax", arr_zmin_zmax, 1, arr_zmin_zmax__doc__}, {"reverse", arr_reverse, 1, arr_reverse__doc__}, --------------F0B944AE7954161E2C4B63D6-- From dubois1@llnl.gov Thu Jan 20 16:46:36 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Thu, 20 Jan 2000 08:46:36 -0800 Subject: [Matrix-SIG] RE: patch to arrayfnsmodule.c In-Reply-To: <3887381C.EB0DAADA@atd.ucar.edu> Message-ID: I'll do it. Paul -----Original Message----- From: vanandel@atd.ucar.edu [mailto:vanandel@atd.ucar.edu] Sent: Thursday, January 20, 2000 8:30 AM To: dubois1@llnl.gov Cc: matrix-sig@python.org Subject: patch to arrayfnsmodule.c I've attached a patch to LLNL/Graphics/Arrayfcns/Src/arrayfnsmodule.c that 1) Allows interp() to operate on multi-dimensional arrays 2) Provides interpf(), to return a single precision array Could someone apply this patch to the standard LLNL distribution? Thanks much. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From mwh21@cam.ac.uk Thu Jan 20 17:09:47 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 20 Jan 2000 17:09:47 +0000 Subject: [Matrix-SIG] Space-saving arrays and authoring tools. In-Reply-To: Travis Oliphant's message of "Thu, 20 Jan 2000 01:08:32 -0600 (CST)" References: Message-ID: Travis Oliphant writes: > Currently, the behavior if two spacesaving arrays are found in an > operation is to cast to the largest precision spacesaving array. However, > when a similar proposal was made several months ago by Michael Hudson, I don't *think* that was me. I'd be perfectly willing to accept evidence to the contrary, but if it was I've forgotten it. not-that-I-mind-taking-the-credit-ly y'rs Michael > several people said that it would be better to throw an exception under > such circumstances. I would like more opinions on this. I haven't had > enough experience to decide which is better, but I'm leaning towards the > throwing-the-exception option. From Oliphant.Travis@mayo.edu Thu Jan 20 17:57:53 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Thu, 20 Jan 2000 11:57:53 -0600 (CST) Subject: [Matrix-SIG] Credit where credit is due. Message-ID: I apologize to Scott Ransom and Michael Haggerty for incorrectly citing Michael Hudson as originator of the idea for an attribute that causes no upcasting. I went back and reviewed the discussion on this list of June and July last year and saw that it was really the conversation between Scott Ransom, Tim Hochberg, Rick White, and Michael Haggerty that produced the idea of a typecode attribute to help in the upcasting problem. Their idea is essentially what was implemented. I also saw that the disagreement about how to handle the case of two arrays with this property was also present in the discussion :-) --Travis From taylor@rhino.llnl.gov Thu Jan 20 18:58:44 2000 From: taylor@rhino.llnl.gov (Lee Taylor) Date: Thu, 20 Jan 2000 10:58:44 -0800 (PST) Subject: [Matrix-SIG] Build problem under Solaris 2.6 In-Reply-To: <38863B52.B0B12747@sarnoff.com> Message-ID: Make sure you're using the new version of arrayobject.h. It is now in directory Numeric instead of numeric. I usually use: #include "Numeric/arrayobject.h" instead of: #include "arrayobject.h" and then use -I$(prefix)/include/python1.5/Numeric on the compile line. Lee Taylor ltaylor@llnl.gov On Wed, 19 Jan 2000, Clay Spence x3039 wrote: > Hi, > > I'm having a problem building release 14 under Solaris 2.6 with Sun's C > compiler. The following occurs: > > cholla 332% python setup.py build install > running build > > Src/_numpymodule.c: > "Src/_numpymodule.c", line 48: undefined symbol: > PyArray_FromDimsAndDataAndDescr_NUM > "Src/_numpymodule.c", line 48: undefined symbol: > PyArray_FromDimsAndDataAndDescr > cc: acomp failed for Src/_numpymodule.c > > It does not seem to be a limitation on preprocessor symbol names. I can > define PyArray_FromDimsAndDataAndDescr_NUM myself in a very short test > program and it compiles with no problem. However, the following file > gives the same error: > > ----------- > #include > #include "Python.h" > #define _ARRAY_MODULE > #include "arrayobject.h" > > int > main() > { > printf("%d\n", PyArray_Type_NUM); > printf("%d\n", PyArray_FromDimsAndDataAndDescr_NUM); > return 0; > } > ----------- > > It doesn't complain about PyArray_Type_NUM. The presence or absence of > "#define _ARRAY_MODULE" doesn't affect the error. Older versions (I > think 11 was the last I tried) compiled fine. Any ideas? > > Thanks, > Clay > > > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig > From perry_stoll@yahoo.com Thu Jan 20 19:02:59 2000 From: perry_stoll@yahoo.com (Perry Stoll) Date: Thu, 20 Jan 2000 11:02:59 -0800 (PST) Subject: [Matrix-SIG] Credit where credit is due. Message-ID: <20000120190259.6512.qmail@web705.mail.yahoo.com> Well, just for historical accuracy ;), check out the thread starting here for more on this topic: http://www.python.org/pipermail/matrix-sig/1996-January/003421.html -Perry --- Travis Oliphant wrote: > > I apologize to Scott Ransom and Michael Haggerty for > incorrectly citing > Michael Hudson as originator of the idea for an > attribute that causes no > upcasting. > > I went back and reviewed the discussion on this list > of June and July last > year and saw that it was really the conversation > between Scott Ransom, Tim > Hochberg, Rick White, and Michael Haggerty that > produced the idea of a > typecode attribute to help in the upcasting problem. > Their idea is > essentially what was implemented. > > I also saw that the disagreement about how to handle > the case of two > arrays with this property was also present in the > discussion :-) > > --Travis > > > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From cspence@sarnoff.com Thu Jan 20 19:04:05 2000 From: cspence@sarnoff.com (Clay Spence x3039) Date: Thu, 20 Jan 2000 14:04:05 -0500 Subject: [Matrix-SIG] Re: Build problem under Solaris 2.6 References: <20000120003154.494041CF71@dinsdale.python.org> Message-ID: <38875C25.30C4F12E@sarnoff.com> I wrote: > I'm having a problem building release 14 under Solaris 2.6 with Sun's C > compiler. The following occurs: > > cholla 332% python setup.py build install > running build > > Src/_numpymodule.c: > "Src/_numpymodule.c", line 48: undefined symbol: > PyArray_FromDimsAndDataAndDescr_NUM > "Src/_numpymodule.c", line 48: undefined symbol: > PyArray_FromDimsAndDataAndDescr > cc: acomp failed for Src/_numpymodule.c and more stuff. Travis Oliphant suggested the solution: The compiler was finding the header file arrayobject.h from my installation of an older version, because the python include directory appears first in the sequence of -I's. Deleting the old arrayobject.h (which was a link anyway) fixed the problem. I'll leave it to others to decide whether something about the distribution should be changed to handle this situation. (Or maybe I didn't read the installation instructions carefully enough?) Clay From cgw@fnal.gov Thu Jan 20 19:59:13 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Thu, 20 Jan 2000 13:59:13 -0600 (CST) Subject: [Matrix-SIG] More fixes for type 'O' arrays Message-ID: <14471.26897.390486.756553@buffalo.fnal.gov> The bug: Python 1.5.2+ (#7, Jan 13 2000, 16:18:27) [GCC 2.95.2 19991024 (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Numeric import * >>> x=array(['a','b','c'],'O') >>> y=array(['d','e','f'],'O') >>> dot(x,y) Segmentation fault The fix: (the patch to multiarraymodule is the real fix, the patch to Numeric.py is just to give a more meaningful message with the exception) Index: Lib/Numeric.py =================================================================== RCS file: /cvsroot/numpy/Numerical/Lib/Numeric.py,v retrieving revision 1.7 diff -u -r1.7 Numeric.py --- Lib/Numeric.py 2000/01/19 23:13:41 1.7 +++ Lib/Numeric.py 2000/01/20 19:56:38 @@ -212,11 +212,11 @@ """ try: return multiarray.innerproduct(a,b) - except(TypeError): + except TypeError,detail: if array(a).shape == () or array(b).shape == (): return a*b else: - raise TypeError, "invalid types for dot" + raise TypeError, detail or "invalid types for dot" def dot(a, b): """dot(a,b) returns matrix-multiplication between a and b. The product-sum Index: Src/multiarraymodule.c =================================================================== RCS file: /cvsroot/numpy/Numerical/Src/multiarraymodule.c,v retrieving revision 1.5 diff -u -r1.5 multiarraymodule.c --- Src/multiarraymodule.c 2000/01/19 23:13:41 1.5 +++ Src/multiarraymodule.c 2000/01/20 19:56:39 @@ -574,10 +574,14 @@ PyObject *tmp1, *tmp2, *tmp; for(i=0;i (dubois1@llnl.gov) References: <200001192327.SAA15242@python.org> <00011915515100.00571@almanac> Message-ID: <200001211540.QAA12735@chinon.cnrs-orleans.fr> > searching by bisection for the errors. Latex in particular suffered from > non-portability between authors who had slightly different installations, as > someone else mentioned. I remember such problems from the early days of LaTeX, but since LaTeX 2e has become the standard, and since everyone uses one out a small number of standard distributions, they have disappeared. The remaining problem to watch out for in collaborative work is personal macros; one solution is to require personal macros to begin with the initials of the author. LaTeX seems the only documentation system at the moment that is free and open. Yes, it is sometimes difficult to solve some LaTeX problem, but it is always possible because you have all the sources. With any proprietary system, you sooner or later reach a point where you just can't go on because you'd have to fix the program, and can't. DocBook is also open and free, including some tools to work on it, but also extremely complicated, and the amount of markup for a typical text is sufficient to make typing extremely unpleasant with a standard text editor, even if it is Emacs with SGML support. I used DocBook for the ScientificPython and MMTK manuals, and I would most definitely not make that choice again. I ended up modifying the original DTD because there was no decent markup for documenting Python, and then I wrote my own translators to HTML and LaTeX because this seemed much simpler than understanding DSSSL and debugging JadeTeX. Another option is to develop a special (and simple) DTD for Python documentation and write translators to other formats (in Python, of course). This would make sense if the whole Python community were interested in such a development. 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 pauldubois@home.com Fri Jan 21 17:18:45 2000 From: pauldubois@home.com (Paul F. Dubois) Date: Fri, 21 Jan 2000 09:18:45 -0800 Subject: [Matrix-SIG] Note on using IE on Numerical Python website Message-ID: I have reported the following bug to SourceForge -- when you use Internet Explorer (or at least IE5) on the site, in SSL logged-in mode, there are a lot of failures when you change pages. However, a "refresh" at that point will usually succeed. There was a follow up indicating they are aware of it. From amullhau@zen-pharaohs.com Fri Jan 21 18:29:50 2000 From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt) Date: Fri, 21 Jan 2000 13:29:50 -0500 Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays) References: <003e01bf62c3$041f7b20$c355cfc0@ski.org> Message-ID: <046301bf643d$82511dc0$5063cb0a@amullhau> > > > Never tried DocBook. > > LaTeX allows people to define macros and makes writers think like > programmers. Bad idea. =) Many many folks don't know LaTeX but would be > able to pick up a WYSIWYG editor easily. So use Scientific Word which produces LaTeX output but is basically a word processor if you want that. You can essentially dial up how much LaTeX pain you want to enjoy. I've written thousands of pages of LaTeX and I started refusing to know TeX before there was LaTeX. TeX is ridiculous, of course, what else would you expect from a guy who still wants his own assembler language in that book? > I refuse to use LaTeX. Can't even justify why, it's a gut reaction after > writing too many papers, a several-hundred page dissertation with it, > spending waaaayy too many hours debugging poorly written LaTeX macros, > fussing with DVI, PS, EPS, bounding boxes, BibTeX, fussy installations, > missing fonts, bad HTML conversion, etc. Next time try Scientific Word. Later, Andrew Mullhaupt From guido@CNRI.Reston.VA.US Fri Jan 21 19:01:08 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 21 Jan 2000 14:01:08 -0500 Subject: [Matrix-SIG] Python Conference weather Message-ID: <200001211901.OAA29501@eric.cnri.reston.va.us> If you're traveling to the Python Conference, be advised that winter has finally arrived in the Washington, DC area. We're currently experiencing *high* temperatures of 22 degrees F (-6 degrees C); with the wind chill it will feel much colder. So be sure to pack warm clothes. Yesterday, about 6 inches of snow fell, disrupting air travel; more is expected on Sunday, so expect delays flying into DC. Local transportation should be fully operational, but may experience some delays. We've placed a weather advisory in the local section of the conference website: http://www.python.org/workshops/2000-01/local.html Over 250 people have registered for the conference. See you all there! --Guido van Rossum (home page: http://www.python.org/~guido/) From bryce.k.gardner@jpl.nasa.gov Fri Jan 21 19:24:55 2000 From: bryce.k.gardner@jpl.nasa.gov (Bryce Gardner) Date: Fri, 21 Jan 2000 11:24:55 -0800 Subject: [Matrix-SIG] Active arrays In-Reply-To: <38865799.188493B0@atd.ucar.edu> References: <20000119235102.11212.qmail@lisboa.ifm.uni-kiel.de> Message-ID: <4.1.20000121103552.00acfee0@mail1.jpl.nasa.gov> >-- Then some names for this `active' thingy. > >>typed >>keeptype >>hold >>holdtype > >How about 'promote', set to '0' if promotion to double is not wanted? I was thinking 'dominant_type' because we want this type to attempt to control the final type of an expression. Something that lends the idea that this type is intended to control the type of the output. Some other words could be overriding_type, prevailing_type, principal_type. just my two-cents worth. Bryce From steriana@gvsu.edu Fri Jan 21 19:40:16 2000 From: steriana@gvsu.edu (Andrew Sterian) Date: Fri, 21 Jan 2000 14:40:16 -0500 Subject: [Matrix-SIG] RE: (Matrix-SIG) Active arrays In-Reply-To: <921810574@gvsu.edu> Message-ID: <000401bf6447$583531c0$0a243d94@gvsu.edu> > >-- Then some names for this `active' thingy. > > > >>typed > >>keeptype > >>hold > >>holdtype > > > >How about 'promote', set to '0' if promotion to double is not wanted? > > I was thinking 'dominant_type' because we want this type to attempt to > control the > final type of an expression. Something that lends the idea > that this type > is intended > to control the type of the output. Given that we want this matrix to be dominant, it is a dominant matrix so perhaps this attribute should be called 'dominatrix' :) (Sorry...couldn't resist) Andrew Sterian | Assistant Professor | Padnos School of Engineering | (616) 771-6756 Grand Valley State University From pearu@ioc.ee Tue Jan 25 14:53:37 2000 From: pearu@ioc.ee (Pearu Peterson) Date: Tue, 25 Jan 2000 16:53:37 +0200 Subject: [Matrix-SIG] f2py 1.116: The Fortran to Python Interface Generator Message-ID: <388DB8F1.F0E1F218@ioc.ee> I am pleased to announce the first public release of f2py 1.116: Writing Python C/API wrappers for Fortran routines can be a very tedious task, especially if a Fortran routine takes more than 20 arguments but only few of them are relevant for the problems that they solve. The Fortran to Python Interface Generator, or FPIG for short, is a command line tool (f2py) for generating Python C/API modules for wrapping Fortran 77 routines, accessing common blocks from Python, and calling Python functions from Fortran (call-backs). The tool can be downloaded from http://cens.ioc.ee/projects/f2py2e/ where you can find also information about f2py features and its User's Guide. f2py is released under the LGPL license. With regards, Pearu Peterson

f2py 1.116 - The Fortran to Python Interface Generator (25-Jan-00) From pearu@ioc.ee Wed Jan 26 11:04:54 2000 From: pearu@ioc.ee (Pearu Peterson) Date: Wed, 26 Jan 2000 13:04:54 +0200 (EET) Subject: [Matrix-SIG] Re: regarding f2py In-Reply-To: <388E2334.30065BB6@first.gmd.de> Message-ID: On Tue, 25 Jan 2000, Thilo Ernst wrote: > Dear Pearu, >=20 > in search for useful tools for my new project, which involves integrating > scientific-computing (largely Fortran) > codes via Python, I saw your f2py announcement & web page. I find f2py v= ery > interesting, I only have one > problem. As you are using Python and NumPy, you are certainly aware of Pa= ul > Dubois=B4 PyFort tool which seems > to be quite related to your work. OTOH, there seem to be important > differences: E.g. I didn=B4t notice support for > Fortran->Python callbacks when scanning the PyFort docs (superficially as= of > yet, I have to admit). > This makes it difficult for me as a prospective "customer" of these two t= ools > to decide which to use. > I think it would be very helpful if you as the author, and obviously a "d= omain > expert" could put some words > of comparison on the f2py web page.=20 I think, Paul Dubois and me started to develop such a tool approximately at the same time (summer 1999) but independently and having different goals in mind. My goal was to have tool that would scan large number of fortran codes (in Netlib libraries such as blas,lapack,minpack,odepack,etc) and produce raw wrappings of the Fortran 77 codes so that they could be called from Python in a similar way as you would call them from C or Fortran.=20 Since many of these routines take `external' arguments, the call-back mechanism was needed in the very early stage of the development. Thanks to Travis Oliphant who implement the first call-back mechanism for f2py.=20 During the development f2py has undergone three iterations, each has be rewritten from scratch. By now it has reached to a quite stable stage. Though, f2py has currently one shortcoming: using multi-dimensional arrays is not very user-friendly --- the user must be aware of differences that are how the multidimensional arrays are stored in Python/C (raw major order) and in Fortran (column major order). I think, Paul has found a more user-friendlier solution to this problem. In fact, the next goal for f2py is to find a better solution to the problem. That is to eliminate the differences between Python and Fortran multi-D arrays in the wrapper level so that the user need not to know about C/Fortran differences. I hope that Paul is willing to give a nice comment on his tool. From the documentation of Pyfort I find that his main goal is to wrap Fortran 95 codes to Python, in future. > One more question: how did you construct the Fortran parser? Well, I took XL Fortran 5.1 Language Reference Guide and by following it carefully, implemented the fortran code "cracker" (see crackfortran.py). The Python Regular Expression module re turned out to be = =20 most useful for parsing fortran code lines. Note also that I was able to produce such a parser partly because the syntax of Fortran 77/90/95=20 language is relatively simple (compared to C, for instance) and because Python is such a nice language (that you all know anyway ;-) Pearu=20 =20 From vanandel@ucar.edu Fri Jan 28 23:08:05 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Fri, 28 Jan 2000 16:08:05 -0700 Subject: [Matrix-SIG] Space-saving arrays and authoring tools. References: Message-ID: <38922155.3CCA14F8@atd.ucar.edu> I've just tried the spacesaver option, and it seems to do just what I want. This is great, I'm very pleased I don't have to sprinkle functions in my code to avoid up-casting. For consistency and convenience, could the Numeric 'ones' and 'zeros' functions accept a savespace argument, which defaults to 0? Thanks much. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From Oliphant.Travis@mayo.edu Sat Jan 29 00:01:16 2000 From: Oliphant.Travis@mayo.edu (Travis Oliphant) Date: Fri, 28 Jan 2000 18:01:16 -0600 (CST) Subject: [Matrix-SIG] Space-saving arrays and authoring tools. In-Reply-To: <38922155.3CCA14F8@atd.ucar.edu> Message-ID: > I've just tried the spacesaver option, and it seems to do just what I > want. > > This is great, I'm very pleased I don't have to sprinkle functions in my > code to avoid up-casting. > > > For consistency and convenience, could the Numeric 'ones' and 'zeros' > functions accept a savespace argument, which defaults to 0? > > Thanks much. This is a good idea. I'll put it on sourceforge soon. Thanks for the feedback. -Travis From gpk@bell-labs.com Mon Jan 31 15:49:30 2000 From: gpk@bell-labs.com (Greg Kochanski) Date: Mon, 31 Jan 2000 10:49:30 -0500 Subject: [Matrix-SIG] Zeros References: <20000129170022.CF1A81CE60@dinsdale.python.org> Message-ID: <3895AF0A.B9D9AF63@bell-labs.com> Speaking of redefining Numeric.zeros(), I've had the need to create an array of Nones, then fill up some of the entries. It would be reasonably nice if Numeric.zeros(size, Numeric.PyObject) produced an array of Nones, rather than the current behavior of producing an array of integer zero python objects. After all, a 'zero' PyObject isn't well defined: you could want a string ('0'), an int (0), a float (0.0), or a complex (0+0j). How is the poor package supposed to read your mind? Better if it produces an array of Nones. Often, one intends Numeric.zeros() to make an 'empty' array, and an array of Nones is as empty as one can get. From dubois1@llnl.gov Mon Jan 31 16:06:30 2000 From: dubois1@llnl.gov (Paul F. Dubois) Date: Mon, 31 Jan 2000 08:06:30 -0800 Subject: [Matrix-SIG] Zeros In-Reply-To: <3895AF0A.B9D9AF63@bell-labs.com> Message-ID: Your suggestion is not acceptable to me. I understand your reasoning but do not agree with it. I question seriously whether Numerical should have any support for non-numeric types, actually. It causes serious complications for very little real gain. There is an array object in the core that might suit your needs. Also, the Python list type will do what you want perfectly well: [None] * n. If you have an application where n is so large that storage is an issue it would be surprising. And no, I don't accept the proposition that storage is always an issue. If you are only filling up "some" of the entries, it is clear you aren't subsequently doing arithmetic on the arrays. Best regards, Paul -----Original Message----- From: matrix-sig-admin@python.org [mailto:matrix-sig-admin@python.org]On Behalf Of Greg Kochanski Sent: Monday, January 31, 2000 7:50 AM To: matrix-sig@python.org Subject: [Matrix-SIG] Zeros Speaking of redefining Numeric.zeros(), I've had the need to create an array of Nones, then fill up some of the entries. It would be reasonably nice if Numeric.zeros(size, Numeric.PyObject) produced an array of Nones, rather than the current behavior of producing an array of integer zero python objects. After all, a 'zero' PyObject isn't well defined: you could want a string ('0'), an int (0), a float (0.0), or a complex (0+0j). How is the poor package supposed to read your mind? Better if it produces an array of Nones. Often, one intends Numeric.zeros() to make an 'empty' array, and an array of Nones is as empty as one can get. _______________________________________________ Matrix-SIG maillist - Matrix-SIG@python.org http://www.python.org/mailman/listinfo/matrix-sig From emmanuel.viennet@lipn.univ-paris13.fr Mon Jan 31 16:17:35 2000 From: emmanuel.viennet@lipn.univ-paris13.fr (Emmanuel Viennet) Date: Mon, 31 Jan 2000 17:17:35 +0100 Subject: [Matrix-SIG] Zeros References: Message-ID: <3895B59F.D1F292AD@lipn.univ-paris13.fr> Paul wrote: > I question seriously whether Numerical should have any support for > non-numeric types, actually. It causes serious complications for very little > real gain. There is an array object in the core that might suit your needs. > But one could use multi-dimensional NumPy Object arrays just to take advantage of the sophisticated indexing methods (like ...) which are not available on standard lists. I know that the Objet typecode is currently poorly supported in NumPy, but it may make sense to use it. Emmanuel From gpk@bell-labs.com Mon Jan 31 16:49:45 2000 From: gpk@bell-labs.com (Greg Kochanski) Date: Mon, 31 Jan 2000 11:49:45 -0500 Subject: [Matrix-SIG] Zeros Message-ID: <3895BD29.D5EACB6F@bell-labs.com> "Paul F. Dubois" wrote: > > I question seriously whether Numerical should have any support for > non-numeric types, actually. > It causes serious complications for very little > real gain. There is an array object in the core that might suit your needs. True enough. However, I use _Numeric_ instead of _array_, to reduce the number of modules that need to be imported. Personally, I see little reason for the array module to continue to exist, given Numeric. One characteristic of a good programming language is that it minimizes the amount of stuff the programmer needs to memorize. Why have two nearly equivalent array modules, and force people to memorize the differences and special cases? Programming is not just a case of MFLOPS and storage efficiency: often development and maintenance time is the limiting factor, which is why I'd rather bring in one module instead of two. > Also, the Python list type will do what you want perfectly well: [None] * n. > If you have an application where n is so large that storage is an issue it > would be surprising. The issue is not storage so much as having a uniform programming interface. From gpk@bell-labs.com Mon Jan 31 17:30:55 2000 From: gpk@bell-labs.com (Greg Kochanski) Date: Mon, 31 Jan 2000 12:30:55 -0500 Subject: [Matrix-SIG] Bug in LinearAlgebra.linear_least_squares() Message-ID: <3895C6CF.49659840@bell-labs.com> The documentation string states: If the rank of A is less than the number of columns of A or greater than the numer of rows, then residuals will be returned as an empty array otherwise resids = sum((b-dot(A,x)**2). This is not quite correct. One can have a fit that has a low rank, (i.e., the basis functions are degenerate) that still doesn't completely explain the data. For instance, fitting the sequence [1.1, 2, 3, 4] with basis functions [1, 2, 3, 4] and [0, 0, 0, 0] will yield a rank of 1, and ought to yield a nonzero residual. Granted, LAPACK is the lazy one, failing to calculate the residual, and the LinearAlgebra module is just passing it on, but the absence of the residual ought to be fixed or at least noted as a bug in the documentation. >>> >>> a array([[ 1., 0.], [ 2., 0.], [ 3., 0.], [ 4., 0.]]) >>> b array([ 1.1, 2. , 3. , 4. ]) >>> >>> LinearAlgebra.linear_least_squares(a, b) (array([ 1.00333333, 0. ]), zeros((0,), 'd'), 1, array([ 5.47722558, 0. ])) >>> >>> Numeric.matrixmultiply(a, [ 1.00333333, 0. ]) array([ 1.00333333, 2.00666666, 3.00999999, 4.01333332]) >>> # Note that we don't quite recover the original sequence, # so the residuals are nonzero. From frohne@gci.net Mon Jan 31 17:57:28 2000 From: frohne@gci.net (Ivan Frohne) Date: Mon, 31 Jan 2000 08:57:28 -0900 Subject: [Matrix-SIG] Zeros In-Reply-To: <3895BD29.D5EACB6F@bell-labs.com> Message-ID: <4.3.0.33.0.20000131085225.00a78550@mail.gci.net> At 07:49 31-01-00 , Greg Kochanski wrote: > Personally, I see little >reason for the array module to continue to exist, given Numeric. Whoa now! Hands off the array module. For single dimension calculations, (which is all they're good for, I know), Python arrays are significantly faster than Numeric arrays. Sometimes it's faster to convert a Numeric array to a Python array before processing it. --Ivan Frohne From cgw@fnal.gov Mon Jan 31 19:00:32 2000 From: cgw@fnal.gov (Charles G Waldman) Date: Mon, 31 Jan 2000 13:00:32 -0600 (CST) Subject: [Matrix-SIG] Zeros In-Reply-To: References: <3895AF0A.B9D9AF63@bell-labs.com> Message-ID: <14485.56272.978010.825744@buffalo.fnal.gov> Paul F. Dubois writes: > I question seriously whether Numerical should have any support for > non-numeric types, actually. It causes serious complications for very little > real gain. There is an array object in the core that might suit your needs. 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. Then when I'm happy with that, I can plug in numeric values and have a fast number-crunching engine. For instance: >>> from Numeric import * >>> from LinearAlgebra import determinant >>> det=determinant >>> class Poly: ... def __init__(self,val): ... self.val=val ... def __add__(self,other): ... return Poly("%s+%s"%(self.val,other.val)) ... def __mul__(self,other): ... return Poly("%s*%s"%(self.val,other.val)) ... def __repr__(self): ... return self.val ... def __str__(self): ... return self.val ... >>> a,b,c,d=map(Poly,'abcd') >>> a a >>> a+b a+b >>> m=array([a,b,c,d],'O') >>> m.shape=2,2 >>> m array([[a , b ], [c , d ]],'O') >>> m*m array([[a*a , b*b ], [c*c , d*d ]],'O') >>> m2=array([w,x,y,z],'O') >>> m2.shape=2,2 >>> dot(m,m2) array([[a*w+b*y , a*x+b*z ], [c*w+d*y , c*x+d*z ]],'O') This, IMO, is a great way to test code and see that your matrix calculations are actually doing what you want them to. Seems to me like the combination of unlimited Python dynamism and speed when you need it, is something really unique to NumPy.... the possibility that you could create arrays of rational numbers, or elements of a finite field, etc, and compute with those is something I'd not like to see go away. Unfortunately, as has been pointed out many times, the support for type 'O' arrays is not uniform: >>> det(m) Traceback (innermost last): File "", line 1, in ? File "/usr/lib/python1.5/site-packages/Numeric/LinearAlgebra.py", line 228, in determinant t =_commonType(a) File "/usr/lib/python1.5/site-packages/Numeric/LinearAlgebra.py", line 27, in _commonType kind = max(kind, _array_kind[t]) KeyError: O I think the solution to this is not to eliminate type 'O' but to do some work to make it work better. Of course I realize whom the burden of such work rests upon...