Mike J Innes
Mike J Innes
[This definition](https://github.com/FluxML/Zygote.jl/blob/8cece0db2ed9fe8039fb1d21882a54b4a69e7e98/src/lib/array.jl#L80) just needs to be more general. We could probably just remove the `AbstractArray` restriction, but need to be a bit careful to that map over tuples is still...
Generally things like `map(identity, (1, "foo"))` should infer, and so should its adjoints. The PR will break that as it currently stands, though it's fine if we fix that later.
Might be good to have a test to demonstrate this specific issue, which the current one doesn't seem to (?). Also, I wonder if it'd be better to do the...
Currently, this is expected; as part of the control flow handling, the pullbacks for `a` and `b` will get stored on a `Vector{Any}` stack, which will lose type information. We're...
This could do with a minimal test case so it's clear what it's fixing.
Ok, I understand what's going on here now. This is a tricky case and we need to think carefully about what the right fix is. The problem generally is that...
Yeah, right now the Flux approach to this is essentially the same as PyTorch. `step!` and `train!` should basically be orthogonal issues; if you want to mentally rewrite the examples...
This seems like a good thing to have, although perhaps with more informative names than `sigmRepl` etc; is there a better name for these gates? Also, the CUDA bindings will...
RE cuda, you can look [here](https://github.com/FluxML/Flux.jl/blob/ac4c49b63e546a6830f669920c65114b6b25dfda/src/cuda/curnn.jl#L5). The situation is the same for vanilla RNNs, we allow the activation function to be changed but only two are supported by CUDNN. Changing...