- +1 vote for hyper-heuristics.

   - IMO ECJ is already easy to use programmatically—but perhaps we need
   better documentation on how users can initialize ECJ from within their
   programs and call the 'Evolve' method directly?

   - -1 on eliminating parameter files.  Arguments in favor of keeping them:
      - The parameter files, admittedly, are industrial-strength sauce, and
      therefore intimidating to newbies (I hated them at first myself).

      - IMO parameter files are a much simpler way to document complex
      experiments than compiled code.  To create an ECJ instance you
      have to define the entire object graph of the simulation—writing all of
      that out from scratch every time you want to use ECJ will force you to
      fiddle with details you'd usually like to ignore.

      - It makes sense to mix code and experiment definition in an
      interpreted language, like Python, but not so much with Java.  Having a
      non-compiled experiment definition language makes tweaking an application
      you've already set up much easier (it's easy to write parameter sweeps in
      the shell, for instance).

      - The param files also effectively provide a dependency injection
      <> (DI) system.
         - DI is a great approach to writing and composing reusable modules
         in a general way.
         - DI is vital for unit testing components that may depend on other
         modules.  Writing tests for complex frameworks that were
written without
         tests in mind can be a nightmare—I was pleased to find that
it's actually
         pretty easy to test components of ECJ independently.

         - Replacing the param file system would require rewriting the
      initialization code for every object in the framework.

      - All that said, a really carefully thought-out programmatic might be
      able to preserve these strengths.  If ECJ *were* to get a new
      programmatic interface, it would make sense to take a good look
at how the Watchmaker
      framework <> goes about it.  Do our
      parameter files offer major strengths over their system?

      - To the contrary, I'd like to see some features added to the
   existing param files.
      - As are, large files are very hard to read, since there is never any
      real nesting.  It would be great if we could replace it with a
YAML scheme.
      - At the very least, I'd like to see the ability to have parameters
      reference each other.
      - Arithmetic expressions would also be nice: so we could tell a
      mutation rate parameter to assume the value "1/L," for instance,
where L is
      a parameter specifying the length of the genome.

On Wed, Jul 27, 2016 at 3:05 PM, White, David <[log in to unmask]>

> Dear Sean,
> Congratulations on your successful grant! This is wonderful news.
> > 1. We need suggestions for what we should do beyond the list below
> (which is a summary of roughly what we proposed). In order to convert ECJ
> into a general-purpose toolkit that could serve as a central library to the
> generl metaheuristics community, what is missing from our proposed work
> below? What would you like to see?
> A few things come immediately to mind:
> - make ECJ much easier to use programmatically. Running experiments
> typically requires frequent invocation of ECJ, and I’d much rather do this
> from within my own code via a clean elegant API.
> - try to simplify the design. I’ve heard a lot of people say they found
> ECJ unwieldy at first. I have some vague ideas on what to simplify/remove,
> but this would required some further thought.
> - (this is just a suggestion) - consider Scala, either in terms of
> providing a Scala API or else rewriting some/all of ECJ in Scala. This is a
> controversial idea, I realise! I’m not sure whether it is on the whole a
> sensible decision or not, it would require some debate. With the rise of
> data analysis via Apache Spark etc., ECJ might want to at least consider
> going in this direction.
> - get rid of the parameter file system. A lot of students have complained
> about this in the past. The “cascading” nature of the files can be very
> confusing and error-prone. It also results in an inelegant approach to
> using the system programmatically (see my first point).
> - consider interoperability with other frameworks, e.g. in terms of being
> able to reuse their variation operations.
> - consider supporting hyper heuristics.
> >
> > 2. We'll be building a board of "power users" of ECJ to assess the work
> and make recommendations here and there. It'll be infrequent and minimal
> work on your part, but it's important for us. I would like you to recommend
> (directly to me) people to be on that board. Yes you can recommend yourself.
> >
> I’d like to volunteer!
> This is great news, congratulations again!
> Best Wishes,
> David


Ph.D student in Computer Science, George Mason University
CFO and Web Director, Journal of Mason Graduate Research