I see. So the way I see it, I should actually use 2 *OP*/X instead? I seems to actually do what I expected.
Regards, Elias On 19 March 2014 22:25, Kacper Gutowski <[email protected]> wrote: > On 2014-03-19 21:22:04, Elias Mårtenson wrote: > > This can't possibly be correct? > > But it is! > Let me just quote relevant excerpt of ISO 13751: > > > Z←f\B > (...) > > If B is a vector, > > If the count of B is less-than two, return B. > > Otherwise return Z, a vector such that the shape-list of Z is the > > shape-list of B, > > and the ravel-list of Z is such that item I of the ravel-list of Z > > is f/B[⍳I] for > > all I in the index-set of the ravel-list of B. The type of Z is > > the sufficient-type > > of the ravel-list of Z under the type mixed. > (...) > > The evaluation sequence above describes a quadratic algorithm > > for scan. If the function f > > is associative, scan may be implemented with a linear algorithm. > > So for Z←f/⍳10, evaluation sequence is as follows: > > Z[1]←f/1 > Z[2]←f/1 2 > Z[3]←f/1 2 3 > Z[4]←f/1 2 3 4 > > and so on. > > If you analyse your output, you'll find that GNU APL follows this > definition. And without additional assumptions, it is not possible > to further reduce number of calls. Even if GNU APL somehow analysed > your function and found it the be associative, you still added a side > effect of printing arguments to it so it's not possible to optimise > it out without changing the (correct) behaviour. > > -k >
