One person wrote me privately with these questions, but I thought that I
would answer them publicly:

> (1) What is the expected duration of the lectures?

My guess is that each lecture will be between 30 to 45 minutes in length.


>  (2) What time of day will the lecture be available on the days it is to
>  be delivered?

I hadn't given that any thought yet, but I would say noon, Mountain Time,
would be highly likely.


>  (3) Would you consider a day other than Friday for the second weekly
>  lecture, perhaps Thursday, for the benefit of those who might have other
>  plans for the weekend?

I chose Mondays and Fridays because I suspect that it will take me a day to
prepare each lecture. This schedule gives me the weekend to prepare Monday's
lecture and three workdays (which are inherently much busier) to get Friday's
together.

However, you don't have to watch the lectures on the day that they're given.
They can be viewed at any time, although best done of course in order.

I expect questions and corrections from the group, sent to me by email. It is
my intention to try to incorporate as many of those questions into each
succeeding lecture as possible.


>  Although I took a (mandatory) class in automata theory some 30 years
>  ago, the only thing I remember about it was the professor's apologies
>  for the fact that it had no practical application.  I suspect that
>  failure to connect theory to something useful reflected a lack of
>  understanding on the part of the professor, rather than the state of
>  automata theory in the early 70's.  That's why your approach to the
>  subject intrigues me.

Yes, that was more the professor than anything else. I've been designing
finite state automata for 30 years now. In fact, everything we've ever built here
has been a finite state automaton, including QCTerm and -- as odd as it may
sound -- synchronous, finite-state analog computational systems.

When you design a system, you design its behavior. Its innards are basically
irrelevant. They can be constructed in software or hardware. From the outside
of the box, ideally you should never be able to tell the difference between
well-designed systems.

As I've mentioned before, philosophy matters greatly. If you design systems
properly, and I will advocate finite state automata theory as the proper design
approach, you can build extremely complexly behaving systems very quickly and
very simply, so that they are not only exceptionally reliable but resilient
and robust as well.

Much of the material in the class everyone knows by either intuition or
through experience, but it's always good to discuss such ideas in a more formal
manner. The ideas are not complicated, but like all really pretty ideas, they
will reside in background as you proceed about your own work.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *