Kyle Daruwalla

Okay should be good?

I have nothing to add other than it should probably be: ```julia MLDataPattern.datasubset(dataiter::GetObsParallel, idxs) = GetObsParallel(datasubset(dataiter.data, idxs), dataiter.useprimary) MLDataPattern.datasubset(dataiter::BufferGetObsParallel, idxs) = BufferGetObsParallel(datasubset(dataiter.data, idxs), dataiter.useprimary) ``` In MLDataPattern.jl, we distinguish between...

I am not sure we want to do that for every iterator. In fact, I am now doubting my previous suggestions. Almost always, a data iterator is the last piece...

Ah, we would end up taking on a StatsBase dependency (which would be dropped in a subsequent LearnBase version).

Don't see a reason why there can't be. We'll just need to update `BatchViewCollated` to accept a user collate function.

Okay seems like this bug is an MLDataPattern.jl issue. Iterating a row vector gives arrays, but iterating a column vector gives scalars. We should specialize `getobs` on `AbstractVector`s separately from...

Since this has now been put on the next milestone, I should chime in. I personally do not like having a super-type. My reasons: - It precludes someone from using...

Good point. The messy thing about macros will be the order in which stuff is called. Something like ```julia struct MyLayer foo end Base.show(..., ::MyLayer) = ... @layer MyLayer ```...

I prefer not to error on something that is completely valid in an unconventional context (at least at the level of Flux.jl). There are libraries built on top of Flux...

That makes sense. It looks like the "function" in your Hyperopt code will be a call to `train!` or some equivalent? In _general_, if you want `train!` to be "safe"...