numpy-discussion

[Numpy-discussion] bug !? dtype type_descriptor does not accept zero length tuple

[Sebastian H. <ha...@ms...>]

Hi!
I have a problem with record array type descriptor.
With numarray this used to work.
My records made of  n integers and m floats.  So I used to be able specify
formats="%di4,%df4"%(self.numInts,self.numFloats) in numarray which would 
translate to 
byteorder = self.isByteSwapped and '>' or '<'
type_descr = [("int",   "%s%di4" %(byteorder,self.numInts)),
                      ("float", "%s%df4" %(byteorder,self.numFloats))]

The problem occurs when numInts or numFloats is zero !?
Could it numpy be changed to silectly accept this case
Here is the complete traceback + some debug info:

'>0i4'Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/haase/PrLinN/Priithon/Mrc.py", line 56, in bindFile
    a = Mrc(fn, mode)
  File "/home/haase/PrLinN/Priithon/Mrc.py", line 204, in __init__
    self.doExtHdrMap()
  File "/home/haase/PrLinN/Priithon/Mrc.py", line 271, in doExtHdrMap
    self.extHdrArray.dtype = type_descr
  File "/home/haase/qqq/lib/python/numpy/core/records.py", line 194, in 
__setattr__
    return object.__setattr__(self, attr, val)
TypeError: invalid data-type for array
>>> U.debug()
> /home/haase/qqq/lib/python/numpy/core/records.py(196)__setattr__()
-> pass
(Pdb) l
191
192         def __setattr__(self, attr, val):
193             try:
194                 return object.__setattr__(self, attr, val)
195             except AttributeError: # Must be a fieldname
196  ->             pass
197             fielddict = sb.ndarray.__getattribute__(self,'dtype').fields
198             try:
199                 res = fielddict[attr][:2]
200             except (TypeError,KeyError):
201                 raise AttributeError, "record array has no attribute %s" % 
attr
(Pdb) p val
[('int', '>0i4'), ('float', '>2f4')]
(Pdb) p attr
'dtype'


Thanks,
Sebastian Haase

Re: [Numpy-discussion] bug !? dtype type_descriptor does not accept zero length tuple

[Travis O. <oli...@ie...>]

Sebastian Haase wrote:
> Hi!
> I have a problem with record array type descriptor.
> With numarray this used to work.
> My records made of  n integers and m floats.  So I used to be able specify
> formats="%di4,%df4"%(self.numInts,self.numFloats) in numarray which would 
> translate to 
> byteorder = self.isByteSwapped and '>' or '<'
> type_descr = [("int",   "%s%di4" %(byteorder,self.numInts)),
>                       ("float", "%s%df4" %(byteorder,self.numFloats))]
>
> The problem occurs when numInts or numFloats is zero !?
> Could it numpy be changed to silectly accept this case
> Here is the complete traceback + some debug info:
>   

If numarray supported it, then we should get NumPy to support it as well 
unless there is a compelling reason not to.  I can't think of any except 
that it might be hard to make it work.  What is '0i4' supposed to mean 
exactly?  Do you get a zero-sized field or is the field not included?   
I think the former will be much easier than the latter.   Would that be 
O.K.?

-Travis

Re: [Numpy-discussion] bug !? dtype type_descriptor does not accept zero length tuple

[Sebastian H. <ha...@ms...>]

On Wednesday 09 August 2006 15:18, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi!
> > I have a problem with record array type descriptor.
> > With numarray this used to work.
> > My records made of  n integers and m floats.  So I used to be able
> > specify formats="%di4,%df4"%(self.numInts,self.numFloats) in numarray
> > which would translate to
> > byteorder = self.isByteSwapped and '>' or '<'
> > type_descr = [("int",   "%s%di4" %(byteorder,self.numInts)),
> >                       ("float", "%s%df4" %(byteorder,self.numFloats))]
> >
> > The problem occurs when numInts or numFloats is zero !?
> > Could it numpy be changed to silectly accept this case
> > Here is the complete traceback + some debug info:
>
> If numarray supported it, then we should get NumPy to support it as well
> unless there is a compelling reason not to.  I can't think of any except
> that it might be hard to make it work.  What is '0i4' supposed to mean
> exactly?  Do you get a zero-sized field or is the field not included?
> I think the former will be much easier than the latter.   Would that be
> O.K.?

That's exactly what numarray did. The rest of my code is assuming that all 
fields exist (even if they are empty). Otherwise I get a name error  which is 
worse than getting an empty array.

Thanks,
Sebastian Haase

Re: [Numpy-discussion] bug !? dtype type_descriptor does not accept zero length tuple

[Sebastian H. <ha...@ms...>]

Travis Oliphant wrote:
> Sebastian Haase wrote:
>> On Wednesday 09 August 2006 15:45, you wrote:
>>  
>>> Sebastian Haase wrote:
>>>    
>>>> On Wednesday 09 August 2006 15:18, Travis Oliphant wrote:
>>>>      
>>>>> If numarray supported it, then we should get NumPy to support it as 
>>>>> well
>>>>> unless there is a compelling reason not to.  I can't think of any 
>>>>> except
>>>>> that it might be hard to make it work.  What is '0i4' supposed to mean
>>>>> exactly?  Do you get a zero-sized field or is the field not included?
>>>>> I think the former will be much easier than the latter.   Would 
>>>>> that be
>>>>> O.K.?
>>>>>         
>>>> That's exactly what numarray did. The rest of my code is assuming that
>>>> all fields exist (even if they are empty). Otherwise I get a name 
>>>> error which is worse than getting an empty array.
>>>>       
>>> Do you have a simple code snippet that I could use as a test?
>>>
>>> -Travis
>>>     
>>
>> I think this should do it:
>>
>> a = N.arange(10, dtype=N.float32)
>> a.shape = 5,2
>> type_descr = [("int",   "<0i4"),("float", "<2f4")]
>> a.dtype = type_descr
>>
>>   
> 
> I'm not sure what a.shape = (5,2) is supposed to do.  I left it in the 
> unit-test out because assigning to the data-type you just defined 
> already results in
> 
> a['float'].shape being (5,2)
> 
> If it is left in, then an extra dimension is pushed in and
> 
> a['float'].shape is (5,1,2)
> 
> 
> This is due to the default behavior of assigning data-types when the new 
> data-type has a larger but compatibile itemsize then the old itemsize.

I have to admit that I don't understand that statement. I thought - just 
"visually" - that a.shape = 5,2 would make a "table" with 2 columns. 
Then I could go on and give those columns names...
Or is the problem that the type "2f4" refers to (some sort of) a "single 
column" with 2 floats grouped together !?

Thanks for implementing it so quickly,
Sebastian Haase