[Any] Groupable Objects

15 views
Skip to first unread message

Jim Aikin

unread,
Aug 11, 2002, 11:49:56 PM8/11/02
to
I've been wrestling for some time with a programming problem (in TADS, but
that's not necessarily relevant), and it's got me thinking that there's an
underlying conceptual issue. I doubt this issue has been adequately
addressed by any of the IF languages -- not surprising, as it seems pretty
thorny. It may be easier to do a clumsy, half-adequate workaround in Inform
than in TADS, thanks to the handy parse_name routine, but at the moment I'm
not interested in workarounds, since I'm about to bail on this particular
puzzle in any case. Instead, I'm curious what some of the code gurus may
think about the underlying concept.

Here's the deal: IF languages generally deal very well with one-of-a-kind
objects. They also allow you to create groups of objects that are utterly
indistinguishable from one another (matches in a matchbook being the
classic example). But in the real world, many or most groups of objects
aren't quite that featureless. In the real world, an object may be
indistinguishable from other objects some of the time, or when some
adjectives are used, or when some actions are called for, but may be unique
at other times, when other adjectives are used, or when other actions are
called for.

It might be interesting or even useful to form a clear idea of what
properties such a group class ought to have. I don't claim to have the
answers -- but here are some preliminary thoughts.

For starters, each instance of the class should be able to sense when other
instances of the class are in scope, and whether they're distinguishable or
not with reference to the verb or noun phrase the user has just entered.
This is so that when the user types a command, **only one of the objects
needs to issue a message.** This avoids ugly, messy output like this:

> take coins
gold coin: Taken.
gold coin: Taken.
gold coin: Taken.
silver coin: Taken.
copper coin: Taken.

What one wants to happen is something much more elegant:

> take coins
You pick up the three gold coins, the silver coin, and the copper coin.

What's more, you want the plural word (coins) to be applicable only if
there are two or more in scope. It's not adequate to declare "coins" as a
synonym for "coin". Among the desired outputs of the objects would be error
messages along these lines:

> take coins
There's only one coin nearby at the moment.

The same holds true for adjectives. If there are three coins present, one
each of gold, silver, and copper, this should happen:

> take gold coins
There's only one gold coin nearby at the moment.

> take coins
You pick up the coins.

Taking and dropping are simple actions. Other actions are not so simple.
Let's suppose the gold coins are magical, and that the user has waved a
wand over three of them at once. They begin to glow, but after a few turns
they get gradually dimmer. What one doesn't want is this:

> z
Time passes...
The gold coin isn't glowing as brightly as before.
The gold coin isn't glowing as brightly as before.
The gold coin isn't glowing as brightly as before.

That's hideous, but it's what an IF engine is designed to do. What one
wants is this:

> z
Time passes...
The three gold coins aren't glowing as brightly as before.

Or, if one of them has been "activated" by the wand a turn or two before
the others, something along these lines:

> z
Time passes...
Two of the gold coins aren't glowing as brightly as before, and one of them
has stopped glowing.

Needless to say, the coin objects have to be able to sense whether any of
their compatriots are perhaps nearby but in a closed container, in which
case the output has to be structured differently.

I have no idea how to pull this off. I've spent some time on an invisible
plural_coins object, which handles all inputs that use the word "coins",
manages the coin inventory, and so on, but my model falls apart at the
point when some of the coins change state (begins glowing, for instance).
And all of my individual coins are still printing out their own messages
when they start getting dimmer.

A coin that wants to print out an "I'm getting dimmer" message could
instead send a message to the plural_coins object, and the latter could
then poll all of the other coins to see if they want to send similar
messages, and order them to suppress the messages, but since the parser is
going to "wave the wand" over the three coins in an arbitrary and unknown
order, it's not clear to me how such an algorithm ought to be designed.

I'm sure it's possible -- hey, they're all just ones and zeroes, right? So
I'm wondering if anyone has developed (or even implemented) a clear
conceptual model for groupable objects.

