<div dir="ltr">Hi All,<div><br></div><div>Thank you for accepting the proposal.</div><div><br></div><div>For the next couple of days, I plan to read again the related papers keeping the implementation in mind and understand Xapian code(backend part).</div><div><br></div><div>Please suggest if any other activity I can do.</div><div><br></div><div>Regards,</div><div>Guruprasad</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 4:05 PM, Guruprasad Hegde <span dir="ltr"><<a href="mailto:guruhegde1308@gmail.com" target="_blank">guruhegde1308@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Please find the draft proposal with this link: <a href="https://github.com/guruhegde/xapian-gsoc-proposal" target="_blank">https://github.com/<wbr>guruhegde/xapian-gsoc-proposal</a><div>It is still work in progress.</div><div><br></div><div>Question: If we index math terms(symbol pair tuples) in the same DB along with the text data, do you think, adding field prefix(making a new one) implicitly for math terms, help in some way w.r.t performance for cases like searching only text terms or only math terms?</div><div><br></div><div>Regards,</div><div>Guruprasad</div><div><div class="h5"><div> </div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 26, 2018 at 3:27 PM, Gaurav Arora <span dir="ltr"><<a href="mailto:gauravarora.daiict@gmail.com" target="_blank">gauravarora.daiict@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class="m_-765199130380659419gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I thought if I start with the MathML as input and build the core, then I can extend the system to support any other query/document type by looking for third party tools available for c++. At the moment, I don't have any idea about this. What do you think? <br></div><div><br></div><div>We can look for the option in bonding period too. For now, I can make latex to mathml as first step in proposal and shuffle the steps later right?</div></div></div></div></blockquote><div><br></div></span><div>Proposal need to account for doing that. i.e proposal should account that before end of GSOC search through latex should be supported and merged. It can be done anytime. It's perfectly fine to build the core using MathML representation initially.</div><span class="m_-765199130380659419gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Generating symbol layout tree requires implementing parser. I guess it invloves good amount of text processing. Since it's standard problem, I hope it should not be hard, but requires handling many scenarios. I plan to read about the parser and try implementing small examples first in coming days. </div></div></div></div></blockquote></span><div>That would be great :) </div><span class="m_-765199130380659419gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I feel generating symbol pair will be easy once I build the tree.</div><div><br></div><div>Do you think I should come up with some sort of psuedocode in proposal?</div></div></div></div></blockquote></span><div>Would definitely help.</div><span class="m_-765199130380659419gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>With other weight metric implementations available and with existing indexing structure, I feel getting the stats and implementing this would not be hard I feel.</div><div><br></div></div></div></div></blockquote></span><div>A basic check and estimate would help to estimate time this would take to plan the project timeline accordingly.</div><span class="m_-765199130380659419gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I have been working on the draft. I am really sorry about the delay in draft. Hope to make up for that with some good work:)</div></div></div></div></blockquote></span><div>Sooner you show us the draft version would increase your chance of getting feedback from us and improving your proposal. </div></div><span class="m_-765199130380659419gmail-HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><br><div class="m_-765199130380659419gmail-m_-3684750500010328216gmail_signature"><div dir="ltr">- Gaurav Arora</div></div>
</font></span></div></div>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>