Re: Lahman, how ya doing?

Responding to Hansen...

What you seem to be describing in the same scenario is 7, 14, 28..., and that third iteration would be processed with a time parameter of 7 ticks rather than 14.

What I am saying is that I wouldn't pass a time parameter at all. I would try to compensate for the skips using something intrinsic to the processing. That is, one addresses the root effect of the skip.

For example, suppose the thing that will skip every 420 ticks is a temperature sample scheduled for each single tick. The statistic computation on the 60th tick will then be computing on 59 samples rather than 60 whenever a skip occurred and that would affect the standard deviation. So the easy way to deal with that is for Thermometer to record an actual sample count which is incremented when a sample is taken, regardless of what tick it is in. Then the standard deviation is correctly computed and the sample count is cleared.

The reason I prefer that is because the compensation is mapped into the semantics of the Thermometer processing. Thermometer doesn't need to understand why it has only 59 samples rather than 60. It just needs to do the right thing with 59 samples. Thermometer is providing a count that is equivalent to the tick count but it is in terms of Thermometer's semantics, not Timer's.


An average and a standard deviation can easily be calculated with 59 samples rather than 60. But some of what I want to do involves time-dependent evolution, like to calculate a change in temperature, or to calculate a control action. You can't just skip a tick and do an average. If you're reading an input f(t) and the number you want is

  (f(7) - f(0)) / 7

and you calculate

  (f(8) - f(0)) / 7

That is Just Plain Wrong.  If a tick is skipped there you must calculate

  (f(8) - f(0)) / 8

It's not quite on schedule, but at least it's a slope. The former isn't a slope, it isn't anything. It's just wrong.

OK. But you said one of the statistics you were computing was a standard deviation. This is something different. I was looking at the standard deviation problem. (I can see computing a mean from endpoints on a slope if one assumes linearity, but in that case standard deviation probably isn't very useful.)

If you do have to compute a slope then the problem semantics will require an absolute time to be recorded somehow. Then it is fair for the notion of a hardware Sample to include both the value sampled and the timestamp (whatever form it is). Then you will still have the correct semantics _in the object itself_ to do the calculation without worry about skips per se.

The way I would probably handle that (given the single tick sample is skipped) is to delegate the sampling in Thermometer to a Sampler object:

              1      uses 1
[Thermometer] ------------- [Sampler]
      | 1
      | used by
      |
      | deletes
      | *
  [Sample]
  + hardwareValue
  + tickCount

The delegation is to allow Thermometer and Sampler to run in different threads where Sampler's is slower. When Thermometer gets a 1-tick event it increments an internal tick count and sends an event to Sampler that will poll the hardware, create a Sample instance, and send back an event to Thermometer with the instance handle. Thermometer responds by adding the Sample instance to its collection and assigning the current value of its internal tick count. Meanwhile, if Thermometer receives another 1-tick event while Sampler is doing its thing, the internal tick count will be properly incremented for the skip. So the state machine for [Thermometer] might look like:

                           [Sample Created] --------+
                           increment sample count   |
                           add to sample collection |
                           assign tick count to     |
                             sample                 |
                               ^                    |
+-------------------------+    |                    |
|      E1:single tick     |    | E3:sampled         |
|                         V    |                    |
+--------------- [Single Tick Done] <---------------+
                 increment tick count     E1:single tick
                 send E4:get sample
                    to Sampler
                    |          ^
                    |          |
       E2:60th tick |          | E1:single tick
                    |          |
                    V          |
                 [Statistics Computed]
                   compute slope
                   compute std dev
                   clear tick count
                   clear sample count

This allows Thermometer, in the high priority thread, to keep track of the actual tick counts between samples. Since those represent the true schedule (i.e., emulated real time) everything Just Works (as long as each action in the state machine can complete within one tick).

[Unless you have some more requirements you want to toss out.  B-)]

I have read a warning against trying too hard to create a theoretically ideal program at the expense of a simpler implementation. I think it was in that UML/OOD book I have. The author has seen much time spent and complication created by programmers trying harder than they should to do things the "proper" way.

But I suppose, like a great author breaking grammar rules, you should first know what the rules are.

Exactly. Alas, one of the problems I have with a lot of methodology books is that they present the methodology in Sermon On The Mount mode and don't provide a lot of explanation about /why/ the methodology wants things done a certain way. That makes it tough to use proper judgment when an exception is really needed.

A classic example is Normal Form in UML Class Diagrams. Every OOA/D book provides a bunch of guidelines and techniques for normalizing a Class Diagram. But usually they will only mention NF in passing or in an appendix -- if they mention it at all! I guess they don't want to confuse their audience with formal set theory definitions. 


You mean set theory is good for something?

Well, I know the mathematicians like it. But as a physicist I've never seen it used except in defining a theorem, e.g. "n is an integer". That's sort of set theory.

