Loading ...
Sorry, an error occurred while loading the content.

Re: [GP] ECJ Citations

Expand Messages
  • David White
    Hi Sean, I can see two very good reasons for writing a paper on ECJ, should you ever have time to do so: 1. We can use it as a proxy to assign academic credit
    Message 1 of 5 , Mar 10, 2013
    • 0 Attachment
      Hi Sean,

      I can see two very good reasons for writing a paper on ECJ, should you ever have time to do so:

      1. We can use it as a proxy to assign academic credit to you and other contributors.

      2. You can take the opportunity to share your experience of developing an EC system, some of the pitfalls and design decisions etc. I see quite a few new EC frameworks being developed (e.g. for new languages), and I'm sure the authors would benefit from an insight into the development of what is probably the most popular GP system.

      As for your citation, I think it's all sensible. The year is a bit unsatisfying… a paper would fix that :-)

      David

      David R White
      SICSA Research Fellow
      School of Computing Science
      University of Glasgow, G12 8RZ, UK.
      http://www.dcs.gla.ac.uk/~whited

      On 8 Mar 2013, at 18:41, Sean Luke <sean@...>
      wrote:

      > On Mar 8, 2013, at 7:08 AM, David White wrote:
      >
      >> Recently, some authors have used my review of ECJ in GPEM as a reference when employing the ECJ toolkit in their research.
      >> I *really* wouldn't want to take credit for the hard work of ECJ guru Sean Luke and the other contributors to ECJ!
      >
      > Well, I'm totally cool with it.
      >
      >> Therefore, please kindly only reference my review where the review itself is relevant (e.g. where the review was useful in identifying which toolkit to use, or when listing a set of reviews etc.).
      >>
      >> There currently is no canonical paper to cite for ECJ; the de facto standard has been to cite the URL of ECJ's website.
      >
      > And it's a problem too, because everyone cites it in a different way, and with a different version number. Collecting all the ECJ cites on google scholar is a nightmare, believe me.
      >
      > The basic problem is of course that there's no ECJ journal article. And that's not from lack of trying: I put together the start of an article long after the fact (around 2010?) and approached folks at GPEM or Evolutionary Computation, I forget which, about it, and the response I got was: what would people really get out of reading the article? And basically that's right I think. So that initial spec wound up modified and put at the beginning of the ECJ manual if you ever want to see it.
      >
      > I think what we should do is provide an official citation on the website proper. Which brings up some interesting issues which I think affects everyone and I think it might be interesting to discuss. So let me throw out a strawman for people to debate. Consider the following citation:
      >
      > @misc{ecj,
      > author={Sean Luke {\it et al}},
      > title={{ECJ} Evolutionary Computation Toolkit},
      > howpublished={Available at http://cs.gmu.edu/$sim$eclab/projects/ecj/},
      > year={1998}
      > }
      >
      > My own opinionated thoughts behind this citation, hoping to spur some discussion:
      >
      > 1. {\it et al}. This is here because ECJ's authorship changes, and some people cite everyone, others cite Sean Luke et al, etc. If the goal is to create a static citation for Google Scholar etc., it's got to have a static authorship. Sean Luke {\it et al} hard-coded into the bibtex entry is the best I can think of. Anyone else?
      >
      > 2. \url. I am really not a fan of \url and similar stuff because they nearly always format as \tt, which is pure unadulterated evil typesetting-wise. Plus \url is nonstandard bibtex and requires that people include packages in their latex file just to use the bibtex entry. BTW, it's always frustrating that latex won't break at /, and there's no way to ask it to so far as I know. My approach doesn't allow hyperrefs, which some people adore I know, but I'm not a fan. :-)
      >
      > 3. $sim$. This makes a proper tilde. I'd do http:/{\!}/ too but that only looks proper in some fonts.
      >
      > 4. Years and versions. ECJ typically goes through up to two versions a year. The problem is that Google Scholar, CiteSeerX, etc. treat different versions as *different publications*. So if we want a consistent static citation, the version can't be there. I'd *like* version information there so you know what version of the software people used, but... Also, the year, I guess, should be the year of Version 1, which was 1998. But it does make it look like the software is out of date, no?
      >
      > 5. Notes. There's no "note" field. Though some style guides are suggesting access information, I'm not a big fan of the [Online; accessed...] stuff, which seems to be a goofiness that's coming out of the tex community. It also can cause Google Scholar to split citations. At any rate ECJ's website has been the same for twelve years.
      >
      > Sean
    • Bob McKay
      Following on David s comments, I wonder whether it would be a suitable topic for Software: Practice and Experience . Going futher, Sean, maybe you could
      Message 2 of 5 , Mar 11, 2013
      • 0 Attachment
        Following on David's comments, I wonder whether it would be a suitable topic for "Software: Practice and Experience". Going futher, Sean, maybe you could coordinate a special issue of S:P&E on software design processes for stochastic algorithms: the issues are, after all, radically different from almost all other forms of software: what is a specification for a stochastic algorithm? How would you prove it correct? What test methodologies carry over and which are pointless? How do you design for modularity when your module specifications are themselves probabilistic?
        Another alternative would be to approach one of the EC journals for a special issue on the same topic (but to be honest, I think that approaching stochastic algorithms from an SP&E perspective, and emphasising how they parallel crisp software and how they differ, would be the more interesting theme),
             Cheers
             Bob
      Your message has been successfully submitted and would be delivered to recipients shortly.