--Jim Aikin

Lucian P. Smith

unread,
Aug 12, 2002, 12:35:38 AM8/12/02
to
Jim Aikin <kill_spammers@kill_spammers.org> wrote in <3D573097.6060804@kill_spammers.org>:

: It might be interesting or even useful to form a clear idea of what

: properties such a group class ought to have. I don't claim to have the
: answers -- but here are some preliminary thoughts.


There are three examples of this that I've collected and filed mentally
over the years. My favorite, by far, is the pair of swords example.
Someone wanted a pair of swords (a katana and a wakizashi), which together
were known as a daisho. Erik Hetzner posted the following Inform code:

http://groups.google.com/groups?selm=5hs0lq%24np%40agate.berkeley.edu&oe=UTF-8

The other classic example is money, which collectively might be known as
'$6.83', but might consist of a five, a one, and some change. Erik also
went to work on this problem, and the result is on the archive:

http://www.ifarchive.org/if-archive/programming/inform6/library/contributions/money.h

The final example are things like 'a pair of gloves'. There's an example
of this in the Toyshop code:

http://www.ifarchive.org/if-archive/programming/inform6/examples/Toyshop.inf

The basic concept behind this example is (as Graham says):

! When the gloves are together, and the player refers to an individual
! glove, the before rule splits up the pair and starts the daemon.
! Once active, the daemon tries every turn to re-join them into a pair.
! (If it succeeds, it turns itself off.)

If you're working with TADS, the first two examples would probably only
help with T3, but the last might give you the conceptual jump needed to do
it there. And maybe someone knows of actual TADS examples of this, too.

-Lucian

Kevin Forchione

unread,
Aug 12, 2002, 1:13:53 AM8/12/02
to
"Jim Aikin" <kill_spammers@kill_spammers.org> wrote in message
news:3D573097.6060804@kill_spammers.org...

> I'm sure it's possible -- hey, they're all just ones and zeroes, right? So
> I'm wondering if anyone has developed (or even implemented) a clear
> conceptual model for groupable objects.

It's indeed an interesting and thorny problem, and there are, no doubt,
several possible solutions.

From a modelling perspective, perhaps the *purest* approach would require
you to be able to distinguish various action statuses for each of the
individual objects, group the objects under these various statuses, and then
generate reports based on them.

Suppose we look at a simple action, such as <<take foos>>. To do this
without diddling around with a collective object you'd need to group all the
foos that received the "Taken." status; all the the foos that produced some
customized response, but were yet successful; all the foos that failed and
for each case in which they failed. Grouping by status of the execution of
the command (the action) is logically equivalent to grouping by the
displayed response of the execution of the command.

I implemented something like this in the TADS Alt library by having each
object issue a non-specific string - instead of displaying "You see nothing
interesting about the silver coin." the object would display "You see
nothing interesting about <theDobj>.". Instead of directly displaying these
messages, they were captured and stored in a queue, along with a list of
objects that produced the same message. When the turn completed, I dumped
the queue, using a listing mechanism to replace <theDobj> with a listing of
all the objects that had accumulated in the corresponding list.

So you would get messages like:

>Take all
Three coins, two rubber balls, and four blind mice: Taken.
The batteries and the rheostate: You'll have to open the glass demi-john
first.

Capturing output eliminated the need to track statuses, but it's not the
easiest approach to implement. As a library, Alt is slow, because it does
alot of things, and doesn't do them as efficiently as it probably could.

Still you might want to browse the documentation, skimpy as it is, at
http://www.lysseus.com/intfict/altdocs/index.htm

I would strongly recommend perusing TADS 3. Although it doesn't employ a
text capturing strategy as Alt does, it's in far finer shape to accomodate
the implementation of something along these lines. TADS 3 was designed from
the ground up with far better separation of command execution and
presentation layers than TADS 2, from which Alt derives.

--Kevin


Jim Fisher

