Dzmitry Bahdanau

I think the major design decision that I disagree with is having both `initializable_roles` and `parameter_roles`. Neither of the two is fully suitable for controlling how the initialization schemes are...

@memimo , we should resume working on this, and I really hope we can finish it until I leave Montreal on June 8.

An addition: same problem for auxiliary variables, they also must be changed. @dwf, I am sort of used to always monitor the training cost on every batch in addition to...

@dmitriy-serdyuk , I am applying replacements after I attached aggregation schemes to some variables, and this does not work. I want to monitor similar expressions on training and vaidation data,...

Thinking about it a bit more, the problem is that annotations are not affected by `ComputationGraph.replace`. That involves their auxiliary variables and updates and might have very nasty consequences, when...

No, #516 is orthogonal. Graph replacement are still not applied to auxiliary variables as they were.

Assuming that you have an aggregation scheme for median, I think it is very possible: ``` python x = tensor.scalar('x') mean_x = aggregation.mean(x) mean_x.name = 'mean_x' median_x = aggregation.median(x) #...

In principle Theano should optimize such repetitions away, and I think it will happen in practice.

That's probably true that it should not be mandatory for `Fork` to set the `output_dim` attribute of its children. On 4 April 2016 at 02:47, David Warde-Farley [email protected] wrote: >...

Why not just make it `output_dims` attribute optional for `Parallel` and `Fork`? It can try to set output dimensions if they are given or hope on the brick to compute...