|From:||Patrick Littell <puchitao@...>|
|Date:||Tuesday, June 7, 2005, 3:40|
This one went to me instead of the list, so I'm quoting it in its entirety
instead of snipping. Sorry, Tom; my bad for not including the gmail warning.
(Gmail is funny with replies-to, if you haven't run into it before.)
On 6/6/05, tomhchappell <tomhchappell@...> wrote:
> Hello, Patrick. Thanks for writing, and thanks for the reference.
> Hello, Rob, also.
> --- In firstname.lastname@example.org, Patrick Littell <puchitao@g...>
> > wrote:
> > On 6/6/05, Rob Haden <magwich78@y...> wrote:
> > > What is suffix-coding?
> > A suffix code would be a code such that none of the sequences
> > is a suffix
> > of another. It would be ugly to parse compared to
> > a prefix code, though.
> I don't see why a "suffix code" should be any less natural than
> a "prefix code". (I can believe /that/ it /is/; I don't see /why/
> it /should be/.)
> For a machine, at least, wouldn't it be just as easy to parse? If
> not, why not? And if so for a machine, why not for a human?
Parsing a prefix code -- for a machine or just for a person who pays
attention -- is absolute simplicity. Take the simple low/high code with the
items H, LL, LHL, LHH. This makes a nice little tree. (That's how you
construct one in the first place.)
That won't format right in everyone's mail reader, I'm sure, but you get the
idea. Now, as the speaker speaks, the listener keeps their metaphorical
finger on their current position. At the beginning, you point to the Ø, and
whenever you hear a high tone you go right and a low tone, left. Once you
head a leaf -- one of the childless nodes -- you're at the end of the word.
Go back to Ø. Simple as pie for humans and computers.
Now take a suffix code with the patterns H, LL, HHL, LHL. (So chosen because
it makes the exact same tree.) The problem is that *during* the parsing
process, you'd need multiple fingers because it wouldn't be clear, after
hearing an L, whether to point to the L leaf that begins LL or the L leaf
that begins LHL. In our simple example it soon becomes clear, of course, but
until then you need two fingers. In an example of arbitrary complexity the
fingers you'd need would grow rapidly.
Now, humans probably wouldn't have much trouble with the sort of parallel
processing this would entail -- until of course we stopped and actually
thought about it. And computers are pretty quick; after all, it's not really
a *difficult* algorithm. It's just a lot less elegant than the prefix-code
one, which is cake.
Anyway, that's a probable reason for your intuition.
OTOH, I guess it would be extremely limiting for a language to be
> both a "prefix code" /and/ a "suffix code", at one and the same
> time, in the terminology you have used in this thread.
Yeah, that would be pretty limiting. I can't off the top of my head think of
an interesting code that's both. (Trivial cases like monosyllablism are, and
so are codes like L vs HH or LL vs LHL vs LHHL vs LHHHL, but I would have to
really sit down and draw for anything further.) Anyway, having both wouldn't
buy you anything more than each on its own.
> morpheme or root could be homophonous with /either/ a prefix /or/ a
> suffix of another, would it even be possible to grow derived and
> inflected forms by affixing prefixes and/or suffixes, and to make
Well, the first question we'd need to ask ourselves is the level of the
coding. That is, is the language segmentable at the morpheme level or the
word level? (We could do both.) If the language is morpheme-segmenting then
we're all cool, but additional difficulties arise if we want
The basic problem, I think, is that if we can add suffixes to the root we
lose prefix coding, and vice-versa. Is this the problem of which you were
thinking? If "morb" is our root, and we negate have the prefix "zo" and a
suffix "el", we have the trouble of "zomorb" being a prefix of "zomorbel".
This violates prefix-coding. On the other hand "morbel" is a suffix thereof,
If we want to maintain prefix-coding, have each (content) word require one
(and only one) of a set of inflectional suffixes. (As always in this
discussion, we'll stipulate that all morphemes are unique.) Other suffixes
are fine so long as they precede the required one. (This is how #5
maintained prefix coding above.) If we want to maintain suffix-coding,
require each to have one of a set of inflectional prefixes. If we want, for
some reason, to have both codings, require both.
Apply some sort of word-level segmentation scheme after the word is
derived/inflected. A process like stress assignment that occurs late, for
example. So we'll say, oh, that all particles are monosyllabic, that no
particle is stressed, that all content words have two or more syllables, and
that all content words are stressed on the first and last syllables. This is
both prefix and suffix coding simultaneously.
Of course, there are many schemes of self-segmenting that don't require
either prefix- or suffix-coding. The C, CVC, CVCVC method is neither of
these, and works fine.
So long as all our morphemes are unique, and the categories of root, prefix,
and suffix never intersect, we can really add all the prefixes and suffixes
we want and still be able to segment it. It's not prefix- or suffix-coding,
but it's still workable.
My new question: It wouldn't be hard to segment morphemes by one scheme and
words by another. Say, morphemes by C/CVC/CVCVC and words by initial or
final stress. Could, however, we segment both by the same scheme? Just using
prefix-coding tone or stress patterns? Just by C/V patterns? Would be
interesting to puzzle out...
PHIL205: MWF 2:00-3:00, M 6:00-9:00
Voice Mail: ext 744
Spring 05 Office Hours: M 3:00-6:00
> Thanks for the examples I snipped out above.
> > > Where are counter-harmonic suffixes attested?
> > There are at least two processes in Itzaj
> > that are regularly antiharmonic.
> > Itzaj is (was) the language of the descendents of
> > the people who built
> > Chichen Itza, iirc, although they long since moved
> > down to Guatemala.
> > [snip]
> > Hmm, you might find Matthew Dryer's article
> > on pronominal subjects for the
> > language atlas interesting. You can find it at
> > http://wings.buffalo.edu/
> > soc-sci/linguistics/people/faculty/dryer/dryer/dryer.htm.
> Thank you for that reference.
> I also hope Dryer's Typology Database is searchable soon. I would
> have looked in it for some answers to some of the questions I have
> asked here, if it were available to folks like me right now.
> The Typology Database's web address is:
> Thank everybody for writing.
> Tom H.C. from MI, now in OK until Thu