Re: [Bug-apl] "SYSTEM_LIMIT (fun_oper)" error

[Juergen Sauermann]

Hi Fred,

when designing derived functions I had the choice between a faster variant that
uses pre-allocated memory for derived functions and a somewhat slower variant
that uses dynamic memory allocation (i.e. new/delete directly or indirectly (eg. vector<>)).

Since this happens on a performance critical path, I decided in favour of the faster variant, assuming that
16 or so operators per statement is not too limiting. The downside was, of course, a limit on the number
of operators per statement. The limit can be changed in file SystemLimits.def line 22 to whatever makes sense;
the only effect is a little more memory consumed per )SI entry.

Increasing the limit does not help with the problem of  Conway's "Game of Life" because for every limit you
chose there is a number of iterations that will hit the limit.

As I have pointed out at http://forums.anandtech.com/showthread.php?p=35685622, instead of reshaping
the statement S, one can iterate over S using each:

∇ N LIFE M
  ⍎¨N⍴⊂S←'⎕←''-''⍪M←(3=T)∨M∧2=T←⊃+/(V⌽¨⊂M),(V⊖¨⊂M),(V,⌽V)⌽¨(V,V←1 ¯1)⊖¨⊂M'
∇

This runs in constant space and does not hit a system limit.

/// Jürgen


On 01/31/2014 11:44 PM, Frederick H Pitts wrote:

Gentle people,

	When I attempt to run the attached life.apl.gz (after uncompressing)
with

	apl -f life.apl

partial output occurs and then "SYSTEM LIMIT (fun_oper) appears with the
offending apl statement after that.  Investigation of the interpreter
source code reveals the "SYSTEM LIMIT (fun_oper)" message is emitted
because more than 16 operators are present in the apl statement as well
there should be since the statement was generated by catenating together
120 strings containing 4 dyadic each operators (¨) per string.
Admittedly this apl program is a contrived one-liner of Conway's "Game
of Life", but I can foresee the 16 operators per APL statement being too
restrictive for some "real" applications. Experimenting on my own, I
raised the limit to 4096 with no negative consequences that I could see.
What is the resource that is going to limit how many operators can
appear in a given statement and is 16 a reasonable number for that
limit?  I hope the limit can be several orders of magnitude higher than
16.

	If anyone is interested in running the program, run it as shown above
in a 43 by 132 ansi terminal with a huge scrollback buffer.  After the
program completes, scroll to where the output starts and then page down
one screen at a time to see how "life" evolves.  I've initialized the
game with the R-pentomino which generates lots of activity and takes
1103 generations to become stable.  Of course you will have to increase
the MAX_FUN_OPER parameter in SystemLimits.def to run more than 3 or 4
generations.

Regards,

Fred Pitts
Retired Chemical Engineer