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

  • 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
  • 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
  • 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
  • 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
  • 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
  • Nathan Torkington at May 27, 2001 at 6:01 pm

    John Porter writes:
    Lots of problems people try to attack in the real world take hours
    or days to solve, on heavy iron.
    I'm not picking on John, but I think this list would be a whole lot
    more productive and interesting if the conversation was focussed on
    things that *we* are trying to do, not random people. Perl's all
    about scratching our own itches, which has benefits that carry over to
    other people's itches.

    Nat
  • John Porter at May 27, 2001 at 6:10 pm

    Nathan Torkington wrote:
    John Porter writes:
    Lots of problems people try to attack in the real world take hours
    or days to solve, on heavy iron.
    I'm not picking on John, but I think this list would be a whole lot
    more productive and interesting if the conversation was focussed on
    things that *we* are trying to do, not random people.
    I hear what you're saying, Nat.

    But I'm not sure I understand it. "random people"?

    --
    John Porter
  • Nathan Torkington at May 27, 2001 at 6:28 pm

    John Porter writes:
    I'm not picking on John, but I think this list would be a whole lot
    more productive and interesting if the conversation was focussed on
    things that *we* are trying to do, not random people.
    I hear what you're saying, Nat.
    But I'm not sure I understand it. "random people"?
    If you've had a specific problem with Perl's speed, memory use, or
    whatever, in a particular AI application, then that would seem to be a
    problem. But "some people run big AI jobs" or "other people will want
    better memory use" just seems like pointlessly abstract argument.
    Code is much more interesting than hypotheticals.

    Nat
  • Lee Goddard at May 27, 2001 at 10:38 pm
    unsubscribe
    -----Original Message-----
    From: John Porter
    Sent: 27 May 2001 19:10
    To: perl-ai@perl.org
    Subject: Re: Just starting out.. newbie help :)


    Nathan Torkington wrote:
    John Porter writes:
    Lots of problems people try to attack in the real world take hours
    or days to solve, on heavy iron.
    I'm not picking on John, but I think this list would be a whole lot
    more productive and interesting if the conversation was focussed on
    things that *we* are trying to do, not random people.
    I hear what you're saying, Nat.

    But I'm not sure I understand it. "random people"?

    --
    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
    *--*--*--*--*--*--*--*--*--*--*--*--*-- --*--*--*--*--*--*--
  • Paul Romer at May 27, 2001 at 9:47 pm
    How about 'Coding hypotheticals'.....}8^D


    ----- Original Message -----
    From: "Nathan Torkington" <gnat@oreilly.com>
    To: <perl-ai@perl.org>
    Sent: Monday, May 28, 2001 4:28 AM
    Subject: Re: Just starting out.. newbie help :)

    Code is much more interesting than hypotheticals.

    Nat

Related Discussions

People

Translate

site design / logo © 2021 Grokbase