Re: Robot challenge

new topic     » goto parent     » topic index » view thread      » older message » newer message

On Sun, 8 Nov 1998 12:32:19 -0800, Hawke <mdeland at NWINFO.NET> wrote:

>Lucius Hilley III wrote:
>>It returns a sequence while it is still alive
>>When my bot quits searching and is dead it returns an atom.
>ok....
>
           <SNIP>
>
>ummmm i was trying to follow this, make sense of it...
>but i'm having trouble because of this section of the example...
>>     if atom(bot) then
>>       if bot then
>>         pixel(RED, bot[1])--bot reached RED
>>       else
>>         pixel(BLUE, bot[1])--bots dead REMOVE carcus
>>       end if
>
        Great EYE.  I doubted anyone would noticed my blunder.
Yes.  I have tested to see if it is an atom and then attempted
to subscript a sequence that doesn't exist.  I will get and
error.  Your work around code that followed was snipped.
Read below to find why.

>first you test if bot is an atom, and if it _IS an atom_,
>you pass bot[1] to pixel().
>now, if we agree that an atom is a length 1 sequence,
>then bot[1], when atom(bot) is true, is a single digit,
>either real or integer, and passing a single digit
>to pixel() (ie:pixel(color,bot[1])) in the parameter
>location you're placing it, won't work because that
>parameter is a coordinate sequence pair.
>
>now, if we agree that an atom and a length 1 sequence
>are NOT the same thing, then, when you test for bot
>being an atom, and it passes, you will subsequently
>attempt to subscript an atom by passing bot[1] to pixel().
>
>(and the latter is what i believe will happen, and what
>i believe is the correct interpretation)
>
>so, with this in mind, i'm having trouble following
>how bot=lucius(bot) would work...
>
>perhaps, if we modified things a wee bit...

        Modifications aren't required.  To fix the code
all you actually need to do is remove the entire 'if atom()'
statement.  This problem arose simply because I began rewriting
my code while I was writing the messgage.  I noticed a few
unimportant things that could be changed.  So, I started
rewriting to make the needed adjustments.  There is another
subtle problem with the code I offered.  The bots aren't visible
long enought for the other bots to see them.  Or the viewer for
that matter.  the pixel(BRIGHT_WHITE, bot[A][1]) in the multiple
bot version should be handled directly after the bot has made
it's move.  NOT while deciding if any bots have reached the finish.
This is imperative because if the bot has made its move it needs
to be visible for the next bot to see.

           <SNIP>
>   --he is less than working, ergo:lounging or comatose
>   --and the memo said that comatose and deceased was no reason
>   --not to be working...
          <SNIP>
Cute.  I like little comical remarks.

>
>
>implementing it this way will also allow for multiple bots...
>----although, here, i would have a sinking feeling that all
>----of the bots would take the same path & make the same
>----decisions because they all start at the same place and they
>----all pass thru the same function... unless, lucius, do you
>----have some sort of weighting or randomosity to your algorithm?
>----something to ensure that (nearly) no 2 bots will travel the same?
        NO weights or randomisity.  I could have had random start
direction.  But I am only moving in 1 of 4 directions.   Thus all of
my bots would go off in only (1 of 4) directions.  Even if random
I wrote the code with the capability to move diagonally but that
*dang* diagonal wall doesn't seem solid enough to keep me from slipping
between pixels.

        Now as you said My bots would seem to all take the same
robotic path around the simple maze to the beautiful pearly gates in
the sky... Oops! Slipped subjects.  I mean to the little red box at
the bottom of the maze.  Or wherever it could be randomly placed.
My bots are roBOTS but they see other bots INCLUDING themselves.
as Non-floor objects, thus, obstacles.  If two bots were to meet in
an open maze they would engage in hometown dosi-do.(sp)  Translation.
The would see each other as walls and attempt tracing around each
other.  This will cause them to appear to be dancing in the middle
of the floor.  The simple thing that causes my bots to not take
the identical path is this. Bot[1] leaves the nest Bot[2] soon
follows  Bot[1] & Bot[2] take identical paths tracing the well
decorated walls until Bot[1] (sees) detects RED. Bot[1] then leaves
the wall and travels toward the RED.  Bot[2] reaches the same point
at which Bot[1] saw the RED but Bot[2] doesn't see it.  WHY?
Bot[1] is in the line of sight.  Bot[2] makes one more step along
wall before spotting a RED pixel.

SIMPLY put.  Bot[1] gets in the way of Bot[2].  Same can be true
of Walls.  My Bots only recognize other bots as MOVING walls.
They try to trace the wall Even if it is a moving Wall.  Thank
goodness I didn't tell them to move towards the closest wall or they
really would have become glued together.  As it stands the bots in
a tango can be interupted by other bots entering the tango.  All
bots CAN be set free by such an interaction.

        <SNIP>
>so, was this what you had in mind? something vaguely similiar?
>cuz, if not, i'm not real sure i understand what you're
>say then...
>
>--Hawke'

    I hope this clears things up a bit.
_________________________

Lucius L. Hilley III    lhilley at cdc.net
http://www.cdc.net/~lhilley
http://www.americanantiques.com
http://www.dragonvet.com
_________________________

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu