Brick inputs and outputs are tagged with an application call

The application call can be used to e.g. include auxiliary variables, such as monitors, extra cost terms etc.

Also: fixes to graph parsing.
On 19.12.2014 16:45, Bart van Merriënboer wrote:
>
> In blocks/bricks/__init__.py 
> <https://github.com/bartvm/blocks/pull/68#discussion-diff-22110594>:
>
> > +
> > +    The application call object is created before the call to the application method and can be accessed by
> > +    specifying an application_call argument.
> > +    """
> > +    def __init__(self, brick, application):
> > +        self.brick = brick
> > +        self.application = application
> > +        self.auxiliary_variables = []
> > +
> > +    def add_auxiliary_variable(self, expression, role):
> > +        #the copy destorys the name. I believe adding a role tag is pretty harmless, so don't copy
> > +        #expression = expression.copy()
> > +        expression.tag.role=role
> > +        self.auxiliary_variables.append(expression)
> > +
> > +    def add_monitor(self, expression):
>
> I'm aware this PR didn't decide on any interface; just figured I'd 
> continue the discussion here. I have no issues with the principle, but 
> mostly with the interface, which I want to make sure stays simple for 
> the basic cases of monitoring values that don't require data, or which 
> are simply average over examples (which covers 99% of use cases). For 
> these cases, I don't think you should need to provide an entire 
> averaging scheme (|fraction(num_errs, num_examples_in_batch)|). This 
> flexibility should be reserved for the exceptional cases where we 
> average over elements (words) in temporal sequences (sentences), or 
> for when for some reason we want to average over batches of non-fixed 
> size.
>
I agree that we should keep things simple for simple usecases. What if 
we agree that the default aggregation semantics (i.e. when the attribute 
in the tag is not given) is simple averaging over batches regardless of 
their relative sizes?

However I very much looking forward to a prototype from Jan, since my 
experience shows that with a code sample the discussion runs much smoother.
>
> Otherwise, no problem with this PR, I like the design choice. There 
> are a few tiny documentation issues, but I'll fix those when I have 
> the time (no newline after the opening |"""|, and the summary 
> description after |"""| cannot exceed 1 line).
>
> Also, I think comments should only be used to explain non-obvious 
> programming logic, and I guess we can use them to tag |# TODO|. I'd 
> prefer that we do not merge questions or personal opinions as with 
> this PR. Those will just linger and confuse people 1 year from now.
>
OK, I think we should have a document "For a New Contributor", where we 
should at least:

* discuss code-style: uppercased constants, numpy-style docstrings, 
length of summary
* explain the user how automatic testing works and why he should always 
take care of syntax and use flake8
* show how to generate docs locally

Bart, would you like to start such a document? I think it should be 
another page in the documentation.
>
> —
> Reply to this email directly or view it on GitHub 
> <https://github.com/bartvm/blocks/pull/68/files#r22110594>.
>