Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!uhccux!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Partial Orders
Message-ID: <4911@goanna.cs.rmit.oz.au>
Date: 6 Mar 91 05:24:00 GMT
References: <13048@darkstar.ucsc.edu> <1991Mar05.021953.11576@comp.vuw.ac.nz>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 37

In article <1991Mar05.021953.11576@comp.vuw.ac.nz>, steve@comp.vuw.ac.nz (Steve Cassidy) writes:
> My terms look like:      447:[class24]/[a]/[class42, e, #]/[ey]
>                       RuleNo:LeftContext/Graph/RightContext/Phon

Operators make for pretty input, but inefficient storage.
On a typical Prolog system, storing
	RuleNo:LeftContext/Graph/RightContext/Phon
will give you a tree looking something like
	:(RuleNo,
	    /(                                        ,Phon))
		/(                      ,RightContext)
		    /(LeftContext,Graph)
which takes 4*3 = 12 words of overhead in addition to the elements stored.
To access	RuleNo		costs	1 "compound" unification step
		LeftContext		4
		Graph			4
		RightContext		3
		Phon			2
If instead you used
	rule(RuleNo,LeftContext,Graph,RightContext,Phon)
then the space overhead would be 6 words, and accessing each element
would take 1 "compound" unification step.

As I said, operators are pretty, so if you are reading rules, it may pay
you to read them in operator syntax, and then flatten them:

	flatten_rule(RuleNo:LeftContext/Graph/RightContext/Phon,
		rule(RuleNo,LeftContext,Graph,RightContext,Phon)).

so that computations can use the more efficient form.  You can use the
same rule to re-introduce the operators for output.

I'm interested in hearing about Prolog-based work on morphology.  Any
more information available about the application/project?

-- 
The purpose of advertising is to destroy the freedom of the market.