You can subscribe to this list here.
2000 
_{Jan}
(8) 
_{Feb}
(49) 
_{Mar}
(48) 
_{Apr}
(28) 
_{May}
(37) 
_{Jun}
(28) 
_{Jul}
(16) 
_{Aug}
(16) 
_{Sep}
(44) 
_{Oct}
(61) 
_{Nov}
(31) 
_{Dec}
(24) 

2001 
_{Jan}
(56) 
_{Feb}
(54) 
_{Mar}
(41) 
_{Apr}
(71) 
_{May}
(48) 
_{Jun}
(32) 
_{Jul}
(53) 
_{Aug}
(91) 
_{Sep}
(56) 
_{Oct}
(33) 
_{Nov}
(81) 
_{Dec}
(54) 
2002 
_{Jan}
(72) 
_{Feb}
(37) 
_{Mar}
(126) 
_{Apr}
(62) 
_{May}
(34) 
_{Jun}
(124) 
_{Jul}
(36) 
_{Aug}
(34) 
_{Sep}
(60) 
_{Oct}
(37) 
_{Nov}
(23) 
_{Dec}
(104) 
2003 
_{Jan}
(110) 
_{Feb}
(73) 
_{Mar}
(42) 
_{Apr}
(8) 
_{May}
(76) 
_{Jun}
(14) 
_{Jul}
(52) 
_{Aug}
(26) 
_{Sep}
(108) 
_{Oct}
(82) 
_{Nov}
(89) 
_{Dec}
(94) 
2004 
_{Jan}
(117) 
_{Feb}
(86) 
_{Mar}
(75) 
_{Apr}
(55) 
_{May}
(75) 
_{Jun}
(160) 
_{Jul}
(152) 
_{Aug}
(86) 
_{Sep}
(75) 
_{Oct}
(134) 
_{Nov}
(62) 
_{Dec}
(60) 
2005 
_{Jan}
(187) 
_{Feb}
(318) 
_{Mar}
(296) 
_{Apr}
(205) 
_{May}
(84) 
_{Jun}
(63) 
_{Jul}
(122) 
_{Aug}
(59) 
_{Sep}
(66) 
_{Oct}
(148) 
_{Nov}
(120) 
_{Dec}
(70) 
2006 
_{Jan}
(460) 
_{Feb}
(683) 
_{Mar}
(589) 
_{Apr}
(559) 
_{May}
(445) 
_{Jun}
(712) 
_{Jul}
(815) 
_{Aug}
(663) 
_{Sep}
(559) 
_{Oct}
(930) 
_{Nov}
(373) 
_{Dec}

From: Paul Barrett <B<arrett@st...>  20000208 20:13:12

