New Demo

[From Rick Marken (970127.0820)]

Bill Powers (970126.1820 MST) re my new demo:

I like it.

I take that as VERY high praise, indeed, coming as it does from someone who
(based on your time stamp) tried this demo in lieu of watching a _great_
Super Bowl (please don't break my bubble and say that you tried it during
half-time;-))

The other side would be to do "same stimulus, different response."

Yes. I did report such an experiment in "Mind Readings". Maybe that
will be my next demo.

Is it possible to draw a rubber-band vector?

Sure. That's a good idea.

I do wish it were possible to at least double the display rate. Any idea
why it's so slow, anyone?

I'm afraid I am clueless about it. This is an area where even my Java
expert is clueless. However, I plan to spend part of this week
trying to figure out what is going on in my animation loops. Something
doesn't work as I expect. The main indication of this is that when I run
these programs via a JIT compiler, thes get all screwed up. They do run
faster, but they seem to store mouse events during the period when I
expect the program to be "sleeping" (and not accepting events). Obviously,
the timing aspect of Java has to be mastered before we can do any _real_
research via the net. I'll try to figure it out.

Best

Rick

[From Rick Marken (970419.1200 PDT)]

I put up a new Java demo up at my web site. It's accessable
from the Demo Page:

http://www.leonardo.net/Marken/ControlDemo

It's called "Hierarchy of Behavior and Control.

It's a "work in progress" but I wanted to get it on the net because
David Goldstein expressed an interest in it and I promised it weeks
ago. I can see that the animation if not great via my browser (because
I am printing more text than necessary on each animation loop). Part of
what took me so long was I kept fiddling with it. Mainly I tried using
graphics (circles of different sizes) rather than letters (as I
have now) but I found that the change in the sequence of circles
could be perceived as a changed event, so the rate needed for good
control would differ depending on whether I was controlling the
event or the sequence. The letter sequence doesn't look as cool
as the circle sequence but at least I don't get the confounding of
perceptual levels.

Anyway, any comments or suggestions would be most welcome.

Best

Rick

[From Rick Marken (970624.0910)]

As a "thank you" to Hans for his unflinching willingness to continue
posting [Hans Blom, 970624] so that we can get gems like [Bill Powers
(970624.0645 MDT)], I am announcing the availability of a new demo at
my web site. The demo was inspired by Hans' persistant insistence
that control actions are generated by an internal model of the
environmental connection between the actor and the variable under
control.

I started developing the demo some time ago but didn't continue
because I could find no way to make the cursor arrow disappear when
the cursor itself disappeared. I still can't make the cursor arrow
disappear -- so I consider the demo still "under construction". But
now I figure that the visibility of the cursor arrow is not really a
problem because the fact that it is visible should make no difference
(or even make things easier) if people are actually model based
controllers.

The demo is the last on the list at:

http://home.earthlink.net/~rmarken/demos.html

Best

Rick

[From Bill Powers (970624.1224 MDT)]

Rick Marken (970624.0910)--

I am announcing the availability of a new demo at
my web site. The demo was inspired by Hans' persistant insistence
that control actions are generated by an internal model of the
environmental connection between the actor and the variable under
control.

This will be a nice demo when it's finished. Right now there are some
problems:

1. When starting up for the first time, the cursor doesn't begin to respond
to the mouse for several seconds. It looks as though the erasing and
writing are out of synch at first, so instead of writing the cursor you're
erasing it.

2. On the first run under EITHER condition, the closed-loop error is larger
than the open-loop error. Everything's fine on subsequent runs under the
same condition (including the initial problem with the cursor).

3. You should emphasize that controlling under the integral condition is
hard to learn. Maybe you should emphasize that cursor VELOCITY corresponds
to mouse-arrow displacement from a center position. I think you could
explain this at great length, and people could practice at it all they want
to, and control would still be lousy without feedback. Nice going.

Best,

Bill P.

[From Rick Marken (970624.1300)]

Bill Powers (970624.1224 MDT) --

1. When starting up for the first time, the cursor doesn't begin
to respond to the mouse for several seconds.

