[Lisa_teatalk] Tea Talk Thursday: Pylearning part 2

Aaron Courville aaron.courville at gmail.com
Tue Sep 7 17:43:06 EDT 2010


Hi All,

This week, once again, we will us our tea talk time to meet and
further our discussion of our ongoing reorganization of our code and
code building practices.

When, Thursday Sept. 9th, 2pm
Where LISA Lab.

It would be helpful if all the committees have met at least once
before the meeting.
More guidance for the committees (PLEASE READ THE FOLLOWING):

Yoshua: Here is how I would define the job of the committees that deal
with software modules (most of them except to upcoming social
engineering committee):

* The end-product of the committee is both an API and its justification.

* It's justification is grounded on
    - algorithms currently used in the lab and that can fit in one
mold or in a shared view of what they view, in the sense of being
interchangeable as seen from the outside world
    - forward looking perspective on other algorithms that we might
want to fit in this mold in the future
    - computational issues:
        * think through how these might be typically implemented, and
consider things like
             - internal state, persistent storage (what happens when a
machine crashes),
             - parallelization (especially of the kind we currently
do, i.e., for hyper-optimization) and asynchronous functionality
   - compatibility issues:
        * what if Theano were to change in the future? try to avoid
dependency on Theano where possible, and where not try to depend only
on the abstraction that we are manupilating symbolic expressions and
keep very Theano-specific commands like compilation in one place
        * compatibility with other python packages, either for data,
learning algorithms, visualization, etc.
   - factorization objectives (e.g. dependency on the filesystem,
cluster type, GPU vs CPU, database type, parallelization ,etc. should
be as much as limited to the smallest subset of the code as possible)


* It may be that the family of algorithms considered don't all fit in
one mold. That's ok. We need to know why and maybe there are
sub-families that can each be grouped in different molds, that is ok
too. So we could have different APIs, one for each of these
sub-families. Or we could come to the conclusion that there is no
common mold at all and the only sharing could be at the level of
'formulas' (this might be the case for inference).


Cheers,
Aaron

-- 
Aaron C. Courville
Département d’Informatique et
de recherche opérationnelle
Université de Montréal
email:Aaron.Courville at gmail.com


More information about the Lisa_teatalk mailing list