I just submited a PR to fix wrong usage of tabensure in all opcodes 
supported by me. The idea behind that is to avoid resizing an already 
initialized array at init time, leaving all resizing operations to perf 
time (if the opcode has a perf-time part). I think that this should be 
applied to all opcodes acting on arrays, or, at least, the unexpected 

in general i dislike moving things from init time to perf time.


On Sun, 31 Mar 2019, Eduardo Moguillansky wrote:

> I just submited a PR to fix wrong usage of tabensure in all opcodes supported 
> by me. The idea behind that is to avoid resizing an already initialized array 
> at init time, leaving all resizing operations to perf time (if the opcode has 
> a perf-time part). I think that this should be applied to all opcodes acting 
> on arrays, or, at least, the unexpected behaviour should be documented in the 
> manual. What do you think?

Also yur scheme does not rotect about missing i-pss which can happen and 
is checke all over te opcodes.

On Sun, 31 Mar 2019, Eduardo Moguillansky wrote:

> I just submited a PR to fix wrong usage of tabensure in all opcodes supported 
> by me. The idea behind that is to avoid resizing an already initialized array 
> at init time, leaving all resizing operations to perf time (if the opcode has 
> a perf-time part). I think that this should be applied to all opcodes acting 
> on arrays, or, at least, the unexpected behaviour should be documented in the 
> manual. What do you think?

 > in general i dislike moving things from init time to perf time.

Of course, in general, but this fix ensures that the code acts as it 
claims it should. Without the perf-time check, the code is just wrong.

On So, Mar 31, 2019 at 7:49 PM, john  wrote:
> Also yur scheme does not rotect about missing i-pss which can happen 
> and is checke all over te opcodes.
> 

I don't understand what you mean here. In tabensure_perf we only check 
about size, because in tabensure_init we checked missing init. In the 
case of an opcode only acting at perf-time, the normal tabensure should 
be called. For an opcode with an init-time func and a perf-time func, 
at init we call tabensure_init to ensure that the array is initialized 
(if it is, we leave it as is), at perf-time we ensure the size

> On Sun, 31 Mar 2019, Eduardo Moguillansky wrote:
> 
>> I just submited a PR to fix wrong usage of tabensure in all opcodes 
>> supported by me. The idea behind that is to avoid resizing an 
>> already initialized array at init time, leaving all resizing 
>> operations to perf time (if the opcode has a perf-time part). I 
>> think that this should be applied to all opcodes acting on arrays, 
>> or, at least, the unexpected behaviour should be documented in the 
>> manual. What do you think?

Before withdrawing this PR, could you at least clarify which are the 
semantics of arrays in csound, so that at least it can be documented?

This is the current behaviour:

# Array size depends on previous operations

The returned array of any array arithmetic operation takes its size not 
from the operands but from the size of the output array itself, which 
means that if the operands size change, the returned array does not 
reflect this change in size

Moreover, the size of the array depends on having been initialize or 
not. The last operation at init time determines the size of the array

Moreover, this is not true for all opcodes, because some opcodes 
correct the size of the array at k-time

# Array size depends on previous instruments

In cases like slicearray, the returned size depends on previous 
instruments ?!


The problem seems to spawn from a conflict between correctness and 
efficiency. If efficiency needs to be given priority, then at least 
this behaviour needs to be documented, enforced and become homogeneous 
across all array returning opcodes.




* Should the output of an array operation (for example "kOut[] = kIn[] 
* 2) have the same size/shape of the input array? Does the size of the 
output array depend on previous operations / previous instances of the 
same instrument?

On So, Mar 31, 2019 at 8:05 PM, Eduardo Moguillansky 
 wrote:
>  > in general i dislike moving things from init time to perf time.
> 
> Of course, in general, but this fix ensures that the code acts as it 
> claims it should. Without the perf-time check, the code is just wrong.
> 
> On So, Mar 31, 2019 at 7:49 PM, john  wrote:
>> Also yur scheme does not rotect about missing i-pss which can happen 
>> and is checke all over te opcodes.
>> 
> 
> I don't understand what you mean here. In tabensure_perf we only 
> check about size, because in tabensure_init we checked missing init. 
> In the case of an opcode only acting at perf-time, the normal 
> tabensure should be called. For an opcode with an init-time func and 
> a perf-time func, at init we call tabensure_init to ensure that the 
> array is initialized (if it is, we leave it as is), at perf-time we 
> ensure the size
> 
>> On Sun, 31 Mar 2019, Eduardo Moguillansky wrote:
>> 
>>> I just submited a PR to fix wrong usage of tabensure in all opcodes 
>>> supported by me. The idea behind that is to avoid resizing an 
>>> already initialized array at init time, leaving all resizing 
>>> operations to perf time (if the opcode has a perf-time part). I 
>>> think that this should be applied to all opcodes acting on 
>>> arrays, or, at least, the unexpected behaviour should be 
>>> documented in the manual. What do you think?
>>> 
>