unread,
Aug 12, 2002, 2:34:43 AM8/12/02
to
"Jim Aikin" <kill_spammers@kill_spammers.org> wrote in message
news:3D573097.6060804@kill_spammers.org...

[snip]


> What one wants to happen is something much more elegant:
>
> > take coins
> You pick up the three gold coins, the silver coin, and the copper coin.
>

[snip]

I did something similar to this in the ORUniqueMultiMessage module of the
ORLibrary. I was targeting output more like this:

> take coins
3 gold coins: Taken.


silver coin: Taken.
copper coin: Taken.

But the code could be adapted to what you describe with a little effort.

-- Jim
--
Jim (AT) OnyxRing (DOT) com
Visit "An Inform Developer's Guide" or browse the
"ORLibrary" extensions to the standard library at
www.OnyxRing.com
----------------------
Some days you eat the code; some days the code eats you.


Dylan O'Donnell

unread,
Aug 12, 2002, 9:51:15 AM8/12/02
to
Jim Aikin <kill_spammers@kill_spammers.org> writes:

[groups of related-but-not-identical objects]

Without addressing the main point, a comment:

> What's more, you want the plural word (coins) to be applicable only if
> there are two or more in scope. It's not adequate to declare "coins"
> as a synonym for "coin". Among the desired outputs of the objects
> would be error messages along these lines:
>
> > take coins
> There's only one coin nearby at the moment.

This would annoy me. By all means flag that there's only one, but take
the damn coin; I don't want to have to retype my command just because
it was in the wrong number.

> The same holds true for adjectives. If there are three coins present,
> one each of gold, silver, and copper, this should happen:
>
> > take gold coins
> There's only one gold coin nearby at the moment.

This even more so.

--
: Dylan O'Donnell http://www.spod-central.org/~psmith/ :
: "Note that computers turn us into aliens." :
: -- Zarf, out of context :

Stephen L Breslin

unread,
Aug 12, 2002, 3:46:45 PM8/12/02
to
I agree with all of Kevin's points entirely. Tads 3 could employ what
Kevin calls a "text capture" strategy, but there's not a module for
doing this at present, so you'd have to write it yourself. It might
just take a day or two; I haven't thought about it very hard yet. I've
run into a similar problem with the liquids module, but it's a low
priority at the moment. I'd be quite interested to see what comes out
of this discussion as it relates to T3.

Tads 3 is the first IF language to handle distinguishable objects
which are "equivalent": for example lit and unlit matches, the Bills
shirt you're wearing, or the Bills shirt that's on the table. So if
you're serious about working with what we're calling distinguishable
equivalents, Tads 3 is the only way to fly.

Mike Roberts

unread,
Aug 12, 2002, 2:26:36 PM8/12/02
to
"Jim Aikin" <kill_spammers@kill_spammers.org> wrote:
> Here's the deal: IF languages generally deal very well with
> one-of-a-kind objects. They also allow you to create groups
> of objects that are utterly indistinguishable from one another
> (matches in a matchbook being the classic example). But in the
> real world, many or most groups of objects aren't quite that
> featureless. In the real world, an object may be indistinguishable
> from other objects some of the time, or when some adjectives
> are used, or when some actions are called for, but may be unique
> at other times [...]

The tads 3 Distinguisher mechanism handles this much - it allows objects
that are basically equivalent to one another (a bunch of matches, for
example) to be treated as distinguishable according to their current state
(location, burning or not, etc).

> For starters, each instance of the class should be able to sense
> when other instances of the class are in scope, and whether they're
> distinguishable or not with reference to the verb or noun phrase the
> user has just entered. This is so that when the user types a
> command, **only one of the objects needs to issue a message.**
> This avoids ugly, messy output like this:
>
> > take coins
> gold coin: Taken.
> gold coin: Taken.
> gold coin: Taken.
> silver coin: Taken.
> copper coin: Taken.
>
> What one wants to happen is something much more elegant:
>
> > take coins
> You pick up the three gold coins, the silver coin, and the copper
> coin.

