[From Bill Powers (970625.1754 MDT)]
Rick Marken (970625.1600)--
My result: closed-loop RMS error = 8.449, "open-loop" error 6.482.
And mine, using the same strategy, was 8.765 and 8.771. I think the
main reason for the larger RMS error in the closed-loop case (when
it occurs) is my failure to throw out the first few seconds of data,
when you are bringing the cursor (or mouse arrow) to the target.
I'll fix that.
It was also because I was boggling at how long the lag was between mouse
cursor and mouse arrow; my mind wasn't entirely on the job until the second
This gives me an idea: in the demos where the cursor is always
visible, why not just use the mouse cursor instead of drawing
one on the screen?
That's a good idea. But the position of mouse arrow that is used in >the
calculation of RMS error is the delayed value that corresponds
to what is now cursor position.
Yeah, that's a problem. However, when the mouse arrow is used to track,
control does get better, implying that removing the effect of the delay is
important for the _user_. There's always a lower loop, which we usually
ignore, that puts the cursor where you intend it to be. A lag in that lower
loop screws up skillful positioning of the cursor relative to the target
(maybe this is a way to get at multi-leveled control?).
The lag you see is mainly a result of the Java "sleep" function.
I have found that the program has to sleep (do nothing at all) for
at least 50 msec in order for Java to be able to read in the mouse
position. I don't know why this is true. My local Java guru
doesn't know why this is true. I don't know if there is a better
way to do animated interactive graphics with Java; my Java guru >doesn't
know if there is a better way.
The lag I'm seeing is a whole lot longer than 50 milliseconds; it's more
like 250, or even more. It's even much longer than your 140 millisecond
delay. Something else is going on, too.
I am doing stuff with Java
that no one else is doing; I have things I would like Java to be
able to do (read the mouse, do computations and refresh the
animation, and do these things in a precisely timed manner) that
no one else is doing with Java. I don't know whether this stuff
_can_ be done with Java as well as it can be done with C or Pascal.
That's what concerns me. Java seems designed mainly to get flashy effects
on the screen, at least as I've seen it used. Who the hell cares about
frames, or animations that jump from one position to another, or filling
out forms, and all that commercial stuff? That's not what we do.
Right now, I clearly can't do the things I want to do as well with
Java as I could do them with another language (at least, not with
Java running through a browser). But I don't think this is a reason
to give up on Java. I can do some things OK; I think the demos work
_pretty_ well. They are not perfect; but we'll see how far we can >go. The
potential advantages of Java (platform independence and easy >access) are,
I think, rather great.
I think it's worth pursuing further, too. But I really don't want to see
PCT exposed to the world looking kludgy and klunky, with nothing working
really well, and lots of irritating difficulties of use. We can be
forgiving of each others' interim results, but other people aren't going to
be so generous.
I was noticing, aghast, how far the computer-drawn cursor lags
behind the mouse cursor -- up to half an inch!
Yes. The result of that damn sleep function. This is a very >unfortunate
feature of Java; it means that you have to WASTE at
least 50 msec in order to read the mouse.
I think the lag we're seeing is caused by more than that.
Right now, I'm afraid the best I can do is make the sleep period
that's certainly worth a try.
To get away from this "cheat" in your demo
I'll try some of your suggestions. But I should note that the
"cheat" in the demo (the lag between mouse and cursor) works
against closed loop control.
I wasn't referring to the lag, but to the trick Bruce Gregory found for
continuing to track by using the mouse arrow instead of the cursor that the
computer draws. This is the cheat that renders the proportional case
meaningless. Have you tried this to see what happens? Just ignore the
computer-drawn cursor and use the mouse arrow to track the target.
I originally used a sine-wave disturbance. I'll go back to it if you
No, then we get people saying that participants are memorizing the pattern.
In this case I was just looking for a simple way to rule out using the
mouse arrow to do the tracking.
Thanks for your interest, by the way.
Everything you do interests me.
A general question for computer experts. Net browsers have the ability to
use "helper" programs while on line. Would it be possible to write one that
downloads source-code, compiles and runs it, and then returns control to
Netscape? If this could be done, we could write our demos in any language
we liked, and people could run them on their machines as they do now. The
only problem would be making the programs platform-independent, but the
people who wrote Java had to write machine-specific routines for every
Alternative: A program like Wolfgang Zocher's "Simcon" allows one to send
very brief scripts in ASCII, which are then interpreted -- very fast -- by
build-in function calls. He already has versions that run on several
platforms. Let's talk with Wolfgang about this at the meeting. This
approach might give more protection against hacker-slime.