# HG changeset patch
# User Razvan Pascanu <r.pascanu@gmail.com>
# Date 1289846965 18000
# Node ID ad53f73020c2d107c87e1d7b7669e1855ccfec2c
# Parent  9474fb4ad10978b09ca6c533b34c4988c2219984
Answered Yoshua's question

diff -r 9474fb4ad109 -r ad53f73020c2 doc/v2_planning/datalearn.txt
--- a/doc/v2_planning/datalearn.txt	Mon Nov 15 11:51:33 2010 -0500
+++ b/doc/v2_planning/datalearn.txt	Mon Nov 15 13:49:25 2010 -0500
@@ -413,6 +413,30 @@
 are possibly constant (e.g. holding some hyper-parameters constant 
 for a while)?
 
+RP answers: If we opt for this lazy compilation mechanism, the library needs
+to know what to put into a shared, and what to expect as input. The
+programmer should give hints to the library by saying this value will always
+be constant, or this is a hyper-parameter that I might want to change, and
+when I do that I don't want to recompile everything so put it as an
+argument. Even when the compilation is done by the user, it would be helpful 
+to have some function that collects all the parameters for you. What I mean
+is that it would be nice to write something like 
+
+  corruption_layer_1 = Parameter ( value = 0.1, name = 'c1')
+  # Followed by  (many) lines of code 
+  f = function ( results.inputs()+ results.hyper-params(), result )
+
+
+where results.hyper-params parses the graph, collects the hyper-parameter 
+and returns them as a list of theano.Variables wrappen in theano.In with 
+a default value and a name. You could call the function either as 
+
+    f()
+or 
+    f(c1 = 0.2)
+
+
+
 Discussion: Helper Functions
 ----------------------------