Travis Oliphant writes: > > > > 1) The reuse of temporary arrays  to conserve memory. > > Please elaborate about this request. When Python evaluates the expression: >>> Y = B*X + A where A, B, X, and Y are all arrays, B*X creates a temporary array, T. A new array, Y, will be created to hold the result of T + A, and T will be deleted. If T and Y have the same shape and typecode, then instead of creating Y, T can be reused to conserve memory. > > > > 2) A copyonwrite option  to enhance performance. > > > > I need more explanation of this as well. This would be an advanced feature of arrays that use memorymapping or access their arrays from disk. It is similar to the secondary cache of a CPU. The data is held in memory until a write request is made. > > > > 3) The initialization of arrays by default  to help novices. > > What kind of initialization are you taking about (we have zeros and ones > and random already). For mixedtype (or object) arrays containing strings, zeros() and ones() would be confusing. Therefore by default, integer and floating types are initialized to 0 and string types to ' ', and the option would be available to not initialize the array for performance. > > > > 4) The creation of a standard API  which I guess is assumed, if it > > is to be part of the Python standard distribution. > > Any suggestions as to what needs to be changed in the already somewhat > standard API. No, not exactly. But the last time I looked, I thought some improvements could be made to it. > > > > 5) The inclusion of IEEE support. > > This was supposed to be there from the beginning, but it didn't get > finished. Jim's original idea was to have two math modules, one which > checked and gave error's for 1/0 and another that returned IEEE inf for > 1/0. > > The current umath does both with different types which is annoying. When I last spoke to Jim about this at IPC6, I was under the impression that IEEE support was not fully implemented and much work still needed to be done. Has this situation changed since then? > > > > And > > > > 6) Enhanced support for mixedtypes or objects. > > > > This last issue is very import to me and the astronomical community, > > since we routinely store data as (multidimensional) arrays of fixed > > length records or Cstructures. A current deficiency of NumPy is that > > the object typecode does not work with the fromstring() method, so > > importing arrays of records from a binary file is just not possible. > > I've been developing my own Cextension type to handle this situation > > and have come to realize that my record type is really just a > > generalization of NumPy's types. > > > I would like to see the code for your generalized type which would help me > see if there were some relatively painless way the two could be merged. recordmodule.c is part of my PyFITS module for dealing with FITS files. You can find it here: ftp://ra.stsci.edu/pub/barrett/PyFITS_0.3.tgz I use NumPy to access fixedtype arrays and the record type for accessing mixedtype arrays. A common example is accessing the second element of a mixedtype (ie. an object) from the entire array. This returns a record type with a single element, which is equivalent to a NumPy array of fixed type. Therefore users expect this object to be a NumPy array and it isn't. They have to convert it to one. > > two Cextension types merged. I think this enhancement can be done > > with minimal change to the current NumPy behavior and minor changes to > > the typecode system. > > If you already see how to do it, then great. Note that NumPy already has some support for an Object type. It has been proposed that it be removed, because it is not well supported and hence few people use it. I have the contrary opinion and feel we should enhance the Object type and make it much more usable. If you don't need it, then you don't have to use it. This enhancement really shouldn't get in the way of those who only use fixedtype arrays. So what changes to NumPy are needed? 1) Instead of a typecode (or in addition to the typecode for backward compatibility), I suggest an optional format keyword, which can be used to specify the mixedtype or object format. Namely, format = 'i, f, s10', where 'i' is an integer type, 'f' a floating point type, and s10 is a string of 10 characters. 2) Array access will be the same as it is now. For example # Create a 10x10 mixedtype array. A = array((10, 10), format = 'i, f, 10s') # Create a 10x10 fixedtype array. B = array((10, 10), typecode = 'i') # Print a 5x5 subarray of mixedtype. print A[:5,:5] # Print a 5x5 subarray of fixedtype print B[:5,:5] # Or # (Note that the 3rd index is optional for fixedtype arrays, it # always defaults to 0.) print B[:5,:5,0] # Print the second element of the mixedtype of the entire array. # Note that this is now an array of fixedtype. print A[:,:,1] The major thorn that I see at this point is how to reconcile the behavior of numbers and strings during operations. But I don't see this as an intractable problem. I actually believe this enhancement will encourage us to create a better and more generic multidimensional array module by concentrating on the behavioral aspects of this extension type. Note that J, which NumPy is base upon, allows such mixedtypes.  Dr. Paul Barrett Space Telescope Science Institute Phone: 4105166714 DESD/DPT FAX: 4105168615 Baltimore, MD 21218 
From: Konrad Hinsen <hinsen@cn...>  20000208 19:58:14

> I know this will be a sticky point. I'm not sure what to do exactly, but > the current behavior and implementation makes the semantics for slicing an > array using a sequence problematic since I don't see a way to represent a You are right there. But is it really necessary to extend the meaning of slices? Of course everyone wants the functionality of indexing with a sequence, but I'd be perfectly happy to have it implemented as a method. Indexing would remain as it is (by reference), and a new method would provide copying behaviour for element extraction and also permit more generalized sequence indices. In addition to backwards compatibility, there is another argument for keeping indexing behaviour as it is: compatibility with other Python sequence types. If you have a list of lists, which in many ways behaves like a 2D array, and extract the third element (which is thus a list), then this data is shared with the full nested list. > > How do you plan to implement mixed arithmetic with scalars? If the > > return value is a rank0 array, then a single library returning > > a rank0 array somewhere could mess up a program well enough that > > debugging becomes a nightmare. > > > > Mixed arithmetic in general is another sticky point. I went back and read > the discussion of this point which occured 19951996. It was very What I meant was not mixedprecision arithmetic, but arithmetic in which one operand is a scalar and the other one a rank0 array. Which reminds me: rank0 arrays are also incompatible with the nestedlist view of arrays. The elements of a list of numbers are numbers, not numberlike sequence objects. But back to precision, which is also a popular subject: > discussion with a colleague who is starting to "get in" to Numerical > Python and he has really been annoyed with the current mixed arithmetic > rules. The seem to try to outguess the user. The spacesaving concept > helps, but it still seem's like a hack to me. I wouldn't say that the current system tries to outguess the user. It simply gives precision a higher priority than memory space. That might not coincide with what a particular user wants, but it is consistent and easy to understand. > I know there are several opinions, so I'll offer mine. We need > simple rules that are easy to teach a newcomer. Right now the rule is > farily simple in that coercion always proceeds up. But, mixed arithmetic Like in Python (for scalars), C, Fortran, and all other languages that I can think of. > Konrad, 4 years ago, you talked about unexpected losses of precision if > this were allowed to happen, but I couldn't understand how. To me, it is > unexpected to have double precision arrays which are really only > carrying singleprecision results. My idea of the coercion hierchy is I think this is a confusion of two different meanings of "precision". In numerical algorithms, precision refers to the deviation between an ideal and a real numerical value. In programming languages, it refers to the *maximum* precision that can be stored in a given data type (and is in fact often combined with a difference in range). The upcasting rule thus ensures that 1) No precision is lost accidentally. If you multiply a float by a double, the float might contain the exact number 2, and thus have infinite precision. The language can't know this, so it acts conservatively and chooses the "bigger" type. 2) No overflow occurs unless it is unavoidable (the range problem). > The casual user will never use single precision arrays and so will not > even notice they are there unless they request them. If they do request There are many ways in which singleprecision arrays can creep into a program without a user's attention. Suppose you send me some data in a pickled array, which happens to be singleprecision. Or I call a library routine that does some internal calculation on huge data arrays, which it keeps at single precision, and (intentionally or by error) returns a singleprecision result. I think your "active flag" solution is a rather good solution to the casting problem, because it gives access to a different behaviour in a very explicit way. So unless future experience points out problems, I'd propose to keep it. Konrad.   Konrad Hinsen  EMail: hinsen@... Centre de Biophysique Moleculaire (CNRS)  Tel.: +332.38.25.55.69 Rue Charles Sadron  Fax: +332.38.63.15.17 45071 Orleans Cedex 2  Deutsch/Esperanto/English/ France  Nederlands/Francais  
From: Pearu Peterson <pearu@io...>  20000208 19:48:23

