# HG changeset patch
# User Razvan Pascanu <r.pascanu@gmail.com>
# Date 1285351805 14400
# Node ID 6f76ecef869e091bc59a4d063575bd61021009d5
# Parent  c88db30f4e0805f62ad28c2b65d75861bdc875b2
a few changes

diff -r c88db30f4e08 -r 6f76ecef869e doc/v2_planning/plugin_RP_GD.py
--- a/doc/v2_planning/plugin_RP_GD.py	Fri Sep 24 13:59:47 2010 -0400
+++ b/doc/v2_planning/plugin_RP_GD.py	Fri Sep 24 14:10:05 2010 -0400
@@ -9,7 +9,8 @@
 4. We have defined two basic types of events:
     4.1 scheduler events: these are emitted by the scheduler itself. For now we have defined:
         scheduler.begin() : sent at the very beginning of scheduler execution
-        scheduler.end()   : sent when the scheduler ends
+        scheduler.end()   : sent when the scheduler ends ( this makes sense since there is 
+                            at least from the user perspective a hierarchy of schedulars)
     4.2 plugin generate events: plugins act as iterators and generate 2 basic events,
         plugin.next() : sent of every "iteration". Each plugin is free to define what an
                         iteration actually means.
@@ -31,7 +32,7 @@
     that it would probably be included in the library somewhere.
     """
 
-    def __init__(self, name, next_count, end_count):
+    def __init__(self, name, end_count, next_count = 1):
         """
         :param name: name of the event we are counting (could be useful for debugging)
         :param next_count: number of iterations before triggering a "next" event
@@ -63,6 +64,18 @@
 
     The fixed_epoch_trainer meta-plugin takes care of training a given model, for a fixed
     number of epochs and then saving the resulting model.
+
+    Other arguments for having meta-plugin : 
+      * they can define a semantically separable block of code 
+      * they are what the library provides 99% of the code ( so you can define a certain 
+      template of connecting plugins as a meta-plugin and ship it without worry of things)
+      * they can be breaked apart by the main schedular ( so you would not have "different" 
+        schedulars running in the same time; is just one schedular, this way of constructing
+        things is just to improve understanding and intuitions of the syste
+      * they help pushing all the complexity over the backbone of the library ( i.e. the 
+        schedular ) 
+      * all plugins registered inside a hyper-plugin are active only when the hyper-plugin is 
+      active; In this sense they can help definining scopes ( as for variables ) - optional
     """
     # we start by defining our own private scheduler
     sched = Scheduler()