Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bbn.com!nic!bunny!tomf
From: tomf@GTE.COM (Tom Fawcett)
Newsgroups: comp.lang.prolog
Subject: Re: Arrays in Prolog
Message-ID: <9668@bunny.GTE.COM>
Date: 30 Aug 90 16:21:27 GMT
References: <90239.175243SCHMIED@DB0TUI11.BITNET> <9653@bunny.GTE.COM> <3629@goanna.cs.rmit.oz.au>
Organization: GTE Laboratories, Waltham MA
Lines: 41


Let me say a few things about my use of arrays in Prolog, and specifically why
I want them.

I'm using them to represent large amounts of state information that have to be
accessed and updated quickly.  In particular, I'm representing chessboards,
so each state has sixty-four components.  I may need to store several thousand
such boards at any one time.

The "obvious" way of representing these is to use a predicate like
"boardn(square,contents)", eg "board73(a3,blank)", where a3 is a square
designator.  Because Quintus Prolog indexes on the functor and first argument,
I can access and update a given square of a given board in constant time.
However, these take up more space than a 64-element vector, and it's still too
slow (every modification must involve a retract and an assert, which is much
slower than a destructive array assignment).  Also, I often want to make one
board be a slight modification of another, which involves copying the contents
of one board to another, and then making the change.  This is also relatively
slow.

As I mentioned before, I tried using an array package, but library(logarr) and
library(arrays) both do what I call constructive, rather than destructive,
modification.  That is, to alter an array element you call a predicate that
passes back a new array with the desired element changed.  If you're storing
these arrays in the database, as I must, every alteration requires a retract
and an assert.  Since these database accesses seem to be more costly than the
array updates themselves, this doesn't help.

I suppose that in other applications it is not necessary to keep these arrays
in the database, and so constructive modification is fine.  But in my
application, and that mentioned in the original arrays-in-prolog message
(involving storing frame information), keeping these arrays in the database is
desirable/necessary.

Real (destructive) arrays, as provided in library(vectors) under Quintus
Prolog, seem to be about 5-10 times faster than any of the other methods I
tried that had to update the database with every access.-- 


-Tom Fawcett
GTE Labs, and UMass/Amherst