Several new Clojush updates
April 18, 2010by Lee Spector (lspector)
I’ve just posted a new version of clojush, the version of Push3/PushGP implemented in Clojure, which includes several significant changes, listed below.
BTW I’m also considering moving the distribution to github, but I haven’t done that yet…
20100320: - Added print-ancestors-of-solution parameter and code. - Print simplification in report only with non-zero value for report-simplifications parameter. - Added sextic polynomial regression example. This example also demonstrates the use of fitness penalties for abnormally terminating programs. - Added a new argument to problem-specific-report (NOTE: not backward compatible). 20100417: - Added thread-local random number generator objects to avoid contention. - Print parameters at the start of pushgp. - Added readme comments about concurrency, -Xmx2000m, and -XX:+UseParallelGC. - Converted time limit code to use System/nanoTime (thanks to Brian Martin). This means that time limits must now be expressed in nanoseconds rather than milliseconds, and I believe it will eliminate contention for shared Date objects (but this should be checked; if there is contention then we should revert to using Date and use thread-local date objects as is being done with the random number generator objects). - Added print-return utility function for debugging. - Added a new Push instruction, code_wrap, which pushes a 1-item list containing the previous top item of the code stack. - Added a new Push instruction, code_map, which acts much like Lisp's (or Scheme's or Clojure's) "map" functions, using the top item on the exec stack as the function to map and the top item on the code stack as the list to map it down. The list of results is left on top of the code stack. This is implemented as a "macro" instruction that expands into a Push code fragment that: 1) for each item in the list on top of the code stack (or for the single non-list item that is there) quotes the item onto the code stack and then runs the code that's on top of the exec stack; 2) uses code_wrap to push a list containing the last result onto the code stack; 3) executes as many instances of code_cons as are necessary to add all of the other results onto the list. Note that this will act like an ordinary "map" function only when the code on the exec stack leaves a single output on the code stack in place of each input on the code stack; if it consumes or produces more or less code then the effect will be quite different.