From: Charles R H. <cha...@gm...> - 2006-09-07 19:22:04
|
On 9/7/06, Travis Oliphant <oli...@ie...> wrote: > > Charles R Harris wrote: > > On 9/6/06, *Charles R Harris* <cha...@gm... > > <mailto:cha...@gm...>> wrote: > > > > > > > > On 9/6/06, *Travis Oliphant* < oli...@ie... > > <mailto:oli...@ie...>> wrote: > > > > Charles R Harris wrote: > > > > > > Where is array at this point? > > Basically it supports the old Numeric behavior wherein object > > array's > > are treated as before *except* for when an error would have > > occurred > > previously when the "new behavior" kicks in. Anything that > > violates > > that is a bug needing to be fixed. > > > > This leaves the new object-array constructor used less > > often. It could > > be exported explicitly into an oarray constructor, but I'm not > > sure > > about the advantages of that approach. There are benefits to > > having > > object arrays constructed in the same way as other arrays. It > > turns out > > many people actually like that feature of Numeric, which is > > the reason I > > didn't go the route of numarray which pulled object arrays out. > > > > At this point, however, object arrays can even be part of > > records and so > > need to be an integral part of the data-type description. > > Pulling that > > out is not going to happen. A more intelligent object-array > > constructor, however, may be a useful tool. > > > > > > OK. I do have a couple of questions. Let me insert the docs for > > array and asarray : > > > > """array(object, dtype=None, copy=1,order=None, subok=0,ndmin=0) > > > > Return an array from object with the specified date-type. > > > > Inputs: > > object - an array, any object exposing the array interface, > any > > object whose __array__ method returns an array, or > any > > (nested) sequence. > > dtype - The desired data-type for the array. If not given, > > then > > the type will be determined as the minimum type > > required > > to hold the objects in the sequence. This > > argument can only > > be used to 'upcast' the array. For downcasting, > > use the > > .astype(t) method. > > copy - If true, then force a copy. Otherwise a copy will > > only occur > > if __array__ returns a copy, obj is a nested > > sequence, or > > a copy is needed to satisfy any of the other > > requirements > > order - Specify the order of the array. If order is 'C', > > then the > > array will be in C-contiguous order (last-index > > varies the > > fastest). If order is 'FORTRAN', then the > > returned array > > will be in Fortran-contiguous order (first-index > > varies the > > fastest). If order is None, then the returned > > array may > > be in either C-, or Fortran-contiguous order or even > > discontiguous. > > subok - If True, then sub-classes will be passed-through, > > otherwise > > the returned array will be forced to be a > > base-class array > > ndmin - Specifies the minimum number of dimensions that the > > resulting > > array should have. 1's will be pre-pended to the > > shape as > > needed to meet this requirement. > > > > """) > > > > asarray(a, dtype=None, order=None) > > Returns a as an array. > > > > Unlike array(), no copy is performed if a is already an array. > > Subclasses > > are converted to base class ndarray. > > > > 1) Is it true that array doesn't always return a copy except by > > default? asarray says it contrasts with array in this regard. > > Maybe copy=0 should be deprecated. > > > > 2) Is asarray is basically array with copy=0? > > > > 3) Is asanyarray basically array with copy=0 and subok=1? > > > > 4) Is there some sort of precedence table for conversions? To me > > it looks like the most deeply nested lists are converted to arrays > > first, numeric if they contain all numeric types, object > > otherwise. I assume the algorithm then ascends up through the > > hierarchy like traversing a binary tree in postorder? > > > > 5) All nesting must be to the same depth and the deepest nested > > items must have the same length. > > > > 6) How is the difference between lists and "lists" determined, i.e., > > > > In [3]: array([list([1,2,3]),list([1,2])], dtype = object) > > Out[3]: array([[1, 2, 3], [1, 2]], dtype=object) > > > > In [8]: array([array([1,2,3]),array([1,2])], dtype = object) > > Out[8]: array([[1 2 3], [1 2]], dtype=object) > > > > > > In [9]: array([1,2,3],[1,2]], dtype = object) > > ------------------------------------------------------------ > > File "<ipython console>", line 1 > > array([1,2,3],[1,2]], dtype = object) > > ^ > > SyntaxError: invalid syntax > > > > Is the difference that list(...) and array(...) are passed as > > functions (lazy evaluation), but a list is just a list? > > > > Sorry to be asking all these questions, but I would like to try > > making the documentation be a bit of a reference. I am sure I will > > have more questions ;) > > > > -Travis > > > > > > And, voila, ragged arrays: > > > > In [9]: a = array([array([1,2,3]),array([1,2])], dtype = object) > > > > In [10]: a*2 > > Out[10]: array([[2 4 6], [2 4]], dtype=object) > > > > In [11]: a + a > > Out[11]: array([[2 4 6], [2 4]], dtype=object) > > Now I remember that this was my original motivation for futzing with the > object-array constructor in the first place. So, now you get there only > after an attempt to make a "rectangular" array first. > > -Travis So is this intentional? In [24]: a = array([[],[],[]], dtype=object) In [25]: a.shape Out[25]: (3, 0) In [26]: a = array([], dtype=object) In [27]: a.shape Out[27]: (0,) One could argue that the first array should have shape (3,) Chuck |