moved module documentation around, added tensor_wrapper so that constants in…

doc/advanced/module.txt

@@ -5,8 +5,72 @@
 Module Interface
 ================
 
-WRITEME
+Functions in theano can share containers, when the `value` argument to `In` is a Container
+instance.  This feature makes it possible for multiple functions to use (and update) the same
+inputs.
+Module is a class in Theano that exists to facilitate the compilation of
+multiple Functions that work on (and update) overlapping sets of input
+Variables.
+
+Modules provide a more intuitive syntax that makes this feature easier to use.  
+They draw on the metaphor of a python import--a module has functions and variables, and
+can contain other modules.  All functions have access to all variables, and whenever any
+function modifies a file-level variable, then that change is visible to all other functions.
+
+In the Module system, the analog of the file is the `Module`, the analog of the function is the
+`Method`, and the analog of the variable is the `Member`.  Module, Member, and Method all work
+at the symbolic level.  Once a graph of Modules, Members, and Methods is ready for use, it must
+be compiled with a call to `make` which will return an isomorphic structure in which Modules
+have become `ModuleInstances`, Members have become `Container`s, and Methods have become
+`Function`s.
+This structure contains numbers and functions, and is ready for computation.
+
 
+Module Graph
+------------
+
+Components can be grouped into a directed graph.
+When we call `make`, this graph is replicated with ComponentInstances instead of
+Components.  Wheras Components are represent symbolic things (ie. Variables), ComponentInstances represent non-symbolic ones (ie. sparse matrices, ndarrays, callable functions).
+
+
+.. index::
+   single: Component
+   single: component; Component
+
+.. _component:
+---------
+Component
+---------
+
+All of the elements of what is called the "module system" or "modules" are
+components.
+
+A component subclass is represents a symbolic theano thing, and implements the
+``build`` function. 
+The ``build`` function is responsible for converting the symbolic thing into a
+non-symbolic thing.
+
+
+Compiling with make
+-------------------
+Conversion from a Component graph to a ComponentInstance graph is performed by `Component.make`.
+This method traverses the Component graph in multiple passes. 
+
+In the first pass (the allocate pass), it creates storage for all Variables that are contained in the graph (see
+`Component.allocate`).  These are the module variables.
+
+In the second pass (the build pass), it creates functions that (in general) operate on these module variables.
+This pass also serves to construct all ComponentInstance-derived instances as well, such as
+`ModuleInstance`s.  The objects that are returned from this second pass are the return value of
+`Component.make`.
+
+In the third pass (the initialize pass), is optional and not necessarily recursive through the
+graph.
+The purpose of the third pass is to call the initialize method of the ComponentInstances built
+during the second pass.
+During this pass the ComponentInstance graph is complete. It is a good time to fill storage
+allocated in phase 1 with sensible values.
 
 .. index::
    single: External

theano/compile/module.py

 """Classes implementing Theano's Module system.
 
-Rationale
-=========
-
-Functions in theano can share containers, when the `value` argument to `In` is a Container
-instance.  This feature makes it possible for multiple functions to use (and update) the same
-inputs.
-
-Modules provide a more intuitive syntax that makes this feature easier to use.  
-They draw on the metaphor of a python import--a module has functions and variables, and
-can contain other modules.  All functions have access to all variables, and whenever any
-function modifies a file-level variable, then that change is visible to all other functions.
-
-In the Module system, the analog of the file is the `Module`, the analog of the function is the
-`Method`, and the analog of the variable is the `Member`.  Module, Member, and Method all work
-at the symbolic level.  Once a graph of Modules, Members, and Methods is ready for use, it must
-be compiled with a call to `make` which will return an isomorphic structure in which Modules
-have become `ModuleInstances`, Members have become `Container`s, and Methods have become
-`Function`s.
-This structure contains numbers and functions, and is ready for computation.
-
-
-Design Documentation
-====================
-
-Module Graph
-------------
-
-Components form a tree structure.  Each component may have a _parent_ to which it is _bound_.
-When we call `make`, this tree structure is replicated with ComponentInstances instead of
-Components.  Wheras Components are primarily symbolic, ComponentInstances are sparse matrices,
-ndarrays, callable functions, etc.
-
-Compilation via make
---------------------
-
-Conversion from a Component graph to a ComponentInstance graph is performed by `Component.make`.
-This method traverses the Component graph in two passes. 
-
-In the first pass (the allocate pass), it creates storage for all Variables that are contained in the graph (see
-`Component.allocate`).  These are the module variables.
-
-In the second pass (the build pass), it creates functions that (in general) operate on these module variables.
-This pass also serves to construct all ComponentInstance-derived instances as well, such as
-`ModuleInstance`s.  The objects that are returned from this second pass are the return value of
-`Component.make`.
-
-In the third pass (the initialize pass), is optional and not necessarily recursive through the
-graph.
-The purpose of the third pass is to call the initialize method of the ComponentInstances built
-during the second pass.
-During this pass the ComponentInstance graph is complete. It is a good time to fill storage
-allocated in phase 1 with sensible values.
-
-Class Structure
----------------
-
-The most important classes for the user API here are `Module`, `ModuleInstance`, and `Method`.  
-Several other classes are defined to factorize functionality.
-
-- `Component`: WRITEME: what properties make something a Component?
-
-- `_RComponent`: WRITEME: what properties make something a Component?
-
-- `External`: WRITEME: what properties hold? What 
-
-- `Member`: WRITEME: what properties hold? What do they do?
+For design notes, see doc/advanced/module.txt
 
 """
 

theano/compile/tests/test_module.py

@@ -502,6 +502,10 @@ class T_module(unittest.TestCase):
         self.assertRaises(NotImplementedError, c.set,"n",1)
 
 
+    def test_wrappable_as_tensor(self):
+        M = Module()
+        M.a = [1,2,3]
+        M.make()
 
 def test_multiple_references():
 

theano/tensor/basic.py

@@ -159,6 +159,15 @@ def constant(x, name=None, ndim=None):
 def value(x, name=None, ndim=None):
     return constant_or_value(x, rtype=TensorValue, name=name, ndim=ndim)
 
+def _obj_is_wrappable_as_tensor(x):
+    try:
+        constant(x)
+        return True
+    except TypeError:
+        return False
+def _wrap_tensor_into_member(x):
+    return compile.module.Member(constant(x))
+compile.module.register_wrapper(_obj_is_wrappable_as_tensor, _wrap_tensor_into_member)
 
 
 class TensorType(Type):
@@ -929,7 +938,8 @@ def argmax(x, axis=None):
 
 @constructor
 def min(x, axis=None):
-    if 'float'in str(x.dtype):
+    str_x_type = str(x.dtype)
+    if str_x_type.startswith('float') or str_x_type.startswith('int'):
         return -max(-x, axis=axis)
     else:
         #Be careful about unsigned integers, complex
@@ -937,7 +947,8 @@ def min(x, axis=None):
 
 @constructor
 def argmin(x, axis=None):
-    if 'float'in str(x.dtype):
+    str_x_type = str(x.dtype)
+    if str_x_type.startswith('float') or str_x_type.startswith('int'):
         return argmax(-x, axis=axis)
     else:
         #Be careful about unsigned integers, complex