Hi Francesc,
> Subject: Re: [Pytables-users] ANN: carray 0.3.1
>
> A Wednesday 19 January 2011 22:38:46 Han Genuit escrigué:
> > Hey Francesc,
> >
> > Congrats, multidim support!
>
> Thanks!
>
> > I had a few short questions about the carray;
> >
> > - Are you planning to implement operator overloading for carrays?
> > For example, a<10 gives a boolean array for numpy, but gives False
> > in the case of a carray, but ca.eval('a<10') works also for
> > carrays.
>
> Yeah, this should be nice. However, it is not among my priorities right
> now.
>
If you could use ca.eval 'under the hood', this should not be too difficult to
implement, I think..
> > - Is there a reason why multidimensional slicing is not supported?
> > Stuff like a[:,2] is very nice imo.. [r[2] for r in a] builds a
> > list, and is a lot slower than the np variant..
>
> Well, I'm thinking about it because it should be feasible to implement
> a[:,2]. But I'm a bit reluctant because what I've actually implemented
> are multidimensional dtypes, not fully multidimensional carrays. The
> difference is somewhat subtle. For example, NumPy does not allow to
> have arrays with multidimensional dtypes:
>
> >>> import numpy as np
> >>> np.zeros(5, dtype="(2,)i4").dtype
> dtype('int32') # where is the (2,) dimension?
> >>> np.zeros(5, dtype="(2,)i4").shape
> (5, 2) # it is appended to shape
>
Ah, I never knew that you can implement multidimensional dtypes in Numpy.. Does
it work the same way as in structured arrays, where an array element can have
multiple components?
> >>> import carray as ca
> >>> ca.zeros(5, dtype="(2,)i4").dtype
> dtype(('int32',(2,))) # the shape of dtype is kept
> >>> ca.zeros(5, dtype="(2,)i4").shape
> (5,) # shape only contains the leading dimension
> # ... shape trailing dimensions are added to dtype:
> >>> ca.zeros((5,2), dtype="(2,)i4").dtype
> dtype(('int32',(2, 2)))
>
> So, carray goes the opposite path than NumPy: instead of transferring
> dimensions from dtype to shape, it transfers dims from shape to dtype.
> I've chosen this way mainly for simplicity reasons (mixing
> multidimensionality and chunking is not an easy thing).
>
Very interesting! To get the original dtype back, you can refer to dtype.base:
>>> a = ca.zeros((5,2), dtype="(2,)i4")
>>> a.dtype.base
dtype('int32')
And to get the total shape, you have to add both the array shape and the dtype
shape:
>>> a.shape + a.dtype.shape
(5, 2, 2)
So that might be something to hold in mind.. ^^
> The idea is that the carray package should be seen as a way to deal with
> observations, not as a general replacement for NumPy. And observations
> are normally made of large collections of items, where each item can be
> made of a number of fields. What I'm allowing in 0.3.1 is that these
> fields can be multidimensional objects.
>
I understand.. would it be an idea, though, to implement a feature that can
transparantly compare Numpy shapes and types with carray shapes and types?
> > - Is that also the reason why the shape information resides partly
> > in the dtype? Problem is that if you do:
> > b = ca.arange(9).reshape((3,3))
> > Then b.shape is (3,), which is not (3,3)..
> > The same issue with the dtype, which is not comparable to the
> > original, e.g. not atomic..
>
> Hope that I've answered this above :)
>
Indeed, thanks!
> Cheers!
>
> --
> Francesc Alted
>
Regards,
Han
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Pytables-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pytables-users