On Tue, 8 Feb 2000, Travis Oliphant wrote: > I know there are several opinions, so I'll offer mine. We need > simple rules that are easy to teach a newcomer. Right now the rule is > farily simple in that coercion always proceeds up. But, mixed arithmetic > with a float and a double does not produce something with double > precision  yet that's our rule. I think any automatic conversion should > go the other way. Remark: If you are consistent then you say here that mixed arithmetic with an int and a float/double produces int?! Right? (I hope that I am wrong.) > Boolean > Character > Unsigned > long > int > short > Signed > long > int > short How about `/* long long */'? Is this left out intentionally? > Real > /* long double */ > double > float Travis, while you are doing revision on NumPy, could you also estimate the degree of difficulty of introducing column major order arrays? Pearu 
From: Paul F. Dubois <pauldubois@ho...>  20000208 18:03:22

Before we all rattle on too long about precision, I'd like to point out that selecting a precision actually carries two consequences in the context of computer languages: 1. Expected: The number of digits of accuracy in the representation of a floating point number. 2. Unexpected: The range of numbers that can be represented by this type. Thus, to a scientist it is perfectly logical that if d is a double and f is a single, d * f has only single precision validity. Unfortunately in a computer if you hold this answer in a single, then it may fail if the contents of d include numbers outside the single range, even if f is 1.0. Thus the rules in C and Fortran that coercion is UP had to do as much with range as precision. 
From: Travis Oliphant <Oliphant.T<ravis@ma...>  20000208 17:41:00

> > 3) Facility for memorymapped dataspace in arrays. > > I'd really like to have that... This is pretty easy to add but it does require some changes to the underlying structure, So you can expect it. > > > 4) Slices become copies with the addition of methods for current strict > > referencing behavior. > > This will break a lot of code, and in a way that will be difficult to > debug. In fact, this is the only point you mention which would be > reason enough for me not to use your modified version; going through > all of my code to check what effect this might have sounds like a > nightmare. I know this will be a sticky point. I'm not sure what to do exactly, but the current behavior and implementation makes the semantics for slicing an array using a sequence problematic since I don't see a way to represent a reference to a sequence of indices in the underlying structure of an array. So such slices would have to be copies and not references, which makes for an inconsistent code. > > I see the point of having a copying version as well, but why not > implement the copying behaviour as methods and leave indexing as it > is? I want to agree with you, but I think we may need to change the behavior eventually so when is it going to happen? > > > 5) Handling of sliceobjects which consist of sequences of indices (so that > > setting and getting elements of arrays using their index is possible). > > Sounds good as well... This facility is already embedded in the underlying structure. My plan is to go with the original idea that Jim Hugunin and Chris Chase had for slice objects. The sliceobject in python is already general enough for this to work. > > > 6) Rank0 arrays will not be autoconverted to Python scalars, but will > > still behave as Python scalars whenever Python allows general scalarlike > > objects in it's operations. Methods will allow the > > usercontrolled conversion to the Python scalars. > > I suspect that full behaviourcompatibility with scalars is > impossible, but I am willing to be proven wrong. For example, Python > scalars are immutable, arrays aren't. This also means that rank0 > arrays can't be used as keys in dictionaries. > > How do you plan to implement mixed arithmetic with scalars? If the > return value is a rank0 array, then a single library returning > a rank0 array somewhere could mess up a program well enough that > debugging becomes a nightmare. > Mixed arithmetic in general is another sticky point. I went back and read the discussion of this point which occured 19951996. It was very interesting reading and a lot of points were made. Now we have several years of experience and we should apply what we've learned (of course we've all learned different things :) ). Konrad, you had a lot to say on this point 4 years ago. I've had a long discussion with a colleague who is starting to "get in" to Numerical Python and he has really been annoyed with the current mixed arithmetic rules. The seem to try to outguess the user. The spacesaving concept helps, but it still seem's like a hack to me. I know there are several opinions, so I'll offer mine. We need simple rules that are easy to teach a newcomer. Right now the rule is farily simple in that coercion always proceeds up. But, mixed arithmetic with a float and a double does not produce something with double precision  yet that's our rule. I think any automatic conversion should go the other way. Konrad, 4 years ago, you talked about unexpected losses of precision if this were allowed to happen, but I couldn't understand how. To me, it is unexpected to have double precision arrays which are really only carrying singleprecision results. My idea of the coercion hierchy is shown below with conversion always happening down when called for. The Python scalars get mapped to the "largest precision" in their category and then normal coercions rules take place. The casual user will never use single precision arrays and so will not even notice they are there unless they request them. If they do request them, they don't want them suddenly changing precision. That is my take anyway. Boolean Character Unsigned long int short Signed long int short Real /* long double */ double float Complex /* __complex__ long double */ __complex__ double __complex__ float Object > > 7) Addition of attributes so that different users can configure aspects of > > the math behavior, to their hearts content. > > You mean global attributes? That could be the end of universally > usable library modules, supposing that people actually use them. I thought I did, but I've changed my mind after reading the discussion in 1995. I don't like global attributes either, so I'm not going there. > > > If their is anyone interested in helping in this "unofficial branch > > work" let me know and we'll see about setting up someplace to work. Be > > I don't have much time at the moment, but I could still help out with > testing etc. Konrad you were very instrumental in getting NumPy off the ground in the first place and I will always appreciate your input. 
From: <hinsen@di...>  20000208 17:15:25

> 3) Facility for memorymapped dataspace in arrays. I'd really like to have that... > 4) Slices become copies with the addition of methods for current strict > referencing behavior. This will break a lot of code, and in a way that will be difficult to debug. In fact, this is the only point you mention which would be reason enough for me not to use your modified version; going through all of my code to check what effect this might have sounds like a nightmare. I see the point of having a copying version as well, but why not implement the copying behaviour as methods and leave indexing as it is? > 5) Handling of sliceobjects which consist of sequences of indices (so that > setting and getting elements of arrays using their index is possible). Sounds good as well... > 6) Rank0 arrays will not be autoconverted to Python scalars, but will > still behave as Python scalars whenever Python allows general scalarlike > objects in it's operations. Methods will allow the > usercontrolled conversion to the Python scalars. I suspect that full behaviourcompatibility with scalars is impossible, but I am willing to be proven wrong. For example, Python scalars are immutable, arrays aren't. This also means that rank0 arrays can't be used as keys in dictionaries. How do you plan to implement mixed arithmetic with scalars? If the return value is a rank0 array, then a single library returning a rank0 array somewhere could mess up a program well enough that debugging becomes a nightmare. > 7) Addition of attributes so that different users can configure aspects of > the math behavior, to their hearts content. You mean global attributes? That could be the end of universally usable library modules, supposing that people actually use them. > If their is anyone interested in helping in this "unofficial branch > work" let me know and we'll see about setting up someplace to work. Be I don't have much time at the moment, but I could still help out with testing etc. Konrad.   Konrad Hinsen  EMail: hinsen@... Centre de Biophysique Moleculaire (CNRS)  Tel.: +332.38.25.55.69 Rue Charles Sadron  Fax: +332.38.63.15.17 45071 Orleans Cedex 2  Deutsch/Esperanto/English/ France  Nederlands/Francais  
From: Konrad Hinsen <hinsen@cn...>  20000208 17:15:23

> 3) Facility for memorymapped dataspace in arrays. I'd really like to have that... > 4) Slices become copies with the addition of methods for current strict > referencing behavior. This will break a lot of code, and in a way that will be difficult to debug. In fact, this is the only point you mention which would be reason enough for me not to use your modified version; going through all of my code to check what effect this might have sounds like a nightmare. I see the point of having a copying version as well, but why not implement the copying behaviour as methods and leave indexing as it is? > 5) Handling of sliceobjects which consist of sequences of indices (so that > setting and getting elements of arrays using their index is possible). Sounds good as well... > 6) Rank0 arrays will not be autoconverted to Python scalars, but will > still behave as Python scalars whenever Python allows general scalarlike > objects in it's operations. Methods will allow the > usercontrolled conversion to the Python scalars. I suspect that full behaviourcompatibility with scalars is impossible, but I am willing to be proven wrong. For example, Python scalars are immutable, arrays aren't. This also means that rank0 arrays can't be used as keys in dictionaries. How do you plan to implement mixed arithmetic with scalars? If the return value is a rank0 array, then a single library returning a rank0 array somewhere could mess up a program well enough that debugging becomes a nightmare. > 7) Addition of attributes so that different users can configure aspects of > the math behavior, to their hearts content. You mean global attributes? That could be the end of universally usable library modules, supposing that people actually use them. > If their is anyone interested in helping in this "unofficial branch > work" let me know and we'll see about setting up someplace to work. Be I don't have much time at the moment, but I could still help out with testing etc. Konrad.   Konrad Hinsen  EMail: hinsen@... Centre de Biophysique Moleculaire (CNRS)  Tel.: +332.38.25.55.69 Rue Charles Sadron  Fax: +332.38.63.15.17 45071 Orleans Cedex 2  Deutsch/Esperanto/English/ France  Nederlands/Francais  
From: John Travers <archiver@db...>  20000208 15:54:43

This message was sent from Geocrawler.com by "John Travers" <j.c.travers@...> Be sure to reply to that address. If the above was implemented, I would be very happy indeed. As a maths student, I use NumPy a lot. And get infuriated with the current implementation. John. Geocrawler.com  The Knowledge Archive 
From: Paul F. Dubois <dubois1@ll...>  20000208 00:29:37

Travis says that I don't necessarily endorse his goals but in fact I do, strongly. If I understand right he intends to make a CVS branch for this experiment and that is fine with me. The only goal I didn't quite understand was: Addition of attributes so that different users can configure aspects of the math behavior, to their hearts content. In a world of reusable components the situation is complicated. I would not like to support a dotproduct routine, for example, if the user could turn off any double precision behind my back. My needs for precision are local to my algorithm. 
From: Travis Oliphant <Oliphant.T<ravis@ma...>  20000208 00:11:26

I wanted to let users of the community know (so they can help if they want, or offer criticism or comments) that over the next several months I will be experimenting with a branch of the main Numerical source tree and endeavoring to "cleanup" the code for Numerical Python. I have in mind a few (in my opinion minor) alterations to the current codebase which necessitates a branch. Guido has made some good suggestions for improving the code base, and both David Ascher and Paul Dubois have expressed concerns over the current state of the source code and given suggestions as to how to improve it. That said, I should emphasize that my work is not authorized, or endorsed, by any of the people mentioned above. It is simply my little experiment. My intent is not to recreate Numerical Python  I like most of the current functionality  but to merely, cleanup the code, comment it, and change the underlying structure just a bit and add some features I want. One goal I have is to create something that can go into Python 1.7 at some future point, so this incarnation of Numerical Python may not be completely Csource compatible with current Numerical Python (but it will be close). This means Cextensions that access the underlying structure of the current arrayobject may need some alterations to use this experimental branch if it every becomes useful. I don't know how long this will take me. I'm not promising anything. The purpose of this announcement is just to invite interested parties into the discussion. These are the (somewhat negotiable) directions I will be pursuing. 1) Still written in C but heavily (in my opinion) commented. 2) Addition of bittypes and unsigned integer types. 3) Facility for memorymapped dataspace in arrays. 4) Slices become copies with the addition of methods for current strict referencing behavior. 5) Handling of sliceobjects which consist of sequences of indices (so that setting and getting elements of arrays using their index is possible). 6) Rank0 arrays will not be autoconverted to Python scalars, but will still behave as Python scalars whenever Python allows general scalarlike objects in it's operations. Methods will allow the usercontrolled conversion to the Python scalars. 7) Addition of attributes so that different users can configure aspects of the math behavior, to their hearts content. If their is anyone interested in helping in this "unofficial branch work" let me know and we'll see about setting up someplace to work. Be warned, however, that I like actual code or codetemplates more than just great ideas (truly great ideas are never turned away however ;) ) If something I do benefits the current NumPy source in a noninvasive, backwards compatible way, I will try to place it in the current CVS tree, but that won't be a priority, as my time does have limitations, and I'm scratching my own itch at this point. Best regards, Travis Oliphant 
From: Travis Oliphant <Oliphant.T<ravis@ma...>  20000204 20:51:48

> I'm having a problem with PyArray_Check. If I just call > PyArray_Check(args) I don't have a problem, but if I try to assign the > result to anything, etc., it crashes (due to acces violation). So, for > example the code at the end of this note doesn't work, yet I know an array > is being passed and I can, for example, calculate its trace correctly if I > type cast it as a PyArrayObject*. > > Also, a more general question: is this the recommended way to input numpy > arrays when using swig, or do most people find it easier to use more > elaborate typemaps, or something else? I have some experience with SWIG but it is not my favorite method to use Numerical Python with C, since you have so little control over how things get allocated. Your problem is probably due to the fact that you do not run import_array() in the module header. There is a typemap in SWIG that let's you put commands to run at module initialization. Try this in your *.i file. %init %{ import_array(); %} This may help. Best, Travis 
From: Tom Adelman <tla@re...>  20000203 22:00:45

I'm having a problem with PyArray_Check. If I just call PyArray_Check(args) I don't have a problem, but if I try to assign the result to anything, etc., it crashes (due to acces violation). So, for example the code at the end of this note doesn't work, yet I know an array is being passed and I can, for example, calculate its trace correctly if I type cast it as a PyArrayObject*. Also, a more general question: is this the recommended way to input numpy arrays when using swig, or do most people find it easier to use more elaborate typemaps, or something else? Finally, I apologize if this is the wrong forum to post this question. Please let me know. Thanks, Tom Method from C++ class: PyObject * Test01::trace(PyObject * args) { if (!(PyArray_Check(args))) { // < crashes here PyErr_SetString(PyExc_ValueError, "must use NumPy array"); return NULL; } return NULL; } Swig file: (where typemaps are the ones included with most recent swig) /* TMatrix.i */ %module Ptest %include "typemaps.i" %{ #include "Test01.h" %} class Test01 { public: PyObject * trace(PyObject *INPUT); Test01(); virtual ~Test01(); }; Python code: import Ptest t = Ptest.Test01() import Numeric a = Numeric.arange(1.1, 2.7, .1) b = Numeric.reshape(a, (4,4)) x = t.trace(b) 
From: Joe Van Andel <vanandel@at...>  20000202 18:37:35

I would like a single precision version of 'interp' in the Numeric Core. (I want such a routine since I'm operating on huge single precision arrays, that I don't want promoted to double precision.) I've written such a routine, but Paul Dubois and I are discussing the best way of integrating it into the core. One solution is to simply add a new function 'interpf' to arrayfnsmodule.c . Another solution is to add a typecode=Float option to interp. Any opinions on how this single precision version be handled?  Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@... 
From: Harald HancheOlsen <hanche@ma...>  20000129 02:39:12

>> print Numeric.trace.__doc__ trace(a,offset=0, axis1=0, axis2=1) returns the sum along diagonals (defined by the last two dimenions) of the array. For arrays of rank 2, trace does what you expect, but for arrays of larger rank, it appears to simply sum along each of the two given axes. A simple experiment follows: >>> B array([[[ 1, 10], [ 100, 1000]], [[ 10000, 100000], [ 1000000, 10000000]]]) >>> # What I thought trace(B) would be: >>> B[0,0,0]+B[1,1,0], B[0,0,1]+B[1,1,1] (1000001, 10000010) >>> # But that is not what numpy thinks: >>> Numeric.trace(B) array([ 10001, 10001000]) >>> # Instead, it must be computing it as follows: >>> B[0,0,0]+B[1,0,0], B[0,1,1]+B[1,1,1] (10001, 10001000) That is, trace(B) is the vector C, given by C[i]=sum(B[j,i,i]: j=0,...). A bit more experimentation reveals that trace ignores its fourth argument, consistent with the above result: >>> Numeric.trace(B,0,0,1) array([ 10001, 10001000]) >>> Numeric.trace(B,0,0,2) array([ 10001, 10001000]) Evidently, trace is going to need a rewrite. It might perhaps also benefit from further optional arguments in groups of three, e.g., trace(A, p, 0, 3, q, 1, 2)[k,l,...] = A[i+p,j+q,j,i,k,l,...] with summing over repeated indices (i, j) ala Einstein.  Harald 
From: Harald HancheOlsen <hanche@ma...>  20000129 02:38:37

I am having some problems relating to the current function dot (identical to matrixmultiply, though I haven't seen the equivalence in any documentation). Here is what the docs say: dot(a,b) Will return the dot product of a and b. This is equivalent to matrix multiply for 2d arrays (without the transpose). Somebody who does more linear algebra really needs to do this function right some day! Or the builtin doc string: >>> print Numeric.dot.__doc__ dot(a,b) returns matrixmultiplication between a and b. The productsum is over the last dimension of a and the secondtolast dimension of b. First, this is misleading. It seems to me to indicate that b must have rank at least 2, which experiments indicate is not necessary. Instead, the rule appears to be to use the only axis of b if b has rank 1, and otherwise to use the secondtolast one. Frankly, I think this convention is ill motivated, hard to remember, and even harder to justify. As a mathematician, I can see only one reasonable default choice: One should sum over the last index of a, and the first index of b. Using the Einstein summation convention [*], that would mean that dot(a,b)[j,k,...,m,n,...] = a[j,k,...,i] * b[i,m,n,...] [*] that is, summing over repeated indices  i in this example This would of course yield the current behaviour in the important cases where the rank of b is 1 or 2. But we could do better than this: Why not leave the choice up to the user? We could allow an optional third parameter which should be a pair of indices, indicating the axes to be summed over. The default value of this parameter would be (1, 0). Returning to my example above, the user could then easily compute, for example, dot(a,b,(1,2))[j,k,...,m,n,...] = a[j,i,k,...] * b[m,n,i,...] while the current behaviour of dot would correspond to the new behaviour of dot(a,b,(1,2)) whenever b has rank at least 2. Actually, there is probably a lot of code out there that uses the current behaviour of dot. So I would propose leaving dot untouched, and introducing inner instead, with the behaviour I outlined above. We could even allow any number of pairs of axes to be summed over, for example inner(a,b,(1,2),(2,0))[k,l,...,m,n,...] = a[k,i,j,l,..] * b[j,m,i,n,...] With this notation, one can for example write the HilbertSchmidt inner product of two real 2x2 matrices (the sum of a[i,j]b[j,i] over all i and j) as inner(a,b,(0,1),(1,0)). If my proposal is accepted, the documentation should probably declare dot (and its alias matrixmultiply?) as deprecated and due to disappear in the future, with a pointer to its replacement inner. In the meantime, dot could in fact be replaced by a simple wrapper to inner: def dot(a,b): if len(b.shape) > 1: return inner(a,b,(1,2) else: return inner(a,b) (with the proper embellishments to allow it to be used with python sequences, of course).  Harald 
From: fredrik <archiver@db...>  20000126 22:19:26

This message was sent from Geocrawler.com by "fredrik" <fredriks@...> Be sure to reply to that address. How do i install the latest version of numPy if i have lapack already installed? I'm using distutils. Geocrawler.com  The Knowledge Archive 
From: Pearu Peterson <pearu@io...>  20000126 19:00:11

On Wed, 26 Jan 2000, Travis Oliphant wrote: > > Proclamation: > > Introduce a columnwise array to Numeric Python where data is > > stored in columnwise order that can be used specifically for fortran > > routines. > > This is a very interesting proposal that we should consider carefully. I > seem to recall reading that Jim Hugunin originally had this idea in > mind when he established the concept of contiguousness, etc. > > My current thoughts on this issue are that it is of only syntatic value > and seems like a lot of extra code has to be written in order to provide > this "userfriendliness." I don't see why it is so confusing to > recognize that Fortran just references it's arrays "backwards" (or Python > references them backwards  whatever your preference). How you index > into an array is an arbitrary decision. Numerical Python and Fortran just > have opposite conventions. As long as that is clear, I don't see the > real trouble. If the Fortran documentation calls for an array of > dimension (M,N,L) you pass it a contiguous Python array of shape (L,N,M) >  pretty simple. > > Perhaps someone could enlighten me as to why this is more than just a > aesthetic problem. Right now, I would prefer that the time spent by > someone to "fix" this "problem" went to expanding the availability of > easytouse processing routines for Numerical Python, I think that this expansion would be quicker if the Python/Fortran connection would not introduce this additional question to worry about. > or improving the > crossplatform plotting capabilities. Here I agree with you completely. I can see the following problems when two different conventions are mixed: 1) if your application Python code is larger than "just an example that demonstrates the correct usage of two different conventions" and it can call other C/API modules that do calculations in C convention then you need some kind of book keeping where your matrices need to be transposed and where not, and where to insert additional code for doing transposition. I think this can be done in lower level and more efficiently than most ordinary users would do anyway. 2) Another but minor drawback of having two conventions is that if you have square matrix that is nonsymmetric, then its misuse would be easy and (may be) difficult to discover. On the other hand, I completely understand why my proposal would not be implemented  it looks like it needs lots of work and in short term the gain would not be visible to most users. Pearu 
From: Travis Oliphant <Oliphant.T<ravis@ma...>  20000126 17:47:38

> Proclamation: > Introduce a columnwise array to Numeric Python where data is > stored in columnwise order that can be used specifically for fortran > routines. This is a very interesting proposal that we should consider carefully. I seem to recall reading that Jim Hugunin originally had this idea in mind when he established the concept of contiguousness, etc. My current thoughts on this issue are that it is of only syntatic value and seems like a lot of extra code has to be written in order to provide this "userfriendliness." I don't see why it is so confusing to recognize that Fortran just references it's arrays "backwards" (or Python references them backwards  whatever your preference). How you index into an array is an arbitrary decision. Numerical Python and Fortran just have opposite conventions. As long as that is clear, I don't see the real trouble. If the Fortran documentation calls for an array of dimension (M,N,L) you pass it a contiguous Python array of shape (L,N,M)  pretty simple. Perhaps someone could enlighten me as to why this is more than just a aesthetic problem. Right now, I would prefer that the time spent by someone to "fix" this "problem" went to expanding the availability of easytouse processing routines for Numerical Python, or improving the crossplatform plotting capabilities. I agree that it can be most confusing when you are talking about matrix math since we are so used to thinking of matrix multiplication as A * B = C with a shape analysis of: M X N * N X L = M X L If the matrix multiplacation code is in Fortran, then it expects to get an (M,N) array and a (N,L) array and returns an (M,L) array. But from Python you would pass it arrays with shape (N,M) and (L,N) and get back an (L,M) array which can be confusing to our "understanding" of shape analysis in matrix multiplication: Python matrix multiplication rule if calling a Fortran routine to do the multiplication: (N,M) (L,N) = (L, M) I think a Pythononly class could solve this problem much more easily than changing the underlying Ccode. This new Python Fortranarray class would just make the user think that the shapes were (M,N) and (N,L) and the output shape was (M,L). For future reference, any arrayprocessing codes that somebody writes should take a strides array as an argument, so that it doesn't matter what "order" the array is in. Travis 
From: Pearu Peterson <pearu@io...>  20000126 17:01:43

Hi! Problem: Using Fortran routines from Python C/API is "tricky" when multidimensional arrays are passed in. Cause: Arrays in Fortran are stored in columnwise order while arrays in C are stored in rowwise order. Standard solutions: 1) Create a new C array; copy the data from the old one in columnwise order; pass the new array to fortran; copy changed array back to old one in rowwise order; deallocate the array. 2) Change the storage order of an array in place: elementwise swapping; pass the array to fortran; change the storage order back with elementwise swapping Why standard solutions are not good? 1) Additional memory allocation, that is problem for large arrays; Elementwise copying is time consuming (2 times). 2) It is good as no extra memory is needed but elementwise swapping (2 times) is approx. equivalent with the elementwise copying (4 times). Proclamation: Introduce a columnwise array to Numeric Python where data is stored in columnwise order that can be used specifically for fortran routines. Proposal sketch: 1) Introduce a new flag `row_order'to PyArrayObject structure: row_order == 1 > the data is stored in rowwise order (default, as it is now) row_order == 0 > the data is stored in columnwise order Note that now the concept of contiguousness depends on this flag. 2) Introduce new array "constructors" such as PyArray_CW_FromDims, PyArray_CW_FromDimsAndData, PyArray_CW_ContiguousFromObject, PyArray_CW_CopyFromObject, PyArray_CW_FromObject, etc. that all return arrays with row_order=0 and data stored in columnwise order (that is in case of contiguous results, otherwise strides feature is employd). 3) In order to operations between arrays (possibly with different storage order) would work correctly, many internal functions of NumPy C/API need to be modifyied. 4) anything else? What is the good of this? 1) The fact is that there is a large number of very good scietific tools freely available written in Fortran (Netlib, for instance). And I don't mean only Fortran 77 codes but also Fortran 90/95 codes. 2) Having Numeric Python arrays with data stored in columnwise order, calling Fortran routines from Python becomes really efficient and spacesaving. 3) There should be little performance hit if, say, two arrays with different storage order are multiplied (compared to the operations between noncontiguous arrays in the current implementation). 4) I don't see any reason why older C/API modules would broke because of this change if it is carried out carefully enough. So, backward compability should be there. 5) anything else? What are against of this? 1) Lots of work but with current experience it should not be a problem. 2) The size of the code will grow. 3) I suppose that most people using Numerical Python will not care of calling Fortran routines from Python. Possible reasons: too "tricky" or no need. In the first case, the answer is that there are tools such as PyFort, f2py that solve this problem. In the later case, there is no problem:) 4) anything else? I understand that my proposal is quite radical but taking into account that we want to use Python for many years to come, the use would be more pleasing if one cause of (constant) confusion would be less during this time. Best regards, Pearu 
From: Hassan Aurag <aurag@cr...>  20000122 16:27:52

Hi, I have just seen with pleasure that numpy is on sourceforge. So welcome. I am maintaining and writing a generic mathematical session manager, in which I have a numpy session. The project if you haven't noticed it is at http://gmath.sourceforge.net Now, this done, I'd like to know if you will be making rpm/tar.gz releases available on your site always and preferably on the anonymous ftp site for latest release, like in: ftp://numpy.sourceforge.net/latest/srpms .... If yes, then I'd be happy to make the app go fetch the packages from that site or another instead of making the srpms myself (which means possible bugs!). Thank you in advance. H. Aurag aurag@... aurag@... 
From: Paul F. Dubois <pauldubois@ho...>  20000120 23:13:14

This is a test. Ignore. Paul 