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
