Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: Re: Choosing a data structure for AI applications

by Ovid (Cardinal)
on Jul 16, 2002 at 14:45 UTC ( #182095=note: print w/replies, xml ) Need Help??

in reply to Re: Choosing a data structure for AI applications
in thread Choosing a data structure for AI applications

Gah! I hate it when people post intelligently but do so anonymously. It suggests to me that they're not going to hang around the monastery. I certainly hope you do.

Actually, last night I was doing quite a bit of thinking (and reading) about this problem and using a database seemed to be one of two solutions. Actually, a multi-value database like UniData would be awesome (it would handle lists very easily), but I don't know of any open-source versions.

The other thought was to use directed graphs with adjacency lists. I think that would be workable and I could use DB_File to handle persistance. However, I am much more familiar with database theory so I think that would be better (and probably allow more people to contribute). The nice thing about databases is that I think they would solve the Unification problem very easily, if I can come up an easy scheme to create them on the fly (I'm seeing more deviation from Prolog already).


Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

  • Comment on Re: Re: Choosing a data structure for AI applications

Replies are listed 'Best First'.
Re: Re: Re: Choosing a data structure for AI applications
by PhiRatE (Monk) on Jul 17, 2002 at 04:27 UTC
    I post here all the time but I never remember to log in and I keep killing all my cookies :)

    The problem thus far with the discussion is that everyone is talking like using a database costs you something, as if its slower than a perl hash or some more complex in-ram data structure.

    The truth is that, for a dataset that can fit reasonably in ram, perl is quicker. But once you talk about anything running into the millions of facts, a real DBMS will be unbelievably helpful. Indexing is a huge win for one, they do their own ram-based caching as well.

    So, let us consider that, short of re-inventing a specialist database engine with many of the features that a DBMS already provides, a DBMS would be the most effective fact store for any reasonably sized factset.

    Your next problem is how to effectively generate database schema in such a way that you get the most out of indexes, ordering and joins within the database without having to replicate data all over the place in different forms (an option, but an unhappy one).

    The first thing is to understand that you want a powerful RDBMS. The object databases, PostgreSQL included, have many benefits, and its possible that one could be appropriate, but in my opinion the area of relational systems has been the most examined and they have the best combination of performance and flexibility (postgresql isn't shabby though, so as a free backend it may well be worth it).

    From this you would then want to read up on reasonably advanced SQL, notably views, indexes, subselects and joins, and the performance parameters inherent in them. Many features of SQL will map directly to features of prolog with the relevant schema, for example a table of facts could represent, in two columns, the IS A relationship and retrieving the facts is a set of trivial SQL statements.

    Unfortunately, I don't know enough prolog to take the analysis further, but it would seem to me that, if you're serious about doing big performance-intensive stuff, which is where expert-system AIs become really valuable, that the RDBMS backend is the only real option.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (7)
As of 2019-10-22 13:35 GMT
Find Nodes?
    Voting Booth?