Hi Ahmed, Thanks a lot for your feedback and sharing your thoughts.
About the suggestion on learning an algorithm, improving/optimizing it, etc. IMHO, it should be possible to learn the math background and the algorithm internals as you do the job. This of course depends (a lot) on the algorithm itself, but maybe don't discard this option right away, especially when it motivates you. Have you taken a look at the issues in GitHub? Maybe there's something in there that could get you started with learning some algorithm at the same time that we could get some work done solving the issue. About the list, let's go then for the PR for views first. Another item you did some nice work on was the linalg design, how do you feel about it? Cheers, Fernando. On Sun, 28 Jul 2019 at 00:46, Ahmed Essam <theartful...@gmail.com> wrote: > Hello all, > > Thanks for your constructive criticism about last term. It was a little > messy, and I didn't do my best. I will be more communicative and won't skip > on blog posts :") > > Regarding this term, I need ideas for what to work on. What I'm currently > interested in is learning about the implemented algorithms and maybe > optimizing them if needed. But this is beyond the scope of my project, plus > I lack the mathematical background, so maybe not in this summer :") > I don't feel particularly passionate about any specific item of my > original proposal, but here is the list: > 1. Immutable features: > - Subsets: I will come up with a PR for views soon (my mental image about > an approach I had in mind isn't pretty yet). > - Internal data access: Replacing 'get_feature_vector' and similar methods. > - Preprocessors: Should we have on the fly methods? Should they be dropped > from the features interface and depend instead on Transformer interface? > 2. Stateless Distance API > 3. Stateless Kernel API: The cached kernel bit is nearly finished.Then > there is the set of "optimization" methods like "init_optimization" and > "delete_optimization". Should be solvable using multiple inheritance (won't > be a problem with swig since it's not exposed). > 4. StringFeatures cleanup: Replacing SGString (nearly finished). Replacing > raw pointers. Creating a new class for embedded string features. > 5. SGObject Mixins: mutliple inheritance won't work. we could flatten the > inheritance, but it would require variadic templates to do properly, and it > doesn't work with swig. > > If you have any other ideas however, I think I would probably prefer it :") > > Thanks, > Ahmed Essam. > >
