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
  • 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.
  • 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:
  • 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.
  • 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 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: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 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
  • 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
  • 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
  • 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.
  • 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
  • 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
  • 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: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
  • 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
  • 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 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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: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
  • 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
  • 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 Jun 8, 2001 at 5:18 pm
    TITLE
    Lisp vs Perl Round One: Operator Associativity and Manipulation

    BACKGROUND
    In the process of converting a general pattern matcher (regular
    expressions are pattern matchers limited to processing strings)
    discussed in Peter Norvig's "Paradigms of Artificial Intelligence:
    Case
    Studies in Common Lisp", I ran into a doosy. Something was a snap to
    do
    in Lisp, but far from trivial in Perl. First the lisp code:

    (defun match-if (pattern input bindings)
    "Test an arbitrary expression involving variables. The pattern
    looks
    like ((?if lisp-code) . rest)."
    (and (progv (mapcar #'car bindings)
    (mapcar #'cdr bindings)
    (eval (second (first pattern))))
    (pat-match (rest pattern) input bindings)))

    What this code is doing is taking some lisp code and evaluating it
    within a certain context. What is a context? A context is a set of
    variable bindings. What the mapcar statement above is doing is
    setting
    up a set of variable bindings so that when the lisp-code is
    evaluated,
    it is evaluated in the context of those bindings. Then what happens
    is
    the eval evauluates the lisp code with the variable bindings from
    the
    context as a frame of reference.

    The difficulty in converting this to Perl lies in the fact that
    operators are not first class. Let's see an example of this lisp
    pattern-matcher in action:
    (pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z)))
    '(3 + 4 is 7))
    ((?z . y) (?y . 4) (?x . 3))
    What happened is that ?x got bound to 3, ?op got bound to + and ?z
    got
    bound to 7 and then the pattern matcher called the if-block based on
    the
    context formed by the earlier matches in the pattern.

    Note how easily Lisp took an operator and stored it in a variable
    just
    like anything else in Lisp. Second (though not the focus of this
    paper),
    note how easy it was for the if block to receive and use a context.
    In
    Perl, operators and contexts are not truly first class, meaning you
    can't pass them around and you can't assign them to variables...
    easily.
    They are in fact available to the Perl parser and a complicated set
    of
    parsing modules, but such Herculean efforts appear ridiculous
    compared
    to the expressive ease shown above.

    In order for you to see firsthand what I am talking about with
    respect
    to Perl, let's take a stab at writing that powerful little Lisp
    snippet
    in Perl. First what would our pattern look like:

    $pattern = [qw(X OP Y is Z),
    'IF',
    sub {$_[0]->{X} $_[0]->{OP} $_[0]->{Y} ==
    $_[0]->{Z}} ];
    $input = [ 3 '+' 4 is 7 ] ;

    And here is our call to get the ball rolling:

    pat_match ($pattern, $input, $bindings) ;

    ## And our desired output:

    { X => 3, Y => 4, Z => 7, OP => '+' }

    sub match_if { my ($pattern, $input,$bindings) = @_ ;

    $pattern->($bindings) ;
    }

    The above subroutine would work well, but it has a problem. There is
    no
    way to assign the '+' to $_->{OP} ; Also, the actual if subroutine
    reference must pander to Perl's complex associativity rules. In both
    respects, Lisp is easier. As stated earlier playing with Lisp
    operators
    is a snap:

    (setq op '+)
    (funcall op 2 2)

    and associativity is a snap: just follow the parentheses.

    The only way to handle a problem like this in Perl is to resort to
    source filtering or parsing. And then you must make sure that your
    minilanguage emulates the associativity semantics of Perl as well as
    Perl in all respects...
  • Simon Cozens at Jun 8, 2001 at 6:39 pm
    *cough*
    <listadmin>
    So, anyone actually want to talk about AI? You've gone past advocacy, that's
    the previous door on the right.
    </listadmin>

    --
    Everything that can ever be invented has been invented
    - Charles H. Duell, Commisioner of U.S. Patents, 1899.
  • Terrence Monroe Brannon at Jun 8, 2001 at 7:23 pm

    Simon Cozens wrote:

    *cough*
    <listadmin>
    So, anyone actually want to talk about AI? You've gone past advocacy, that's
    the previous door on the right.
    </listadmin>
    Look:

    1 - I was in the process of coding something from a book on AI
    2 - A cornerstone of research using AI is which language you use
    3 - I came across an example of how Perl was clearly less suited for a
    well-known AI pattern-matcher from a well-known text
    4 - I was hoping that this inadequacy would be of interest and
    discussion to a bunch of people who feel that Perl and AI make a good
    combination where for the example showed, they clearly are not.
  • Lee Goddard at Jun 8, 2001 at 7:31 pm

    Simon Cozens wrote:
    *cough*
    <listadmin>
    So, anyone actually want to talk about AI? You've gone past advocacy, that's
    the previous door on the right.
    </listadmin>
    Here here, etc.
    Look:

    1 - I was in the process of coding something from a book on AI
    2 - A cornerstone of research using AI is which language you use
    3 - I came across an example of how Perl was clearly less suited for a
    well-known AI pattern-matcher from a well-known text
    4 - I was hoping that this inadequacy would be of interest and
    discussion to a bunch of people who feel that Perl and AI make a good
    combination where for the example showed, they clearly are not.
    Quite. It would be really very interesting, though, if you were to consider writing Language::Lisp - now *that* would get the round
    of applause you seem to covert.

    Go on, you know you can do it.

    Please...?

    lee
  • John Porter at Jun 8, 2001 at 8:24 pm

    Lee Goddard wrote:
    It would be really very interesting, though, if you were to consider
    writing Language::Lisp -
    People considering that should check CPAN first.

    --
    John Porter
  • Lee Goddard at Jun 8, 2001 at 8:37 pm

    Lee Goddard wrote:
    It would be really very interesting, though, if you were to consider
    writing Language::Lisp -
    People considering that should check CPAN first.
    On which, does anyone fancy do a bit of work
    on Language::Prolog...?
  • Terrence Monroe Brannon at Jun 8, 2001 at 10:57 pm

    Lee Goddard wrote:
    Lee Goddard wrote:
    It would be really very interesting, though, if you were to consider
    writing Language::Lisp -
    People considering that should check CPAN first.
    On which, does anyone fancy do a bit of work
    on Language::Prolog...?
    I checked this out. It looks quite good. My problems with it are:

    1 - no test suite

    2 - no docs on implementation or usage or installation or anything !

    3 - he did not use strict ;

    So, I received some off-list help on how to write Perl in Perl instead
    of trying to write Lisp in Perl and I will forge ahead with my efforts
    at implementing the Prolog discussed in Norvig's text.
  • Lee Goddard at Jun 9, 2001 at 10:37 am

    Lee Goddard wrote:
    Lee Goddard wrote:
    It would be really very interesting, though, if you were to consider
    writing Language::Lisp -
    People considering that should check CPAN first.
    On which, does anyone fancy do a bit of work
    on Language::Prolog...?
    I checked this out.
    *Thank you!*

    It looks quite good. My problems with it are:
    1 - no test suite
    Well, there is a test PROLOG script which runs correctly,
    but no, you couldn't give a cpantest pass grade.... I can
    change that.
    2 - no docs on implementation or usage or installation or anything !
    True, and it doesn't install as a usual CPAN module, but again,
    I can change that - which means it's no big deal :)
    3 - he did not use strict ;
    You're telling me!
    So, I received some off-list help on how to write Perl in Perl instead
    of trying to write Lisp in Perl and I will forge ahead with my efforts
    at implementing the PROLOG discussed in Norvig's text.
    If you do make any changes to Language::Prolog, would you mind sending
    them into the list? I've made a few minor changes, and a little POD,
    and uploaded them to CPAN, and I'd really like to make some more, and
    welcome any input.

    It now at least loads PROLOG files, strips single-/multi-line comments,
    but doesn't yet handle much else. I'm not really interested in getting
    much more functionality, just an equivalent of POPLOG PROLOG on Win32
    - basic text output, inline mathematics.

    Cheers, and thanks,
    lee
  • Terrence Monroe Brannon at Jun 9, 2001 at 5:28 pm

    Lee Goddard wrote:
    Lee Goddard wrote:
    It now at least loads PROLOG files, strips single-/multi-line comments,
    but doesn't yet handle much else. I'm not really interested in getting
    much more functionality, just an equivalent of POPLOG PROLOG on Win32
    - basic text output, inline mathematics.

    Well my goal is Prolog semantics with Perl syntax. I think the goal of
    that module is Prolog semantics and Prolog syntax.

    I want something that can be used dynamically within Perl.
  • Andreas Marcel Riechert at Jun 10, 2001 at 1:37 pm

    Terrence Monroe Brannon writes:

    Well my goal is Prolog semantics with Perl syntax. I think the goal of
    that module is Prolog semantics and Prolog syntax.

    I want something that can be used dynamically within Perl.
    A "Perlog" [1] module which allows you to do some logic programming
    in Perl would be a great module, I presume. IMHO, implementing whole
    Languages inside Perl doesn't seem the way to go. Of course modules
    like "Language-Prolog-Interpreter" are nice as toys or proofs of concept,
    but if one badly needs BASIC, Prolog or Lisp he should use that languages
    directly, try to write an Inline module for the language or try to implement
    missing features (paradigm) into Perl itself ("Perlog" as an idea).
    Well, your mileage may vary.

    Andreas Marcel

    [1] Perlog could be a something like Schelog (Prolog in Scheme without
    loosing Scheme); http://www.cs.rice.edu/CS/PLT/packages/schelog/
  • Gidon Wise at Jun 8, 2001 at 7:39 pm
    Which style of programming do you guys think is best
    for AI???

    Math and Algorithm problems seem to be best left
    to simple procedural or functional styles
    of programming.

    On the other hand, I've always had the best results personally
    with OOP for AI problems. Because AI problems for me atleast
    tend to be hairy enough to need the OO.


    In fact I usually start with simple function and procedure
    oriented programming with logical packages, and move to OOP
    as the project progresses. Because I always hope that it will
    not get that complex.


    The advantage of perl in this situation is that it is rather
    easy to move a program from procedural to OOP without too many
    changes at all. This is because any type can be blessed into
    an object.


    Another big issue for me and AI is the debugging.
    Most AI programs have so many more steps in execution
    that they can be tricky to debug...

    I find the 'x $variable_name' perl -d option to be very handy
    for exploring datastructures. And the 'b condition' to be handy
    for finding buggy situations.

    The perl profiler strangely enough is also a great debugging tool
    for such programs, because often when you see the execution tree,
    you realize that there are whole branches that are screwy or too big.

Related Discussions

People

Translate

site design / logo © 2021 Grokbase