Re: [Bug-apl] Scan operator has strange behaviour

[Elias Mårtenson]

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 <address@hidden> 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