<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 5:12 PM, James Aylett <span dir="ltr"><<a href="mailto:james-xapian@tartarus.org" target="_blank">james-xapian@tartarus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 14, 2016 at 02:09:13AM +0530, Richhiey Thomas wrote:</span><br>
<span class=""></span><span class=""><br>
</span>If there are good default values that will work for most people, that<br>
would be fine (that's what we do for the parameters to BM25, for<br>
instance; in more extreme situations you have to change from the<br>
defaults, but most of the time you can just accept them and get<br>
reasonable behaviour). If the documentation can give an idea of when<br>
you'd want to change from the defaults, that would be even better.<br></blockquote><div> </div><div>Yes! We can use default values that work well with K-means and PSO and then provide and option to override these defaults incase of a specialized use case. So that will work well in all cases.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""></span><span class=""><br>
> To break things down further, we can look at things like this<br>
> June 7-June 10<br>
> Create a class to represent particles and write code to initialize each<br>
> particle in the dataset with cluster-centroids<br>
> June 11 - June 16:<br>
> Implement code to find the fitness value for each particle and finding the<br>
> new location of the particle.<br>
> June 17-June 20:<br>
> Test the code against any dataset which contains documents so that we can<br>
> see how the code will be finding the initial centroids and so that we can<br>
> tweak the initial parameters to get good performance.</span> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>It'd be good to break the tests into two groups: one very fine<br>
grained, testing individual pieces of functionality (such as the<br>
fitness calculation, and calculating the new particle location); one<br>
higher level, testing the overall algorithm. Depending on how your<br>
classes work, the fine grained tests may not need to know about<br>
Xapian::Document, which might make them easier to write.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
either before or at the same time as the code they test.<br></blockquote><div> <br></div><div>Yes I completely agree with your suggestion on including fine grained tests checking on individual functionalities and a higher level test for the overall algorithm.<br></div><div>The timeline could be made better by providing two days in between after implementing a small part and spending 1-2 days on testing and documentation since that will add more value than doing it after implementing the whole algorithm<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
</span>On things like code indentation, you may want to look at<br>
clang-format. It may take a little while to get a format definition<br>
file that matches Xapian's code layout, but you can then run it<br>
regularly so you aren't spending ages fixing things up later. (The<br>
sooner you fix any indentation issues, the faster you'll get familiar<br>
with indenting things in the style of Xapian.)<br>
<br>
(We don't have a clang-format file at the moment, but if you were to<br>
make one as part of this project, we could include it for people in<br>
future.)<br>
<span class=""><br></span></blockquote><div><br></div><div>I wouldn't mind making a clang format file as a part of a pre-GSOC exercise too! It can just help me get used to the indentation style and the way the code is laid out in Xapian.<br></div><div>Also, is there any other way I can start contributing to the project or anything that I can go ahead with during this period?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I've tried to breakdown the timeline out here but I'm sure that this is<br>
> still not perfect enough. So I'd love it if you could tell me where I am<br>
> going wrong and what more detail I could provide so I can think about it<br>
> and get back to you.<br>
<br>
</span>What you have now is a lot better than your previous timeline --<br>
hopefully you feel that it's more structured as well. I think at this<br>
point the best move is to update your draft, and (in a few hours) open<br>
an application on the GSoC website, at which point we can discuss<br>
things further.<br>
<span class=""><br></span></blockquote><div>Thanks James!<br></div><div>I will be sending across my first proposal in a few hours from now! Hoping for constructive criticism on the same! <br></div></div><br></div></div>