Hi all, I am using a 2-d array to store values that will be an index into a list. It is huge, sot to samve space I have used a type Int16. Now when I pull a value outl it is of type array, so it can not be used to index a sequence. The strange thing is that it works if the array is of rank 1. Some tests:
a.shape = (2,5) #reshape it to be rank-2
# now change the type
a.shape = (2,5) # now change the shape to rank-2
print type(a[1,3]) <type 'array'>
#!!!!!!!#### # Now a single item is of type 'array'
# and it can not be used as an index! I can work around this with an explicite type cast with int(), but it seems like wierd behaviour to me. I am accesing a single item, it is typcaste as an Int when the item is pulled out of a rank-1 array, but it is a rank-0 array when pulled from a rank > 1 array. Any ideas what causes this? Is there a good reson for htis, or is it a bug? -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
Feature, I think. a[1,3] is a rank-0 array, with typecode Int16. There is no other way to handle a Int16 scalar in Python (Int16 is not a python type). This solution allows to correctly propagate the types in array arithmetic, without unwanted upcasts. Emmanuel Chris Barker wrote:
Feature, I think.
Right, but a relatively recent one. In the first NumPy releases, the result was a scalar Integer object. There are good arguments for both variants. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Konrad Hinsen wrote:
OK. I see that there are trade-offs either way, and I certainly see the benefit of keeping the precision consistent(even though it would be easier in this case to have th upcast). I do think it's a bug, however, to have the upcast when pulling a single value out of a 1-d array, but not when pulling it out of a higher rank array:
a = array(((1,2,3),(4,5,6)),Int16)
type(a[1,1]) <type 'array'>
a.shape = (6,)
type(a[2]) <type 'int'>
This seems totally inconsistant. Note that this same effect occurs for arrays of type Float16 (and probably others) By the way, would it be at all possible for Python to accept an array of rank 0 as an index? How big a change would that be? -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
Hi all, I am using a 2-d array to store values that will be an index into a list. It is huge, sot to samve space I have used a type Int16. Now when I pull a value outl it is of type array, so it can not be used to index a sequence. The strange thing is that it works if the array is of rank 1. Some tests:
a.shape = (2,5) #reshape it to be rank-2
# now change the type
a.shape = (2,5) # now change the shape to rank-2
print type(a[1,3]) <type 'array'>
#!!!!!!!#### # Now a single item is of type 'array'
# and it can not be used as an index! I can work around this with an explicite type cast with int(), but it seems like wierd behaviour to me. I am accesing a single item, it is typcaste as an Int when the item is pulled out of a rank-1 array, but it is a rank-0 array when pulled from a rank > 1 array. Any ideas what causes this? Is there a good reson for htis, or is it a bug? -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
Feature, I think. a[1,3] is a rank-0 array, with typecode Int16. There is no other way to handle a Int16 scalar in Python (Int16 is not a python type). This solution allows to correctly propagate the types in array arithmetic, without unwanted upcasts. Emmanuel Chris Barker wrote:
Feature, I think.
Right, but a relatively recent one. In the first NumPy releases, the result was a scalar Integer object. There are good arguments for both variants. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Konrad Hinsen wrote:
OK. I see that there are trade-offs either way, and I certainly see the benefit of keeping the precision consistent(even though it would be easier in this case to have th upcast). I do think it's a bug, however, to have the upcast when pulling a single value out of a 1-d array, but not when pulling it out of a higher rank array:
a = array(((1,2,3),(4,5,6)),Int16)
type(a[1,1]) <type 'array'>
a.shape = (6,)
type(a[2]) <type 'int'>
This seems totally inconsistant. Note that this same effect occurs for arrays of type Float16 (and probably others) By the way, would it be at all possible for Python to accept an array of rank 0 as an index? How big a change would that be? -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
participants (4)
-
Chris Barker -
Emmanuel Viennet -
Konrad Hinsen -
Paul F. Dubois