Hi everyone, I'm in the process of writing a very basic node for mdp that basically wraps the tutorial mdp.Flow of [SFANode, QuadraticExpansionNode, SFANode]. I wrote a plain node that inherits from mdp.Node, stores an internal self._flow and relays all calls for train() and execute() to that self._flow. It's straightforward and seems to work. My question is: What other options are there and is there something I'm missing? I'm asking because the mdp.FlowNode is basically the same thing but contains a LOT more checks and balances and behaves differently. An mdp.Flow can be trained in one go and consequently my new node can as well. However, mdp.FlowNode, pre- sumably implementing the same functionality, requires multiple calls to both train() and stop_training(). My first version inherited from mdp.FlowNode - as that already produces a node designed to handle an mdp.Flow - but I didn't see any benefit from the way training is handled there.. and I don't quite under- stand why an mdp.Flow is trained with a single call while the mdp.FlowNode needs several calls to train the same thing..? Since the mdp.FlowNode seems more cumbersome to use I'm not quite sure I under- stand what it should be used for? I know it's a building block for the hinet module and allows to insert an mdp.Flow within another mdp.Flow and/or hinet architecture, but a very simple node wrapping an mpd.Flow seemingly can do the same and only requires a single call to train. So my follow up questions would be: (a) What is the intended use for the mdp.FlowNode? (b) What can the mdp.FlowNode do that a simple wrapper node managing an mdp.flow instance cannot? (c) If the explicit training of the multiple nodes within an mdp.FlowNode holds some advantage then why is an mdp.Flow trained in one go? The main difference that I can see is that all nodes within an mdp.Flow, during training, are trained with the same data. In the mdp.FlowNode, this may differ. I'm not sure what the advantage is though? It also seems strange that mdp.Node and mdp.Flow behave the same during training, while the mdp.FlowNode, which is designed to allow users to handle an mdp.Flow like an mdp.Node does NOT behave like mdp.Node during training. Am confused. Please help. Cheers, Fabian
Hi Fabian,
On Thu 23 Mar, 17:15, Fabian Schoenfeld
I wrote a plain node that inherits from mdp.Node, stores an internal self._flow and relays all calls for train() and execute() to that self._flow. It's straightforward and seems to work.
I'm asking because the mdp.FlowNode is basically the same thing but contains a LOT more checks and balances and behaves differently. An mdp.Flow can be trained in one go and consequently my new node can as well. However, mdp.FlowNode, pre- sumably implementing the same functionality, requires multiple calls to both train() and stop_training().
The difference is that you train your node passing, presumably, an array to the train method. A Flow additionaly supports iterables for training. You could read this section of the tutorial to get a bit more detail: http://mdp-toolkit.sourceforge.net/tutorial/iterables.html It should clarify why in general Node and Flow behave differently. Note that a Node can have multiple training phases, and each of the phases must be stopped by calling stop_training. FlowNode takes care of all this complexity, so yes, if you have three nodes that can be trained within the FlowNode, you'll have to call train/stop_training three times. Your FlowNode is effectively a Node with three training phases. If it weren't like that, how would the FlowNode otherwise know that you are finished training one of the internal nodes? My guess is that you are training your node/flow chimera by sending a single array. In this case your trick of passing the arguments directly to the self._flow.train method works. As soon as you start using iterables you'll get problems, because the training phase of the first subnode will be already closed when you try to pass the second batch of the training data… Is the situation now a bit more clear? If not, ask again: it has been a long time I used MDP, so I too need a refresh ;-) Ciao, Tiziano
Hi Fabian,
have you seen the current pull request from Varun? He has already
implemented a similar HSFA node.
Apart from that I agree with Tiziano. I would also carefuly think
about the tradeoffs between a specialized solution and a general
solution like FlowNode.
Personally I simply used FlowNode for all of my HSFA work, and used a
factory function for the creation of the HSFA flow node. I didn't see
any need for a specialized node.
Cheers,
Niko
On Fri, Mar 24, 2017 at 8:03 AM, Tiziano Zito
Hi Fabian,
On Thu 23 Mar, 17:15, Fabian Schoenfeld
wrote: I wrote a plain node that inherits from mdp.Node, stores an internal self._flow and relays all calls for train() and execute() to that self._flow. It's straightforward and seems to work.
I'm asking because the mdp.FlowNode is basically the same thing but contains a LOT more checks and balances and behaves differently. An mdp.Flow can be trained in one go and consequently my new node can as well. However, mdp.FlowNode, pre- sumably implementing the same functionality, requires multiple calls to both train() and stop_training().
The difference is that you train your node passing, presumably, an array to the train method. A Flow additionaly supports iterables for training. You could read this section of the tutorial to get a bit more detail: http://mdp-toolkit.sourceforge.net/tutorial/iterables.html
It should clarify why in general Node and Flow behave differently. Note that a Node can have multiple training phases, and each of the phases must be stopped by calling stop_training. FlowNode takes care of all this complexity, so yes, if you have three nodes that can be trained within the FlowNode, you'll have to call train/stop_training three times. Your FlowNode is effectively a Node with three training phases. If it weren't like that, how would the FlowNode otherwise know that you are finished training one of the internal nodes?
My guess is that you are training your node/flow chimera by sending a single array. In this case your trick of passing the arguments directly to the self._flow.train method works. As soon as you start using iterables you'll get problems, because the training phase of the first subnode will be already closed when you try to pass the second batch of the training data…
Is the situation now a bit more clear? If not, ask again: it has been a long time I used MDP, so I too need a refresh ;-)
Ciao, Tiziano
_______________________________________________ mdp-toolkit mailing list mdp-toolkit@python.org https://mail.python.org/mm3/mailman3/lists/mdp-toolkit.python.org/
participants (3)
-
Fabian Schoenfeld
-
Niko Wilbert
-
Tiziano Zito