That's a good goal, but I personally wouldn't try to handle it on the
parsing side, since I think that's all but intractable. I had some ideas
along these lines when I was first thinking about the adv3 parser, but it
seemed clear that they'd never be workable. What I had in mind was to have
the parser create a grouping object dynamically to operate on a set of
related objects - so "take coins" wouldn't turn into a series of atomic Take
actions applied to individual coins, but rather a single Take action applied
to this ephemeral grouping object, which in turn would point to the
underlying coins. For simple cases, it seems like an elegant solution - the
grouping object looks essentially like a regular object to the parser, which
invokes the normal verify/check/action/etc methods; and the group object
method implementations operate on the underlying objects, but can take
advantage of their full awareness of the entire set for message generation
and the like.

This approach breaks down, though, as soon as you encounter any special
processing. Consider:

>take coins
copper coin: Taken.
silver coin: Taken.
gold coin: You reach out to take the coin, but Miser slaps your hand away!

The problem is that any special processing you want to attach to an action
on a particular object needs to be coded not only on the object but on any
group that can contain the object. For something really special-case like
my example above, maybe that's something game authors could deal with; but
try generalizing this to more global conditions, like hands-full limits, and
it looks incredibly complicated to me.

The approach that I think is more promising is to handle the message
grouping after the fact. In other words, you let the parser do its work the
traditional way, one object at a time; only then, after the parser has
determined the outcome of the command, do you try to get clever about the
message grouping. The advantage of this approach is that the message
grouping has absolutely no impact on programming the world model; it all
happens after the fact. So, when you have the common cases, like a
successful Take on multiple items, the grouping is just a matter of
detecting the case and rewriting the message; when you have an exceptional
case, the grouping doesn't detect a known case, so it just leaves the basic
parser output intact. The grouping is thus a scalable add-on: you can
customize as much or as little as you want, knowing that any cases you don't
handle will still work correctly using the default parser output.

I think that Kevin Forchione took this approach with a tads 2 library
extension. Kevin's extension captured the displayed text and inspected it
for certain patterns. In tads 3, the "transcript" mechanism would provide a
much higher-level starting point than raw text capture; in fact, part of my
goal for the transcript system was to support exactly the kind of message
grouping you're talking about. The thing about the transcript is that it
doesn't just keep track of the text - it also keeps track of the original
action that generated each bit of text, which means you can find the
original objects involved. Having access to the objects is useful because
it means you can call on the objects to generate their plural names, for
example, rather than having to guess how to make a plural name from the
generated text.

In report.t in adv3, the TranscriptTransform class is designed specifically
for this kind of message re-writing. I have an item on my to-do list for
writing a couple of transforms for the most common message groups, like Take
and Drop.

> > z
> Time passes...
> The gold coin isn't glowing as brightly as before.
> The gold coin isn't glowing as brightly as before.
> The gold coin isn't glowing as brightly as before.

> [vs]


> Time passes...
> The three gold coins aren't glowing as brightly as before.

This would fit into the scheme I'm suggesting as well. The disadvantage is
that you have to code each kind of message grouping separately, so this will
take another bit of code separate from the Take grouping code or the Drop
grouping code. However, I suspect that most games will have just a few
special cases that would benefit from such grouping, so it might not turn
out to be that much work, given a template to start from.

--Mike
mjr underscore at hotmail dot com

Jim Aikin

unread,
Aug 12, 2002, 9:13:20 PM8/12/02
to
Mike Roberts wrote:


> What I had in mind was to have
> the parser create a grouping object dynamically to operate on a set of
> related objects - so "take coins" wouldn't turn into a series of atomic Take
> actions applied to individual coins, but rather a single Take action applied
> to this ephemeral grouping object, which in turn would point to the
> underlying coins. For simple cases, it seems like an elegant solution - the
> grouping object looks essentially like a regular object to the parser, which
> invokes the normal verify/check/action/etc methods; and the group object
> method implementations operate on the underlying objects, but can take
> advantage of their full awareness of the entire set for message generation
> and the like.
>
> This approach breaks down, though, as soon as you encounter any special
> processing.


