Implement average poolings and try to generalize the functions

[ricor07]

I'd like to implement functions such as averagepooling, globalmaxpooling and globalaveragepooling. Since all of this have a 1d, a 2d and a 3d implementation, i think it is possible to write this as an unique function, just as how input was done.

[milancurcic]

Back to the topic of how to make 1d/2d/3d constructors behind generic names.

For the reshape (what should now be called reshape3d) and reshape2d layers, it's straightforward because the output shape needs to be provided to the constructor, and so a type-kind-rank distinction can be made, like we did with input layers.

However, it's not clear to me how we can make conv1d/2d and maxpool1d/2d generic, as either 1d or 2d variants take pool size and stride integers as input, which can't be used to make a type-kind-rank distinction.

Any ideas?

[milancurcic]

A potential approach to make conv1d/2d, maxpool1d/2d generic is not at the constructor function, but in the internal implementation of the layer itself, for example instead of the current approach of:

type conv1d_layer, extends(base_layer)
  ...
contains
  procedure :: forward, backward
  ...

and

type conv2d_layer, extends(base_layer)
  ...
contains
  procedure :: forward, backward
  ...

we could have one conv_layer type for all ranks

type conv_layer, extends(base_layer)
  ...
contains
  procedure :: forward1d, forward2d
  procedure :: backward1d, backward2d
  generic :: forward => forward1d, forward2d
  generic :: backward => backward1d, backward2d
  ...

(the specific syntax may be incorrect but should give you an idea)

Then, the generic conv % forward and conv % backward is resolved based on the input and gradient array ranks..

[ricor07]

I would just write a basic function called conv or maxpool, which takes the shape of the input array and then calls the other functions (not accessible to user) maxpool1d, 2d or 3d. But I think there are better solutions. Let me know. If you want we can also have a call

[milancurcic]

It's possible but it would make the API not as nice as it is now, as it would require the user to keep track of the shape of the data as it moves from layer to layer. I agree that it would be good to have a call to discuss this and a few other design choices between you, me, @OneAdder and @jvdp1, and possibly others. I'll be busy with travel until March 25, after which I'll be on central european time which is the same as @jvdp1 and is closer to @OneAdder's local time. I'll follow up soon to find a time.