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

gp/lisp newbie questions

Expand Messages
  • hippygenius
    i have the first three koza books on gp, and langdon d foundations of gp . clearly, there is a lot of emphasis on lisp in gp. so i have two specific
    Message 1 of 11 , Dec 2, 2003
      i have the first three koza books on gp, and langdon'd 'foundations of
      gp'.
      clearly, there is a lot of emphasis on lisp in gp. so i have two
      specific questions:

      1. what exact modern lisp compiler/interpreter for linux is best?
      2. i'm guessing that the better c++ implementations are faster, but
      how good or bad is the performance of lisp code? twice as slow as c++?
      3. what is the 'best' or most modern version of koza's lisp code? is
      it available for download? if i want to play with it as is, which
      linux lisp packages are needed to run it?
      4. is it actually easier to go with lisp than gp? i mean easier in
      terms of having explanations of the code directly in dr. koza's books,
      and easier in the sense that experimentation with creating new
      applications of the technology would be less of a hassle in lisp...

      thank you.
    • hippygenius
      sorry- question 4 should read: 4. is it actually easier to go with lisp than a c++ gp package? i mean easier in ... books, ... of ... c++? ... books,
      Message 2 of 11 , Dec 2, 2003
        sorry- question 4 should read:
        4. is it actually easier to go with lisp than a c++ gp package? i mean
        easier in
        > terms of having explanations of the code directly in dr. koza's
        books,
        > and easier in the sense that experimentation with creating new
        > applications of the technology would be less of a hassle in lisp...
        >


        --- In genetic_programming@yahoogroups.com, "hippygenius"
        <geneticprogrammer@s...> wrote:
        > i have the first three koza books on gp, and langdon'd 'foundations
        of
        > gp'.
        > clearly, there is a lot of emphasis on lisp in gp. so i have two
        > specific questions:
        >
        > 1. what exact modern lisp compiler/interpreter for linux is best?
        > 2. i'm guessing that the better c++ implementations are faster, but
        > how good or bad is the performance of lisp code? twice as slow as
        c++?
        > 3. what is the 'best' or most modern version of koza's lisp code? is
        > it available for download? if i want to play with it as is, which
        > linux lisp packages are needed to run it?
        > 4. is it actually easier to go with lisp than gp? i mean easier in
        > terms of having explanations of the code directly in dr. koza's
        books,
        > and easier in the sense that experimentation with creating new
        > applications of the technology would be less of a hassle in lisp...
        >
        > thank you.
      • John Koza
        Hello All: This e-mail raises the interesting question of what constitutes a faster implementation of GP. The obvious answer is that fastest is assembly code
        Message 3 of 11 , Dec 3, 2003
          Hello All:

          This e-mail raises the interesting question of what constitutes a "faster"
          implementation of GP.

          The obvious answer is that fastest is assembly code or its close cousin, C.

          However, the answer is very different if you look at this question from the
          point of view of how to make better use of the scarcest and most valuable
          resource, namely the researcher's time. In that case, the answer is a
          higher level language. A higher-level language lets you code much more
          efficiently. Moreover, assuming you are a programmer who makes mistakes, a
          higher level language lets you debug programs a whole lot quicker and easier
          (especially in the case of LISP) .

          In this spirit, after fiddling between 1994 and 1999 with GP coded in C, we
          moved (in 2000) from a C version of GP to a JAVA version of GP. There is
          nothing that requires the GP operations to be coded in the same programming
          language as the problem's fitness measure. For most real-world problems, the
          bulk of the computer time is expended in evaluating fitness. (There are
          notable exceptions, such as operations research types of problems, where the
          problem is very complex, but the fitness calculation is comparitively
          quick). For a great many real-world problems, the time-consuming fitness
          measure often comes in the form of a problem-specific simulator. In many
          cases, the problem-specific simulator comes from some outside source and the
          GP researcher isn't involved in writing the simulator at all. We observed
          that we spend about 2% of execution time inside the GP code and about 98% of
          the time inside the fitness measure. The JAVA code is, of course, much
          slower than the corresponding C code. But, who cares if you look at this
          question from the point of view of human efficiency. I don't add up a
          column of numbers in the most efficient possible way (i.e., write an
          assembly code program with N floating-point adds), but, instead, I use a
          million-lines of code in the form of Excel to present the numbers and their
          sum in my favorite font in my favorite font size on a big video screen.

          After reading this posting, it makes me wonder whether the best move, at
          this point in the history of GP, wouldn't be to move from JAVA back to LISP!

          Cheers.

          John R. Koza

          Consulting Professor
          Biomedical Informatics
          Department of Medicine
          Medical School Office Building (MC 5479)
          Stanford University
          Stanford, California 94305-5479

          Consulting Professor
          Department of Electrical Engineering
          School of Engineering
          Stanford University

          PREFERRED MAILING ADDRESS:
          Post Office Box K
          Los Altos, CA 94023-4011 USA

          Phone: 650-941-0336
          Fax: 650-941-9430
          E-Mail: koza@...
          WWW Home Page: http://www.smi.stanford.edu/people/koza

          For information about field of genetic programming in general:
          http://www.genetic-programming.org

          For information about Genetic Programming Inc.:
          http://www.genetic-programming.com

          For information about the 2003 book "Genetic Programming IV: Routine
          Human-Competitive Machine Intelligence", visit
          http://www.genetic-programming.org/gpbook4toc.html

          For the genetic programming bibliography, visit
          http://liinwww.ira.uka.de/bibliography/Ai/genetic.programming.html

          For information about the Genetic Programming book series from Kluwer
          Academic Publishers, visit http://www.genetic-programming.org/gpkluwer.html

          For information about the annual Genetic and Evolutionary Computation
          Conference (GECCO) (which includes the annual Genetic Programming
          Conference) to be held in Seattle on June 26-30, 2004 (Saturday -
          Wednesday), visit http://www.isgec.org/gecco-2004/

          For information about the International Society on Genetic and Evolutionary
          Computation visit: http://www.isgec.org/

          For information about the annual Euro-Genetic-Programming Conference to be
          held in April 5-7, 2004 (Monday-Wednesday) at the University of Coimbra in
          Coimbra Portugal, visit http://www.evonet.info/eurogp2004/

          For information about the annual NASA/DoD Conference on Evolvable Hardware
          (EH) in Seattle on June 24-26 (Thursday - Saturday), 2004, visit
          http://ehw.jpl.nasa.gov/events/nasaeh04/

          For information about the Asia-Pacific Workshop on Genetic Programming
          (ASPGP03), visit http://www.cs.adfa.edu.au/~cec_gp/

          For information about the Genetic Programming Theory and Practice (GPTP)
          workshop organized by the Center for the Study of Complex Systems of the
          University of Michigan, visit
          http://cscs.umich.edu/calendar/conferences/gptp2003/

          For information about the Genetic Programming and Evolvable Hardware journal
          published by Kluwer Academic Publishers, visit
          http://www.kluweronline.com/issn/1389-2576













          -----Original Message-----
          From: hippygenius [mailto:geneticprogrammer@...]
          Sent: Tuesday, December 02, 2003 7:50 PM
          To: genetic_programming@yahoogroups.com
          Subject: [GP] gp/lisp newbie questions


          i have the first three koza books on gp, and langdon'd 'foundations of
          gp'.
          clearly, there is a lot of emphasis on lisp in gp. so i have two
          specific questions:

          1. what exact modern lisp compiler/interpreter for linux is best?
          2. i'm guessing that the better c++ implementations are faster, but
          how good or bad is the performance of lisp code? twice as slow as c++?
          3. what is the 'best' or most modern version of koza's lisp code? is
          it available for download? if i want to play with it as is, which
          linux lisp packages are needed to run it?
          4. is it actually easier to go with lisp than gp? i mean easier in
          terms of having explanations of the code directly in dr. koza's books,
          and easier in the sense that experimentation with creating new
          applications of the technology would be less of a hassle in lisp...

          thank you.






          To unsubscribe from this group, send an email to:
          genetic_programming-unsubscribe@yahoogroups.com



          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        • Mike Eggleston
          Hi John! ... Fascinating. I love this stuff. I was talking about this specific topic last night. If then the easiest thing is to move back to lisp (love the
          Message 4 of 11 , Dec 3, 2003
            Hi John!

            On Wed, 03 Dec 2003, John Koza wrote:

            > Hello All:
            >
            > This e-mail raises the interesting question of what constitutes a "faster"
            > implementation of GP.
            >
            > The obvious answer is that fastest is assembly code or its close cousin, C.
            >
            > However, the answer is very different if you look at this question from the
            > point of view of how to make better use of the scarcest and most valuable
            > resource, namely the researcher's time. In that case, the answer is a
            > higher level language. A higher-level language lets you code much more
            > efficiently. Moreover, assuming you are a programmer who makes mistakes, a
            > higher level language lets you debug programs a whole lot quicker and easier
            > (especially in the case of LISP) .
            >
            > In this spirit, after fiddling between 1994 and 1999 with GP coded in C, we
            > moved (in 2000) from a C version of GP to a JAVA version of GP. There is
            > nothing that requires the GP operations to be coded in the same programming
            > language as the problem's fitness measure. For most real-world problems, the
            > bulk of the computer time is expended in evaluating fitness. (There are
            > notable exceptions, such as operations research types of problems, where the
            > problem is very complex, but the fitness calculation is comparitively
            > quick). For a great many real-world problems, the time-consuming fitness
            > measure often comes in the form of a problem-specific simulator. In many
            > cases, the problem-specific simulator comes from some outside source and the
            > GP researcher isn't involved in writing the simulator at all. We observed
            > that we spend about 2% of execution time inside the GP code and about 98% of
            > the time inside the fitness measure. The JAVA code is, of course, much
            > slower than the corresponding C code. But, who cares if you look at this
            > question from the point of view of human efficiency. I don't add up a
            > column of numbers in the most efficient possible way (i.e., write an
            > assembly code program with N floating-point adds), but, instead, I use a
            > million-lines of code in the form of Excel to present the numbers and their
            > sum in my favorite font in my favorite font size on a big video screen.
            >
            > After reading this posting, it makes me wonder whether the best move, at
            > this point in the history of GP, wouldn't be to move from JAVA back to LISP!
            >
            > Cheers.
            >
            > John R. Koza
            >
            > Consulting Professor
            > Biomedical Informatics
            > Department of Medicine
            > Medical School Office Building (MC 5479)
            > Stanford University
            > Stanford, California 94305-5479
            >
            > Consulting Professor
            > Department of Electrical Engineering
            > School of Engineering
            > Stanford University
            >
            > PREFERRED MAILING ADDRESS:
            > Post Office Box K
            > Los Altos, CA 94023-4011 USA
            >
            > Phone: 650-941-0336
            > Fax: 650-941-9430
            > E-Mail: koza@...
            > WWW Home Page: http://www.smi.stanford.edu/people/koza
            >
            > For information about field of genetic programming in general:
            > http://www.genetic-programming.org
            >
            > For information about Genetic Programming Inc.:
            > http://www.genetic-programming.com
            >
            > For information about the 2003 book "Genetic Programming IV: Routine
            > Human-Competitive Machine Intelligence", visit
            > http://www.genetic-programming.org/gpbook4toc.html
            >
            > For the genetic programming bibliography, visit
            > http://liinwww.ira.uka.de/bibliography/Ai/genetic.programming.html
            >
            > For information about the Genetic Programming book series from Kluwer
            > Academic Publishers, visit http://www.genetic-programming.org/gpkluwer.html
            >
            > For information about the annual Genetic and Evolutionary Computation
            > Conference (GECCO) (which includes the annual Genetic Programming
            > Conference) to be held in Seattle on June 26-30, 2004 (Saturday -
            > Wednesday), visit http://www.isgec.org/gecco-2004/
            >
            > For information about the International Society on Genetic and Evolutionary
            > Computation visit: http://www.isgec.org/
            >
            > For information about the annual Euro-Genetic-Programming Conference to be
            > held in April 5-7, 2004 (Monday-Wednesday) at the University of Coimbra in
            > Coimbra Portugal, visit http://www.evonet.info/eurogp2004/
            >
            > For information about the annual NASA/DoD Conference on Evolvable Hardware
            > (EH) in Seattle on June 24-26 (Thursday - Saturday), 2004, visit
            > http://ehw.jpl.nasa.gov/events/nasaeh04/
            >
            > For information about the Asia-Pacific Workshop on Genetic Programming
            > (ASPGP03), visit http://www.cs.adfa.edu.au/~cec_gp/
            >
            > For information about the Genetic Programming Theory and Practice (GPTP)
            > workshop organized by the Center for the Study of Complex Systems of the
            > University of Michigan, visit
            > http://cscs.umich.edu/calendar/conferences/gptp2003/
            >
            > For information about the Genetic Programming and Evolvable Hardware journal
            > published by Kluwer Academic Publishers, visit
            > http://www.kluweronline.com/issn/1389-2576
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            >
            > -----Original Message-----
            > From: hippygenius [mailto:geneticprogrammer@...]
            > Sent: Tuesday, December 02, 2003 7:50 PM
            > To: genetic_programming@yahoogroups.com
            > Subject: [GP] gp/lisp newbie questions
            >
            >
            > i have the first three koza books on gp, and langdon'd 'foundations of
            > gp'.
            > clearly, there is a lot of emphasis on lisp in gp. so i have two
            > specific questions:
            >
            > 1. what exact modern lisp compiler/interpreter for linux is best?
            > 2. i'm guessing that the better c++ implementations are faster, but
            > how good or bad is the performance of lisp code? twice as slow as c++?
            > 3. what is the 'best' or most modern version of koza's lisp code? is
            > it available for download? if i want to play with it as is, which
            > linux lisp packages are needed to run it?
            > 4. is it actually easier to go with lisp than gp? i mean easier in
            > terms of having explanations of the code directly in dr. koza's books,
            > and easier in the sense that experimentation with creating new
            > applications of the technology would be less of a hassle in lisp...

            Fascinating. I love this stuff. I was talking about this specific
            topic last night. If then the easiest thing is to move back to lisp
            (love the language) then what is the most current lisp code that
            implements this type of system? Is there lisp code that easily
            implements island-model? I know I can hook stuff into xlisp (my
            lisp is rusty), how about using gcl instead?

            Mike
          • Lee Spector
            ... John et al., As a dyed-in-the-wool Lisper I like the sound of that! The benefits of high-level languages are all the greater if one is actively
            Message 5 of 11 , Dec 3, 2003
              On Dec 3, 2003, at 12:23 PM, John Koza wrote:
              > After reading this posting, it makes me wonder whether the best move,
              > at
              > this point in the history of GP, wouldn't be to move from JAVA back to
              > LISP!


              John et al.,

              As a dyed-in-the-wool Lisper I like the sound of that! The benefits of
              high-level languages are all the greater if one is actively
              experimenting with new GP algorithms and representations, rather than
              just using well-established GP techniques. I'm not denying that there
              are interesting experiments that one can do within a C-based GP system,
              but my own rather radical departures have been very much facilitated by
              Lisp's unique high-level features.

              On the questions about specific Lisps: I would recommend using a Common
              Lisp implementation, of which there are many (some free, some not).
              There are several Lisp FAQs around the net with lists of
              implementations, like the one at
              http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html. I personally
              prefer MCL under MacOS (http://www.digitool.com/) and CMUCL under Linux
              (http://www.cons.org/cmucl). Another potentially useful Lisp resource
              is http://www.paulgraham.com/lisp.html -- this is a page by Paul
              Graham, who has written some great books on Lisp.

              On the questions about Lisp GP code: All of the public stuff that I
              know of is at http://www.genetic-programming.org/gpftpsite.html, but
              none of that implements traditional GP with an island deme model (about
              which the poster asked). But one should be able to add demes to Koza's
              original code fairly easily. BTW my PushGP, which is listed on the
              page, exists in C and Lisp implementations (though it doesn't say that
              there), along with a Java version by Russ Abbott.

              -Lee

              --
              Lee Spector
              Dean, Cognitive Science + Associate Professor, Computer Science
              Cognitive Science, Hampshire College, Amherst, MA 01002
              lspector@..., http://hampshire.edu/lspector/
              Phone: 413-559-5352, Fax: 413-559-5438
            • Ken Anderson
              Here s an old paper http://openmap.bbn.com/~kanderso/performance/postscript/courage-in-profiles.ps that shows that a little profiling can go a long way to make
              Message 6 of 11 , Dec 3, 2003
                Here's an old paper
                http://openmap.bbn.com/~kanderso/performance/postscript/courage-in-profiles.ps
                that shows that a little profiling can go a long way to make Lisp competitive with C. One of its benchmarks is John Koza's GP code from the first book.

                k

                At 02:06 PM 12/3/2003 -0500, Lee Spector wrote:
                >On Dec 3, 2003, at 12:23 PM, John Koza wrote:
                >> After reading this posting, it makes me wonder whether the best move,
                >> at
                >> this point in the history of GP, wouldn't be to move from JAVA back to
                >> LISP!
                >
                >
                >John et al.,
                >
                >As a dyed-in-the-wool Lisper I like the sound of that! The benefits of
                >high-level languages are all the greater if one is actively
                >experimenting with new GP algorithms and representations, rather than
                >just using well-established GP techniques. I'm not denying that there
                >are interesting experiments that one can do within a C-based GP system,
                >but my own rather radical departures have been very much facilitated by
                >Lisp's unique high-level features.
                >
                >On the questions about specific Lisps: I would recommend using a Common
                >Lisp implementation, of which there are many (some free, some not).
                >There are several Lisp FAQs around the net with lists of
                >implementations, like the one at
                >http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html. I personally
                >prefer MCL under MacOS (http://www.digitool.com/) and CMUCL under Linux
                >(http://www.cons.org/cmucl). Another potentially useful Lisp resource
                >is http://www.paulgraham.com/lisp.html -- this is a page by Paul
                >Graham, who has written some great books on Lisp.
                >
                >On the questions about Lisp GP code: All of the public stuff that I
                >know of is at http://www.genetic-programming.org/gpftpsite.html, but
                >none of that implements traditional GP with an island deme model (about
                >which the poster asked). But one should be able to add demes to Koza's
                >original code fairly easily. BTW my PushGP, which is listed on the
                >page, exists in C and Lisp implementations (though it doesn't say that
                >there), along with a Java version by Russ Abbott.
                >
                > -Lee
                >
                >--
                >Lee Spector
                >Dean, Cognitive Science + Associate Professor, Computer Science
                >Cognitive Science, Hampshire College, Amherst, MA 01002
                >lspector@..., http://hampshire.edu/lspector/
                >Phone: 413-559-5352, Fax: 413-559-5438
              • Mats Andrén
                Isn t this discussion kind of off-topic really? I mean, what programming language that really suits one best should have more to do with what you are used to
                Message 7 of 11 , Dec 3, 2003
                  Isn't this discussion kind of off-topic really? I mean, what programming
                  language that really suits one best should have more to do with what you
                  are used to than with what "is the best". If we want to save research-time,
                  then people should use whatever language they are confortable with, instead
                  of having to learn a language from scratch. Isn't it enough to state, once
                  and for all, that the principles of GP is possible to implement in just
                  about any programming language?

                  (Although I agree that there seems to be some confusion about this whole
                  "speed"-topic in the GP-community, so in that respect the question is
                  relevant, perhaps.)

                  My apologies if I sound rude or so. I just happen to be very tired of
                  Linux/Windows, LISP/C/Java/etc-controversies.

                  /Mats

                  At 15:08 2003-12-03 -0500, you wrote:
                  >Here's an old paper
                  >http://openmap.bbn.com/~kanderso/performance/postscript/courage-in-profiles.ps
                  >that shows that a little profiling can go a long way to make Lisp
                  >competitive with C. One of its benchmarks is John Koza's GP code from the
                  >first book.
                  >
                  >k
                  >
                  >At 02:06 PM 12/3/2003 -0500, Lee Spector wrote:
                  > >On Dec 3, 2003, at 12:23 PM, John Koza wrote:
                  > >> After reading this posting, it makes me wonder whether the best move,
                  > >> at
                  > >> this point in the history of GP, wouldn't be to move from JAVA back to
                  > >> LISP!
                  > >
                  > >
                  > >John et al.,
                  > >
                  > >As a dyed-in-the-wool Lisper I like the sound of that! The benefits of
                  > >high-level languages are all the greater if one is actively
                  > >experimenting with new GP algorithms and representations, rather than
                  > >just using well-established GP techniques. I'm not denying that there
                  > >are interesting experiments that one can do within a C-based GP system,
                  > >but my own rather radical departures have been very much facilitated by
                  > >Lisp's unique high-level features.
                  > >
                  > >On the questions about specific Lisps: I would recommend using a Common
                  > >Lisp implementation, of which there are many (some free, some not).
                  > >There are several Lisp FAQs around the net with lists of
                  > >implementations, like the one at
                  > >http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html. I personally
                  > >prefer MCL under MacOS (http://www.digitool.com/) and CMUCL under Linux
                  > >(http://www.cons.org/cmucl). Another potentially useful Lisp resource
                  > >is http://www.paulgraham.com/lisp.html -- this is a page by Paul
                  > >Graham, who has written some great books on Lisp.
                  > >
                  > >On the questions about Lisp GP code: All of the public stuff that I
                  > >know of is at http://www.genetic-programming.org/gpftpsite.html, but
                  > >none of that implements traditional GP with an island deme model (about
                  > >which the poster asked). But one should be able to add demes to Koza's
                  > >original code fairly easily. BTW my PushGP, which is listed on the
                  > >page, exists in C and Lisp implementations (though it doesn't say that
                  > >there), along with a Java version by Russ Abbott.
                  > >
                  > > -Lee
                  > >
                  > >--
                  > >Lee Spector
                  > >Dean, Cognitive Science + Associate Professor, Computer Science
                  > >Cognitive Science, Hampshire College, Amherst, MA 01002
                  > >lspector@..., http://hampshire.edu/lspector/
                  > >Phone: 413-559-5352, Fax: 413-559-5438
                  >
                  >
                  >
                  >To unsubscribe from this group, send an email to:
                  >genetic_programming-unsubscribe@yahoogroups.com
                  >
                  >
                  >
                  >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                • Sean Luke
                  ... You mentioned this was the case in 2000. 2003 Java VM versions (and C# ugh) are pretty dang fast at lots of stuff, the big exception being array access
                  Message 8 of 11 , Dec 3, 2003
                    On Dec 3, 2003, at 12:23 PM, John Koza wrote:

                    > We observed that we spend about 2% of execution time inside the GP
                    > code and about 98% of the time inside the fitness measure. The JAVA
                    > code is, of course, much slower than the corresponding C code.

                    You mentioned this was the case in 2000. 2003 Java VM versions (and C#
                    ugh) are pretty dang fast at lots of stuff, the big exception being
                    array access (which requires a bounds check each time for safety).
                    Java and C# have *really* improved over the last five years in terms of
                    speed. My experience is that for most programs, a well written,
                    non-lazy Java program performs quite well compared to a C program on a
                    modern VM.

                    The same, alas, cannot be said for Lisp, which appears to have not
                    improved at all in the last ten years. I love the language. But the
                    runtime technology in Allegro, MCL, Xanalys, and cmucl is way behind,
                    forcing me to hand optimize on a per-platform basis, and to (ugh)
                    heavily type my code, resulting in lots of 'the' and 'declaim' -- even
                    to keep up with *bad* Java code. One's mileage may vary of course, but
                    I've not had good Lisp speed experiences lately. :-(


                    > But, who cares if you look at this question from the point of view of
                    > human efficiency.

                    This IS the central problem with Java. It requires a LOT of typing to
                    get a simple thing done. In Lisp you can hack something very quickly
                    and get it running.


                    > After reading this posting, it makes me wonder whether the best move,
                    > at
                    > this point in the history of GP, wouldn't be to move from JAVA back to
                    > LISP!

                    Much as I hate the fact, I am using Lisp less and less now because
                    there is a terrible dearth of standardized libraries which run across
                    all platforms (GUI? OpenGL? XML? really standard sockets? threading?
                    crypto?), and no acceptably efficient, free cross-platform runtime with
                    which to distribute our code. And compared to what's available for C++
                    or Java, even for free, even the commercial Lisp IDEs are *horrible*.
                    What an amazing change of events. This was the language which
                    _invented_ the IDE.

                    Lisp is fading away, and faster now than before. <sigh>

                    Sean
                  • Lee Spector
                    ... Alas, I agree. But some of us die-hards still await the Lisp revival... The Paul Graham site I mentioned has some good evangelism toward this end. ... Yes,
                    Message 9 of 11 , Dec 4, 2003
                      On Dec 3, 2003, at 9:50 PM, Sean Luke wrote:
                      > The same, alas, cannot be said for Lisp, which appears to have not
                      > improved at all in the last ten years.  I love the language.  But the
                      > runtime technology in Allegro, MCL, Xanalys, and cmucl is way behind,


                      Alas, I agree. But some of us die-hards still await the Lisp revival...
                      The Paul Graham site I mentioned has some good evangelism toward this
                      end.

                      Sean wrote:
                      > This IS the central problem with Java.  It requires a LOT of typing to
                      > get a simple thing done.  In Lisp you can hack something very quickly
                      > and get it running.


                      Yes, and that's the main reason for my advocacy. I develop ideas in
                      Lisp, and run in Lisp as much as possible (often regaining speed by
                      working on a cluster), but sometimes later re-implement things in C
                      when the specs have stabilized and speed is essential -- that explains
                      our current re-implementation of PushGP in C.

                      BTW, one reason this is relevant for GP research in particular, and not
                      just an off-topic programming language debate, is that some of Lisp's
                      high-level features are particularly handy for GP. Of course the
                      standard GP program representation is Lisp-style expressions, but
                      that's just the beginning -- for example, Lisp's list-manipulation
                      primitives make it simple to implement program-manipulation operators,
                      and the presence of EVAL simplifies fitness evaluation (at a speed
                      cost!) in some situations.

                      -Lee

                      --
                      Lee Spector
                      Dean, Cognitive Science + Associate Professor, Computer Science
                      Cognitive Science, Hampshire College, Amherst, MA 01002
                      lspector@..., http://hampshire.edu/lspector/
                      Phone: 413-559-5352, Fax: 413-559-5438
                    • hippygenius
                      Hello to Dr. Koza and the group! You really have answered the question I was trying to ask: What is the fastest WAY TO GET THIS RESEARCH DONE. ... Indeed,
                      Message 10 of 11 , Dec 4, 2003
                        Hello to Dr. Koza and the group!

                        You really have answered the question I was trying to ask: "What is
                        the fastest WAY TO GET THIS RESEARCH DONE."

                        > However, the answer is very different if you look at this question
                        > from the point of view of how to make better use of the scarcest
                        > and most valuable resource, namely the researcher's time. In that
                        > case, the answer is a higher level language.

                        Indeed, execution time can be spent doing other things, reading, etc.
                        But coding time is pretty much pure focus on the code. If given a
                        choice between my computer running all night, or sitting up all night
                        many nights wrangleing c++ code, I think the former sounds a lot
                        better.

                        > After reading this posting, it makes me wonder whether the best
                        > move, at this point in the history of GP, wouldn't be to move from
                        > JAVA back to LISP!

                        me too!

                        Thanks for the excellent answer to the question I almost asked :)

                        I plan to get a book on LISP today.


                        --- In genetic_programming@yahoogroups.com, "John Koza" <john@j...>
                        wrote:
                        > Hello All:
                        >
                        > This e-mail raises the interesting question of what constitutes a
                        "faster"
                        > implementation of GP.
                        >
                        > The obvious answer is that fastest is assembly code or its close
                        cousin, C.
                        >
                        > However, the answer is very different if you look at this question
                        from the
                        > point of view of how to make better use of the scarcest and most
                        valuable
                        > resource, namely the researcher's time. In that case, the answer is
                        a
                        > higher level language. A higher-level language lets you code much
                        more
                        > efficiently. Moreover, assuming you are a programmer who makes
                        mistakes, a
                        > higher level language lets you debug programs a whole lot quicker
                        and easier
                        > (especially in the case of LISP) .
                        >
                        > In this spirit, after fiddling between 1994 and 1999 with GP coded
                        in C, we
                        > moved (in 2000) from a C version of GP to a JAVA version of GP.
                        There is
                        > nothing that requires the GP operations to be coded in the same
                        programming
                        > language as the problem's fitness measure. For most real-world
                        problems, the
                        > bulk of the computer time is expended in evaluating fitness. (There
                        are
                        > notable exceptions, such as operations research types of problems,
                        where the
                        > problem is very complex, but the fitness calculation is
                        comparitively
                        > quick). For a great many real-world problems, the time-consuming
                        fitness
                        > measure often comes in the form of a problem-specific simulator. In
                        many
                        > cases, the problem-specific simulator comes from some outside source
                        and the
                        > GP researcher isn't involved in writing the simulator at all. We
                        observed
                        > that we spend about 2% of execution time inside the GP code and
                        about 98% of
                        > the time inside the fitness measure. The JAVA code is, of course,
                        much
                        > slower than the corresponding C code. But, who cares if you look at
                        this
                        > question from the point of view of human efficiency. I don't add up
                        a
                        > column of numbers in the most efficient possible way (i.e., write an
                        > assembly code program with N floating-point adds), but, instead, I
                        use a
                        > million-lines of code in the form of Excel to present the numbers
                        and their
                        > sum in my favorite font in my favorite font size on a big video
                        screen.
                        >
                        > After reading this posting, it makes me wonder whether the best
                        move, at
                        > this point in the history of GP, wouldn't be to move from JAVA back
                        to LISP!
                        >
                        > Cheers.
                        >
                        > John R. Koza
                        >
                        > Consulting Professor
                        > Biomedical Informatics
                        > Department of Medicine
                        > Medical School Office Building (MC 5479)
                        > Stanford University
                        > Stanford, California 94305-5479
                        >
                        > Consulting Professor
                        > Department of Electrical Engineering
                        > School of Engineering
                        > Stanford University
                        >
                        > PREFERRED MAILING ADDRESS:
                        > Post Office Box K
                        > Los Altos, CA 94023-4011 USA
                        >
                        > Phone: 650-941-0336
                        > Fax: 650-941-9430
                        > E-Mail: koza@s...
                        > WWW Home Page: http://www.smi.stanford.edu/people/koza
                        >
                        > For information about field of genetic programming in general:
                        > http://www.genetic-programming.org
                        >
                        > For information about Genetic Programming Inc.:
                        > http://www.genetic-programming.com
                        >
                        > For information about the 2003 book "Genetic Programming IV: Routine
                        > Human-Competitive Machine Intelligence", visit
                        > http://www.genetic-programming.org/gpbook4toc.html
                        >
                        > For the genetic programming bibliography, visit
                        > http://liinwww.ira.uka.de/bibliography/Ai/genetic.programming.html
                        >
                        > For information about the Genetic Programming book series from
                        Kluwer
                        > Academic Publishers, visit http://www.genetic-programming
                        org/gpkluwer.html
                        >
                        > For information about the annual Genetic and Evolutionary
                        Computation
                        > Conference (GECCO) (which includes the annual Genetic Programming
                        > Conference) to be held in Seattle on June 26-30, 2004 (Saturday -
                        > Wednesday), visit http://www.isgec.org/gecco-2004/
                        >
                        > For information about the International Society on Genetic and
                        Evolutionary
                        > Computation visit: http://www.isgec.org/
                        >
                        > For information about the annual Euro-Genetic-Programming Conference
                        to be
                        > held in April 5-7, 2004 (Monday-Wednesday) at the University of
                        Coimbra in
                        > Coimbra Portugal, visit http://www.evonet.info/eurogp2004/
                        >
                        > For information about the annual NASA/DoD Conference on Evolvable
                        Hardware
                        > (EH) in Seattle on June 24-26 (Thursday - Saturday), 2004, visit
                        > http://ehw.jpl.nasa.gov/events/nasaeh04/
                        >
                        > For information about the Asia-Pacific Workshop on Genetic
                        Programming
                        > (ASPGP03), visit http://www.cs.adfa.edu.au/~cec_gp/
                        >
                        > For information about the Genetic Programming Theory and Practice
                        (GPTP)
                        > workshop organized by the Center for the Study of Complex Systems of
                        the
                        > University of Michigan, visit
                        > http://cscs.umich.edu/calendar/conferences/gptp2003/
                        >
                        > For information about the Genetic Programming and Evolvable Hardware
                        journal
                        > published by Kluwer Academic Publishers, visit
                        > http://www.kluweronline.com/issn/1389-2576
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        > -----Original Message-----
                        > From: hippygenius [mailto:geneticprogrammer@s...]
                        > Sent: Tuesday, December 02, 2003 7:50 PM
                        > To: genetic_programming@yahoogroups.com
                        > Subject: [GP] gp/lisp newbie questions
                        >
                        >
                        > i have the first three koza books on gp, and langdon'd 'foundations
                        of
                        > gp'.
                        > clearly, there is a lot of emphasis on lisp in gp. so i have two
                        > specific questions:
                        >
                        > 1. what exact modern lisp compiler/interpreter for linux is best?
                        > 2. i'm guessing that the better c++ implementations are faster, but
                        > how good or bad is the performance of lisp code? twice as slow as
                        c++?
                        > 3. what is the 'best' or most modern version of koza's lisp code? is
                        > it available for download? if i want to play with it as is, which
                        > linux lisp packages are needed to run it?
                        > 4. is it actually easier to go with lisp than gp? i mean easier in
                        > terms of having explanations of the code directly in dr. koza's
                        books,
                        > and easier in the sense that experimentation with creating new
                        > applications of the technology would be less of a hassle in lisp...
                        >
                        > thank you.
                        >
                        >
                        >
                        >
                        >
                        >
                        > To unsubscribe from this group, send an email to:
                        > genetic_programming-unsubscribe@yahoogroups.com
                        >
                        >
                        >
                        > Your use of Yahoo! Groups is subject to http://docs.yahoo
                        com/info/terms/
                      • hippygenius
                        Dr. Spector & the group- I am indeed developing a method at this phase of my research, and I agree that LISP is great for that. This morning I read from some
                        Message 11 of 11 , Dec 4, 2003
                          Dr. Spector & the group-

                          I am indeed developing a method at this phase of my research, and I
                          agree that LISP is great for that. This morning I read from some of
                          the LISP sites that you mentioned in your previous post.

                          The analogy that came to mind was that perhaps developing a concept in
                          c/c++ is like composing a thesis on an old Smith Corona. As a child I
                          watched my mother write (white-out in hand) at the old typewriter,
                          while my father (also in grad school at the time) used a legal pad,
                          then paid to have it typed. I think he suffered less.

                          Perhaps if I sort of sketch out the idea in LISP, get it working, and
                          need more execution speed, I can translate the code into c, for
                          real-world use.

                          By the way, I don't think the subject is off-topic at all, either. I
                          don't think anyone was speaking in terms of 'which is the best
                          language,' but rather 'which language is best if your priorities are
                          x,y,z.' When I have a dedline looming, I don't feel particularly
                          'comfortable' with any language, nor do I get paid to feel
                          comfortable. So, as Dr. Koza nicely stated, there are some
                          considerations in planning a project that involve researcher time as
                          well as execution time. I appreciate the fine thinking that was put
                          into the responses, and my question was answered very nicely.





                          --- In genetic_programming@yahoogroups.com, Lee Spector <lspector@h...
                          > wrote:
                          >
                          > On Dec 3, 2003, at 9:50 PM, Sean Luke wrote:
                          > > The same, alas, cannot be said for Lisp, which appears to have not
                          > > improved at all in the last ten years.  I love the language.  But
                          the
                          > > runtime technology in Allegro, MCL, Xanalys, and cmucl is way
                          behind,
                          >
                          >
                          > Alas, I agree. But some of us die-hards still await the Lisp
                          revival...
                          > The Paul Graham site I mentioned has some good evangelism toward
                          this
                          > end.
                          >
                          > Sean wrote:
                          > > This IS the central problem with Java.  It requires a LOT of
                          typing to
                          > > get a simple thing done.  In Lisp you can hack something very
                          quickly
                          > > and get it running.
                          >
                          >
                          > Yes, and that's the main reason for my advocacy. I develop ideas in
                          > Lisp, and run in Lisp as much as possible (often regaining speed by
                          > working on a cluster), but sometimes later re-implement things in C
                          > when the specs have stabilized and speed is essential -- that
                          explains
                          > our current re-implementation of PushGP in C.
                          >
                          > BTW, one reason this is relevant for GP research in particular, and
                          not
                          > just an off-topic programming language debate, is that some of
                          Lisp's
                          > high-level features are particularly handy for GP. Of course the
                          > standard GP program representation is Lisp-style expressions, but
                          > that's just the beginning -- for example, Lisp's list-manipulation
                          > primitives make it simple to implement program-manipulation
                          operators,
                          > and the presence of EVAL simplifies fitness evaluation (at a speed
                          > cost!) in some situations.
                          >
                          > -Lee
                          >
                          > --
                          > Lee Spector
                          > Dean, Cognitive Science + Associate Professor, Computer Science
                          > Cognitive Science, Hampshire College, Amherst, MA 01002
                          > lspector@h..., http://hampshire.edu/lspector/
                          > Phone: 413-559-5352, Fax: 413-559-5438
                        Your message has been successfully submitted and would be delivered to recipients shortly.