That was the approach I was trying to use -- an invisible "coins" object
attached to Me, which would pretend not to exist (issuing fake error
messages) except when there was more than one coin available. And it broke
down for exactly the reason you indicate.

Even so, I suspect such an object might be useful for more complex
operations. For instance, if you have 3 coins, each could "register" its
impending output message by calling a method in the coin_manager object.
The coin_manager would return a "let's wait and see" message to each coin,
and make a list of the pending actions. At the end of the processing cycle,
the coin_manager would send messages to all of its coins telling them what
sort of message (if any) to print, and make its own decision about whether
a group output message is called for.

This wouldn't impact the world model, because each coin would still decide
for itself what it was going to do.

Another advantage of a group_manager would arise if you wanted to create a
puzzle in which the player is allowed to take a maximum of 3 coins in a
single turn -- but if she gets greedy and tries to take more, she isn't
allowed to take any (a monkey-reaching-into-the-jar puzzle). The
group_manager could count the number of coins that send it an "I'm being
taken" message, and if the total increments past 3, it could send back a
message undoing the taking, or triggering some other event.

--Jim Aikin

Joao Mendes

unread,
Aug 12, 2002, 10:17:11 PM8/12/02
to
Ayohoho, :)

"Kevin Forchione" <ke...@lysseus.com> wrote in
news:kuH59.4240$ev2.15...@newssvr21.news.prodigy.com:

> I would strongly recommend perusing TADS 3. Although it doesn't employ
> a text capturing strategy as Alt does, it's in far finer shape to
> accomodate the implementation of something along these lines. TADS 3
> was designed from the ground up with far better separation of command
> execution and presentation layers than TADS 2, from which Alt derives.

Actually, T3 does have a text capturing strategy, given that everything
that is 'sent to the screen' is actually captured as a 'report' and added
to a 'transcript'. There are a number of hooks available to deal with the
transcripts. Powerful stuff.

Cheers,

J.

Stephen L Breslin

unread,
Aug 13, 2002, 1:50:21 AM8/13/02
to
On Tue, 13 Aug 2002 02:17:11 +0000 (UTC), Joao Mendes
<public...@anywhere.invalid> wrote:

>Actually, T3 does have a text capturing strategy, given that everything
>that is 'sent to the screen' is actually captured as a 'report' and added
>to a 'transcript'. There are a number of hooks available to deal with the
>transcripts. Powerful stuff.

Yeah, I wrote my last post on this thread having never known about,
let alone investigated this report.t transcript stuff. Mike's last
post on this thread introduces this to me. I am taking a look at this
now. It's supercool. I'm glad you also mention this, Joao. I'm still
very much a newbie for the T3 transcript stuff. What I thought was
empty space is already well worked out. (I have already been suprised
like this often enough that I should have known to carefully verify
before I say of anything that it hasn't yet been achieved by the new
library!)

I ran into some delay problems with the transcript stuff at one point.
I think the problem was that a post-player-move message wasn't being
printed prior to a pre-next-move input call. There's a command by
which one can override the output interrupt to allow whatever's cued
to be printed:

gCommandReports.deactivate();

I am going to look much more closely at this stuff now that I recall
that I haven't yet, and now that I realize it's such cool stuff.
Thanks Mike, thanks Joao, and all.

Kevin Forchione

unread,
Aug 13, 2002, 8:35:30 PM8/13/02
to
"Mike Roberts" <mjr-S...@hotmail.com> wrote in message
news:D2T59.5$871...@news.oracle.com...

> This would fit into the scheme I'm suggesting as well. The disadvantage
is
> that you have to code each kind of message grouping separately, so this
will
> take another bit of code separate from the Take grouping code or the Drop
> grouping code. However, I suspect that most games will have just a few
> special cases that would benefit from such grouping, so it might not turn
> out to be that much work, given a template to start from.

