Re: Lahman, how ya doing?

In article <Xyqhe.849$_f7.263@trndny01>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>Responding to Hansen...
>

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

I was actually thinking in the more general sense, but using this
particular problem for concrete examples, since it's the one I have
experience in and we've been discussing. As you've seen, sometimes I have
trouble translating the abstract into the concrete, so I needed a
particular ferinstance to center the discussion.

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

Not thinking of skips in particular, just in getting certain necessary
information into an object when an event triggers it. Hardware sample
includes both the value sampled and the timestamp. Let's see what I can
make of that with abbreviated fragments of code and big names.

Timer {
....
public:
float get_time();
};

Thermometer {
....
Timer* timer;
float temperature;
float sample_time;
public:
float get_temperature() {return temperature;}
float get_sample_time();
};

SlopeCalculator {
....
float previous_time;
float previous_temperature;
float slope;
Thermometer* therm;
public:
void calculate_slope() {
float temp = therm->get_temperature();
float t = therm->get_sample_time();
slope = (temp - previous_temperture) / (t - previous_time);
previous_temperature = temp;
previous_time = t;
}
float get_slope() {return slope;}
};

So in other words, the time is not sent to SlopeCalculator (or the
controller, or etc.) when an event is sent to it. The thermometer records
both the temperature and the time when a Get Sample event is sent to it.
When a Calculate Slope event is sent to SlopeCalculator, it receives both
the temperature and the time that the temperature was recorded from
Thermometer, not from Timer, and not passed in the event. I want to
assign the primary acquisition and storage of the time of a sample with
the thing that takes the sample, they're a matched pair. When something
uses the sample to calculate a slope, control action, filtering, etc., it
gets the time of sample from the same place that it got the value of the
sample.

And the event sent to SlopeCalculator is to Calculate Slope, not Calculate
Slope With This Time.

And when a tick is missed and control eventually gets to Thermometer to
sample the temperature, it will simply record the time it samples when it
samples.

Okay, let's see what you say.

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

Uh-oh. Just when I conclude that I don't have to stuff any
context-specific information into an event, you stuff an instance handle
into it.

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

Is this a reasonable alternative? Thinking specifically of a simulation,
the Sampler, representing the hardware interface to the lock-in, gets its
ticks reliably from a high priority queue. It always has a timely
temperature sample and time of sample, ready for whoever wants to read it.
Thermometer, representing the part of the digital world that records the
temperature for system use, the code that can be delayed, is on the low
priority queue. Its processing can be delayed, and Sampler can keep right
on sampling without it. But when Thermometer does receive a Get Sample
event, it gets whatever sample and time of sample that Sampler has at the
time. No instance handles in the events.

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

Oh, I'm sure I can foil or misinterpret any carefully crafted lesson you
can throw my way.

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

I've been somewhat intrigued ever since I'd seen the phrase "proof of
algorithm correctness" somewhere, and ever since I'd seen a CSCI student
with his graph theory textbook. I've been meaning to look into the formal
theory of algorithms, and even bought a textbook that I found at a
reasonable price. I didn't get very far in it before my attention turned
to what seemed like higher priority things, but I intend to return to it
when I have more leisure time.

Compound that with the recent onslaught of nice weather, and it's just
gotten pretty hard to spend much time with this stuff.
--
"Tell me, Dr. Einstein, at what time does Boston arrive at this train?"
.

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?
    ... 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?
    ... 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. ... A classic example is Normal Form in UML Class Diagrams. ...
    (comp.object)