On Fri, Apr 27, 2018 at 8:43 AM, Sudeepam Pandey <address@hidden> wrote:
On Fri, Apr 27, 2018 at 5:05 PM, Nicholas Jankowski <address@hidden> wrote:On Fri, Apr 27, 2018, 04:33 Sudeepam Pandey <address@hidden> wrote:On 27 Apr 2018 5:38 a.m., "Bradley Kennedy" <address@hidden> wrote:On 2018-04-26, at 19:12, Sudeepam Pandey <address@hidden> wrote: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?It seems you have several separable programming tasks. These need to be blocked out and addressed independently. That includes and analysis of options and alternatives after a review of what's been done before by others.1 - implement a suggestion feature within octave, independent of algorithm, and a framework for connecting to it. I would consider this a near term objective, lest it become a last minute kludge. It would be testable with even the most trivial of suggestion algorithms2 - implement a suggestion algorithm for 'online' suggestions, that needs to be delay free to the user. It may make sense to have both high confidence and lower confidence a approaches to this, bit I'm not yet convinced you've researched to options including what's already been done.3 - implement any offline suggestion algorithm components that will aid 2. This may or may not be separable from 2. If this requires maintainer action, that will need a reasonable framework.4. Document. Especially if this will require later manual actions on each new octave release. updatesI am really sorry but I don't understand some of these things. Please clear these up for me.
At some time, the interpreter comes to a realization that it does not understand what the word ( sst1) is that was given to it. It then says that "sst1" is undefined. We should then make core octave call foo.m . foo.m is the "independent of an algorithm" code. Now foo.m can call an implemetation of NN or any other trivial code.
1) What exactly do you mean by a suggestion feature "independent of an algorithm" and "testable with even the most trivial of suggestion algorithms"?2) What do you mean by "online and offline suggestions"?
I think he means online as what happens when octave is running and offline would be the training of the NN before you use it in octave.