Whitespace fixes.

doc/extending/op.txt

@@ -318,10 +318,10 @@ is a :ref:`variable` we statically know the value of.
 
 Now the code works the way we want it to.
 
-.. note:: 
-   Most Theano Ops follow this convention of up-casting literal 
+.. note::
+   Most Theano Ops follow this convention of up-casting literal
    make_node arguments to Constants.
-   This makes typing expressions more natural.  If you do 
+   This makes typing expressions more natural.  If you do
    not want a constant somewhere in your graph, you have to pass a Variable
    (like ``double('x')`` here).
 
@@ -343,7 +343,7 @@ arithmetic operators:
    from theano import gof
 
    class BinaryDoubleOp(gof.Op):
-   
+
        def __init__(self, name, fn):
            self.name = name
            self.fn = fn
@@ -353,7 +353,7 @@ arithmetic operators:
 
        def __hash__(self):
            return hash(type(self)) ^ hash(self.name) ^ hash(self.fn)
-   
+
        def make_node(self, x, y):
            if isinstance(x, (int, float)):
                x = gof.Constant(double, x)
@@ -362,22 +362,22 @@ arithmetic operators:
            if x.type != double or y.type != double:
                raise TypeError('%s only works on doubles' % self.name)
            return gof.Apply(self, [x, y], [double()])
-   
+
        def perform(self, node, (x, y), (z, )):
            z[0] = self.fn(x, y)
 
        def __str__(self):
            return self.name
-   
+
    add = BinaryDoubleOp(name = 'add',
                         fn = lambda x, y: x + y)
-   
+
    sub = BinaryDoubleOp(name = 'sub',
                         fn = lambda x, y: x - y)
-   
+
    mul = BinaryDoubleOp(name = 'mul',
                         fn = lambda x, y: x * y)
-   
+
    div = BinaryDoubleOp(name = 'div',
                         fn = lambda x, y: x / y)
 

doc/nice_quotes.txt

@@ -2,7 +2,7 @@
 
 "Thank YOU for correcting it so quickly. I wish all packages I worked
 with would have such an active maintenance - this is as good as it
-gets :-)" 
+gets :-)"
 -- Jan Antolik, [theano-users] strange behaviour, Mon, Aug 2, 2010 at 1:36 PM
 
 -------------------------

doc/proposals/conditional.txt

@@ -4,7 +4,7 @@ Proposal for New Linking Strategy supporting Lazy Evaluation: Op.make_thunk
 =============================================================================
 
 .. note::
-   
+
    Proposal made June 2010.
 
 
@@ -103,17 +103,17 @@ in the PureOp class (a superclass of Op) that will return a Thunk.
     class PureOp(object):                       # recall:
                                                 # Op inherits from PureOp
 
-        def make_node(self, *inputs):           # leave alone 
+        def make_node(self, *inputs):           # leave alone
            ...
 