This doesn't happen for me and I run this using Netscape 3.0
for the Mac and Netscape 4.0 for the PC (Windows 3.1). You're
running Netscape 3.0 in a Windows 95 environment, right? I wonder
if anyone else gets this delayed response with their system?

2. On the first run under EITHER condition, the closed-loop error
is larger than the open-loop error.

Again, this doesn't happen for me. I don't know what might be going
on. I guess I'll try running it on a system like yours.

3. You should emphasize that controlling under the integral
condition is hard to learn.

Yes. I just sent out a fast and dirty write up. But, even so, I
should have mentioned that the integral control condition is
_difficult_ (in the closed loop condition; it's _impossible_ in
the open loop condition) and that it takes a lot of practice to
get to a reasonable level of control. The best level of control
I can exert (in the closed loop condition) is an RMS error of
about 20 pixels. The best I've been able to do in the open loop
condition is an RMS error of 90 pixels (and this was just luck);
the typical open-loop error for me is about 250.

If anyone else does this demo I would appreciate your comments
and suggestions as well.

Thanks

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/^rmarken

Hi Rick,
I printed out a whole batch of stuff on your New Demo, but I don't
think my equipment can get the actual Demo itself. I have Netscape 2.02
and a Mac LC III. I don't have JAVA. Ergo, I could not try the process.
However, FYI, in my
doctoral research I used a program developed in HyperCard. The mouse
tap launched a disk missile in a parabolic arc toward a vertical line target.
Subject had to tap mouse a second time to stop it on target. Closeness was
measured in 0.001 inch. Means of forty tries were correlated with subjects
body type. Results were pretty clear cut.

BTW, I don't even know what RMS means.

When I think of PCT, I feel very inadequate toward understanding it. It makes
very good logical sense and it also has the quality of aesthetic appeal,
for me anyway.
I get a real kick out of reading Blom's ripostes.

Give me another year to get clear on PCT, now that I am out of the academic
melee with my fresh Ph.D.

Also does anyone out there know the work of the Baron vonEuxkull?

All my best

Elleryl

[From Bruce Gregory (970625.1100 EDT)]

Rick Marken (970624.1300)

If anyone else does this demo I would appreciate your comments
and suggestions as well.

Something strange going on here. I can control better open loop
than closed loop in the proportional condition. (RMS 17 closed
loop, 12 open loop.) I simply track the target with the mouse
cursor. First run in the integral condition also produced a very
respectable open loop number rms 100, versus 67 for closed loop.
I am using Nescape 3.0 running under Windows NT on a 90 MHz
Pentium.

Bruce

[From Rick Marken (970625.0850 PDT)]

Bruce Gregory (970625.1100 EDT) --

Something strange going on here. I can control better open loop
than closed loop in the proportional condition. (RMS 17 closed
loop, 12 open loop.)

