Add @boundscheck for MOInput and remove explicit definitions of length and iterate

[sharanry]

Removing unneeded definitions and using @boundscheck macro based on discussion in https://github.com/JuliaGaussianProcesses/AbstractGPs.jl/pull/30

[sharanry]

@devmotion do you think it is okay to merge this or do you suggest any other changes?

[devmotion]

Looks good mainly, just two questions:

• What is the motivation for introducing moinput? It seems in contrast to mooutput there is no alternative implemented that doesn't return a MOInput instance?
• The difference between MOInput and MOOutput is mainly that the first one's elements are tuples where the second element corresponds to the output dimension, right?

[sharanry]

What is the motivation for introducing moinput? It seems in contrast to mooutput there is no alternative implemented that doesn't return a MOInput instance?

I wanted it to be similar to moutput. Mixed use of capitals just seemed very non-intuitive to me. I want to avoid usage like

X, Y = MOInput(x, out_dim), moutput(y)

The difference between MOInput and MOOutput is mainly that the first one's elements are tuples where the second element corresponds to the output dimension, right?

This is one aspect of it. Additionally, one can think of MOInput to emulate repetition of inputs for each output dimension. For example N inputs are viewed through MOInput as out_dim x N inputs without allocating any additional memory. Whereas, MOutput emulates flattening of the outputs from size (out_dim, N) to vector of length out_dim x N.

[devmotion]

I wanted it to be similar to moutput. Mixed use of capitals just seemed very non-intuitive to me.

Seems reasonable. In this case I suggest to not export MOInput anymore though.

[sharanry]

@devmotion @willtebbutt Is this okay to merge?

[willtebbutt]

Stale, so closing. Please re-open if updates are provided.