Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: Artificial Intelligence Programming in Perl

by cjf (Parson)
on Jul 01, 2002 at 05:47 UTC ( #178472=note: print w/ replies, xml ) Need Help??


in reply to Re: Artificial Intelligence Programming in Perl
in thread Artificial Intelligence Programming in Perl

I don't think Perl's speed (as in execution time) is a major concern for most AI programming. It's frequently noted that developer time is often far more valuable then execution time for other projects, why would AI programming be any different?

Inertia, on the other hand, would definately play a part. If you've been programming in Lisp your entire life, why not continue to use it? Does Perl really offer enough advantages in this area for it to be worth learning? Even if it did, chances are the learning curve would reduce your productivity for an extended period of time (you mean every second character doesn't have to be a parenthesis ?).

That said, not everyone starts programming with Lisp or Java, in fact many start with Perl. Is there any reason why they shouldn't continue to use Perl? Why would we not expect to see its uses in AI gradually increase?


Comment on Re: Re: Artificial Intelligence Programming in Perl
Re: Re: Re: Artificial Intelligence Programming in Perl
by theorbtwo (Prior) on Jul 01, 2002 at 07:44 UTC

    Sorry. For quite a while, I was involved (as a trained monkey) for a compony doing AI as it's core product. Thus, unlike most people, when I think AI I don't think "way out-there research toy", I think "oh, god, why can't they write us tools that work instead of whining about how sandboxing is theoreticly impossible because of the halting problem". Speed matters for them. They did it all in Java, (which was a mistake; should have been C or C++, efficency).

    Anyway, what I meant about inertia is more of an instutional thing. The compony I worked for wouldn't use perl, even for things like log-munging, for quite a while because the productivity-analisys tools that ate their CVS couldn't handle it. (The place wasn't always run the most sanely -- I no longer work there because they no longer exist.) You use the languages that your advisors know, and you use the languages that the journals publish, and you use the languages that the prior art is written in.


    We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book

Re: Re: Re: Artificial Intelligence Programming in Perl
by demerphq (Chancellor) on Jul 01, 2002 at 11:01 UTC
    I don't think Perl's speed (as in execution time) is a major concern for most AI programming

    Hmm, on this note I disagree. AI tends to be computationally expensive. AL (ie GA) even more so. Even a minor efficiency improvement can make a _big_ difference.

    It's frequently noted that developer time is often far more valuable then execution time for other projects, why would AI programming be any different?

    Well, this is true and not true. IME its true when the speed differences are marginal at best. Implementing an efficient algorithm in C and the same in Perl will most likely produce acceptable performance for the end product with much lower dev times. However with GA/AI/AL the same is not true. (Well, from what ive seen.) Lower development times are overwhelemed by extremely slow execution times.

    Yves / DeMerphq
    ---
    Writing a good benchmark isnt as easy as it might look.

      I agree with your disagreement ;).

      As I'm learning more about the subject (link, link, link) I can see how execution time could be very important. I've also noticed that a lot of the AI projects/libraries out there tend to have a few very computationally expensive parts, and many not so expensive parts. Wouldn't such a case be perfect for a Perl-Inline::C combination?

      Or am I just showing my Perl bias?

        Or am I just showing my Perl bias?

        No I agree.

        Perl would be ideal for much of the framework. But the kernal (ykwim) needs to be as efficient as possible. Inline::C would seem to be an ideal compromise.

        Yves / DeMerphq
        ---
        Writing a good benchmark isnt as easy as it might look.

        Perhaps, but don't forget that the Perl-XS barrier is an expensive one to cross. Every call from Perl to C and from C to Perl creates memory accesses and runs lots of code.

        I found this out firsthand working on a QuakeIII Perl API. During development I took a lot of shit from the QuakeIII people about how Perl would be too slow to write a QuakeIII bot (which is basically a simple AI project). I thought I could beat the system with a mix of Perl and XS. Well, I was wrong.

        -sam

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://178472]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (9)
As of 2014-07-25 19:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (174 votes), past polls