Grokbase Groups Perl ai May 2001
FAQ
Hello All,

I'm brand new to real AI and was wondering if those on the list who are
interested
in helping out a newbie could point me in the right direction as to what
I can read
to get me up to speed with AI.

To be more specific my interests lye in creating a pole / response
program which
can recognize human language and learn from its inputted data.

I've done this to an extent already but I'm sure that it is no where
near the correct
or proficient way. As is stands now my program can be polled and
responds by
recognizing one word from the input and searching a file for that word.

The file contains lines as such: hi:::Hello how are you?

If there is an entry associated with that word it responds with the
corresponding
remainder after the :::'s.

Like I said I don't in any way believe that this is proficient. As a
mater of fact I
understand that it's the absolute wrong way to do it.

That's why I'm here :)

Can anyone help?

Brian Foy Jr.

Search Discussions

  • Lee Goddard at May 23, 2001 at 1:50 pm
    Is anyone got any output from music composition scripts they'd be happy to
    share? Definitely not source code, just MIDI/mp3 files?

    TIA,
    lee
  • Guinevere liberty at May 23, 2001 at 2:52 pm

    --- Lee Goddard wrote:
    Is anyone got any output from music composition
    scripts they'd be happy to
    share? Definitely not source code, just MIDI/mp3
    files?

    I'll take the source code! :-)

    =====
    perl -e '$_=qq{ibdlfs qfsm bopuifs kvtu};
    map{print " ",map(chr(ord($_)-1),split //)} reverse split;'
    or
    perl -e '@_=qw(ibdlfs qfsm bopuifs kvtu);print reverse map{chr(ord($_)-1)} @_'
    for short.

    __________________________________________________
    Do You Yahoo!?
    Yahoo! Auctions - buy the things you want at great prices
    http://auctions.yahoo.com/
  • Michael Schuyler Karman at May 23, 2001 at 4:50 pm
    I've got output from lisp code if you'd like to here that.
    On Wed, 23 May 2001, Lee Goddard wrote:

    Is anyone got any output from music composition scripts they'd be happy to
    share? Definitely not source code, just MIDI/mp3 files?

    TIA,
    lee
  • Paris Sinclair at May 24, 2001 at 1:57 am

    On Wed, 23 May 2001, CIO wrote:

    Hello All,

    I'm brand new to real AI and was wondering if those on the list who are
    interested
    in helping out a newbie could point me in the right direction as to what
    I can read
    to get me up to speed with AI.

    To be more specific my interests lye in creating a pole / response
    program which
    can recognize human language and learn from its inputted data.
    <snip>

    My advice is not even think about doing actual tasks until you have an
    understanding of the field and don't consider yourself a newbie. There are
    lots of high level sites for this...

    This list is mainly for people with academic or pragmatic approaches to
    problem solving in AI to flame each other, and for people who don't know
    what namespace to put their modules... :)

    Paris Sinclair
  • Ken Williams at May 24, 2001 at 5:03 am

    Paris Sinclair wrote:
    On Wed, 23 May 2001, CIO wrote:
    I'm brand new to real AI and was wondering if those on the list who
    are interested in helping out a newbie could point me in the right
    direction as to what I can read to get me up to speed with AI.

    To be more specific my interests lye in creating a pole / response
    program which can recognize human language and learn from its
    inputted data.
    <snip>

    My advice is not even think about doing actual tasks until you have an
    understanding of the field and don't consider yourself a newbie.
    I disagree. One should work on whatever project is interesting. CIO
    (if that is your real name), I think this is a great project to start
    out on. Paris, I don't think it's very helpful to scare people away
    from working on projects they think will be fun.

    I have a couple pieces of advice on the project. First, you should know
    that lots of people have done projects like this, with varying degrees
    of success. Most of the successful ones tend to create massive sets of
    trigger->response data like the one you've described, and the success
    of the system tends to lie in the quality and quantity of the data. The
    program machinery tends to be very small and simple in comparison.

    Your system does need to be flexible enough so that it can grow, though.
    You'll probably become frustrated quickly with scanning for single
    words, so you might decide to use arbitrary regular expressions as the
    triggers. Then once you're using regular expressions, you'll probably
    want to have a way to do transformations of the input, so that a
    statement like "I like eggs" can be greeted with the response "Why do
    you like eggs?". This might be done with Perl's substitution operator.
    Or that might prove too limiting, so you might want to allow some
    arbitrary subroutine to be run and generate the response.

    As you can see, the complexity is only limited by what you're willing to
    implement. There are the usual tradeoffs of flexibility vs. speed vs.
    complexity vs. motivation, etc.

    You also might want to check out some of the more successful projects
    like yours, to see what approaches they've taken. The Loebner prize
    contest is a good place to start:
    http://www.loebner.net/Prizef/loebner-prize.html

    You mentioned learning, and for that you might want to take a look at
    'purl', the infobot that hangs out on the #perl channel. It/she
    observes people's conversations, learns facts (with varying degrees of
    success), and spits those facts back out when it seems relevant. She's
    sometimes useful and quite often entertaining.
    This list is mainly for people with academic or pragmatic approaches to
    problem solving in AI to flame each other, and for people who don't know
    what namespace to put their modules... :)

    What gave you the idea about flaming? I've never seen any flame wars on
    this list. Traffic is so low that I've hardly seen much else either,
    but flames are decidedly absent.

    And while there are some academic types around here, I don't know
    whether that's the norm. I don't know the backgrounds of most people.
    But the description of this list on http://lists.perl.org/ simply says
    "Discussions of Artificial Intelligence in Perl." It doesn't say
    anything about newbies being unwelcome.


    ------------------- -------------------
    Ken Williams Last Bastion of Euclidity
    ken@forum.swarthmore.edu The Math Forum
  • Gidon Wise at May 24, 2001 at 5:33 am
    Right on, Ken.


    Also check out the Eliza bot in CPAN.

    Ken Williams wrote:
  • Jonathan Eisenzopf at May 24, 2001 at 5:42 am
    Or even try out Eliza as an AIM bot :)
    http://www.webreference.com/perl/tutorial/13/

    ----- Original Message -----
    From: "Gidon Wise" <gidon@gidon.com>
    To: "Ken Williams" <ken@forum.swarthmore.edu>
    Cc: "Paris Sinclair" <pariss@efn.org>; "CIO" <cio@ewebplace.com>;
    <perl-ai@perl.org>
    Sent: Thursday, May 24, 2001 1:41 AM
    Subject: Re: Just starting out.. newbie help :)

    Right on, Ken.


    Also check out the Eliza bot in CPAN.

    Ken Williams wrote:
  • Lee Goddard at May 24, 2001 at 12:17 pm
    To be honest, I think you're asking a bit much of us!

    AI is a huge and much disputed field; there are less
    authorities, more histories. Yesterday's hyped general
    problem solver is today's laughable toy.

    I took a Master of Science degree at Sussex, which is
    a pretty good place to study, got a good grade and
    still feel I know very very little.

    The best advice I heard was to read a history of AI
    alongside a political history of the USA: I was not
    amazed to see the military needs and the MIT budget,
    the military needs and the MIT line.

    For good bibliographies, check out the MSc introductory
    reading lists at www.cogs.susx.ac.uk, http://www.edinburgh.ac.uk/,
    and www.mit.edu.

    As to doing AI in Perl - you're really much better
    off starting in PROLOG, POP-11, or LISP (in order of
    my personal preference), and then transferring to a
    high-power language like C++ and (ha!) Java.

    Perl is, to my mind, for all of it's syntactic
    openness, far too slow for any AI projects involving
    standard techniques like Artificial Neural Networks
    or Genetic Algorithms.

    As to the project you mentioned below: it's not clear
    to my frazzled brain exactly what you are doing.

    You said,

    ... my interests lye in creating a pole/response
    program which can recognize human language and learn
    from its inputted data.

    I've done this to an extent already ... but I'm sure
    that it is no where near the correct or proficient way....

    I wouldn't accept anyone telling you you've done it in
    an incorrect manner - only an inefficient or ineffective
    manner. If you're dealing with speech recognition, you're
    up there with the big corps: Bill Gates has frequently
    gone on record saying that this is the way forward for
    Microsoft and all consumer computer interfaces.

    Along with handwriting recognition, this is the prime
    application for ANNs - irregular input with a definite
    intention, and the ability to progressively "learn".

    But I'm not sure that's what you're up to: if you care
    to clarify, maybe someone here can give you a hand.

    OTOH, you may find the new "learners" list a perl.com
    to offer more feedback, though it's very new.

    Cheers,
    lee






    Lee Goddard http://www.leegoddard.com
    Perl / XML / XSLT / Java / AI MIDI Music


    -----Original Message-----
    From: CIO
    Sent: 23 May 2001 14:38
    To: perl-ai@perl.org
    Subject: Just starting out.. newbie help :)


    Hello All,

    I'm brand new to real AI and was wondering if those on the list who are
    interested
    in helping out a newbie could point me in the right direction as to what
    I can read
    to get me up to speed with AI.

    To be more specific my interests lye in creating a pole / response
    program which
    can recognize human language and learn from its inputted data.

    I've done this to an extent already but I'm sure that it is no where
    near the correct
    or proficient way. As is stands now my program can be polled and
    responds by
    recognizing one word from the input and searching a file for that word.

    The file contains lines as such: hi:::Hello how are you?

    If there is an entry associated with that word it responds with the
    corresponding
    remainder after the :::'s.

    Like I said I don't in any way believe that this is proficient. As a
    mater of fact I
    understand that it's the absolute wrong way to do it.

    That's why I'm here :)

    Can anyone help?

    Brian Foy Jr.
  • Paris Sinclair at May 24, 2001 at 12:22 pm

    On Thu, 24 May 2001, Lee Goddard wrote:

    As to doing AI in Perl - you're really much better
    off starting in PROLOG, POP-11, or LISP (in order of
    my personal preference), and then transferring to a
    high-power language like C++ and (ha!) Java.

    Perl is, to my mind, for all of it's syntactic
    openness, far too slow for any AI projects involving
    standard techniques like Artificial Neural Networks
    or Genetic Algorithms.
    Perl is only slow when you use algorithms that were intended for PROLOG,
    LISP, C/C++ or Java.

    Correct Perl is usually just as fast. And sometimes faster... for example
    the Schwartzian Transform is faster than standard C algorithms for the
    same task, because it creates less temporary variables... certainly you
    could write the same thing in C, as perl is written in C, but it would not
    be easy and clear.

    Paris Sinclair
  • Lee Goddard at May 24, 2001 at 12:43 pm
    From: Paris Sinclair
    On Thu, 24 May 2001, Lee Goddard wrote:

    As to doing AI in Perl - you're really much better
    off starting in PROLOG, POP-11, or LISP (in order of
    my personal preference), and then transferring to a
    high-power language like C++ and (ha!) Java.

    Perl is, to my mind, for all of it's syntactic
    openness, far too slow for any AI projects involving
    standard techniques like Artificial Neural Networks
    or Genetic Algorithms.
    Perl is only slow when you use algorithms that were intended for PROLOG,
    LISP, C/C++ or Java.
    Which most AI algorithms are, when not written in logic notation.
    Correct Perl is usually just as fast. And sometimes faster... for example
    the Schwartzian Transform is faster than standard C algorithms for the
    same task, because it creates less temporary variables... certainly you
    could write the same thing in C, as perl is written in C, but it would not
    be easy and clear.
    Yep: if you can do it in Perl, you can do it in C, and as the compiled C
    is not interpreted, and can be better optimised, it's usually faster.
    Of course, Perl is much clearer, nicer to read, and the people are much
    more laid back (besides me and my triple espresso), but then how many
    ground-breaking AI apps are open source?!

    lee
  • Paris Sinclair at May 24, 2001 at 12:57 pm

    On Thu, 24 May 2001, Lee Goddard wrote:


    From: Paris Sinclair
    On Thu, 24 May 2001, Lee Goddard wrote:

    As to doing AI in Perl - you're really much better
    off starting in PROLOG, POP-11, or LISP (in order of
    my personal preference), and then transferring to a
    high-power language like C++ and (ha!) Java.

    Perl is, to my mind, for all of it's syntactic
    openness, far too slow for any AI projects involving
    standard techniques like Artificial Neural Networks
    or Genetic Algorithms.
    Perl is only slow when you use algorithms that were intended for PROLOG,
    LISP, C/C++ or Java.
    Which most AI algorithms are, when not written in logic notation.
    Which is why a Person should know a lot of Perl before using it for
    AI... if you're going to use "traditional" algorithms, it is best to use
    them in the languages they were written for.

    Of course, this need for rethinking is probably a good thing, since AI
    lags so far behind most areas of computing...
    Correct Perl is usually just as fast. And sometimes faster... for example
    the Schwartzian Transform is faster than standard C algorithms for the
    same task, because it creates less temporary variables... certainly you
    could write the same thing in C, as perl is written in C, but it would not
    be easy and clear.
    Yep: if you can do it in Perl, you can do it in C, and as the compiled C
    is not interpreted, and can be better optimised, it's usually faster.
    Of course, Perl is much clearer, nicer to read, and the people are much
    more laid back (besides me and my triple espresso), but then how many
    ground-breaking AI apps are open source?!

    lee
    Yes, if you write the algorithm the same, the C will be as fast or faster.
    Of course you make your claim without addressing the Schwartzian Transform
    example... there are other such examples out there too. But if you know
    anything about Perl, you know that it is inaccurate to just say it's
    "interpretted." It is in fact compiled into byte code, which doesn't
    require much interpretation. Real life examples that compare _good_ Perl
    to _good_ C generally show that they run about the same speed... the
    partially interpretted aspect of Perl allows additional types of
    optimization that are not possible in C, and the largely compiled aspect
    allows for optimizations not generally possible in fully interpretted
    languages. One of the reasons for this might be that because you can throw
    up your code much quicker in Perl, Perl programmers are more likely to
    throw out a few first attempts, and do more optimization. (I make this
    conjecture because I've seen studies that show Perl programmers often end
    up spending as much time on the program as a C coder would)

    I've heard these speed claims before, but I've also seen benchmarks of
    code from the wild to perform the same tasks in many languages, (it should
    be easy to find examples with google) and C and Perl performed very close
    to the same speed in nearly every one of these. (whereas Java keeps up
    only on certain types of tasks, and VB lags no matter what you're doing)

    Paris
  • John Porter at May 24, 2001 at 1:43 pm

    Paris Sinclair wrote:
    Perl is only slow when you use algorithms that were intended for PROLOG,
    LISP, C/C++ or Java.
    No, that is fundamentally mistaken.

    Algorithms are not "intended" for specific languages.
    At least, not the kinds of algorithms we're concerned
    with, like rule rewring, semantic net matching, etc.
    Sure, these will be inherently faster to implement
    in some languages, but it is false to conclude that
    the algorithms were "intended" for these languages.

    The plain, simple, and unfortunate fact is that Perl
    is slow for almost anything you would want to do.
    The one part of Perl that is almost always faster
    than equivalent functionality in other languages is
    the regular expression engine. Unless you can
    implement your critical algorithmic pieces on the
    perl regex engine, you're going to be slow.

    for example
    the Schwartzian Transform is faster than standard C algorithms for the
    same task, because it creates less temporary variables...
    Let's see your benchmarks. I don't believe you have any.


    --
    John Porter
  • John Porter at May 24, 2001 at 1:47 pm

    Lee Goddard wrote:
    if you can do it in Perl, you can do it in C,
    Unfortunately, not true. Perl is a very dynamic language,
    on the order of Lisp. That makes it capable of things
    compiled languages can't do. There is no "eval" in C.

    Of course, these languages are Turing-equivalent, so you
    really could do "eval" in C if you really, REALLY wanted
    to. But no one wants to bad enough to actually do it. :-)

    and as the compiled C
    is not interpreted, and can be better optimised, it's usually faster.
    Yes. For the things that *can* be done in C, they will usually
    be faster. The major downside is the horrendous *programmer*
    inefficiency of writing in C instead of a high-level language
    like Perl!

    --
    John Porter
  • Lee Goddard at May 24, 2001 at 1:48 pm
    From: John Porter
    Paris Sinclair wrote:
    Perl is only slow when you use algorithms that were intended for PROLOG,
    LISP, C/C++ or Java.
    No, that is fundamentally mistaken.
    Ahhh....that's better.
    Unless you can implement your critical algorithmic pieces on the
    perl regex engine, you're going to be slow.
    Or Yacc and Lex

    Let's see your benchmarks. I don't believe you have any.
    I want to believe.

    lee
  • John Porter at May 24, 2001 at 1:53 pm

    Lee Goddard wrote:
    John Porter wrote:
    Unless you can implement your critical algorithmic pieces on the
    perl regex engine, you're going to be slow.
    Or Yacc and Lex
    Um, I'm talking about when *perl* is fast...


    Let's see your benchmarks. I don't believe you have any.
    I want to believe.
    What, that Perl can be as fast as C for typical real-world
    tasks? I'd like to too, but I already know better.


    --
    John Porter
  • Simon Cozens at May 24, 2001 at 1:56 pm

    On Wed, May 23, 2001 at 02:50:26PM +0100, Lee Goddard wrote:
    Is anyone got any output from music composition scripts they'd be happy to
    share? Definitely not source code, just MIDI/mp3 files?
    http://sound-hack.org/

    --
    SM is fun. ADSM is not.
    "Safe, Sane, Consensual"... three words that cannot used to describe
    ADSM.
    - Graham Reed, sdm.
  • Gidon Wise at May 24, 2001 at 1:56 pm
    http://dev.scriptics.com/people/john.ousterhout/scripting.html

    Here are some studies that show that using scripting
    languages like perl saves you programming time.

    It is written by the inventor or TCL, another high level
    scripting language.
  • Gustaf Bjorksten at May 24, 2001 at 2:05 pm

    On Thu, 24 May 2001, John Porter wrote:

    Let's see your benchmarks. I don't believe you have any.
    I want to believe.
    What, that Perl can be as fast as C for typical real-world
    tasks? I'd like to too, but I already know better.
    ...and just when someone was saying that the list _never_ has flame
    wars... :P

    I think y'all missing the point. The original premise that "perl is not
    fast enough _for_AI_" is incorrect IMHO. This is not about raw execution
    speed! Perl is ace for modelling sh!t and definately has a place in my
    AI hacking toolkit. I don't give a damn if it aint the bleedingest
    lightningest-fast thing on two bits

    L8rz,
    gU5t4F


    Net Cens0rship = Book Burning in the Digital Age

    Act Now -> http://www.efa.org.au/Campaigns/alert99.html

    -----BEGIN GEEK CODE BLOCK-----
    Version: 3.1
    GIT d--(dpu) s++:--- a C++$ ULBX+++$ P++$ L++$>++++ !E W+++ N+
    o? K+ w-- !O !M-- !V PS(+) PE(+) Y+ !PGP t+ !5 !X R+++ tv b>b++ DI+
    !D@ G++ e+>+++ h* r+++ y+++*
    ------END GEEK CODE BLOCK------
  • Unknown Sender at May 24, 2001 at 2:09 pm

    I want to believe.
    What, that Perl can be as fast as C for typical real-world
    tasks? I'd like to too, but I already know better.
    ...and just when someone was saying that the list _never_ has flame
    wars... :P

    I think y'all missing the point. The original premise that "perl is not
    fast enough _for_AI_" is incorrect IMHO. This is not about raw execution
    speed! Perl is ace for modelling sh!t and definately has a place in my
    AI hacking toolkit. I don't give a damn if it aint the bleedingest
    lightningest-fast thing on two bits

    And prototyping speed is also important, which I find perl excells at.
  • J proctor at May 24, 2001 at 2:09 pm
    Remember, it's not flaming. It's polite discussion. :)

    I heard it claimed recently that AI is anything we haven't figured out how
    to do yet. Because once we figure it out, we look at it and say "that's
    not intelligence."

    Perl is only slow when you use algorithms that were intended for PROLOG,
    LISP, C/C++ or Java.
    Sure, these will be inherently faster to implement
    in some languages, but it is false to conclude that
    the algorithms were "intended" for these languages.
    Perhaps a better statement is that some of the languages were intended
    for particular classes of algorithms, and as such, are more efficient at
    handling them than other languages. Most of us had a pretty good sense of
    what he meant.

    It's an interesting debate about whether one should study AI and Perl
    separately, then try to synthesize them, or instead try to learn them
    together. I think it is valid for a newbie (who has enough sense to
    recognize himself as such) to experiment in areas he's interested.

    He won't be "taken seriously" for awhile by people who have made careers
    of AI research, but I didn't get the impression that was his intent,
    anyway. I hope that goal isn't a barrier to entry to this mailing list,
    and I hope we didn't scare him off.


    j
  • John Porter at May 24, 2001 at 2:25 pm

    Gustaf Bjorksten wrote:
    I think y'all missing the point. The original premise that "perl is not
    fast enough _for_AI_" is incorrect IMHO. This is not about raw execution
    speed! Perl is ace for modelling sh!t and definately has a place in my
    AI hacking toolkit. I don't give a damn if it aint the bleedingest
    lightningest-fast thing on two bits
    Unfortunately, most AI-related algorithms are
    computationally intense; execution speed *does*
    end up being critical. For example, I tried using
    perl to do some genetic algorithms stuff:
    On Sun, 31 Dec 2000 12:46:00 -0500,
    in <20001231124600.B1576@min.net>
    John Porter wrote:
    I'd like to say a little something from my own experience with doing
    GA/GP in Perl: Don't. That is, unless you're just doing it for fun,
    to see how it might look if written in Perl. If you're expecting to
    evolve (:-) a useful, production-quality system, think hard about
    your performance requirements. To do a GA/GP system really requires
    OO, I think, and OO in perl is bloody slow. I wrote a little
    OO-based GP testbed, with a total class hierarchy size of less than
    a dozen classes, and it was still a good two orders of magnitude
    slower than the full-blown Java-based system I've been using, ECJ,
    which contains like hundreds of classes. And that's Java. There
    are C++-based systems which are undoubtedly even faster. As you
    know, if you've done any GA/GP research, performce is critical
    because you'd like to run large populations for many generations,
    and in GP particularly, the time to evaluate an individual grows
    like exponentially in the number of generations, unless you have
    some kind of advanced aggressive size control.
    Undoubtedly some of you are going to argue that my "mistake"
    was using OO in perl. But as I said, "To do a GA/GP system
    really requires OO", and I stand firmly by that remark.

    --
    John Porter
  • Jacoby, David at May 24, 2001 at 2:43 pm
    If they badly wanted eval within C, they'd probably get it badly.

    --
    Dave Jacoby, Systems Administrator for Arnett Clinic
    (765) 448-8098 jacobyd@arnett.com
    If you're too tired to type the password right,
    you shouldn't be root anyway.
    -----Original Message-----
    From: John Porter [SMTP:jdporter@min.net]
    Sent: Thursday, May 24, 2001 8:48 AM
    To: perl-ai@perl.org
    Subject: Re: Just starting out.. newbie help :)

    Lee Goddard wrote:
    if you can do it in Perl, you can do it in C,
    Unfortunately, not true. Perl is a very dynamic language,
    on the order of Lisp. That makes it capable of things
    compiled languages can't do. There is no "eval" in C.

    Of course, these languages are Turing-equivalent, so you
    really could do "eval" in C if you really, REALLY wanted
    to. But no one wants to bad enough to actually do it. :-)

    and as the compiled C
    is not interpreted, and can be better optimised, it's usually faster.
    Yes. For the things that *can* be done in C, they will usually
    be faster. The major downside is the horrendous *programmer*
    inefficiency of writing in C instead of a high-level language
    like Perl!

    --
    John Porter
  • Terrence Monroe Brannon at May 24, 2001 at 2:44 pm

    Lee Goddard wrote:


    As to doing AI in Perl - you're really much better
    off starting in PROLOG, POP-11, or LISP (in order of
    my personal preference), and then transferring to a
    high-power language like C++ and (ha!) Java.

    Perl is, to my mind, for all of it's syntactic
    openness, far too slow for any AI projects involving
    standard techniques like Artificial Neural Networks
    or Genetic Algorithms.
    One of the most popular programs ever at www.perlmonks.org is a genetic
    program

    http://www.perlmonks.org/index.pl?node_id=31147&lastnode_id=9066
  • Gustaf Bjorksten at May 24, 2001 at 2:57 pm

    On Thu, 24 May 2001, John Porter wrote:

    On Sun, 31 Dec 2000 12:46:00 -0500,
    in <20001231124600.B1576@min.net>
    John Porter wrote:
    I'd like to say a little something from my own experience with doing
    GA/GP in Perl: Don't. That is, unless you're just doing it for fun,
    to see how it might look if written in Perl. If you're expecting to
    evolve (:-) a useful, production-quality system, think hard about
    your performance requirements. To do a GA/GP system really requires
    Yeah, well for me it is more about concepts rather than serious
    implementation. I've been hacking perl for half-a-dozen years and be
    damned learning PROLOG just for the odd occasion i want to dabble in AI
    stuff. Of course, if one day i join the ranks of the 1337 AI programmers
    and find myself building the most k-rad killer AI app then i prolly
    will look at languages other than perl.

    Point taken though about a _long-term_ evolving/learning system - you'd
    wanna make your decisions very carefully (and therefore should start
    out with a very open mind regards implementation language. Do tests -
    go with what works in your particular situation)

    I now return you to your regular perl-ai channel of... hrm.. silence! :\

    L8rz,
    gU5t4F


    Net Cens0rship = Book Burning in the Digital Age

    Act Now -> http://www.efa.org.au/Campaigns/alert99.html

    -----BEGIN GEEK CODE BLOCK-----
    Version: 3.1
    GIT d--(dpu) s++:--- a C++$ ULBX+++$ P++$ L++$>++++ !E W+++ N+
    o? K+ w-- !O !M-- !V PS(+) PE(+) Y+ !PGP t+ !5 !X R+++ tv b>b++ DI+
    !D@ G++ e+>+++ h* r+++ y+++*
    ------END GEEK CODE BLOCK------
  • John Porter at May 24, 2001 at 2:57 pm

    Interesting; thanks for the pointer. I will check it out.

    It will take some work to make a benchmark for comparison
    against, say, Java; but I will be surprised if Perl doesn't
    turn out significantly slower, as usual.

    --
    John Porter
  • John Porter at May 24, 2001 at 2:59 pm

    Gustaf Bjorksten wrote:
    Yeah, well for me it is more about concepts rather than serious
    implementation. ...
    Point taken though about a _long-term_ evolving/learning system - you'd
    wanna make your decisions very carefully (and therefore should start
    out with a very open mind regards implementation language. Do tests -
    go with what works in your particular situation)
    Yes, of course, Perl is great as a prototyping language.
    We all know that.


    --
    John Porter
  • Ken Williams at May 24, 2001 at 3:17 pm

    Terrence Monroe Brannon wrote:
    One of the most popular programs ever at www.perlmonks.org is a genetic
    program

    http://www.perlmonks.org/index.pl?node_id=31147&lastnode_id=9066
    There's also a GA article that Brad Murray and I wrote for TPJ a couple
    years ago.


    ------------------- -------------------
    Ken Williams Last Bastion of Euclidity
    ken@forum.swarthmore.edu The Math Forum
  • Lee Goddard at May 24, 2001 at 3:25 pm

    On Thu, 24 May 2001, John Porter wrote:
    On Sun, 31 Dec 2000 12:46:00 -0500,
    in <20001231124600.B1576@min.net>
    John Porter wrote:
    I'd like to say a little something from my own experience with doing
    GA/GP in Perl: Don't. That is, unless you're just doing
    it for fun,
    to see how it might look if written in Perl. If you're expecting to
    evolve (:-) a useful, production-quality system, think hard about
    your performance requirements. To do a GA/GP system really requires
    Yeah, well for me it is more about concepts rather than serious
    implementation. I've been hacking perl for half-a-dozen years and be
    damned learning PROLOG just for the odd occasion i want to dabble in AI
    stuff. Of course, if one day i join the ranks of the 1337 AI programmers
    and find myself building the most k-rad killer AI app then i prolly
    will look at languages other than perl.
    Hey, do PROLOG in Perl! It's a piece of cake:

    http://search.cpan.org/search?dist=Prolog-alpha
  • Lee Goddard at May 24, 2001 at 3:29 pm

    I think y'all missing the point. The original premise that "perl is not
    fast enough _for_AI_" is incorrect IMHO.
    Your opinion versus my opinion - all nonsense and useless.

    What we want are benchmarks - but maybe they're somewhere
    in the internet ether, winging their way to me.

    lee
  • Lee Goddard at May 24, 2001 at 3:30 pm

    http://dev.scriptics.com/people/john.ousterhout/scripting.html

    Here are some studies that show that using scripting
    languages like perl saves you programming time.
    Yeah, we all know *that*...! Seriously, though: have you anything
    about *processing* time, which was the point I tried to make without
    starting this bloody flame.

    lee
  • Lee Goddard at May 24, 2001 at 3:32 pm

    One of the most popular programs ever at www.perlmonks.org is a genetic
    program

    http://www.perlmonks.org/index.pl?node_id=31147&lastnode_id=9066
    With due respect, so what?

    It's still Perl, and I bet you my arse it'd still be too slow to run
    anything really useful. Not that it ain't cool.

    lee
  • Lee Goddard at May 24, 2001 at 3:34 pm
    From: John Porter
    Lee Goddard wrote:
    John Porter wrote:
    Unless you can implement your critical algorithmic pieces on the
    perl regex engine, you're going to be slow.
    Or Yacc and Lex
    Um, I'm talking about when *perl* is fast...
    Oh sorry - thought you were saying that perl is *faster* than C
    on that bit. It wasn't in my experience. Sadly.

    But hey, Perl 6.... you never know!

    Let's see your benchmarks. I don't believe you have any.
    I want to believe.
    What, that Perl can be as fast as C for typical real-world
    tasks? I'd like to too, but I already know better.
    Yup.

    lee
  • John Porter at May 24, 2001 at 3:35 pm

    It's still Perl, and I bet you my arse it'd still be too slow to run
    anything really useful. Not that it ain't cool.
    I took a look at it. Turns out, it's not especially cool.
    First, it isn't GP, as the author claims. It's GA.
    And as GA goes, it's not the least bit sophisticated.

    --
    John Porter
  • Lee Goddard at May 24, 2001 at 3:37 pm

    Lee Goddard wrote:
    if you can do it in Perl, you can do it in C,
    Unfortunately, not true. Perl is a very dynamic language,
    on the order of Lisp. That makes it capable of things
    compiled languages can't do. There is no "eval" in C.

    Of course, these languages are Turing-equivalent, so you
    really could do "eval" in C if you really, REALLY wanted
    to. But no one wants to bad enough to actually do it. :-)
    Some might say you shouldn't need to do it in Perl.
    Not me, of course: TMTOWTDI.
    and as the compiled C
    is not interpreted, and can be better optimised, it's usually faster.
    Yes. For the things that *can* be done in C, they will usually
    be faster. The major downside is the horrendous *programmer*
    inefficiency of writing in C instead of a high-level language
    like Perl!
    To an extent, I agree. I used to agree 100%, but then I started
    working Perl development contracts and saw so much very very very
    bad Perl that it occured to me that a laid-back language like Perl
    often leads to code so laid back it could do with some of the
    formalities often imposed by project managers on huge teams of C
    programmers.

    It's a scale thing, for me: Perl for prototyping (and, er, scripting)
    and C (or even Java) for the real work, that requires processing
    speed and reliability.

    Lee
  • William Thompson at May 24, 2001 at 3:49 pm
    While I hesitate to step into what seems like a religious war, there's an
    attempt at measuring processing time for a number of compiled and script
    languanges in the document

    wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf

    Not an AI benchmark, but string/dictionary search which is sometimes a component
    of AI programs. It's extremely hard to prove that any one language is in general
    any better at everything than another. I think that's probably a corallary of
    the "no free lunch" theorem.
    Mailing-List: contact perl-ai-help@perl.org; run by ezmlm
    List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list perl-ai@perl.org
    From: "Lee Goddard" <home@leegoddard.com>
    To: "Gidon Wise" <gidon@gidon.com>
    Cc: <perl-ai@perl.org>
    Subject: RE: Just starting out.. newbie help :)
    Date: Thu, 24 May 2001 16:30:38 +0100
    MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    X-Priority: 3 (Normal)
    X-MSMail-Priority: Normal
    X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
    Importance: Normal
    X-Spam-Rating: onion.valueclick.com 1.6.2 0/1000/N
    http://dev.scriptics.com/people/john.ousterhout/scripting.html

    Here are some studies that show that using scripting
    languages like perl saves you programming time.
    Yeah, we all know *that*...! Seriously, though: have you anything
    about *processing* time, which was the point I tried to make without
    starting this bloody flame.

    lee
    Bill Thompson, PhD
    Computer Scientist
    Wadsworth Center
    NY State Dept of Health
    ESP C-138
    P.O. Box 509
    Albany, NY 12201-0509
    phone: (518) 486-7882
  • Victor Zamouline at May 24, 2001 at 3:50 pm
    AI is a vast field, you can't just generalize that "AI stuff cannot be implemented in Perl". Many of the AI-related branches are
    closely related to heavy calculus, which if, of course, stupid to implement entirely in Perl.

    However, there are quite a lot of other AI-related features that can be perfectly written in Perl with no loss in performance and a
    dramatical gain in maintainance. Anything about data processing just can't be maintained easier. If your data is based on a formal
    syntax definition, you may want to write the parser in a low-level language and you *will* win performance, but if you deal with
    arbitrary data, you may want to have a Perl wrapper around your parser to have some real fun cleaning it up.

    In my company, we do a lot of automatic data processing based on arbitrary source documents which are scrutinized in all ways to try
    to make some sense out of them. There are quite a lot of algorithms that we have successfully implemented entirely in Perl: for
    example, those that detect lexical congestions in a raw text in order to filter out junk before parse attemps are applied to
    sections which are considered as most probably pertinent.

    If you want to check out what performance Perl can attain, check out www.jazzvalley.com. Every time you click, there are thousands
    of objects being instanciated (100% object-oriented design of the whole site, and it is pure Perl).

    Vic.
  • Lee Goddard at May 24, 2001 at 3:55 pm

    AI is a vast field, you can't just generalize that "AI stuff
    cannot be implemented in Perl".
    Whoah! Who said it 'cannot'?!
  • Terrence Monroe Brannon at May 24, 2001 at 3:55 pm

    Gustaf Bjorksten wrote:


    Yeah, well for me it is more about concepts rather than serious
    implementation. I've been hacking perl for half-a-dozen years and be
    damned learning PROLOG just for the odd occasion i want to dabble in AI
    stuff. Of course, if one day i join the ranks of the 1337 AI programmers
    and find myself building the most k-rad killer AI app then i prolly
    will look at languages other than perl.
    I just finished reading about the Dutch National Flag problem in "Craft
    of Prolog" and how the naive Prolog solution generates all these
    permutations and then tests them... hohoho. That's a Perl-one-liner.

    But I do love the implementation of a Finite State Automaton in two (?)
    lines that I saw in "Art of Prolog"
  • Jonathan Eisenzopf at May 24, 2001 at 4:46 pm
    You should talk to Kevin Lenzo over a CMU. One of the projects he's worked
    on is written mostly in Perl I believe and it works much better than most
    other AI voice apps.

    ----- Original Message -----
    From: "John Porter" <jdporter@min.net>
    To: <perl-ai@perl.org>
    Sent: Thursday, May 24, 2001 10:25 AM
    Subject: Re: Just starting out.. newbie help :)

    Gustaf Bjorksten wrote:
    I think y'all missing the point. The original premise that "perl is not
    fast enough _for_AI_" is incorrect IMHO. This is not about raw execution
    speed! Perl is ace for modelling sh!t and definately has a place in my
    AI hacking toolkit. I don't give a damn if it aint the bleedingest
    lightningest-fast thing on two bits
    Unfortunately, most AI-related algorithms are
    computationally intense; execution speed *does*
    end up being critical. For example, I tried using
    perl to do some genetic algorithms stuff:
    On Sun, 31 Dec 2000 12:46:00 -0500,
    in <20001231124600.B1576@min.net>
    John Porter wrote:
    I'd like to say a little something from my own experience with doing
    GA/GP in Perl: Don't. That is, unless you're just doing it for fun,
    to see how it might look if written in Perl. If you're expecting to
    evolve (:-) a useful, production-quality system, think hard about
    your performance requirements. To do a GA/GP system really requires
    OO, I think, and OO in perl is bloody slow. I wrote a little
    OO-based GP testbed, with a total class hierarchy size of less than
    a dozen classes, and it was still a good two orders of magnitude
    slower than the full-blown Java-based system I've been using, ECJ,
    which contains like hundreds of classes. And that's Java. There
    are C++-based systems which are undoubtedly even faster. As you
    know, if you've done any GA/GP research, performce is critical
    because you'd like to run large populations for many generations,
    and in GP particularly, the time to evaluate an individual grows
    like exponentially in the number of generations, unless you have
    some kind of advanced aggressive size control.
    Undoubtedly some of you are going to argue that my "mistake"
    was using OO in perl. But as I said, "To do a GA/GP system
    really requires OO", and I stand firmly by that remark.

    --
    John Porter
  • Lee Goddard at May 24, 2001 at 5:05 pm
    I'm getting everything form perl.org lists twice
    - is it me? If not, I'll write to someone....

    lee
  • Simon Cozens at May 24, 2001 at 5:17 pm

    On Thu, May 24, 2001 at 11:49:22AM -0400, William Thompson wrote:
    While I hesitate to step into what seems like a religious war
    I'm the list admin, so I guess it's my job to step into a religious war. :)

    Guys, can we move the advocacy to advocacy@perl.org where it belongs? If
    what you're posting is *really* about the suitability of Perl for AI,
    then feel free to post it, but if it ain't, it shouldn't be here.

    --
    The Messiah will come. There will be a resurrection of the dead -- all
    the things that Jews believed in before they got so damn sophisticated.
    - Rabbi Meir Kahane
  • Terrence Monroe Brannon at May 24, 2001 at 5:30 pm
    The reply header is setup to reply to people. So, in laziness, I hit
    "Reply all" and then it gets to perl-ai

    They should fix the reply header.

    I am 32. The 50 is because Netscape mail truncates my mailing address of
    500 oracle parkway to 50 for some great grand gui unknown mystery.

    If I only I could use Emacs and LInux insted of Nutscrape and NT around
    here.

    Lee Goddard wrote:
    I'm getting everything form perl.org lists twice
    - is it me? If not, I'll write to someone....

    lee
  • Ken Williams at May 24, 2001 at 8:16 pm

    Simon Cozens wrote:
    On Thu, May 24, 2001 at 11:49:22AM -0400, William Thompson wrote:
    While I hesitate to step into what seems like a religious war
    I'm the list admin, so I guess it's my job to step into a religious war. :)

    Guys, can we move the advocacy to advocacy@perl.org where it belongs? If
    what you're posting is *really* about the suitability of Perl for AI,
    then feel free to post it, but if it ain't, it shouldn't be here.
    I've been reading these threads with a vague interest, and it seems to
    me that if there's any consensus (which there may not be) it's that Perl
    is fun for many AI tasks but not necessarily efficient for the heavy
    lifting.

    So why don't we do something about it? We would do well to look at
    things like PDL, the creaters of which observed that Perl wasn't very
    good at large n-dimensional array storage & computation, so they tried
    to fix it. I suggest that we either harness modules like that, or
    identify some problems that are worth solving and solve them.


    ------------------- -------------------
    Ken Williams Last Bastion of Euclidity
    ken@forum.swarthmore.edu The Math Forum
  • John Porter at May 24, 2001 at 8:21 pm

    Ken Williams wrote:
    ...Perl
    is fun for many AI tasks but not necessarily efficient for the heavy
    lifting.
    So why don't we do something about it?
    ...identify some problems that are worth solving and solve them.
    I recall that there was some discussion on the p6 lists
    about adding an induction engine -- and a declarative
    syntax for using it. Wouldn't that be cool?

    --
    John Porter
  • Ecdysone at May 24, 2001 at 8:22 pm

    On Wed, May 23, 2001 at 02:50:26PM +0100, Lee Goddard wrote:
    Is anyone got any output from music composition scripts they'd be happy to
    share? Definitely not source code, just MIDI/mp3 files?


    http://www.god-emil.dk/=cw4t7abs/=cw4t7abs.mp3




    1001 ventuze.nn









    /_/
    /
    \ \/ i should like to be a human plant
    \/ __
    __/
    i will shed leaves in the shade
    \_\ because i like stepping on bugs



    *--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
    Netochka Nezvanova nezvanova@eusocial.com
    http://www.eusocial.com
    http://www.biohakc.com
    http://www.ggttctttat.com/!
    I am not Greta Garbo!!! http://steim.nl/leaves/petalz
    *--*--*--*--*--*--*--*--*--*--*--*--*-- --*--*--*--*--*--*--
  • Paris Sinclair at May 26, 2001 at 10:46 am

    On Thu, 24 May 2001, Ken Williams wrote:

    simon@brecon.co.uk (Simon Cozens) wrote:
    On Thu, May 24, 2001 at 11:49:22AM -0400, William Thompson wrote:
    While I hesitate to step into what seems like a religious war
    I'm the list admin, so I guess it's my job to step into a religious war. :)

    Guys, can we move the advocacy to advocacy@perl.org where it belongs? If
    what you're posting is *really* about the suitability of Perl for AI,
    then feel free to post it, but if it ain't, it shouldn't be here.
    I've been reading these threads with a vague interest, and it seems to
    me that if there's any consensus (which there may not be) it's that Perl
    is fun for many AI tasks but not necessarily efficient for the heavy
    lifting.

    So why don't we do something about it? We would do well to look at
    things like PDL, the creaters of which observed that Perl wasn't very
    good at large n-dimensional array storage & computation, so they tried
    to fix it. I suggest that we either harness modules like that, or
    identify some problems that are worth solving and solve them.


    ------------------- -------------------
    Ken Williams Last Bastion of Euclidity
    ken@forum.swarthmore.edu The Math Forum
    One of Perl's greatest strengths is that it is a glue language. Perl plays
    very nicely with C, and is itself written in C. If there is some bit
    twiddling to do, and you implement it in C. Many of the core modules are
    in C, so it should be safe religiously.

    So, what is really needed in the area of Perl AI and GA/GP is for CPAN to
    have a robust set of modules implemented in C, with implementations for
    all of the common algorithms. Sadly there are only a few things there.

    Then we will set up some benchmarks. ;)

    --
    Paris
  • Sean M. Burke at May 26, 2001 at 10:17 pm

    At 03:50 AM 2001-05-26 -0700, Paris Sinclair wrote:
    [...]
    So, what is really needed in the area of Perl AI and GA/GP is for CPAN to
    have a robust set of modules implemented in C, with implementations for
    all of the common algorithms. Sadly there are only a few things there.

    Then we will set up some benchmarks. ;)
    It was ages ago that I did this so my memory is a bit hazy on the details,
    but I once took a maze-generation algorithm that was recursive (I think it
    was using recursion as the basis for backtracking) and implemented it in
    Perl. When it was done and working, I happened to also have a
    non-recursive implemention in C to benchmark it against.
    From the way people talk down recursion and Perl, I expected a recursive
    Perl program to run at least ten times as slow as a nonrecursive C program
    that does the same thing. The difference was "minimal" -- i.e., the Perl
    program was slower, but no more than twice as slow, or else I'd remember
    saying "guh! five times slower!?!" instead of merely muttering "so who said
    recursion is slow?" and then going off to play Tetris.


    And on that note, I disagree with the implications made on this list
    ("Memory is cheap; time is expensive" being a quotably short one) that AI
    is necessarily always time-critical. A time difference of, say, 4x is bad
    if you're talking hours or days, but if the timescale is in single seconds
    (as they typically are in the things I'm fiddling with these days), then
    /I/ typically don't mind at all. When AI is technology (i.e., you
    developing something slick for everyone to use), speed is often a concern;
    but when AI is science (trying to see what's possible, what algoriths even
    work, etc.), execution speed often isn't so much of a limiting factor.


    --
    Sean M. Burke sburke@cpan.org http://www.spinn.net/~sburke/
  • Gene Boggs at May 26, 2001 at 10:45 pm

    ... When AI is technology (i.e., you
    developing something slick for everyone to use), speed is often a concern;
    but when AI is science (trying to see what's possible, what algoriths even
    work, etc.), execution speed often isn't so much of a limiting factor.
    --
    Sean M. Burke

    Thank you. :-) TorgoX++

    -gb
    Gene Boggs <gene@ology.net>
    Software Engineer at-large
    ___________________________
  • Lee Goddard at May 26, 2001 at 10:52 pm

    From: Sean M. Burke
    ... when AI is science (trying to see what's possible, what algoriths even
    work, etc.), execution speed often isn't so much of a limiting factor.
    Man, I wish I had your budget.

    ;)
  • John Porter at May 27, 2001 at 5:57 pm

    Sean M. Burke wrote:
    I disagree with the implications made on this list
    ("Memory is cheap; time is expensive" being a quotably short one)
    that AI is necessarily always time-critical.
    I didn't imply that AI is necessarily always time-critical.

    "Necessarily" and "always" we can dispense with out of hand.
    But "time-critical" is quite subjective. Clearly you can't
    put a terrain recognition system in your cruise missiles
    that takes minutes to do one recognition. Lots of problems
    people try to attack in the real world take hours or days
    to solve, on heavy iron. I don't know if that's "time-critical",
    but time is money, so...

    A time difference of, say, 4x is bad
    if you're talking hours or days, but if the timescale is in single seconds
    Of course! At that scale, it's far more important to optimize
    *programmer* time, not *program* time.
    That's why (/when) we use Perl, after all.

    When AI is technology (i.e., you
    developing something slick for everyone to use), speed is often a concern;
    Yes, and that is not uncommon now. Certainly much more
    common than it used to be. But also consider that a lot
    of AI-as-technology is in-house stuff, with which
    companies solve their own problems, or hire out their
    problem-solving capability. E.g. GeneticProgramming.com.

    --
    John Porter

Related Discussions

People

Translate

site design / logo © 2021 Grokbase