[Top][All Lists]

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

Re: [Bug-apl] performance in of ¨

From: Christian Robert
Subject: Re: [Bug-apl] performance in of ¨
Date: Mon, 20 Jun 2016 04:42:52 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

On 2016-06-19 23:55, Xiao-Yong Jin wrote:
Jürgen, I can confirm that loop problem is fixed.

Christian, that “function” is an operator, same as each (¨). You would find it 
listed in )ops, similar to ⎕NL 4, and ⎕NC'FE' would return 4 (as an operator).  
In gnu apl you can use )nms to list all the )vars )fns and )ops.

thank you Xiao-Yong,

I was not aware of the distinction between functions and operators. Learning 
every day.



On Jun 19, 2016, at 12:16 AM, Christian Robert <address@hidden> wrote:

I think you fixed it. No longer running O(NxN) (still slower than native C++, I 
can live with that, no problems)

btw, When I defined this test function two days ago:

     f2def 'FE'

     )erase FE

     ∇Z←A (LO FE) B;rho_Z;N;N_max
rho_Z←⍴B ◊ N←⎕IO ◊ A←,A ◊ N_max←N+⍴B←,B ◊ Z←N_max⍴0
LOOP: Z[N]←⊂(⊃A[N]) LO ⊃B[N] ◊ →(N_max>N←N+1)⍴LOOP
D   MEASURE     MEASURE2    Replace     df  f2def   ltrim   rtrim   time    
trim    vert
     ⍝ FE does not appear here ! But *is* a function

     ⍝ but this function name appear in ⎕nl 4

     D ⎕nl ¨ ⍳4
│┌⊖┐ ┌⊖┐ ┌8───────┐ ┌2─┐│
│⌽ │ ⌽ │ 1D       │ ↓FE││
│└─┘ └─┘ 1MEASURE │ └──┘│
│        │MEASURE2│     │
│        │Replace │     │
│        │df      │     │
│        │f2def   │     │
│        │ltrim   │     │
│        │rtrim   │     │
│        │time    │     │
│        │trim    │     │
│        │vert    │     │
│        └────────┘     │

what is {quad}nl 4 ?

why 'FE' not displayed in ")fns" ?


On 2016-06-18 16:21, Juergen Sauermann wrote:

I believe I have fixed the problem,*SVN **749*.

The fault was actually not related to macros but a general problem
affecting the performance of virtually all workspaces.

The time-consuming line in the EACH macro was this:

*LOOP: Z[N]←⊂(⊃A[N]) LO ⊃B[N] ◊ →(N_max>N←N+1)⍴LOOP*

Due to an inefficiency in the runtime parser, the parser would, for example, 
first resolve
B (which creates a copy of B) and then index the copy to obtain B[N] . Same for 
If B has N items then this would generate N copies of B, each copy taking O(N) 
and therefore the runtime of the above innocent looking LOOP would be O(N×N).

Macros are a little slower than their built-in siblings, but the code that 
could be removed
by using macros belonged to the most error-prone in the past, and some of the 
operators (which are called when their function argument(s) are primitive 
functions) could
also be simplified.

/// Jürgen

reply via email to

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