NAME

for_loop -- unit to iterate operands

PROTOTYPE

unitptr for_loop( int nu, int nr, char *pcFmt, unitptr uHost)

ARGUMENTS

int nu
ABS(nu)=number of successor units to iterate. The sign of nu determines, whether the condition for premature termination ( CTL\_in[0]==0 ) is always checked before ( nu>0 ) or after ( nu<0 ) each iteration.
int nr
initial nr (>=0) of iterations to be made. A value of 0 specifies an infinite loop that can only be broken if one of the units in the loop sets the CTL\_in field to zero.
char *pcFmt
option string (see below)
unitptr uHost
host unit

RETURN VALUE:

A pointer to the created unit or NULL in the case of an error.

INTERFACE OF CREATED UNIT:

X_in[1]
break field: if during iteration of the for-unit this field changes (!) from zero to a positive value, the loop will terminate after completion of the current exec call of the current operand. If adaptation is specified too, all adaptations for the performed exec's will be carried out. Note that an initial positive value of the break field does not prevent the for loop from being started!
CTL_in[1]
control input: iteration count limit. Operation of the for_loop unit requires a non-zero value at this pin. When the value is equal or lower than the current iteration count (at X_out[0]), operation of this unit terminates after completion of the current iteration. If the value is zero at the beginning, the unit does nothing (except for some internal bookkeeping, such as marking its operands).
X_out[0]
current iteration count

DESCRIPTION:

This unit is provided to perform repeated iterations of the following nu units in the exec-queue. These will become operands of the for_loop unit. This unit and its options is similar to the iterator unit. The main difference is the absence of any saving and feeding fields and the dynamically changeable number of iterations.

EXECUTION:

An exec call to the for_loop unit will have the effect to call the chain of its nu successors nr times in sequence. Before the i-th call is made, the for_loop checks whether its iteration count is equal or larger than CTL_in[0]. If yes, operation of the for_loop unit terminates prematurely. By specifying the %a option (``exec+adapt'' in NEO), the for-iterations will include adaptation steps according to the pattern

   for (i=0; i<ABS(nr); i++) {
       exec_unit(Operand_1) ... exec_unit(Operand_nu);
       adapt_unit(Operand_nu) ... adapt_unit(Operand_1);
   }

In this case, no further adaptation calls to the operands will be made during the adapt_unit() call for the for_loop.

ADAPTATION:

Usually, the for_loop unit does not adapt its operand units. Adaptation must be explicitly enabled by setting options. As explained above, the %a will provide adaptation during the exec_unit call for the for_loop unit. The following two options will enable adaptation for the operands of the for_loop unit when the adapt_unit call is made.
%A
(``adapt1'' in NEO) adapt_unit() acts as if

   for (i=0; i<ABS(nr); i++) {
       adapt_unit(Operand_nu) ... adapt_unit(Operand_1);
   }

%p
(``adapt2'' in NEO) modifies %A-option by prefixing each adapt_unit(operand) with a exec_unit(operand), ie. now adapt_unit() acts as if

   for (i=0; i<ABS(nr); i++) {
       exec_unit(Operand_nu); adapt_unit(uOperand_nu)
       ...
       exec_unit(Operand_1); adapt_unit(Operand_1)
   }


If the iterated units contain an adaptable unit, each adapt should usually be prefixed by an exec-call, i.e., the %p - mode should be used. If neither of %A or %p is present, the adapt_unit() call is without any effect.

VIRTUAL MODE:

If the option string contains the token %v, the for_loop unit operates in a special mode, similar to a virtual_unit: it then uses as its operands the iOperands successor units of its host unit. This facilitates to build operator units that iterate their operands.

SEE ALSO:

iterator

FILE

/homes/jontrup/nst5/man/../o.sol2//../nstsrc/nst_misc.c