-        def perform(self, node, 
-              inputs, output_storage):          # move to `Op` class 
+        def perform(self, node,
+              inputs, output_storage):          # move to `Op` class
            ...
 
         def make_thunk(self, node,              # new function
               input_computed, output_computed,
               input_registers, output_registers,
-              ): 
+              ):
            """
            :type node: Apply instance
            :param node: previous rval from make_node(self, *inputs)
@@ -137,7 +137,7 @@ in the PureOp class (a superclass of Op) that will return a Thunk.
            :param input_registers: the i'th input can be read from
            input_registers[i][0] when input_computed[i][0] == 1.
 
-           :param output_registers: the i'th output must be stored to 
+           :param output_registers: the i'th output must be stored to
            output_registers[i][0], at which point the thunk must set output_computed[i][0] == 1.
 
            :returns: a Thunk (subclass) instance

doc/release.txt

@@ -34,7 +34,7 @@ welcome on the mailing list.
         1) Known errors should not be used to encode "feature wish lists", as
            is currently the case.
         2) Incorrect results should raise errors and not known errors (this
-           has always been the case) 
+           has always been the case)
         3) All known errors should have a ticket and a reference to that
            ticket in the error message.
 

doc/sandbox/module.txt

@@ -21,7 +21,7 @@ version of your Theano file.
 In the ModuleInstance, your symbolic variables have become containers (containing None),
 and your Methods have become callable functions.
 You should initialize the symbolic variables by calling
-``ModuleInstance.initialize()`` (although make() will call it for you, 
+``ModuleInstance.initialize()`` (although make() will call it for you,
 on the top-level ModuleInstance.)
 
 You can compile a Module several times, to create multiple ModuleInstances.
@@ -51,7 +51,7 @@ 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. 
+``build`` function.
 The ``build`` function is responsible for converting the symbolic thing into a
 non-symbolic thing.
 
@@ -60,7 +60,7 @@ 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. 
+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.

doc/sandbox/module2.txt

@@ -73,7 +73,7 @@ Each key in the updates dictionary must be the name of an existing ``Member`` of
 Inner Module
 ------------
 
-To share a ``Member`` between modules, the modules must be linked through the inner module mechanism. 
+To share a ``Member`` between modules, the modules must be linked through the inner module mechanism.
 
 Usage:
 
@@ -140,7 +140,7 @@ Now, using ``Module``:
     #m.dec = M.Method(n, [], updates = {c: m.c - n})#global c don't exist
     #m.plus10 does not update the state
     m.plus10 = M.Method([], m.c + 10) # m.c is always accessible since it is a member of this mlass
-    
+
     inst = m.make(c = 0) # here, we make an "instance" of the module with c initialized to 0
     assert inst.c == 0
     inst.inc(2)
@@ -148,7 +148,7 @@ Now, using ``Module``:
     inst.dec(3)
     assert inst.c == -1
     assert inst.plus10() == 9
-    
+
 Benefits of ``Module`` over ``function`` in this example:
  * There is no need to manipulate the containers directly
  * The fact inc and dec share a state is more obvious syntactically.
@@ -170,8 +170,8 @@ Using function:
            inc = theano.function([n, ((c, c + n), 0)], [])
            dec = theano.function([n, ((c, c - n), inc.container[c])], [])#inc and dec share the same state.
            return inc,dec
-    
-    
+
+
     inc1, dec1 = make_incdec_function()
     inc2, dec2 = make_incdec_function()
     a, b = T.scalars('ab')
@@ -193,7 +193,7 @@ Using Module:
         m.inc = M.Method(n, [], updates = {m.c: m.c + n}) # m.c <= m.c + n
         m.dec = M.Method(n, [], updates = {m.c: m.c - n}) # m.c <= m.c - n
         return m
-    
+
     m = M.Module()
     m.incdec1 = make_incdec_module()
     m.incdec2 = make_incdec_module()
@@ -227,12 +227,12 @@ Here is how we use the model:
 
     data_x = N.random.randn(4, 10)
     data_y = [ [int(x)] for x in N.random.randn(4) > 0]
-    
-    
+
+
     model = SoftmaxXERegression(regularize = False).make(input_size = 10,
                        target_size = 1,
                        stepsize = 0.1)
-    
+
     for i in xrange(1000):
        xe = model.update(data_x, data_y)
        if i % 100 == 0:
@@ -240,7 +240,7 @@ Here is how we use the model:
            pass
        #for inputs, targets in my_training_set():
            #print "cost:", model.update(inputs, targets)
-    
+
     print "final weights:", model.w
     print "final biases:", model.b
 
@@ -255,12 +255,12 @@ Extending ``Methods``
     model_module = SoftmaxXERegression(regularize = False)
     model_module.sum = T.scalar() # we add a module member to hold the sum
     model_module.update.updates.update(sum = model_module.sum + model_module.cost) # now update will also update sum!
-    
+
     model = model_module.make(input_size = 4,
                              target_size = 2,
                              stepsize = 0.1,
                              sum = 0) # we mustn't forget to initialize the sum
-    
+
     test = model.update([[0,0,1,0]], [[0,1]]) + model.update([[0,1,0,0]], [[1,0]])
     assert model.sum == test
 

doc/sandbox/sandbox.txt

@@ -100,7 +100,7 @@ write an Op:**
             raise NotImplementedError('only floatingpoint is implemented')
     scalar_xlogx  = XlogX(scalar.upgrade_to_float, name='scalar_xlogx')
     xlogx = tensor.Elemwise(scalar_xlogx, name='xlogx')
-    
+
 **It is also necessary to talk about UnaryScalarOp vs. BinaryOp.**
 
 UnaryScalarOp is the same as scalar.ScalarOp with member variable nin=1.

doc/tutorial/examples.txt

@@ -77,7 +77,7 @@ squared difference between two matrices ``a`` and ``b`` at the same time:
 >>> diff_squared = diff**2
 >>> f = function([a, b], [diff, abs_diff, diff_squared])
 
-.. note:: 
+.. note::
    `dmatrices` produces as many outputs as names that you provide.  It is a
    shortcut for allocating symbolic variables that we will often use in the
    tutorials.
@@ -162,17 +162,17 @@ array([[ 0.25      ,  0.19661193],
 The resulting function computes the gradient of its first argument
 with respect to the second. In this way, Theano can be used for
 `automatic differentiation <http://en.wikipedia.org/wiki/Automatic_differentiation>`_.
-As opposed to what this page tell, Theano do efficient symbolic differentiation 
+As opposed to what this page tell, Theano do efficient symbolic differentiation
 even for function with many inputs.
 
 .. note::
-   
+
    The second argument of ``T.grad`` can be a list, in which case the
    output is also a list. The order in both list is important, element
    *i* of the output list is the gradient of the first argument of
    ``T.grad`` with respect to the *i*-th element of the list given as second argument.
    The first argument of ``T.grad`` has to be a scalar (a tensor
-   of size 1). For more information on the semantics of the arguments of 
+   of size 1). For more information on the semantics of the arguments of
    ``T.grad`` and details about the implementation, see :ref:`this <libdoc_gradient>`.
 
 
@@ -269,7 +269,7 @@ will replace the ``.value`` of each shared variable with the result of the
 corresponding expression".  Above, our accumulator replaces the ``state``'s value with the sum
 of the state and the increment amount.
 
-Anyway, let's try it out! 
+Anyway, let's try it out!
 
 .. If you modify this code, also change :
 .. theano/tests/test_tutorial.py:T_examples.test_examples_8
@@ -314,7 +314,7 @@ updates).  Also, theano has more control over where and how shared variables are
 allocated, which is one of the important elements of getting good performance
 on the GPU.
 
-It may happen that you expressed some formula using a shared variable, but 
+It may happen that you expressed some formula using a shared variable, but
 you do *not* want to use its value. In this case, you can use the
 ``givens`` parameter of ``function`` which replaces a particular node in a graph
 for the purpose of one particular function.
@@ -330,7 +330,7 @@ for the purpose of one particular function.
 >>> skip_shared(1, 3)  # we're using 3 for the state, not state.value
 array(7)
 >>> state.value        # old state still there, but we didn't use it
-array(0)  
+array(0)
 
 The givens parameter can be used to replace any symbolic variable, not just a
 shared variable. You can replace constants, and expressions, in general.  Be
@@ -340,7 +340,7 @@ the substitutions have to work in any order.
 
 In practice, a good way of thinking about the ``givens`` is as a mechanism
 that allows you to replace any part of your formula with a different
-expression that evaluates to a tensor of same shape and dtype. ``givens`` 
+expression that evaluates to a tensor of same shape and dtype. ``givens``
 
 .. _using_random_numbers:
 
@@ -348,15 +348,15 @@ Using Random Numbers
 ====================
 
 Because in Theano you first express everything symbolically and
-afterwards compile this expression to get functions, 
-using pseudo-random numbers is not as straightforward as it is in 
-numpy, though also not too complicated. 
-
-The way to think about putting randomness into Theano's computations is 
-to put random variables in your graph. Theano will allocate a numpy 
-RandomStream object (a random number generator) for each such 
-variable, and draw from it as necessary. We will call this sort of 
-sequence of random numbers a *random stream*. *Random streams* are at 
+afterwards compile this expression to get functions,
+using pseudo-random numbers is not as straightforward as it is in
+numpy, though also not too complicated.
+
+The way to think about putting randomness into Theano's computations is
+to put random variables in your graph. Theano will allocate a numpy
+RandomStream object (a random number generator) for each such
+variable, and draw from it as necessary. We will call this sort of
+sequence of random numbers a *random stream*. *Random streams* are at
 their core shared variables, so the observations on shared variables
 hold here as well.
 

doc/tutorial/modes.txt

@@ -9,21 +9,21 @@ Mode
 ====
 
 Everytime :func:`theano.function <function.function>` is called
-the symbolic relationships between the input and output Theano *variables* 
-are optimized and compiled. The way this compilation occurs 
+the symbolic relationships between the input and output Theano *variables*
+are optimized and compiled. The way this compilation occurs
 is controlled by the value of the ``mode`` parameter.
 
 Theano defines the following modes by name:
 
 - ``'FAST_COMPILE'``: Apply just a few graph optimizations, but use C implementations where possible.
 - ``'FAST_RUN'``: Apply all optimizations, and use C implementations where possible.
-- ``'DEBUG_MODE'``: Verify the correctness of all optimizations, and compare C and python 
-    implementations. This mode can take much longer than the other modes, 
+- ``'DEBUG_MODE'``: Verify the correctness of all optimizations, and compare C and python
+    implementations. This mode can take much longer than the other modes,
     but can identify many kinds of problems.
 - ``'PROFILE_MODE'``: Same optimization then FAST_RUN, put print some profiling information
 
 The default mode is typically ``FAST_RUN``, but it can be controlled via
-the configuration variable :attr:`config.mode`, 
+the configuration variable :attr:`config.mode`,
 which can be overridden by passing the keyword argument to
 :func:`theano.function <function.function>`.
 
@@ -43,14 +43,14 @@ PROFILE_MODE      ``compile.profilemode.ProfileMode()``
 Using DebugMode
 ===============
 
-While normally you should use the ``FAST_RUN`` or ``FAST_COMPILE`` mode, 
+While normally you should use the ``FAST_RUN`` or ``FAST_COMPILE`` mode,
 it is useful at first (especially when you are defining new kinds of
-expressions or new optimizations) to run your code using the DebugMode  
-(available via ``mode='DEBUG_MODE'``). The DebugMode is designed to 
-do several self-checks and assertations that can help to diagnose 
-possible programming errors that can lead to incorect output. Note that 
-``DEBUG_MODE`` is much slower then ``FAST_RUN`` or ``FAST_COMPILE`` so 
-use it only during development (not when you launch 1000 process on a 
+expressions or new optimizations) to run your code using the DebugMode
+(available via ``mode='DEBUG_MODE'``). The DebugMode is designed to
+do several self-checks and assertations that can help to diagnose
+possible programming errors that can lead to incorect output. Note that
+``DEBUG_MODE`` is much slower then ``FAST_RUN`` or ``FAST_COMPILE`` so
+use it only during development (not when you launch 1000 process on a
 cluster!).
 
 
@@ -65,9 +65,9 @@ DebugMode is used as follows:
 
     f = theano.function([x], 10*x, mode='DEBUG_MODE')
 
-    f([5]) 
-    f([0]) 
-    f([7]) 
+    f([5])
+    f([0])
+    f([7])
 
 
 If any problem is detected, DebugMode will raise an exception according to
@@ -92,8 +92,8 @@ is quite strict.
 ProfileMode
 ===========
 
-Beside checking for errors, another important task is to profile your 
-code. For this Theano uses a special mode called ProfileMode which has 
+Beside checking for errors, another important task is to profile your
+code. For this Theano uses a special mode called ProfileMode which has
 to be passed as an argument to :func:`theano.function <function.function>`. Using the ProfileMode is a three-step process.
 
 To change the default to it, put the theano flags mode to PROFILE_MODE.
@@ -101,7 +101,7 @@ To change the default to it, put the theano flags mode to PROFILE_MODE.
 Creating a ProfileMode Instance
 -------------------------------
 
-First create a ProfileMode instance. 
+First create a ProfileMode instance.
 
 >>> from theano import ProfileMode
 >>> profmode = theano.ProfileMode(optimizer='fast_run', linker=theano.gof.OpWiseCLinker())
@@ -112,7 +112,7 @@ application. For example, a user wanting to profile the Python
 implementation only, should use the gof.PerformLinker (or "py" for
 short). On the other hand, a user wanting to profile his graph using C
 implementations wherever possible should use the ``gof.OpWiseCLinker``
-(or "c|py"). For testing the speed of your code we would recommend 
+(or "c|py"). For testing the speed of your code we would recommend
 using the 'fast_run' optimizer and ``gof.OpWiseCLinker`` linker.
 
 Compiling your Graph with ProfileMode
@@ -138,13 +138,13 @@ of its time.
 This is best shown through an example.
 Lets use the example of logistic
 regression.  (Code for this example is in the file
-``benchmark/regression/regression.py``.) 
+``benchmark/regression/regression.py``.)
 
 Compiling the module with ProfileMode and calling ``profmode.print_summary()``
 generates the following output:
 
 .. code-block:: python
-    
+
     """
     ProfileMode.print_summary()
     ---------------------------