Re: [Jprogramming] Benchmarks

2021-10-05 Thread Jose Mario Quintana
I can only comment on the solutions [0, 1] I wrote: I would be very surprised if (as written) they provide a practical solution to the production of efficient (anonymous) recursive verbs. [0] Y combinator - Rosetta Code [1] Y combinato

Re: [Jprogramming] Benchmarks

2021-10-05 Thread Raul Miller
I am fine with the combinator being implemented within the language, rather than being a primitive function. But, also, the page I referenced includes incompatible implementations of the combinator. The Y combinator implementations which take verb arguments representing the recursive functionality

Re: [Jprogramming] Benchmarks

2021-10-05 Thread Raoul Schorer
Does that mean we could consider making the Y combinator part of the language as a library or primitive function? Speaking only for myself, I am very much in support of better recursion support in the language, since I usually draw my inspiration from Scheme programs. Cheers, Raoul Le mar. 5 oct

Re: [Jprogramming] Benchmarks

2021-10-05 Thread Raul Miller
This is an old subject, which may no longer have motivation and/or interest, but it occurred to me, today, that it ought to be possible to avoid stack errors from recursive verb implementations by using the Y Combinator. https://rosettacode.org/wiki/Y_combinator#J FYI, -- Raul On Mon, May 24,

Re: [Jprogramming] Benchmarks

2021-05-29 Thread Henry Rich
Benchmarks such as these are hard to make meaningful and easy to misuse, perhaps maliciously. In any benchmark set there will be some that don't map to efficient primitives.  The benchmark will have to loop, and performance will suffer.  Opponents will trumpet the poor results. Perhaps we sh

Re: [Jprogramming] Benchmarks

2021-05-29 Thread Devon McCormick
Looking at the summing code in these benchmarks, I see that there is a "sumloop" written in a very loopy, non-J fashion and a "sumj" which looks like at attempt to accomplish the same thing in a more J-like fashion like this: sumj =: 13 : '+/ y$1' NB. sum consecutive integers as in J Of course thi

Re: [Jprogramming] Benchmarks

2021-05-24 Thread Raul Miller
In J80x, there's no deriv_jcalculus_ because deriv_jcalculus_ is a replacement for the d. primitive. So, in J807, you can just use that primitive. I think the idea was that by making it a library routine instead of a primitive it would be easier for motivated J programmers to enhance it with addit

Re: [Jprogramming] Benchmarks

2021-05-24 Thread Thomas McGuire
For those interested in Benchmarks I have split my original benchmark routine into 2 scripts. One the Kernighan/Van Wyk benchmarks and an advanced benchmarks script. The advanced benchmarks were taken from some of the functionality that the Scheme language benchmarks for which I found J implemen

Re: [Jprogramming] Benchmarks

2021-05-19 Thread Raul Miller
deriv_jcalculus_ does symbolic differentiation on tacit expressions. For example: load'math/calculus' (3+*:) deriv_jcalculus_ 1 0"0 + +: 3 0 1&p. deriv_jcalculus_ 1 0 2&p. (3+*:) deriv_jcalculus_ 1 i. 5 0 2 4 6 8 3 0 1&p. deriv_jcalculus_ 1 i. 5 0 2 4 6 8 (The right argument to der

Re: [Jprogramming] Benchmarks

2021-05-19 Thread Thomas McGuire
Thanks Raul, I added your ‘tail' implementation to the code and it works without issue. The KJV text is listed in reverse line order in the output file. benchmarks '' sumloop: 0.227858 8.39149e6 sumj: 0.000171 1.04986e6 ack: 2e_6 721472 array1: 5.6e_5 1.05107e6 array1t: 4.8e_5 1.05107e6 stri

Re: [Jprogramming] Benchmarks

2021-05-18 Thread Raul Miller
Here's the tail benchmark written in J: tail=: 4 : 0 (;|.<;.2 freads x) fwrites y ) This is based on my reading of the C implementation of the tail benchmark vs the cat benchmark, and on the cat benchmark in this J implementation, except that I have failed to reproduce a bug in the C implementa