# HG changeset patch # User Yoshua Bengio # Date 1284499345 14400 # Node ID 81ea57c6716d55a52fce8462fba5c0709abbab4c # Parent 8cc324f388baa21cc5bf3ad363401a70a4e334e3 clarification to plugin.txt diff -r 8cc324f388ba -r 81ea57c6716d doc/v2_planning/plugin.txt --- a/doc/v2_planning/plugin.txt Tue Sep 14 16:01:32 2010 -0400 +++ b/doc/v2_planning/plugin.txt Tue Sep 14 17:22:25 2010 -0400 @@ -20,15 +20,16 @@ The schedule is some function that takes two "times", t1 and t2, and returns True if the plugin should be run in-between these times. The -reason why we check a time range [t1, t2] rather than some discrete -time t is that we do not necessarily want to schedule plugins on -iteration numbers. For instance, we could want to run a plugin every -second, or every minute, and then [t1, t2] would be the start time and -end time of the last iteration - and then we run the plugin whenever a -new second started in that range (but still on training iteration -boundaries). Alternatively, we could want to run a plugin every n -examples seen - but if we use mini-batches, the nth example might be -square in the middle of a batch. +indices refer to a "timeline" unit described below (e.g. "real time" or +"iterations"). The reason why we check a time range [t1, t2] rather than +some discrete time t is that we do not necessarily want to schedule plugins +on iteration numbers. For instance, we could want to run a plugin every +second, or every minute, and then [t1, t2] would be the start time and end +time of the last iteration - and then we run the plugin whenever a new +second started in that range (but still on training iteration +boundaries). Alternatively, we could want to run a plugin every n examples +seen - but if we use mini-batches, the nth example might be square in the +middle of a batch. I've implemented a somewhat elaborate schedule system. `each(10)` produces a schedule that returns true whenever a multiple of 10 is in