Hi Fernando, Thanks for your interest! I think I was being unnecessarily difficult :") About the algorithms stuff, I don't think it would be feasible, especially with this being the last month (also I want to take the time to first study the prerequisite maths :") . And the linalg design needs some discussion and time to come up with alternative approaches.
I intended on working on the views PR this week, but I hit annoying blockers/bugs that took me some time to solve. So hopefully this week there will be progress for it. Thanks, Ahmed Essam. On Mon, Jul 29, 2019 at 4:21 PM Fernando J. Iglesias García < fernando.iglesi...@gmail.com> wrote: > 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. >> >> >
