|
From: | Juergen Sauermann |
Subject: | Re: [Bug-apl] "SYSTEM_LIMIT (fun_oper)" error |
Date: | Wed, 12 Feb 2014 16:43:37 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |