Re: RunOncePerCycleIfMatchBlankWithSensor [was: TT 3.66] and [was: Should ToonTalk robots that only update sensors be allowed to run more than once per cycle?]

Hi all.

The core of this issue is what does it mean if you have a robot that repeatedly adds 1 to the width of a picture. Should one expect the width to grow between 20 and 80 units per second (roughly what the very old and the new behavior is) or should it go as fast as it can (growing by many thousands per second)? Note that in all cases it depends upon how fast the computer is and what else the computer and ToonTalk is doing.

So if one cares about the speed one should use the millisecond timer sensor. That is what Playground and current WebLabs tools do. Then it will grow at EXACTLY the speed desired.

So why bother with this new toontalk.ini option one might ask? I think pedagogically one should introduce robots on the back of a picture changing sensors without the complexity of dealing with the millisecond timer. So when first learning about programming sensors I think the slow growth is more desirable.

I would recommend setting RunOncePerCycleIfMatchBlankWithSensor=0 only for unusual uses where you need fast iterative computations that update sensors.

But as Ylva points out if you do set this option then you won't be able to produce a tool that can be composed with other things since other users typically won't have this flag set to 0. I recommend setting this flag only for stand-alone projects.

One major enhancement to ToonTalk that could fix this (and other scheduling issues) is to provide an interface to setting such options local to a team of robots rather than globally for all of ToonTalk. This would clearly be the most powerful and flexible but probably more complex than desired.

In this particular case, if you really needed robots to run many times (maybe to do a complex computation for the width of a picture) then a good style is to load up a truck with robots to do that computation and then when the bird brings back the result a robot uses that to set the width.

By the way, another reason for implementing this toontalk.ini switch is that there may be users who are depending upon the fast behavior (since it has "accidentally" been the way ToonTalk has been working for several months), so I don't want to make an incompatible change without giving such users the ability to continue as before.

Best,

-ken
  ----- Original Message ----- 
  From: ylva fernaeus 
  To: Ken Kahn 
  Cc: [email protected] 
  Sent: Tuesday, April 06, 2004 12:24 PM
  Subject: RE: [WebLabs-requests] RunOncePerCycleIfMatchBlankWithSensor [was: TT 3.66]




    If, for example, you train a robot to repeatedly add 1 and put this robot on the back of a picture and give it a sensor like the width or x position, it used to be (and now is again in 3.66 and beyond) that it would slowly grow or move. For many months now the picture grows or moves VERY FAST. The default is the old slow way and you can get the fast behaviour by setting this flag to 0 in toontalk.ini. Note that if you do set it to 0 so it changes as fast as possible, the corresponding Java applet will still be slow. 

  This sound like projecxt will run differently depending on how parameters are set in the ini-file?

  What happens when you want to share your project with someone else (putting them on the website, etc)? Or all behaviours that we have already programmed, for instance all the ones for the ecoliteracy domain? Can you make sure you project runs then on other machines just as it did when you programmed and debugged it?

  /ylva