If you get time could you review my proposal. I have made some changes as suggested. Would be ready to make more improvements.
Thank you On Fri 23 Mar, 2018, 9:41 PM Heiko Strathmann, <heiko.strathm...@gmail.com> wrote: > Hi! > See below > > 2018-03-22 11:33 GMT+00:00 Akash Shivram <akashshivr...@gmail.com>: > >> I was going through the hackathon base API ideas. >> >> 1. With the pipeline, do you want to convert a transformer to a machine ? >> If yes, how would that be better from present approach( having different >> classes as transformers and machines). >> > > I guess we want to eventually build pipelines where we can transform > features, and wrap machines into other machines. The hackathon ideas were > just the result of some initial brainstorming. Far more though is required > to do all this. > >> >> 2. Does not using different feature types means dropping the way of >> declaring feature objects like is done now >> features = some<CdenseFeatures<float64_t> >(f_train) >> > >> And change it to something >> features = some_fn(f_train) >> > > Yes, absolutely. At algorithm level, we should not be concerned about the > bit-length of the features. Such details should be pushed down into lower > level parts of the implementation > > >> >> This some_fn will return what some<CdenseFeatures<float64_t>>() usually >> would.? >> >> Thank you. >> >> >> On Wed, Mar 21, 2018 at 6:03 PM, Viktor Gal <viktor....@maeth.com> wrote: >> >>> Hi Akash, >>> >>> thnx for the application! i have added already some comments, please let >>> us know if you have any further questions. >>> >>> cheers >>> viktor >>> >>> > On 21 Mar 2018, at 11:40 AM, Akash Shivram <akashshivr...@gmail.com> >>> wrote: >>> > >>> > Hey Heiko! >>> > >>> > I have sent the draft to NumFOCUS. Please have a look. >>> > >>> > Thank You >>> > >>> > On Tue, Mar 20, 2018 at 3:57 PM, Heiko Strathmann < >>> heiko.strathm...@gmail.com> wrote: >>> > Nevermind, the earlier the better so we can give you feedback! >>> > >>> > 2018-03-20 10:11 GMT+00:00 Akash Shivram <akashshivr...@gmail.com>: >>> > Yes sure. >>> > >>> > It is incomplete yet, with a lot to add. >>> > I hope that should not bother. >>> > I will be uploading it by today. >>> > >>> > Thank you >>> > >>> > On Tue 20 Mar, 2018, 3:37 PM Heiko Strathmann, < >>> heiko.strathm...@gmail.com> wrote: >>> > I see, sure! >>> > >>> > Let me comment further in the proposal draft. Could you make sure to >>> send it soon? Then we can give feedback! >>> > >>> > Thanks! >>> > H >>> > >>> > 2018-03-20 8:05 GMT+00:00 Akash Shivram <akashshivr...@gmail.com>: >>> > Hi Heiko >>> > Thanks for replying! >>> > >>> > By the "headings being followed by the pilcrow sign" I mean this : >>> > <Peek 2018-03-20 11-22.gif> >>> > >>> > It is a part of the <a> tag with href with value "#example" (e.g. in >>> this case). Well, this is because of reStructuredText. It just adds >>> implicit hyper-link target referencing to the section title itself. >>> > >>> > I was going though Read-the-Docs for finding better ways to document >>> hosting. I thought this could help putting all the cookbooks, examples, >>> other docs in one place. The current API is better in displaying example >>> code snippets for all the languages. I think cookbooks' templates are good >>> for displaying code snippets as it does at present. >>> > >>> > Could you elaborate more on what you suggest need to be done for >>> "integrating all existing sources of documentation into a single one: >>> cookbooks, API, parameter docs should all use the same content in order to >>> improve maintainability." >>> > >>> > I see most of cookbooks have the links to intra-doc pages, some don't >>> so I can fix that. >>> > >>> > Regarding the proposal: >>> > The project is divided into tasks (llke basic API design, exception >>> handling, API examples, parameters), I am confused how to set the time-line >>> for these, as these are different and somewhat independent. How do you >>> suggest I should structure the timeline ? >>> > >>> > Is there anything more that could be added to the project ? >>> > >>> > Thank you >>> > >>> > On Mon, Mar 19, 2018 at 6:05 PM, Heiko Strathmann < >>> heiko.strathm...@gmail.com> wrote: >>> > Hi Akash >>> > >>> > welcome! >>> > >>> > See below for my comments >>> > >>> > >>> > 2018-03-18 21:19 GMT+00:00 Akash Shivram <akashshivr...@gmail.com>: >>> > Hey there! >>> > >>> > I am S Akash (GitHub url : syashakash) and I want to do the project >>> mentioned in the subject in GSoC this year. >>> > >>> > I have gone through the wiki page and also the notes linked. >>> > >>> > I agree that refactoring the methods and naming them as per the >>> current convention is needed as now most libraries have these methods like >>> "fit" and "transform". This would make familiarization easier. >>> > Absolutely. Keep in mind this is a quite minor change. Takes maybe a >>> day or two. >>> > >>> > Does introducing new exceptions means removing ShogunException and >>> using the new ones instead, or all are going to inherit ShogunException ? >>> > We would specialize ShogunException to more useful cases that inform >>> the user of what he did wrong. >>> > >>> > >>> > The headings in the cookbook currently are followed by a pilcrow >>> symbol. I see that it is an anchor tag that links to nowhere. I think this >>> should be removed as it serves no purpose other than scrolling up. >>> > No sure what you mean here. >>> > >>> > >>> > >>> > I am currently going through the documentation of Read-the-docs. I am >>> unsure as to whether this would be fruitful but my intention is to see >>> whether there can be a plug-in to render the reStructuredText files as doc >>> or not or any other way. As we now want an integration of the cookbooks and >>> examples. Read-the-docs is compatible with Sphinx. >>> > >>> > What exactly do you want to do here? Can you explain? >>> > >>> > >>> > I also had one suggestion, and this has been ever since I started to >>> get familiar with Shogun, whenever there is a reference to another feature >>> or method in a cookbook example, there is no link to the example being >>> referred. Take for the cookbook for Bray Curtis Distance Manhattan >>> Distance is mentioned but not linked to the cookbook for Manhattan >>> Distance. Many documentations do this like sklearn, etc. This is a wide >>> change but just needs minor code updates in all the necessary files. >>> > If this sounds reasonable I would like to send a PR on this. >>> > >>> > I think we CAN link cookbooks to each other. See e.g. >>> http://shogun.ml/examples/latest/examples/evaluation/cross_validation_mkl_weights_storage.html >>> > >>> > But it would be of course better if this happened by automagically. >>> > >>> > >>> > I am writing my proposal with all use-cases and stories as asked in >>> the wiki and would submit a draft as soon as possible for review. >>> > >>> > Great, looking forward to seeing your proposal >>> > >>> > >>> > Thank you for your patience. >>> > Akash S >>> > >>> > >>> > >>> > >>> > >>> >>> >> >
