Implementing Neural Turing Machines
arxiv.org
arxiv.org
Also compared to the open source implementation (https://github.com/snowkylin/ntm) it seems like his main novel claim is that he looked at different memory initialisation patterns.
Edit:
compare the original: https://github.com/snowkylin/ntm/blob/master/ntm/ntm_cell.py
to the derivative work: https://github.com/MarkPKCollier/NeuralTuringMachine/blob/ma...
from what I can tell the main innovation is that the derivative work uses a named tuple instead of a dictionary for state keeping and there is new memory initialisation code. The original author apparently initialised the memory randomly. I also feel like the paper should cite the implementation they are basing their work on. The paper https://arxiv.org/pdf/1807.08518.pdf merely states that other implementations exist on page one and makes no mention of the fact that their implementation is based on one of those. Combine that with the fact that they are asking people in the Readme to cite their paper feels like not a very good idea.
A note on the difference between our work and Snowkylin's: the code implementing the operations of the NTM are very similar and both are similar to other open source NTM implementations as the operations for a NTM are defined by the equations of the original NTM paper and have a clear mapping into code.
The primary difference is that our implementation works and is stable - the code changes to achieve this are minimal but this still required substantial experimentation and work to figure out what was causing slow convergence and the gradients becoming NaN (causing training to fail) in other implementations. Thus our primary contribution is not to put a NTM into code but to get that code to reliably and quickly train.
- line 53-56 (in your code), which correspond to line 41-45 in Snowkylin's code
- line 70 vs 69, where you've used a build in function instead of the explicit compositional form of softplus
- finally the major change I can see are various variable initialisation schemes 147-178 in your code, which is handled by line 157-185 in snowlkylin's code
and some miscellaneous places where you've used a NamedTuple instead of a dictionary. And yes the choice of initialisation is a valid improvement. As far as I can tell Snowkylin's implementation is not broken, but just might learn more slowly because of a different state initialisation scheme. It does not suffer the NaN problem for example.
It should be communicated very clearly also in the paper that the code you are releasing is derived from another open-source implementation, with a precise explanation of the changes you have made. Also you can't change the LICENSE and copyright notice of open-source code to yourself without permission. I believe even in the current form your Github repo is in breach of the LGPL3. For more details how to use the LGPL properly, please refer to https://www.gnu.org/licenses/gpl-howto.en.html. Notice that the original repository actually does not carry out all those steps properly.
Namely it is missing LICENSE and Copyright notices in every file. It also doesn't have an explicit copyright notice anywhere.
https://github.com/snowkylin/ntm/blob/master/LICENSE
Moreover, in the paper 5 times you write:
"Our implementation"
You also don't acknowledge that you are piggybacking on snowkylin's code. You didn't make it magically "stable", like fixed NaNs or anything like that.
And you want to be cited as follows:
title={Implementing Neural Turing Machines, author={Collier, Mark and Beel, Joeran},
That's just very bad.
You should:
1. State changes (orbifold did it for you below). Acknowledge snowkylin. Link to them.
2. Title it "Improved initialization in NTM" or something like that, not "Implementing NTM".
https://petewarden.com/2018/03/19/the-machine-learning-repro...
Does it mean that one can expect better explainability in the future from these models?