[alicebot-archcomm] [motion] <shuffle>

[Conan Callen]

Who needs to declare that they are on vacation these days? One benifit of
the US economy is that we have all been given a guilt free extended
vacation. Although it would be funner if it were accompanied with an endless
source of income. Oh well, cant have it all :)

The idea of random vrs. shuffle is very subtle. Personally I like the idea
of an additional random (flags) property that would allow the aiml designer
to specify shuffle or some other behavior. To me shuffle means to shuffle an
array, when you get to the end of the array, resuffle the elements.

Shuffleing leads to a couple questions, do you use an index and shuffle the
index or do you shuffle the elements themselves? For example, if you have 5
instances of the bot Bob, it would save memory to have a single array of
strings (li children) in memory, and create an index array for each bot (5
indexes), rather the to have redundant sets of strings (li children). An
index could be a 32 (or 64 bit on sytems like AMD's SledgeHammer) pointer to
the string, or it could be a 8bit index into a zero terminated array of
strings or structs where n <= 256.

This example is fairly simple, but it could become more involved. For
instance the aiml corpus could be compressed or encrypted in memory (there
was a thread about encryption a while back. Providing encryption could be a
great differentiator, but not all applications require encryption therefore
the spec should not require encryption, but define a consistant model for
dealing with encryption.

Additionally there are countless datastructures, b-tree variations, memory
management schemes, language choices, all these choices should be open to
the designer. Should aiml attempt to constrain the designer to a single
piticular choice optimized for yet another language specific implementation?
(I know you probalby hear that a lot, but I think its a key point in the
decision making process).

If the random tag did have an extandable flags property, this would allow
the desiger to add behaviour beyond what the spec calls out or allows for.
This is where the spec needs to allow for extensions. All great specs allow
for extensions, otherwise it leaves room for a newer more flexible spec to
muscle its way into the picture.

Conan

----- Original Message -----
From: "Noel Bush" <noel@alicebot.org>
To: "Alicebot and AIML Architecture Committee"
<alicebot-archcomm@list.alicebot.org>
Sent: Thursday, May 16, 2002 9:15 AM
Subject: Re: [alicebot-archcomm] [motion] <shuffle>


> I'm not interested in taking a vacation.  I think there's quite a lot of
> work that can be done here; I don't think that the disagreements to
> which Rich alluded need to interfere with this committee's work, and I
> don't think they need to be aired here.
>
> To get back to the topic, Andrew Teal asked:
> > how do we cope with all those other variants of random which were
> > desired by a range of people? A range of new tags?
>
> > Hmm ... not so good. So what about using attributes to random? More
> > extensible as the variants are developed?
>
> I know that that's what Jon proposed, too.  My problem was that when I
> reviewed the list of other variants of random, I didn't see any that
> seemed essential, from my point of view.  That doesn't mean they aren't,
> just that I didn't understand.
>
> But considering the question of adding attributes to an existing element
> vs. adding a new element, I have to wonder: what's the difference?  One
> advantage to the idea of adding attributes is that we could specify a
> general rule that known tags with attributes unknown to a given AIML
> interpreter should be interpreted in a default way -- i.e., an AIML
> interpreter might encounter <random type="shuffle"> but not know about
> the "shuffle" type, so just use the default (or an undefined) kind of
> random.  I can see the benefit in that -- actually, though, it makes me
> want to step back and propose this more general rule first.
>
> On the other hand, adding a new element really isn't any different.  If
> they are semantically distinct enough -- if a shuffle isn't really a
> "variant" of random but is just "something different", then it would be
> more appropriate for an AIML interpreter that didn't know about it to
> raise an error, rather than to treat it in some default way.  It would
> not, for instance, be appropriate for a bot that was simulating a card
> game to use a "default" random such as the one we've currently got -- it
> would be better for the bot to loudly fail to understand.
>
> If people are willing to discuss this further, I think I should withdraw
> the motion and return this to discussion mode.
>
> On Wed, 2002-05-15 at 20:19, Dr. Richard S. Wallace wrote:
> > Uh, we...are...taking....a....summer...vacation.
> >
> > Thanks
> >
> > Rich
> >
> > ----- Original Message -----
> > From: "Noel Bush" <noel@alicebot.org>
> > To: "Alicebot and AIML Architecture Committee"
> > <alicebot-archcomm@list.alicebot.org>
> > Sent: Wednesday, May 15, 2002 9:17 AM
> > Subject: Re: [alicebot-archcomm] [motion] <shuffle>
> >
> >
> > > On Wed, 2002-05-15 at 19:27, Conan Callen wrote:
> > > > 1. Will the <random> remain, or will <shuffle> obsolete <random>
> > >
> > > I think <random> should remain.  I actually think that <shuffle> will
> > > turn out to be more useful than <random>, but there's no reason to
> > > remove <random>.
> > >
> > > > 2. When the deck is shuffled, it is possible that the last card will
be
> > the
> > > > first card after the shuffle. If this is not the desired behavior,
you
> > might
> > > > insert some text that says something to the effect "while insuring
that
> > the
> > > > last li child returned will not be the first li child returned after
the
> > > > shuffle" at the point marked by <INSERTED HERE>.
> > > >
> > > > then the status of the shuffle is reset  as though none of its li
> > children
> > > > have been returned to the current user by the AIML interpreter for
> > > > the current bot <INSERTED HERE>, and a selection is made
> > > > according to the first rule.
> > >
> > > Yes, that's an interesting point.
> > >
> > > > 3. Also the link to the Aiml schema on
> > > > http://alicebot.org/committees/aimlSchema.html is broken.
> > >
> > > Thanks!
> > >
> > > _______________________________________________
> > > alicebot-archcomm mailing list
> > > alicebot-archcomm@list.alicebot.org
> > > http://list.alicebot.org/mailman/listinfo/alicebot-archcomm
> >
> > _______________________________________________
> > alicebot-archcomm mailing list
> > alicebot-archcomm@list.alicebot.org
> > http://list.alicebot.org/mailman/listinfo/alicebot-archcomm
> >
>
>
> _______________________________________________
> alicebot-archcomm mailing list
> alicebot-archcomm@list.alicebot.org
> http://list.alicebot.org/mailman/listinfo/alicebot-archcomm
>