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.
> - 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
>>> 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).
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.
> - 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 :)
Cheers!
--
Francesc Alted
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Pytables-users mailing list
Pytables-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytables-users
