new proposals

doc/proposals/advidx.txt

+==================
+Advanced Indexing
+==================
+
+Continue the Advanced Indexing project that is on either github or bitbucket.
+

doc/proposals/conditional.txt

+
+Conditional Evaluation
+=======================
+
+This has been discussed informally lots.  Modify the linker to look for a
+lazy_perform function in each op, that can either return the fact that
+computations are done, or it can return a list of inputs that must first be
+evaluated before it can proceed.

doc/proposals/dp_optimization.txt

+
+========================
+DP Instruction Selection
+========================
+
+Read Ch 9 of Modern Compiler Implementation about instruction selection.
+We should probably be doing graph optimization totally differently:  
+Optimizations *only add* new ways of implementing something, they do not replace
+the old way.  Every graph node (apply) as a cost, and Dynamic Programming (DP)
+is used to select the minimum cost graph.
+
+The advantage of this approach is that optimizations do not have to run in such
+a careful order, and graph selection would be much faster.
+
+
+Think about how aliasing and destructive operations (the destroy-handler) would
+fit in this approach.
+

doc/proposals/intermediate_language.txt

+
+=====================
+Intermediate Language
+=====================
+
+
+It would be nice to be able to use Theano from other languages.
+This requires two things: a way to communicate the expression to the theano
+compiler, and a way to pass data to and from the compiled function.
+
+One way to do this would be define a textual representation of theano graphs.
+A Scheme-like language seems appropriate.  Perhaps just scheme would be
+appropriate.
+
+
+How to pass shared variables?
+

doc/proposals/mongodb_cache.txt

+
+=================
+MongoDB DLL Cache
+=================
+
+
+In network environments (like at DIRO on NFS3), a distributed DB like mongo or couch is faster and more
+robust to concurrency than the $HOME/.theano.  Also, a single cache could be
+shared by multiple users.  This would result in less compilation time, for
+everyone, and less stale-cache problems.
+

doc/proposals/noupdates.txt

@@ -4,6 +4,7 @@ Automatic updates
 
 .. note:
    Proposed 2010 01 13
+   Done 2010 04 ??
 
 
 The Module version of RandomStreams could arrange for the automatic update of

doc/proposals/opencl.txt

+=======
+OpenCL
+=======
+
+Migrate the GPU code-generators to the PyCUDA style, and eventually to OpenCL.
+This means mainly to use a different kind of code-generation strategy.  The
+kernel itself is compiled, but the calling code remains in python or cython.  We
+would no longer generate entire C files this way, and no longer use the CLinker
+for GPU code.
+

doc/proposals/premerge.txt

+
+Proactive Merging
+=================
+
+
+Merge is done now as an optimization. 
+But if Merging was done at graph construction time, things like #476 would work.
+Additionally, memo-izing at graph construction time would make it possible to
+define recursive formula with recursive python functions (e.g. Fibonacci).
+Currently the merge optimization would make the Fibonacci series linear, but the
+size of the program used to express the program would be exponential.
+

doc/proposals/tensor_attributes.txt

+
+
+========================
+Add tensor attributes
+========================
+
+
+Size, shape, psd, symmetric, triangular, contiguous.  
+Add these attributes to the TensorType with the option always that they be
+'unknown'.
+Add attributes that are useful for optimizations, or useful for code generation.
+
+