# C programming; Model-based control

**URL:** <http://discourse.iapct.org/t/c-programming-model-based-control/2039>\
**Category:** CSG1994\
**Created:** [February 2, 1994, 5:08pm UTC](http://discourse.iapct.org/t/c-programming-model-based-control/2039 "1994-02-02T17:08:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![William\_T\_Powers2](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/w/c67d28/32.png) [@William\_T\_Powers2](http://discourse.iapct.org/u/William_T_Powers2)\
**Post date:** [February 2, 1994, 5:08pm UTC](http://discourse.iapct.org/t/c-programming-model-based-control/2039/1 "1994-02-02T17:08:31Z")

</div>

[From Bill Powers (940202.0915 MST)]

Bill Leach (940201.1846) --

RE: programming.

One reason I prefer the PC environment is that our experiments  
and simulations tend to use the whole capacity of the CPU -- even  
the 33 MHz 486 DX machine I now use. In tracking and other  
control experiments, I like to sample the handle position (the  
subject's behavior) at least 30 times per second and preferably  
60 or more, and this cycle time has to include erasing and  
regenerating the display in real time, as well as all  
computations that are used to relate the handle action to what  
happens on the screen. The display and sampling rates have to be  
synchronized with the frame rate of the screen. On multitasking  
systems like the the Macintosh, the Amiga, or a Unix system, it's  
pretty hard to make sure that the samples and display refreshes  
actually occur at uniform intervals of real time synchronized  
with the display rate. I had an Amiga for a while, and discovered  
that the sampling rate depended on whether the mouse was moving,  
and on how fast it moved -- all those interrupts and the enormous  
overhead of multitasking screwed up quantitative data-taking. I  
sold it and went back to PCs. On a Unix machine where you're  
sharing the CPU with other users, I should think this problem  
would be even worse. It's even bad on a Macintosh with only one  
user.

Also, I'm in the same boat as you: I'm not an advanced  
programmer, so the friendly environment of Borland C 2.0 is  
perfect for me. Compile and run, or pop back into the editor with  
the cursor on the error. I can't imagine going back to the  
command-line mode. What is that GNU C program like to use? Do you  
have to use a separate editor? I suppose I should try it before I  
get others involved too deeply in Turbo C. Martin Taylor: is that  
offer still good?

I'm avoiding going into OOPS, because it's really not structured  
right for control theory. Associating objects with operations  
means that a given control system, which is a series of  
operations on variables, gets tied to specific objects in the  
environment instead of being applicable to any objects it senses  
and acts upon. So if a hand is used to lift a glass, that's a  
different "object" from the same hand lifting a pencil or a book.  
I looked into OOPS with Turbo Pascal 5.5, but didn't get turned  
on by it. Don't really know a lot about it, though. Also, the  
object code from C++, I have heard from authorities, is  
considerably slower than vanilla C.

I tried Forth, too, and it is fun to write but hard to keep track  
of (at least the way I write it). I think it appeals most to  
natural mathematicians who have no difficulty remembering what  
complex operations symbols stand for. That's not me. Also, Forth  
was really optimized for a PDP11 -- it's not all that fast on a  
PC.

I think that if we write our programs in Turbo C 2.0, we should  
be compatible with ANSI machines except for some library  
routines, like the graphics, and DOS-specific commands like  
interrupts, sound, time functions, etc. Come to think of it, the  
list grows -- it could be a pain.

Do you want me to send you some source code to see how hard it is  
to port to your machine? The surest way to get \_really\_ hooked on  
PCT is to do some experiments and see how well the models fit the  
data!

BTW, when I don't answer some comments, it's not necessarily  
because I don't find them interesting. I often can't think of  
anything to add that's worth saying. As Dag says, "No comment, no  
error" (hardly).

> **···**
>
> ---------------------------------------------------------------  
> Mark Olson (940201.1752) --
> 
> Mark, you're talking about model-based control, an elaboration of  
> controlling imagined perceptions. This may be appropriate for  
> some of the higher levels of control. The problem at lower levels  
> is updating the model rapidly enough to handle real-time  
> disturbances (which the model can't anticipate). I haven't yet  
> seen any demos of this type of control, and haven't tried any  
> myself.  
> ---------------------------------------------------------------  
> Best to all,
> 
> Bill P.

---

<div class="post-metadata">

**Author:** ![Bill\_Leach1](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/b/848f3c/32.png) [@Bill\_Leach1](http://discourse.iapct.org/u/Bill_Leach1)\
**Post date:** [February 3, 1994, 2:10am UTC](http://discourse.iapct.org/t/c-programming-model-based-control/2039/2 "1994-02-03T02:10:36Z")

</div>

\<Bill Leach 02 Feb 1994 18:58:40

> [From Bill Powers (940202.0915 MST)]

RE: Programming

> One reason I prefer...

I wonder, did you have access to some sharp Amiga programmers? For the  
sort of thing that I am imagining a really detailed knowledge of how to  
program the machine would make a world of difference. Indeed, you can  
stop ALL activity on the machine but that which you want to have occur  
(except for bus faults of course).

Properly programmed, the machine can be absolutely consistent for  
graphics displays regardless of image delta complexity (for example).

I gather that these programs involve "user" or "test subject"  
interactions?

Unix, I can take a machine to "single user state" if necessary but  
suspect that it would be pointless when a different platform is available  
(I prefer programming on the Amiga anyway).

> ...C++... heard from authorities, is considerably slower than vanilla C.

That is VERY compiler dependent and somewhat programmer dependent. C++  
written in Comeau for example quite often runs faster than the same  
program written in C. -- Now before some "hot shot" jumps down my throat  
saying "That's impossible"... Yes, if the programmer wrote the same code  
that the C++ processor created then of course it's impossible. However,  
the programmer won't write the same code. Switching to the object  
oriented methodology often results in faster running code IF a good  
compiler is used.

> I tried Forth, too, ...

I love Forth. Of course I about fall all over myself trying to write  
stuff in Forth but I still like the language. I am definately NOT a  
mathematician! I have a Forth Compiler on this machine and its resulting  
code usually rivals C code. Of course the 68K's are much like the PDP's.

> ANSI

Well then, that would depend a lot on how the code was written. If the  
machine dependent stuff is identified well and sufficient remarks to  
indicate what the machine function is supposed to do (and maybe a little  
of how), porting shouldn't be a killer.

> Do you want me to send you some source code to see how hard it is...

Sure, though I best point out that it might take me awhile before I could  
get to it. I think I will soon start feeling about like I think Martin  
must be feeling. 🙂

> BTW, when I don't answer some comments, ...

Not a problem. I personally am quite pleased and impressed with the  
response from the participants in this list and recognize that not  
everyone can or even necessarily should comment on every message.

> As Dag says, "No comment, no error" (hardly).

For programmers, shouldn't that be:  
"No comment, no error. NOT"

-bill