Re: Robot challenge
- Posted by Lucius Hilley III <lhilley at CDC.NET> Nov 08, 1998
- 546 views
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 _________________________