[Numpy-discussion] Broadcasting rules (Ticket 76).

[Travis Oliphant]

Sasha wrote:
> On 4/24/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>   
>> Sasha wrote:
>>     
>>>>>> x[:]=1,1
>>>>>> x[:]=1,1,1
>>>>>>
>>>>>>             
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in ?
>>> ValueError: number of elements in destination must be integer multiple
>>> of number of elements in source
>>>
>>>       
>> I think the only reasonable thing to do is to raise an error unless the
>> shapes were compatible like Numeric did and eliminate the multiple
>> copying feature.
>>     
>
> I've attached a patch to the ticket:
>
> <http://projects.scipy.org/scipy/numpy/attachment/ticket/76/shape-check.patch>
>
> I don't see why slice assignment cannot reuse the ufunc code.  It
> looks like slice assignment can just be dispatched to a trivial
> (pass-through) ufunc.  This aproach may even prove to be faster
> because type-aware copying loops can be faster than memmove on popular
> platforms.
>
>   

It could re-use that code but there are at least two drawbacks to that 
approach:


1) The overhead of the ufunc for small array copies.
2) The special-casing that would be needed for variable-size arrays 
(string, unicode, void...) which are not supported by the ufunc machinery. 

and we've already improved the copying by making them type-aware.


Right now copying is handled by the data-type functions (not the ufuncs). 


Perhaps what should be done instead is to allow for strided copying in 
the copyswapn function.


To fully support record arrays with object components the copy operation 
for the VOID case needs to be recursive when fields are defined.  


-Travis