Hi Hans-Peter,
I have increased the system limit for operators per statement (!) from
16 to 32.
This system limit is required for performance reasons since it avoids memory
allocations and de-allocations for derived functions.
I would assume that a single APL statement with more than 32 operators
(your example
has 17 EACH operators) will never occur in real-life code.
*SVN 1849*.
In principle every system limit is a compromise that is chosen such that
it will not harm
real life APL code. However, almost every system limit can be exceeded
by constructing
an example that aims at exceeding it. I do not consider that as a design
fault.
Best Regards,
Jürgen
On 3/1/25 20:40, Hans-Peter Sorge wrote:
Hi Jürgen,
* 3 ⎕CR ⍎∊17⍴⊂'(1↑¨''a'')'*
SYSTEM LIMIT (fun_oper)
(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')
^ ^
* 3 ⎕CR ⍎∊16⍴⊂'(1↑¨''a'')'**
*┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓
┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓
┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃
┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃ ┃┏→┓┃
┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃
┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃ ┃┃a┃┃
┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃
┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃ ┃┗━┛┃
┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛
┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛ ┗ϵ━━┛
Looks like there are not more than 16 each Symbols allowed in such an
expression:-)
The operator does not matter ↑ or / or , and may be others.
Bets Regards
Hans-Peter
Am 01.03.25 um 16:35 schrieb Dr. Jürgen Sauermann:
Hi Hans-Peter,
I cannot quite answer your question, but maybe we can
find the problem together. My analysis so far is this:
I started with storing the common part of your c, d, and e in
variable *E*.
With that your examples become:
*
E←⊂¨2 2⍴0/¨⊂,¨2 2 ⍴ 0⍴0
c← E
d← ⊃¨E ⍝ ⊃¨c
e←⊂¨⊃¨E ⍝ ⊂¨⊃¨c expected by d
*
I then checked if ⊂ and ⊃ work as expected with *E*:
*
E ≡ ⊃⊂E
1*
That worked, therefore the suspect became the EACH operator.
I then used a little trick which wraps ⊂ and ⊂ into defined functions:
*
∇Z←ENCL B
Z←⊂B
∇
∇Z←DISCL B
Z←⊃B
∇
E ≡ DISCL ENCL E
1
(⊃ ⊂ E) ≡ DISCL ENCL E
1
*
No surprise yet, just proving that ENCL and DISCL are the same as ⊂
and ⊃.
However: inside GNU APL there is a big difference between ENCL/DISCL
and ⊂/⊃.
The difference (and that is the trick) is that ENCL/DISCL are user
defined which
causes the EACH operator to be executed as a macro (=a built-in
function written
in APL). In contrast ⊂/⊃ are built-in functions written in C/C++ and
in that case
the EACH operator is also executed as a built-in function written in
C/C++.
Since, as we have seen, the macro used with ENCL/DISCL gives the same
result
as the built-in used with ⊂/⊃, the fault (if any) must also be in
the macro. The macro
is actually quite simple (see file *Macro.def* lines 59ff:
*
∇Z←(LO Z__LO_EACH_B) B;rho_Z;N;N_max
rho_Z←⍴B ◊ N←⎕IO ◊ N_max←N+⍴B←,B ◊ Z←N_max⍴0
(N⊃Z)←LO N⊃B ◊ 0 → N_max>N←N+1
Z←rho_Z⍴Z
∇*
The macro is called with LO=ENCL or LO=DISCL and B.
My conclusion so far (and I am running out of ideas) is this:
Either there is no fault, or the fault is in both the macro and in
the C/C++
implementation of the EACH operator. The most likely suspect in my
experience is the pick (monadic ⊃) function.
Best Regards,
Jürgen
On 2/24/25 00:19, Hans-Peter Sorge wrote:
Hi,
The expressions for "a" and "b" yield the proper results:
*a← (⊂¨ 2 2 ⍴⊂,¨2 2 ⍴⍬ )**
b← (⊃¨⊂¨ 2 2 ⍴⊂,¨2 2 ⍴⍬ ) **/⍝⊃¨a/*
/⍝ The disclose in "b" works as expected/
*'ab',¨ ⊂¨ 3 ⎕CR ¨ a b /⍝ expression to represent "a" and "b" in one
line. /*
a ┏━━━━━━━━━┓ ┏━━━━━━━━━┓ b ┏→━━━━━━┓ ┏→━━━━━━┓
┃┏→━━━━━━┓┃ ┃┏→━━━━━━┓┃ ↓┏→┓ ┏→┓┃ ↓┏→┓ ┏→┓┃
┃↓┏→┓ ┏→┓┃┃ ┃↓┏→┓ ┏→┓┃┃ ┃┃0┃ ┃0┃┃ ┃┃0┃ ┃0┃┃
┃┃┃0┃ ┃0┃┃┃ ┃┃┃0┃ ┃0┃┃┃ ┃┗━┛ ┗━┛┃ ┃┗━┛ ┗━┛┃
┃┃┗━┛ ┗━┛┃┃ ┃┃┗━┛ ┗━┛┃┃ ┃┏→┓ ┏→┓┃ ┃┏→┓ ┏→┓┃
┃┃┏→┓ ┏→┓┃┃ ┃┃┏→┓ ┏→┓┃┃ ┃┃0┃ ┃0┃┃ ┃┃0┃ ┃0┃┃
┃┃┃0┃ ┃0┃┃┃ ┃┃┃0┃ ┃0┃┃┃ ┃┗━┛ ┗━┛┃ ┃┗━┛ ┗━┛┃
┃┃┗━┛ ┗━┛┃┃ ┃┃┗━┛ ┗━┛┃┃ ┗ϵ━━━━━━┛ ┗ϵ━━━━━━┛
┃┗ϵ━━━━━━┛┃ ┃┗ϵ━━━━━━┛┃
┗ϵϵ━━━━━━━┛ ┗ϵϵ━━━━━━━┛ ┏→━━━━━━┓ ┏→━━━━━━┓
┏━━━━━━━━━┓ ┏━━━━━━━━━┓ ↓┏→┓ ┏→┓┃ ↓┏→┓ ┏→┓┃
┃┏→━━━━━━┓┃ ┃┏→━━━━━━┓┃ ┃┃0┃ ┃0┃┃ ┃┃0┃ ┃0┃┃
┃↓┏→┓ ┏→┓┃┃ ┃↓┏→┓ ┏→┓┃┃ ┃┗━┛ ┗━┛┃ ┃┗━┛ ┗━┛┃
┃┃┃0┃ ┃0┃┃┃ ┃┃┃0┃ ┃0┃┃┃ ┃┏→┓ ┏→┓┃ ┃┏→┓ ┏→┓┃
┃┃┗━┛ ┗━┛┃┃ ┃┃┗━┛ ┗━┛┃┃ ┃┃0┃ ┃0┃┃ ┃┃0┃ ┃0┃┃
┃┃┏→┓ ┏→┓┃┃ ┃┃┏→┓ ┏→┓┃┃ ┃┗━┛ ┗━┛┃ ┃┗━┛ ┗━┛┃
┃┃┃0┃ ┃0┃┃┃ ┃┃┃0┃ ┃0┃┃┃ ┗ϵ━━━━━━┛ ┗ϵ━━━━━━┛
┃┃┗━┛ ┗━┛┃┃ ┃┃┗━┛ ┗━┛┃┃
┃┗ϵ━━━━━━┛┃ ┃┗ϵ━━━━━━┛┃
┗ϵϵ━━━━━━━┛ ┗ϵϵ━━━━━━━┛
The expression for "c" yields the proper result
The expression for "d" yields an unexpected result - or is it intended?
The expression for "e" yields the result expected by "d":
*c←(⊂¨ 2 2 ⍴0/¨⊂,¨2 2 ⍴ 0⍴0)**
d←(⊃¨⊂¨ 2 2 ⍴0/¨⊂,¨2 2 ⍴ 0⍴0) /⍝ ⊃¨c/
e← (⊂¨⊃¨⊂¨ 2 2 ⍴0/¨⊂,¨2 2 ⍴ 0⍴0)*///*⍝ ⊂¨⊃¨c expected by d*//
//
⍝ Zero rank elements stem from /*0/¨.*
/
⍝ The result from disclose in "d" is unexpected, I expected the
output like in "e".
⍝ The left most enclose /*⊂¨*/in "e" should not be required to get
the proper rank/depth.
⍝ In a more complex variable structure having "a" and "c" elements
⍝ the application of a uniform disclose over each element
⍝ results in "⊃¨a" >> "b" and "⊃¨c" >> "d" elements
⍝ finally causing a domain error.
⍝ If the disclose //in the more complex variable structure //would
result in "⊃¨a" >> "b" and "⊃¨c" >> "e" then the //domain error
disappears.
⍝ Currently I have to check each element within the variable data
structure and transform "d" to "e" where applicable.
//
⍝ Remark: I did some text editing here due to "/⊖/" being two chars
wide. The APL output is correct./
*'cde',¨ ⊂¨3 ⎕CR ¨ c d e**/⍝ expression to represent "c", "d" and
"e" in one line./*
c ┏━━━━━┓ ┏━━━━━┓ d ┏⊖┓┏⊖┓ e ┏━━━┓ ┏━━━┓
┃┏⊖━━┓┃┃┏⊖━━┓┃ ↓0┃ ↓0┃ ┃┏⊖┓┃ ┃┏⊖┓┃
┃↓┏→┓┃┃ ┃↓┏→┓┃┃ ┃0┃ ┃0┃ ┃↓0┃┃ ┃↓0┃┃
┃┃┃0┃┃┃ ┃┃┃0┃┃┃ ┗━┛ ┗━┛ ┃┃0┃┃ ┃┃0┃┃
┃┃┗━┛┃┃ ┃┃┗━┛┃┃ ┃┗━┛┃ ┃┗━┛┃
┃┃┏→┓┃┃ ┃┃┏→┓┃┃ ┏⊖┓┏⊖┓ ┗ϵ━━┛ ┗ϵ━━┛
┃┃┃0┃┃┃ ┃┃┃0┃┃┃ ↓0┃ ↓0┃ ┏━━━┓ ┏━━━┓
┃┃┗━┛┃┃ ┃┃┗━┛┃┃ ┃0┃ ┃0┃ ┃┏⊖┓┃┃┏⊖┓┃
┃┗ϵ━━┛┃ ┃┗ϵ━━┛┃ ┗━┛ ┗━┛ ┃↓0┃┃ ┃↓0┃┃
┗ϵϵ━━━┛ ┗ϵϵ━━━┛ ┃┃0┃┃ ┃┃0┃┃
┏━━━━━┓ ┏━━━━━┓ ┃┗━┛┃ ┃┗━┛┃
┃┏⊖━━┓┃┃┏⊖━━┓┃ ┗ϵ━━┛ ┗ϵ━━┛
┃↓┏→┓┃┃ ┃↓┏→┓┃┃
┃┃┃0┃┃┃ ┃┃┃0┃┃┃
┃┃┗━┛┃┃ ┃┃┗━┛┃┃
┃┃┏→┓┃┃ ┃┃┏→┓┃┃
┃┃┃0┃┃┃ ┃┃┃0┃┃┃
┃┃┗━┛┃┃ ┃┃┗━┛┃┃
┃┗ϵ━━┛┃ ┃┗ϵ━━┛┃
┗ϵϵ━━━┛ ┗ϵϵ━━━┛
An observed side effect:
Placing the expression from a, b, c, d, and e in one line generates
as SYSTEM LIMIT:
3 ⎕CR ¨(⊂¨ 2 2 ⍴⊂,¨2 2 ⍴⍬) (⊃¨⊂¨ 2 2 ⍴⊂,¨2 2 ⍴⍬) (⊂¨ 2 2 ⍴0/¨⊂,¨2 2
⍴ 0⍴0) (⊃¨⊂¨ 2 2 ⍴0/¨⊂,¨2 2 ⍴ 0⍴0) (⊂¨⊃¨⊂¨ 2 2 ⍴0/¨⊂,¨2 2 ⍴ 0⍴0)
SYSTEM LIMIT (fun_oper)
3 ⎕CR¨(⊂¨2 2⍴⊂,¨2 2⍴⍬)(⊃¨⊂¨2 2⍴⊂,¨2 2⍴⍬)(⊂¨2 2⍴0/¨⊂,¨2
2⍴0⍴0)(⊃¨⊂¨2 2⍴0/¨⊂,¨2 2⍴0⍴0)(⊂¨⊃¨⊂¨2 2⍴0/¨⊂,¨2 2⍴0⍴0)
Related problems:
*≡¨a b c d e*
4 3 4 2 3 /⍝ ≡d should be 3
/* ⍴¨¨¨¨c*
DOMAIN ERROR
⍴¨¨¨¨c
^ ^
/⍝ ¨¨¨¨ (4 times each) corresponds to 4 ←→ ≡c, the //DOMAIN
ERROR//is not expected (works with ⍴¨¨¨¨a). /
Best Regards
Hans-Peter