This sounds excellent!

--Kevin


Stephen L Breslin

unread,
Aug 15, 2002, 1:59:17 AM8/15/02
to
On Tue, 13 Aug 2002 01:13:20 GMT, Jim Aikin
<kill_spammers@kill_spammers.org> wrote:

>Even so, I suspect such an object might be useful for more complex
>operations. For instance, if you have 3 coins, each could "register" its
>impending output message by calling a method in the coin_manager object.
>The coin_manager would return a "let's wait and see" message to each coin,
>and make a list of the pending actions. At the end of the processing cycle,
>the coin_manager would send messages to all of its coins telling them what
>sort of message (if any) to print, and make its own decision about whether
>a group output message is called for.

This is the sort of approach I was hypostesizing. In fact, I was
thinking that this action could be handled by one of the instances of
coin, but as you and Mike point out, handling it with a group object
sounds cleaner. If you're planning on doing this sort of thing with
T3, I'd be very interested.

Peter McMurray

unread,
Aug 15, 2002, 8:52:16 PM8/15/02
to
On this day 12 Aug 2002 14:51:15 +0100, the Great and Almighty Dylan
O'Donnell strode forth and proclaimed...

> Jim Aikin <kill_spammers@kill_spammers.org> writes:
>
> [groups of related-but-not-identical objects]
>
> Without addressing the main point, a comment:
>
> > What's more, you want the plural word (coins) to be applicable only if
> > there are two or more in scope. It's not adequate to declare "coins"
> > as a synonym for "coin". Among the desired outputs of the objects
> > would be error messages along these lines:
> >
> > > take coins
> > There's only one coin nearby at the moment.
>
> This would annoy me. By all means flag that there's only one, but take
> the damn coin; I don't want to have to retype my command just because
> it was in the wrong number.
>
> > The same holds true for adjectives. If there are three coins present,
> > one each of gold, silver, and copper, this should happen:
> >
> > > take gold coins
> > There's only one gold coin nearby at the moment.
>
> This even more so.
>
>

I agree. In fact, I was about to raise this point myself until I saw
that someone else had beaten me to it.

--
Peter McMurray

Metalman's Realm http://www.alphalink.com.au/~makka

-------------------------------------------------------------------------
"The problem with being a good sport is that you have to lose to prove
it."
- author unknown.
-------------------------------------------------------------------------

Earn cash online: EmailCash
http://www.emailcash.com.au/join.asp?refer=C21219

Stephen L Breslin

unread,
Aug 16, 2002, 3:14:32 PM8/16/02
to
On 12 Aug 2002 04:35:38 GMT, "Lucian P. Smith" <lps...@rice.edu>
wrote:

>If you're working with TADS, the first two examples would probably only
>help with T3, but the last might give you the conceptual jump needed to do
>it there. And maybe someone knows of actual TADS examples of this, too.

I don't find anything conceptually different between example one and
example three, although the execution is different. Why should two
swords making a collection with a collective name be different than
two gloves making a collection with a collective name? I like these
two examples, but I don't see why you consider them different.

I don't know if anyone has done it, but it seems simple enough to have
three objects, one for each individual object, and a third for the
pair when they're in the same location. You could make a check for
whenever an object's location changes, to see if it now shares the
locaiton with its counterpart, and if so, move the individual objects
to nil, and the composite to the new location. You'd want to be able
to refer to the individuals as well as to the collective, so you'd
want to set up a class hierarchy such that the collective inherits
vocabulary from each consitiuent individual object, with appropriate
behavior when one of the parts of the collective is moved. This
wouldn't take too long to code.

The middle example is pretty neat too. That's more complicated I
think.

Stephen L Breslin

unread,
Aug 18, 2002, 4:49:55 PM8/18/02
to
On Fri, 16 Aug 2002 10:52:16 +1000, Peter McMurray
<ma...@alphalink.com.au> wrote:

