Re: implementation dilema

Responding to Ma740988...

Assume a system with three cards. For discussion purposes we'll call
them A B and C. Assume data comes in from an external source to A & B.
A and B computes mean on data and transmits result to C. C performs a
sum on the mean of A and B and transmits _its_ (C's result) result to A
and B. A and B runs an _algorithm_ on the data utilizing the result
from C. A and B sends result from the algorithm to C. A, B and C play
this 'game' (i.e A and B does something send results to C, C does
something send result to A and B and so on ) for say 7 iterations.

Assume pictorially this is akin to:

A & B C
---------------------------------------------------------
mean mean
standard deviation standard deviation
algorithm_ab1 algorithm_c1
algorithm_ab2 algorithm_c2
algorithm_ab3 algorithm_c3
algorithm_ab4 algorithm_c4
algorithm_ab5 algorithm_c5


The question: I'm trying to design a class that'll capture the fact
that the mean and standard deviation are common to 'both' ( code on A
and B is generic, so both here is A/B and C). From there the
algorithms are different.. I'm not sure if I'm missing a design
pattern or .. what's a good way to architect this?
One other thing. Some of the algorithms on both sides is comprised of
FFTs. For instance ( algorithm_ab1/ab2/ab4 is comprised of an FFT,
similarily algorithm_c2/c3/c4 is comprised of an FFT).
Not sure how to put this together nicely to make maintenance easy.

I am concerned by the cohesion of A and B. They seem to be doing quite different things in the problem context. Statistics like mean and standard deviation are intrinsic properties of data collections. However, things like FFT algorithms are operations one performs /on/ data collections.

Another clue is the problem you are concerned with: A and B differ in the data, mean, and deviation but not in the behavior. If A and B are different classes, then one has a normalization problem because they both "own" the abN algorithms. So for your scheme to work A and B would have to be objects of the same class. That's not a big deal except that C looks very similar but it does need to be a different class because the cN algorithms are not the same as the abN algorithms.

This all suggests that the various flavors of FFT algorithms need to be delegated out. One way to do that would be a variation on the Gof Strategy pattern:

+------------------------------+
| R1 |
| | updated by
* | * currently eats 1 | 1
[Data] ------------------------ [FFT]
+ values R2 A
+ mean | R3
+ deviation +-------+--------+
| |
[abSeries] [cSeries]
A A
| R4 | R5
+-----+----+----+----+ ...
| | | | |
[1] [2] [3] [4] [5]

The idea here is that there are some number of instances of data collections (instances A, B, and C) that are modified by some set of FFT algorithms in a prescribed order. The order is captured in the relationships. That is, one dynamically instantiates R1 and R2 so that the FFT in the current step of the processing has the right inputs and outputs.

[My diagram is not quite correct because of space restrictions. Technically the multiplicities are different for the [abSeries] and [cSeries] FFTs. ab has two inputs and one output while c has one input and two outputs. But hopefully extending to cover that restriction is clear.]

Now your overall algorithm that deals with the iteration comes down to nothing more than instantiating the R1 and R2 relationships correctly and kicking off the FFT/mean/deviation computations. (That high-level algorithm would live in another object not shown here.) Note that this is pretty robust because you can add FFTs and data collections or even different combinations of inputs and outputs with only minor changes to the overall algorithm.


*************
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: implementation dilema
    ... standard deviation are intrinsic properties of data collections. ... things like FFT algorithms are operations one performs /on/ ... collections that are modified by some set of FFT ...
    (comp.object)
  • Re: FFT algoritms
    ... trying to infer, from the illustration, what the rhyme or reason there ... place algorithms without bit-reversal. ... if you compare a highly optimized in-order FFT like FFTW ... One reason to be cautious here is that O&S is comparing apples and ...
    (comp.dsp)
  • Re: dft : property of symmetry for real & even seq
    ... *begin rant* ... In the same section ("Other FFT algorithms") as the one where the ... What they are referring to is the fact that higher radices can reduce ... The discussion of the Winograd algorithms in NR is mostly garbled; ...
    (comp.dsp)
  • Re: (Execution Cycles) Timing Budget for TI eZdspf2812
    ... I am designing different algorithms on the DSP to work in real ... filter and FFT i can design to run in real time. ...
    (comp.dsp)
  • Re: dft : property of symmetry for real & even seq
    ... a few times slower than highly composite N). ... Bluestein FFT or Rader FFT). ... are many distinct FFT algorithms, in addition to the most well known ... (I've been repeatedly correcting the popular misconception that N log ...
    (comp.dsp)