bug-apl
[Top][All Lists]
Advanced

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

Re: [Bug-apl] performance in of ¨


From: Xiao-Yong Jin
Subject: Re: [Bug-apl] performance in of ¨
Date: Sun, 19 Jun 2016 22:55:15 -0500

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.

Best,
Xiao-Yong

> 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'
> 
>      )sic
>      )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
> Z←rho_Z⍴Z
>
>      )fns
> 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
> ┌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" ?
> 
> Xtian.
> 
> 
> On 2016-06-18 16:21, Juergen Sauermann wrote:
>> Hi,
>> 
>> 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 A.
>> If B has N items then this would generate N copies of B, each copy taking 
>> O(N) cycles,
>> 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 built-in
>> 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]