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