Tough to do software without it. Virtually everything in computing above Turing machines is based on it. RDBs are just the tip of the iceberg. I know of abstract action languages for OOA models that are so set-oriented that they do not even have a construct for element-by-element iteration (e.g., for/while loops).

As a result, though, a lot of experienced OO developers today don't even realize that when they apply those guidelines they are normalizing the model. If they don't understand how object identity and NF are related, how are they supposed to make close decisions?


Have you seen Dirac's bra-ket notation used? It's typically used in quantum mechanics, which makes heavy use of linear algebra. This <a| is a bra, this |a> is a ket, <a| is the dual to |a> in the sense of contravariant versus covariant vectors. <a|b> is the overlap, inner product, or "dot product" between a and b, (a,b) or (a_i)(b^j). An operator acting on a vector like U_ij a_j is represented as U|a>, you can form a scalar by <b|U|a> = <b|(U|a>) = ((Ub)^\dag |a>, change representations by |a> = \sum_i |i><i|a>, and so on. It's like matching dominoes. You don't need to know everything it represents, just get the pointed ends facing the right directions.

Alas, I am not familiar with it. My math focused on OR stuff -- linear programming, regression, monte carlo, etc. -- long, long ago.

Are there any candidate 4GLs?

Now that UML has defined a semantic meta model for abstract action languages, UML itelf is a bona fide 4GL. Actually, UML has just standardized one. The technology for 4GL execution models has been around since the '80s and there are several tools on the market that support such 4GLs. (Pathfinder is one such vendor.) Once OMG standardized UML and the action semantics, all the existing vendors dropped their proprietary notations and jumped on the UML bandwagon.

It took nearly two decades to evolve decent optimization because one faces a much larger scope than a 3GL compiler does. But the technology has been stable since the late '90s. A couple of years ago Ivar Jacobson gave a conference keynote address where he predicted that in a decade writing 3GL code would be as rare as writing Assembly today. I don't think it will happen quite that quickly, but I am as sure as he is that it is inevitable.


Sometimes ideas are ahead of their time, like Raskin's thesis in 1969(?) which formed the guideline for the Macintosh interface in 1984, although even in 1984 the technology was barely up to the job. And sometimes all it takes is the Next Great Idea and a lot of work, but on the same technology we've had for a decade.

Right. Realizing that the computing space is deterministic (in no small part due to set theory!) and, therefore, fully automatable is one thing. It is quite another to overcome the engineering problems to make that insight useful.

OTOH, sometimes they get it right the first time. Smalltalk was the first true OO language (Scheme notwithstanding). Yet Kay & Co. got it pretty much right the first time -- despite the fact that OOA/D theory didn't mature for another two decades. And contrast it with technical disasters like C++ that followed.


I've mused about our ability to abstract things with flowcharts, block diagrams, programming philosophies, and so on. I thought it might make a good basis for a science fiction story that compares puny human minds to the intelletual powerhouses of some alien species. Except the aliens don't have the abstraction tools, which turns out to be a critical flaw. I had no story to go with it, so that didn't go anywhere. But despite taunts that REAL men program with toggle switches, it would be interesting to see what new tools make possible.

That seems like a chicken-or-egg thing. How does one become an intellectual powerhouse without the ability to deal with abstract concepts? Once one can deal with abstract notions it is a pretty small step to creating them and/or gluing them together.

[OTOH, I suppose one can argue that chess programs that beat Grand Masters are brute force computation rather than dealing with abstractions like Position and Initiative. But somebody had to build the computer and the program and I don't see that happening without manipulating abstract concepts.]

I think I'm starting to wind down on this. 

OK.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Lahman, how ya doing?
    ... But some of what I want to do involves time-dependent evolution, like to calculate a change in temperature, or to calculate a control action. ... You can't just skip a tick and do an average. ... but at least it's a slope. ... The Thermometer state machine was essentially the same as the one I originally proposed a few messages ago; it just no longer did the actual hardware sample and now counted ticks. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... You can't just skip a tick and do an average. ... >> It's not quite on schedule, but at least it's a slope. ... float temperature; ... The thermometer records ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... If the thermometer in the real system doesn't have an event ID, the user shouldn't have to include an event ID when he instantiates a thermometer. ... The user might parameterize the processing (e.g., defining the number of samples to use for computing basic Thermometer statistics), but that mapping to simulation ticks is a pure software design issue. ... My implentation tests for current_time>=next_time so that the skipped event would be generated one tick late instead of ten, and it tracks last_time so that the actual interval current_time-last_time can be passed rather than an assumed nominal interval. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... >> Well, in the real controller, when the processing is delayed, it's resumed ... >temperature sample scheduled for each single tick. ... >A classic example is Normal Form in UML Class Diagrams. ... >confuse their audience with formal set theory definitions. ...
    (comp.object)