Re: Help on choosing a valid pattern: composite or not?
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Tue, 29 Nov 2005 16:55:47 GMT
Responding to CarmineM...
*** The (short) story ***
A while ago, I wrote a sort of toolkit to play with neural networks (back prop.).
Ah, a little context always helps. B-) Basically I agree with Kazakov so my comments below just provide a somewhat different spin...
*** The (rough) idea ***
Implement a toolkit that allows to: - Build "Nodes" with run-time pluggable behaviours that, given some numerical inputs, will produce one numerical output.
- Build "Nets" of such nodes that, given some numerical inputs, will produce one or more numerical outpus. "Nets" are partitioned in "Layers".
- Allow a "Net" to be a "Node" of another "Net" in such a way that the "Parent-Net" doesn't have to be aware of its subnets. It should treat them just as "Nodes".
All this structure is can be captured in relationships. Since a neural net is inherently hierarchical the GoF Composite pattern would work fine. Just make the substitutions for the GoF structure:
Component := Kazakov's "classifier". Composite := Net Leaf := Node
The tricky part is that the Node has pluggable behaviors. You could do that by tacking on a GoF Strategy or State pattern. That is, the "links" you proposed would just instantiate the relationship from a given Node to the right behavior role.
IOW, when one "walks" the net for training (assigning "links") or execution, it is the Composite's structure one navigates but the grunt work is done in the State/Strategy.
- Extend the "Net" so that it could be persisted to some sort of storage (just to make things a little more funny, let's say that the storage medium can be chosen via a plugin interface). (O/R Mapping tools to use and/or implement?!?)
Different problem. Figure out how to solve the neural net problem and then worry about how to store the nets. IOW, that's a job for another subsystem that is encapsulated by an interface that is designed for the neural net view. The subsystem then performs the transformation to whatever the persistence view of the data is (RDB, OODB, clay tablets, etc.).
- Extend the "Net" and the "Node" so that it could be graphically represented and manipulated.
That is just a matter ot "walking" the composite structure to add/remove nodes and instantiate/deinstantiate relationships.
Why I think it "could be interesting" to write from scratch?
- Practice with MVC (or its variation) to decouple the model (Net, Nodes, Subnets...) from its graphical representation.
I wouldn't dream of using MVC for this. B-( The CRUD/USER layered models are designed for pipeline applications between a UI and an RDB where the "business" layer doesn't really do anything except provide data integrity validation and an intermediate step stone for converting one view to the other. Your neural net's "business" layer is far too complex for that. IOW, the UI and DB are both peripheral to the real problem rather than dominant aspects of it.
[However, if there was a handy MVC infrastructure around to make talking to the UI or the RDB easier, I would not be averse to using it. B-)) But when doing so it would be encapsulated in UI and persistence access subsystems so that it was entirely transparent to the neural net solution.]
- Practice with what I've read in the GoF's Pattern book (Composites, Factories, Iterators, Strategies...)
Plenty of opportunity for that.
- Practice with Application layering (UI, Business, Storage...)
I suspect you will have multiple subsystems just for the neural net solution (e.g., the basic net configuration/navigation, training logic, and execution logic could be quite different subject matters). Throw in persistence, a UI, and a fancy graphics editor and application partitioning starts to get interesting. [I have a category devoted to this on my blog that may be of interest.]
- Try to find a spot where to insert some Dependency Injection ( a network needs a Log service and a Persistence service...)
- Use it to learn C# (and .NET framework) and Ruby
- Future plans: Nets (and subnets) can be remotable on LAN/WAN, can be wrapped in Web Services...
A variation on persistence access. One usually encapsulates the nuts & bolts of network access in a subsystem.
*** And now back to what I started writing in the original post ***
I came to the point of designing what the "Node" and the "Net" are ( yes, I've just stared bothering... :) ), and thought "Composite Pattern" could be of some help in unifying the interface from a client's point of view.
At its minimum the interface shared by "Node" and "Net" is:
- Execute . A "Net" can be told to execute itself, and that would mean to call each "Node"'s Execute . A "Node" can be told to execute itself, and that would mean to fetch its input and apply some calculation in order to produce its output.
I see this as a job for someone else who "walks" the neural net structure in a predefined order. Whenever they get to a Node, they invoke the relevant behavior(s) via the "links" to the Strategy/State. (It is in the nature of Strategy/State that the specific behavior is hidden from whoever is "walking" the net so every node is "executed" in exactly the same way.)
BTW, I would see training as a different mode of operation for the neural net. However, I suspect it can be expressed as a superset of execution. That is, the net is executed exactly the same way but someone else evaluates the results to modify the "links" between Node and Strategy/State.
- Add
. A "Node" can be added to a "Net", and that would mean to
become the destination of some other "Node"'s output, and/or
the input of another one (or one of the "Net"'s outputs...)
. A "Net" can be added to another "Net", and that would
mean to become one or more inputs of a "Node" and/or one
of the parent "Net" outputs.
Again, I think this is just relationship manipulation in the Composite.
- Remove
. A "Node" can be removed from a "Net", breaking all it's
forward and backward links to other "Net"'s elements.
I share Kazaov's skepticism on the implications of removal. But I haven't done a whole lot of neural net work. B-)
This means that "Node" and "Net" will contain other things aside of this shared interface.
E.g.: "Node" have some parameters that can be adjusted so that the
computing strategy can produce "better" outputs (whatever better means...)
I would leave that for the State/Strategy objects. As I envision it [Node] would just be a navigation placeholder for the execution.
************* 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
.
- Follow-Ups:
- Re: Help on choosing a valid pattern: composite or not?
- From: CarmineM
- Re: Help on choosing a valid pattern: composite or not?
- References:
- Help on choosing a valid pattern: composite or not?
- From: Carmine Moleti
- Re: Help on choosing a valid pattern: composite or not?
- From: CarmineM
- Help on choosing a valid pattern: composite or not?
- Prev by Date: Re: more dimensional method like a query...
- Next by Date: Re: more dimensional method like a query...
- Previous by thread: Re: Help on choosing a valid pattern: composite or not?
- Next by thread: Re: Help on choosing a valid pattern: composite or not?
- Index(es):
Relevant Pages
|
Loading