[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Elias Mårtenson
Subject: Re: [Bug-apl] Scan operator has strange behaviour
Date: Wed, 19 Mar 2014 23:16:32 +0800

I see. So the way I see it, I should actually use 2 OP/X instead? I seems to actually do what I expected.


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[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]