>> > What's more, you want the plural word (coins) to be applicable only if
>> > there are two or more in scope. It's not adequate to declare "coins"
>> > as a synonym for "coin". Among the desired outputs of the objects
>> > would be error messages along these lines:
>> >
>> > > take coins
>> > There's only one coin nearby at the moment.
>>
>> This would annoy me. By all means flag that there's only one, but take
>> the damn coin; I don't want to have to retype my command just because
>> it was in the wrong number.
>>
>> > The same holds true for adjectives. If there are three coins present,
>> > one each of gold, silver, and copper, this should happen:
>> >
>> > > take gold coins
>> > There's only one gold coin nearby at the moment.
>>
>> This even more so.
>>
>>
>
>I agree. In fact, I was about to raise this point myself until I saw
>that someone else had beaten me to it.

Ideally, the library would enable the game author to tailor this to
the specific ogjects in the game. In the case of gold coins, a game
author following convention would probably opt for the default you
suggest, but in more complicated cases, the game author should be able
to override this, especially in the case where there's a question of
disambiguation. For example, a shard of glass and a pair of glasses.

You are giving a voice to convention and common sense, which is
sometimes useful. But it's also important to think about the problem
before arguing what (sometimes misleadingly) appears to be common
sensical and obvious.

Peter McMurray

unread,
Aug 20, 2002, 8:12:11 PM8/20/02
to
On this day Sun, 18 Aug 2002 20:49:55 GMT, the Great and Almighty Stephen
L Breslin strode forth and proclaimed...

I believe I understand what your saying, but your example does not really
show the problem you are apparently trying to present, as it would be
unlikely for someone to refer to the shard of glass (or multiple shards
of glass) as "glasses".

I think a better example would be a drinking glass and a pair of glasses.
Assuming that there are multiple drinking glasses in the game, and that
they can be referred to in plural, I think it would be acceptable for the
parser to assume that you mean the pair of glasses if there was only one
of the drinking glasses present.

Getting back the original coins example, to me, it's like saying to
someone "Give me your coins" and have them replaying "I only have one
coin, but I can't give it to you because you didn't ask for just one
coin."

Stephen L Breslin

unread,
Aug 21, 2002, 12:51:32 PM8/21/02
to
On Wed, 21 Aug 2002 10:12:11 +1000, Peter McMurray
<ma...@alphalink.com.au> wrote:

>I believe I understand what your saying, but your example does not really
>show the problem you are apparently trying to present, as it would be
>unlikely for someone to refer to the shard of glass (or multiple shards
>of glass) as "glasses".

However you like. It's another problem what weight adjectives are
given when there's a perfect adjective match and a near-match for a
noun. I haven't thought about it enough to come up with great
examples, only enough to realize that trying to generalize a rule or
guideline or preference from one simple example is a bad idea.

>I think a better example would be a drinking glass and a pair of glasses.
>Assuming that there are multiple drinking glasses in the game, and that
>they can be referred to in plural, I think it would be acceptable for the
>parser to assume that you mean the pair of glasses if there was only one
>of the drinking glasses present.

What if there's a glass shard present also? What if there's a pair of
glasses, a drinking glass, and a glass shard present? You need to
really analyze this before making any conclusions about what you want
the parser to assume, even if only to isolate the situation you're
addressing from more complicated situations.

>Getting back the original coins example, to me, it's like saying to
>someone "Give me your coins" and have them replaying "I only have one
>coin, but I can't give it to you because you didn't ask for just one
>coin."

Assuming you mean the case where there's no other possible
object-matches for the word 'coins' in location 'someone' or possessed
by 'someone', then I think you're arguing what anyone would; such
arguments ("sky is blue") normally aren't that intriguing. But you can
make the point interesting for discussion if you did some analysis.

For example, what if 'someone' has one coin, and has some coins in his
piggy bank in the next room (out of scope)? What if the command is
">someone, tell me about your coins". It's really a much more
interesting topic than you're letting on.

Reply all
Reply to author
Forward
0 new messages