Not surprising. You are really closed-loop in both cases since
the mouse arrow position corresponds exactly to the (now invisible)
cursor position in the open-loop case. The difference between an
average squared error (that's what RMS means, Ellery) of 17 and
12 pixels is within the range of variability one would expect due
to differences in the characteristics of the random target movements
during the open and closed loop phases of the experiment. I expect
the results you got; the open and closed loop RMS errors should be
about the same in the Proportional control experiment since the open and
closed loop cases are really both closed loop.

Calling the Proportional control conditions "closed" and "open"
loop would have made more sense if I were actually able to make
the mouse arrow disappear in the open loop phase. But even if I
could do that, you would still have the kinesthetic and tactile
perceptions of mouse position to control as surrogates for the
perception of cursor position. Since these perceptions mouse
position are a poorer surrogate for the actual perception of
cursor position than is the mouse arrow, your RMS error in the
open loop phase of the Proportional control experiment would have
been much large relative to the error in the closed loop phase if I
could have made the mouse arrow disappear.

First run in the integral condition also produced a very
respectable open loop number rms 100, versus 67 for closed loop.

This is not a surprise either. I have found that certain patterns
of mouse movement will keep the invisible cursor in the open loop
Integral control condition within the screen boundaries; when this
happens the RMS error measure can be rather low (sometimes as low
as 50 pixels). The only way to see that you are really _not_
controlling the cursor in the open loop Integral control condition
is to practice controlling in the Integral condition until you can
reliably control the cursor (with an RMS error of, say, 25 or less)
in the closed loop phase. Then you will see that the RMS error in
the open loop phase is _always_ much larger (usually on the order
of 10 times larger) than it is in the closed loop phase.

Once you get skilled at controlling in the Integral condition
(and, as Bill noted, it takes a _lot_ of practice to get skilled
at Integral control) you will be able to "see" (subjectively) that
you are really not controlling at all in the open-loop phase of the
Integral control condition. You are just _guessing_ at the effects
you _might_ be having on the (invisible) cursor. I have found that
the harder I try to "control" the invisible cursor in the open-loop
phase -- that is, the harder I try to imagine the effects that
my mouse movements are having on the now invisible cursor -- the _worse_
I do. Guess I won't be the poster-boy for model-based
control:-(

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

[From Bill Powers (970625.1013 MDT)]

Rick Marken (970625.0850 PDT)--

Bruce Gregory (970625.1100 EDT) --

Something strange going on here. I can control better open loop
than closed loop in the proportional condition. (RMS 17 closed
loop, 12 open loop.)

Not surprising.

No, considering what I have just discovered: if the mouse arrow travels
over either button, the cursor stops moving. Same problem I had before.
This is why I thought that on the first run, the cursor didn't respond to
the mouse for a while -- I didn't get the mouse arrow off the button at
first, since I wasn't watching it. Any way to remove or disable the buttons
during the run? It's distracting to have to control the mouse arrow to
avoid the button at the same time as trying to control the cursor -- even
when you can see the cursor.

A kludge to get around the mouse-arrow problem might be to ask the user to
keep the cursor on a horizontal line during the run, and see to it that in
order to do so, the mouse arrow must be up at the top of the screen.

The demo might work better if you make the range of movement of the target
larger and slower, so the little errors due to the slowness of the display
make less difference.

It seems really strange that a program running on my 100MHz 486 can't
display the cursor position more than 4 or 5 times per second. Java seems a
lot slower than Basic on my old 1 MHz 8086.

Best,

Bill P.

[Hans Blom, 970625b]

(Rick Marken (970624.0910))

As a "thank you" to Hans for his unflinching willingness to continue
posting [Hans Blom, 970624] so that we can get gems like [Bill
Powers (970624.0645 MDT)], ...

I wonder why disturbances occasionally produce/prompt such gem-like
results. Unintended side effects? :wink:

... I am announcing the availability of a new demo at my web site.

I'm still running Windows 3.1, so I cannot run your demos. Sorry.

Have fun,

Hans

[From Bill Powers (970625.1138 MDT)]

Hans Blom, 970625b (writing to Rick) --

I'm still running Windows 3.1, so I cannot run your demos. Sorry.

They would not be hard for you to program and run yourself, you know -- if
you really wanted to see what they do. Are you ready to accept Rick's
conclusions without even trying the experiments?

Best,

Bill P.

[From Rick Marken (970625.1120)]

Bill Powers (970625.1013 MDT)--

if the mouse arrow travels over either button, the cursor stops
moving.

It's not the buttons that do it. The mouse is only effective when
the arrow is in the "panel" area above the button area. This is true
of all the demos and there is no way around it. I suppose I should
note this in the instructions and draw a line indicating the lower
border of the panel that takes mouse arrow position as an input.

The demo might work better if you make the range of movement of
the target larger and slower, so the little errors due to the
slowness of the display make less difference.

I'm generating a new noise disturbance each time you launch the
Applet (which occurs when you reload the page, I believe). I
could make it so that the same noise is used every time. I have
found that some disturbances work better (in terms of getting a
more distinct difference between closed and open loop RMS error)
than others.

It seems really strange that a program running on my 100MHz 486
can't display the cursor position more than 4 or 5 times per
second. Java seems a lot slower than Basic on my old 1 MHz 8086.

Actually, I think Java ris remarkably fast. The "Test for
the Controlled Variable" demo, for example, is computing
three correlations (between three pairs of 200 element vectors)
on each animation cycle and it runs pretty smoothly on a
40 MHz Mac. I have run JIT compiled versions of Java and they
don't make much difference in terms of the speed of animation
(and you pay a price in terms of the time you have to wait
for the browser to compile the Java before it's run).

Most of the slowness you experience in the Open Loop "Control" demo
is the result of a delay I inserted in the control loop; the program
sleeps for 140 msec. So the _maximum_ animation speed is about 7
cycles/sec. So if you're getting 5/sec you are losing about 50 msec
on each cycle to computational overhead. I've found that the minimum
sleep time that allows Java to read the mouse is 50msec; so the max
animation speed possible is about 20 cycles/sec. I could run the
Open Loop "Control" demo at this speed if I changed the frequency of
the disturbance; but then I would need to store a longer disturbance
and I might start pushing the memory limits of the Applet. Although
the animation rate is slow in the current demo it seems quite smooth
to me on my 120MHz Mac and on my 166MHz PC.

I agree that Java has it's problems relative to what we want to do.
Interactive graphics were apparently not at the top of the list of
requirements when Java was developed. But I think that Java will
eventually be developed to the point where it will be very useful
for our purposes; it will _eventually_ make it possible for _anyone_
who has browser access to the www to do our demos. This is not
the current state of affairs but I think it will be. I think it
would be best to view my demos as demonstrations of the
_feasability_ of using the Web for interactive, real time demonstrations
of control phenomena and models.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

[From Rick Marken (970625.1300 PDT)]

Hans Blom (970625b) --

I'm still running Windows 3.1, so I cannot run your demos. Sorry.

Bill Powers (970625.1138 MDT) --

They would not be hard for you to program and run yourself, you
know -- if you really wanted to see what they do.

That's true. But Java programs can be now be run in a Windows 3.1
environment using the new version of Netscape called Communicator
4.01. Hans (and all other Windows 3.1 folk) can go to

http://home.netscape.com/download/client_download.html?communicator4.01

and download a trial copy (it only runs for a few months, I think)
of Communicator Standard 4.01 for Windows 3.1 for free. I've done it and
it works fine.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

[From Bill Powers (970625.1405 MDT)]

Rick Marken (970625.1120)--

It's not the buttons that do it. The mouse is only effective when
the arrow is in the "panel" area above the button area. This is true
of all the demos and there is no way around it. I suppose I should
note this in the instructions and draw a line indicating the lower
border of the panel that takes mouse arrow position as an input.

That would help. Interesting how one's mind stops when an adequate, rather
than a right, hypothesis is found.

The demo might work better if you make the range of movement of
the target larger and slower, so the little errors due to the
slowness of the display make less difference.

It seems really strange that a program running on my 100MHz 486
can't display the cursor position more than 4 or 5 times per
second. Java seems a lot slower than Basic on my old 1 MHz 8086.

Actually, I think Java ris remarkably fast. The "Test for
the Controlled Variable" demo, for example, is computing
three correlations (between three pairs of 200 element vectors)
on each animation cycle and it runs pretty smoothly on a
40 MHz Mac. I have run JIT compiled versions of Java and they
don't make much difference in terms of the speed of animation
(and you pay a price in terms of the time you have to wait
for the browser to compile the Java before it's run).

In my Little Man demo, I have to do several thousand lines of code per
iteration, to calculate the dynamic arm response to torques, the position
of the arm segments, and the visual angles of the target and fingertip --
and then erase and redraw the moving parts of the Little Man figure and
update all the data plots. I get 30 iterations per second out of it. Java
still seems slow to me.

Incidentally, to compile a 10,000 line program in Turbo Pascal takes about
10 seconds on my machine, most of the delay being disk activity when
recompiling all the Units. I think the basic speed is 17,000 lines per second.

Most of the slowness you experience in the Open Loop "Control" demo
is the result of a delay I inserted in the control loop; the program
sleeps for 140 msec. So the _maximum_ animation speed is about 7
cycles/sec. So if you're getting 5/sec you are losing about 50 msec
on each cycle to computational overhead. I've found that the minimum
sleep time that allows Java to read the mouse is 50msec; so the max
animation speed possible is about 20 cycles/sec. I could run the
Open Loop "Control" demo at this speed if I changed the frequency of
the disturbance; but then I would need to store a longer disturbance
and I might start pushing the memory limits of the Applet. Although
the animation rate is slow in the current demo it seems quite smooth
to me on my 120MHz Mac and on my 166MHz PC.

Well, 20 iterations per second would be a whole lot better. Why not just
see if you run out of data memory? If you don't, the result would be much
more user-friendly. A compromise would be to use the same length of data
table as before, but advance the index 1/4 as fast, so the same value of
the disturbance is used 4 times in a row. This would still allow the effect
of the handle on the cursor to be much faster and smoother.

I agree that Java has it's problems relative to what we want to do.
Interactive graphics were apparently not at the top of the list of
requirements when Java was developed. But I think that Java will
eventually be developed to the point where it will be very useful
for our purposes; it will _eventually_ make it possible for _anyone_
who has browser access to the www to do our demos. This is not
the current state of affairs but I think it will be. I think it
would be best to view my demos as demonstrations of the
_feasability_ of using the Web for interactive, real time >demonstrations

of control phenomena and models.

As I told Rupert Young, I guess this means I have to learn to program in
Java. I hope you and he will help me get started, at the meeting.

Best,

Bill P.

[From Bill Powers (970625.1431 MDT)]

Rick Marken (970625.1120)--

Additional comments on new demo:

I tried Bruce Gregory's trick and just tracked the target (proportional
case) with the mouse cursor, ignoring (or trying to ignore) the
computer-drawn cursor. My result: closed-loop RMS error = 8.449,
"open-loop" error 6.482.

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? I was
able to track much better that way. One reason the errors were greater in
the closed-loop part was that I was noticing, aghast, how far the
computer-drawn cursor lags behind the mouse cursor -- up to half an inch!
It looks a lot as though there's a leaky-integral lag between the mouse
arrow position and the position where the cursor is drawn. Is this in your
program, or is it a "feature" of Java? The lag is definitely more than 1/7
of a second, which you describe as the minimum time between cursor samples
in your program. Just try suddenly moving the mouse arrow, and see how long
the drawn cursor takes to come to the same position!

I just tried this, and it's worse than I thought. Between a sudden movement
of the mouse and the corresponding movement of the drawn cursor, there is a
lag of somewhere around a quarter of a second, easily visible! And it's a
plain transport lag: the resulting trace is a square wave. It's as if the
mouse positions are being stored in a FIFO buffer that's at least 3 to 6
elements long (assuming 1/7 second per sample). Could someone else check
this out to see if it's just me?

On top of all that, I discovered that my mouse is accelerated -- I get
bigger pointer movements for fast mouse movements. No apparent way to
eliminate this feature in the Windows95 control panel. Of course this
renders all parameters of control systems measured in tracking with the
mouse invalid. If anybody knows how to kill this feature I would love to
know about it.

To get away from this "cheat" in your demo, the easiest fix would be to
make the computer-drawn cursor move oppositely to the mouse arrow. The next
easiest would be to put in a slow disturbance, so the mouse arrow position
would no longer correspond to the computer-drawn cursor position. The
disturbance could just be a slow sine-wave, which does one full cycle
during each half of the run.

Alternately, since the point is to test whether human subjects use internal
models of the environment, you could do the tracking with the mouse cursor
but let the _target_ disappear, or just blank the display altogether. If
you're working off an internal model, you should be able to go right on
tracking! Heck, you could even let the target move in a slow sine-wave, to
give the "internal model" proposition an easy problem.

Best,

Bill P.

[From Rick Marken (970625.1600)]

Bill Powers (970625.1431 MDT) --

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.

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.

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. 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.

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 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 don't know why this
is true or if there is any way to work around it. It may be a
quasi-bug that will be fixed in a future implementation of Java.
Right now, I'm afraid the best I can do is make the sleep period
minimal.

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. So I'm "cheating" in favor of the
rival theory.

you could do the tracking with the mouse cursor
but let the _target_ disappear...If you're working off
an internal model, you should be able to go right on
tracking!

Not a bad idea but then how do you do the "Integral" condition?

Heck, you could even let the target move in a slow sine-wave, to
give the "internal model" proposition an easy problem.

I originally used a sine-wave disturbance. I'll go back to it if you
like. But I think I'll stick to blanking the cursor rather than the
target. But maybe I'll try reducing the sleep period so that the
lag from mouse to cursor movement is reduced.

Thanks for your interest, by the way.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

[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
half.

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
minimal.

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
like.

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
platform anyway.

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.

Best,

Bill P.

[Hans Blom, 970630]

(Rick Marken (970625.1300 PDT))

... Java programs can be now be run in a Windows 3.1 environment
using the new version of Netscape called Communicator 4.01. Hans
(and all other Windows 3.1 folk) can go to

http://home.netscape.com/download/client_download.html?communicator4.01

and download a trial copy (it only runs for a few months, I think)
of Communicator Standard 4.01 for Windows 3.1 for free. I've done it
and it works fine.

Thanks, Rick. It works!

Two comments. First, I don't see "open loop control" in the
proportional case: there's still feedback from the mouse arrow.
Second, being halfway around the world from where you are, I
experience long (and, it appears, variable) delays when running the
programs. That delay introduces extra, unanticipated factors in your
demos, and control becomes a lot more difficult.

Otherwise your programs look good!

Greetings,

Hans

[Hans Blom, 970630b]

(Bill Powers (970625.1754 MDT))

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?

I've been told that, for security reasons, this ability is absent or
extremely limited. Think of an unscrupulous person (you and I
wouldn't, of course!) whose compiled program executed del *.* or
worse! It appears that Java was designed to prevent this kind of
thing from happening. Whether it is fully successful at that remains
to be seen...

Greetings,

Hans

[From Bill Powers (970630.0645 MDT)]

[Hans Blom, 970630b]--

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?

I've been told that, for security reasons, this ability is absent or
extremely limited. Think of an unscrupulous person (you and I
wouldn't, of course!) whose compiled program executed del *.* or
worse! It appears that Java was designed to prevent this kind of
thing from happening. Whether it is fully successful at that remains
to be seen...

That had crossed my mind, which is why I veered off in the direction of
script languages in my post. If the remote user or downloaded program can
execute only a fixed set of library programs, none of which can damage the
system, hacking should not be a problem.

Your post to Rick suggests that when an Java applet is running, it depends
on some kind of continuing input over the internet. If so, that could
explain the lags I see, as I have only a 14.4 Kbaud modem. But I had
thought that Java programs run locally, on my computer. Is this incorrect?

Speaking of hacking, it seems to me that the malicious hacker always has
one overriding problem: not being identified. Hacking into other people's
systems is basically a cowardly business; it has to be done from a hidden
position, like shooting someone in the back from ambush. While we can't
force anyone to admit to identity, we could make it a condition for being
allowed to enter into specific forms of communication with us. A bank
doesn't have to cash your check if you won't show the required forms of
identification. One effective form of identification is call-back security.
When someone calls you up with a wonderful opportunity, and you're
interested, you say "Please give me your name and phone number, and I'll
call you right back, collect." I think that would stop most scams in their
tracks, while not ruling out genuine opportunities (if there are any that
come to you that way). If, as a scam artist, you give out the right phone
number, you are at immediate risk of being tracked down. If you give the
wrong phone number, what's the point?

Unfortunately, security schemes only work for those aware enough to use
them, and most people won't bother. However, it would be nice to be able to
do certain things when it's worth the bother. If there were some way to
demand positive identification of a caller (and for the caller to provide
it) before agreeing to open the lines, there would be far less need for
elaborate protections for our computers. There must be some way to say,
when it matters, "I'll be glad to let you into my computer if you can
satisfy me that I know who and where you are." Nobody has to reveal that
information -- unless they're willing to trade it for access. But no
malicious hacker would willingly make that trade.

So the question boils down to how one person can establish identity and
location sufficiently well for another person to rely on that information.
I think a workable method for doing this would stop the malicious hacking.

Any clever ideas out there? Are hackers really smarter than the rest of us,
as they think they are?

Best,

Bill P.