you for your inputs Bradley. I'll consider them when I start working on the NN approach.
To my mentors and the maintainers, I understand that the novelty of the neural networks approach makes it harder to trust them and that the edit distance algorithm seems like a better option at this point.
To make sure that everyone is comfortable with how this feature is developed, how about I create two sub branches in my public repository? One for the edit distance approach and one for the neural network approach.
Just like Bradley suggested, I'll work on the edit distance approach first, and make a complete suggestion feature out of it. When I say complete, I mean an integration with Octave and an on/off option included. Maybe this could be the main part/ primary goal of my GSoC project.
During the last days, I can work on the other branch and add a complete NN implementation to it (It won't take much time since I would have most of the stuff figured out). A NN based implementation can be my secondary goal for GSoC. Essentially, the maintainers will have the flexibility to choose either the edit distance approach or the NN based approach, whatever they think provides the best UX and is easier to maintain.
Should I proceed with this idea and make the appropriate changes to my timeline and public repo?