Re: Eager robots, addaptive scheduling

Hi all.

I've decided that this message from Yishay is on a topic of wide
interest so I've included the ToonTalk and the technical WebLabs
lists.The background to this discussion are attempts to have children
explore mathematics using a "streaming" style where birds take numbers
to their nest, a robot then computes something with that number and
gives the result to another bird and who takes it her nest and so on.

> Ken,
>
> I think these issues may deserve a wider audience. I leave it up to
you
> - feel free to forward this mail to any forum you see relevant.
> My next "convergence" session was planned to start with a
demonstration
> of running the reciprocals robot, tunnelling the output stream through
> an add up robot to generate the harmonic series, and then passing it
to
> the excel tool and plotting the two sequences in excel. While
preparing
> for this session, I encountered many snags - nothing I would call a
> "bug", but things that made running the demo not as smooth as I would
> like it to be. As an example, frequently when I have a robot running
on
> the floor and I want to grab something, the robot "jumps into my
hard".
> This is a simple statistical consequence of the robots' "eagerness" to
> show me what they're doing. At any given point in time, the chances of
> there being a robot under your hand are quite high.
>

As Yishay mentions below this particular problem is easy to fix -- 
robots should not leave the area where they started working. Robots
shouldn't be so eager to work where you can see them. This is a small
enough change and one that is unlikely to break other things so I'm open
to the idea of doing it very soon.

> This experience resonates with some thoughts I've had reflecting on
our
> activities this year. As you know, we felt somewhat disillusioned
> regarding the stream approach. Students, as well as researchers, found
> it much harder to handle than we expected. We started wondering
whether
> its worth the effort. My position has swung back after running the
> convergence activities. Apparently, it is not the programming pattern
> that is problematic - it is the underlying mathematical concept.
> Applying a process / function (summing) to an object which is in
itself
> a process (a sequence) and obtaining an object which is a process too,
> its all a bit overwhelming. Summing up is the discrete equivalent of
> integration, it is a function from functions to functions.
>
> The bottom line is that streaming and adding up might be worth doing
> precisely BECAUSE it is hard. Perhaps if we make it easier, we will
> develop skills that will make the mathematical concepts more
accessible
> to children.
>

It does appear that this style is hard for children. Whether the
difficulities are intrinsic or due to way these ideas are introduced,
used, and motiviated is an open question (and probably a good research
topic). And the difficulties would be somewhat less if ToonTalk
addressed better some of the issues Yishay brings up here. Maybe
significantly less.

> Getting back to the issue we started with, we have had long talks in
the
> past about ToonTalk's affordances and disaffordances when it comes to
> streams. At a basic level, TT is a wonderful language for dealing with
> the idea of streams processing. It's concurrency, transparency and
> modularity are a natural fit. On the other hand, just when it gets
> exciting it breaks down. Watching two (let alone more) robots on the
> floor is very confusing. If you send some robots out in trucks, you
> loose control as well as view - you are left with the product without
> access to the process. On top of that, once a robot is sent out it's
> production rate spirals, and soon you are bogged down by a nest with
> 10k's of items on it.
>

No doubt things can be better but I'm not convinced things are as bad as
Yishay makes them sound. The multiple robots (not in the same team)
running at once on the floor of the same house may well be confusing
because of the robots' eagerness to work in view. Fixing this may
largely fix that. Regarding trucks and new houses I'm not convinced that
the problem is so real. I've built many programs that work in many
houses and find that it is a good thing to be able to focus on one
process at a time. I often use F8 to stop everything until I get to a
place where I want to see what is happening. While it is true that under
some circumstances thousands of objects may end up on a nest remember
that if you are viewing either the sending or receiving end then they
don't run fast. And again F8 helps here.

> In a nutshell, I'd say we have two major problems hindering the
> usability of streams in toontalk:
> * Asynochonicity, which is generally a virtue, becomes a drawback when
> piping data from a fast process to a slow one.
> * The lack of support for "zooming in / out" on a process. ToonTalk
> provides two levels of granularity - either the process is "in your
> face" or it is "out of reach".
>
> Over the last year and a half we've discussed various ways to overcome
> these issues (limiting nest capacity, robots on picture fronts, etc.).
> You were reluctant to implement any of these, on the grounds that
there
> are other planned enhancements which will address these issues. An
> argument which I was willing to accept. On the issue of
synchronization,
> you suggested a clever scheduling scheme, which would be biased
against
> producers and for consumers. As for zooming on a process, your
solution
> was remote looks (or CCTVs) of houses. As a stop-gap, you suggested
that
> robots will be confined to their original viewport, so that if you
have
> two robots running in a room you can place them far enough apart and
> watch each one separately.
>
> Now, as we know, none of these features will make it to the Easter
> release. My estimate is that CCTVs will not be implemented by the end
of
> WebLab's life span. So, my question is, can the other two features
> (adaptive scheduling and non-eager robots) be put high on the list for
> the summer release? Do you have any other plans that might help?
>

Non-eager robots can be done in a half a day and in a way that doesn't
break old demos and provides a toontalk.ini option to revert back to the
current behavior. Maybe another half a day to make the robots a bit
smarter about where they drop things since that also can be confusing
when they drop things on top of other things.

Adaptive scheduling is a bigger job. User-defined sensors and improved
sensors has higher priority. But maybe adaptive scheduling should be
soon after that. What do others think?

> Thinking about these issues, I suddenly had this idea: why do houses
> have roofs?
> As I said, once you send a robot off in a truck you loose sight and
> control of it. Theoretically, you could go out and find it, but unless
> you took some clever provisions, this means doing a door-to-door
search.
> My experience (TT and elsewhere ..) is that this is a very costly
> procedure. By the time you find what you're looking for, its too late.
> If houses were roofless, and I could summon the helicopter from within
a
> house, I could hover over the city and watch the robots from above. I
> could zoom in / out by flying higher or lower. Essentially, this
brings
> together your original conception of houses as encapsulators and my
idea
> of running robots on picture fronts. In other words, it turns houses
> from black boxes to grey boxes.
>

Interesting idea. Quite possibly useful but pretty probably will look
ugly. And there is an issue of scale - the robots and their boxes would
probably be too small to see what they are doing. An alternative is to
use the roof sensor more. The advantage being that you have complete
control over what things are shown. The downside is that it requires
extra programming and robots (or more complex robots).

Best,

-ken




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/WebLabs-requests/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/