Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #560 > unrolled thread

Related containers

Back to article view | Back to comp.lang.java.help

Contents

  Related containers Rob McDonald <rob.a.mcdonald@gmail.com> - 2011-04-06 10:58 -0700
    Re: Related containers markspace <-@.> - 2011-04-06 11:44 -0700
    Re: Related containers Roedy Green <see_website@mindprod.com.invalid> - 2011-04-06 12:50 -0700

#560 — Related containers

Thanks everyone for the answers and help given in the other thread I
started -- I found a couple of solutions to my problem and they make
sense now.

Unfortunately, that progress got me up to another problem -- which I
believe to be an underlying design issue.  So, this time, I'll ask for
suggestions for how to design the problem on a larger scale.

I have a class (Task) which defines a name and a set of inputs and
outputs.  It is analogous to an interface

class Task{
  String name;
  int nIn, nOut;
  ArrayList<String> inputs;
  ArrayList<String> outputs;
  // various getters and setters.
}

There can be groups of tasks, which can be treated as a task itself.
Since the outputs of one task can provide the inputs for another, the
group inputs are the task inputs which never are outputs of another
task.  The group outputs are simply the combined outputs of all tasks.

class GroupTask extends Task{
  ArrayList<Task> subtasks;
  int nTask, nBack;
  ArrayList<String> feedback;
  // add & remove task
  // re-order tasks to minimize/eliminate feedback
  // compile group input and output list for given subtask list.
  // identify feedback variables (build feedback list)
}

These two classes can be used to create useful programs in their own
right.  For example, a set of Tasks can be created, manipulated,
reordered, etc.  The GroupTask can contain subtasks - or subgroups.
Visualization of these tasks can be performed as a DAG.  So far,
everything works great.

Next, I would like to put an actual equation behind the implied input/
output relationship of a task.

interface IFunction{
  void setInVals(double[] inVals);
  double[] getOutVals();
  double[][] getJacobian();
  void evaluate();
}

class TaskFunc extends Task, implements IFunction{
  double[] inVals, outVals;
  double[][] jacob;
  // Implement getters/setters and evaluate();
}

Here, evaluate() does whatever it takes to calculate outVals from a
set of inVals.  It could simply be a polynomial, or it could be
something quite complex.  It also calculates the Jacobian of the
system, the first derivatives of all the outputs with respect to all
of the inputs.  Depending on what you're doing, they can be
analytical, or possibly finite difference derivatives.

Now, as you might have guessed, I would like to be able to work with a
group of TaskFunc's such that I can numerically evaluate the coupled
system behavior.

class System extends GroupTask, implements IFunction{
  double[] inVals, outVals;
  double[][] jacob;
  // Implement getters/setters
  // Implement evaluate() as Newton's method for solving coupled
systems of equations.
  // Also calculate system sensitivity matrix as Jacobian of coupled
system.
}

In order to implement System.execute(), I need to access all of the
contained Tasks as TaskFunc's.  Unfortunately, GroupTask doesn't
contain TaskFunc's, it only contains Tasks.  I could just force it
with a bunch of casts, but that gets ugly quickly.

I had pursued a solution where GroupTask was a simple implementation
of an abstract AGroupTask.  All of the complicated bits of re-ordering
tasks, visualization, etc. were handled by AGroupTask.  Just the
container and add/remove type functions are implemented in GroupTask
-- matching abstract stubs specified in AGroupTask.

In that approach, System would also implement AGroupTask, using a
container of TaskFunc's.  I planned on handling the casting in the
getters/setters.  Separate (unique name) getters would be used to do
things like getFunc(i) vs. getTask(i).  They access the same data in
the same containers, but they cast the result differently.

Unfortunately, this was getting very messy very quickly.  I hope I've
laid out enough to express the core of the challenge.

Is there a design pattern which relates to this situation?  Is there a
suggested or canonical solution?

Thanks in advance,

Rob

[toc] | [next] | [standalone]

#561

On 4/6/2011 10:58 AM, Rob McDonald wrote:

> Is there a design pattern which relates to this situation?  Is there a
> suggested or canonical solution?


I'm not sure what you are doing, but it seems you want to execute a 
hierarchy of things.  That sounds like an Interpreter:

http://en.wikipedia.org/wiki/Interpreter_pattern

Here, your Task would be a TerminalExpression, and your GroupTask would 
be a NonTerminalExpression.  Otherwise, the Interpreter pattern seems 
much simpler.  It's at least worth a look.

[toc] | [prev] | [next] | [standalone]

#563

On Wed, 6 Apr 2011 10:58:18 -0700 (PDT), Rob McDonald
<rob.a.mcdonald@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>Thanks everyone for the answers and help given in the other thread I
>started -- I found a couple of solutions to my problem and they make
>sense now.

You might have a look at my Filters package.  It has ways of combining
atomic filters into combined filters.

see http://mindprod.com/products1.html#FILTER
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Doing what the user expects with respect to navigation is absurdly important for user satisfaction.
~ anonymous Google Android developer

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.help

csiph-web