Compare with Dyalog,
]runtime +/⍳100
* Benchmarking "+/⍳100"
(ms)
CPU (avg): 1
Elapsed: 1
]runtime {⍺+⍵}/⍳100
* Benchmarking "{⍺+⍵}/⍳100"
(ms)
CPU (avg): 270
Elapsed: 279
> On Mar 30, 2020, at 9:38 AM, Xiao-Yong Jin
For comparison, here is J,
JVERSION
Engine: j901/j64avx2/darwin
Release-e: commercial/2020-01-29T12:41:32
Library: 9.01.21
Platform: Darwin 64
Installer: J901 install
InstallPath: /applications/j901
Contact: www.jsoftware.com
timex'+/i.100'
0.00184
plus=:4 :'x+y'
timex'plus/i.1
This brings up an interesting point. Truth is, the functional programming
model is extremely slow unless, as it often is, the function call is
optimized out.
On Mon, Mar 30, 2020 at 6:51 AM Elias Mårtenson wrote:
> Thank you for the clarification. I can see that the problem isn't that the
> lam
Thank you for the clarification. I can see that the problem isn't that the
lambda function is slow. It's the +/ variant that is really fast. :-)
Of course, as you say, in real code you'd never write it the way I did. :-)
Regards,
Elias
On Mon, 30 Mar 2020 at 17:53, Dr. Jürgen Sauermann
wrote:
Hi Elias,
in GNU APL (and I suppose also in other APLs) lambda expressions
are not
macros (or inline functions) but fully-fledged defined functions.
That is,
{⍺+⍵}/ ⍳100 is NOT equivalent to: +/ ⍳100
Rather:
The following expression takes about 12 seconds to compute on my laptop:
*{⍺+⍵}/ ⍳100*
However, the equivalent expression without the lambda expression is
immediate (i.e. thr prompt returns before I have time to notice that it
even started calculating):
*+/ ⍳100*
What is causing the lar
