Re: Proceeding with the GSoC Project

[Sudeepam Pandey]

On Fri, Apr 27, 2018 at 6:50 PM, Nicholas Jankowski <address@hidden> wrote:

On Fri, Apr 27, 2018, 08:43 Sudeepam Pandey <address@hidden> wrote:

On Fri, Apr 27, 2018 at 5:05 PM, Nicholas Jankowski <address@hidden> wrote:

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 algorithms 

2 - 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. updates

I am really sorry but I don't understand some of these things. Please clear these up for me.

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"?

1 - how the feature presents itself to the user and hooks into octave is separate from what happens behind the scenes to generate the words to suggest.  

If we implemented a  pop-up dialog box where the user could select the intended command, that could be tested without having any neural network or nearest neighbor searching going on in the background. It could be tested with a simple 10 word look up table just to show that the functionality is correct. Later the actual suggestion feature should be some separate, independent function that is separately testable. But having it be independent will involve defining the interface to that piece such that any algorithm should be able to provide word suggestions to it. If a better algorithm comes along later, someone could implement it without having to change the code for actually hooking into octave.

2. The difference between the two might depend a lot on what algorithm you actually use. but I was thinking of it as separating the actual functions that need to be run at compile time versus the function that will be run live when the user mistypes a command. Maybe dictionary generation, neural network training, etc. The live algorithms will need to be more computationally efficient so that they don't impose a delay on the user. Anything done in advance, computational effort is less of a concern

Ohh I understand what you are trying to say now. I agree with what you are saying and actually, even I planned to make separate programs for the two tasks i.e. the task of a) How words to suggest are generated and b) How these are shown to the user. Maybe I did not mention that anywhere in this thread before. I'm sorry for that. Anyway, earlier I planned to do the showing to the user part later on, but I see your point now and I totally agree, it would be better to first make the 'hooking up to Octave' part.