changeset 1259:6f76ecef869e

a few changes
author Razvan Pascanu <r.pascanu@gmail.com>
date Fri, 24 Sep 2010 14:10:05 -0400
parents c88db30f4e08
children a565c20a39d7
files doc/v2_planning/plugin_RP_GD.py
diffstat 1 files changed, 15 insertions(+), 2 deletions(-) [+]
line wrap: on
line diff
--- 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()