search for: vivekp

> It may be worth splitting that part of the $set documentation out into its > own section somehow, because it's getting a bit long - Undoubtedly; $set command has the longest section on the documentation page :) But it would be hard splitting that up because the documentation is organised in a way that each command is really contained in its own specific section. > and the details

> You could do that by identifying the search session instead of the user, > which makes it closer to what we need than to something that might trip you > into privacy concerns. Okay, that would be much better. :) > Third records some information about what sort of query it is — add, > morelike or a plain query. Last provides the estimated match size and then > the HTTP

> The log command will be executed wherever it is in the template. > By "current system user", what do you mean? There'll need to be > write permission for the CGI process, which is probably the same > identity as the web server process. I basically changed the ownership of the /var/log/omega directory to the current user using: sudo chown `whoami` /var/log/omega But I

Hi, In my explorations of Omega codebase, I have found that Omega is currently missing support for newer weighting schemes added in 1.4.1 (BM25+, PL2+, Dir+). I'd submit a PR addressing that but as I think I might be missing something so just wanted to check if there's a particular reason for that? P.S. Finally back after a long week. Been eagerly waiting for a weekend since the

> So I think you should go ahead with SDBN, and not worry about the class > hierarchy. Okay, I'll start with the implementation of SDBN class. > What sort of performance constraints are there on the implementation? > Which language are you proposing building this in? Only major performance constraint would be on the training step in the implementation. Although, SDBN has a

> Hi, Vivek — there isn't any particular reason that I'm aware of. It's > probably worth pointing (in the omegascript documentation) to the part of > the getting started guide which talks about the different weighting schemes If there isn't any reason then I'd like to send in a patch adding support for those weighting schemes in weight.cc and I agree omegascript

> [Please keep discussions on the mailing list.] I accidentally clicked on "Reply" instead of "Reply to all" but later I did send a separate mail to the mailing list. > Thinking about this, the way that CGI works is you set a 'Status' > header which changes this behaviour. So we don't actually need a > new command, just something like: > >

Hello everyone, I have been working on adding support for BM25+ weighting function from the last couple of weeks. Initially, I considered modifying bm25weight.cc to add support for BM25+ function without disturbing functionalities of BM25. But that didn't work out very well. A day or two was spent trying to refactor and debug the same code. Later, I took another approach following the

Hi, Now that the clickstream logging PR (#161) is close to getting merged I'm starting to move onto the next step i.e. the implementation of DBN click model for which I think it'd be best to discuss the approach that I intend to take and the classes required. I'm thinking of starting with the implementation of a base class Model to enable the implementation of DBN click model as its

> > I'm not clear on what the OFFSET really represents. Could you > > please explain a bit? > > Omega paginates results (as does Xapian's MSet, internally). So if > you're displaying the second page of results, you'll need to know > that when building training data. It's affected by TOPDOC and also > by the <>[# CGI variables, but internally to

On Sat, Apr 08, 2017 at 09:11:22PM +0100, James Aylett wrote: > On 8 Apr 2017, at 19:15, Vivek Pal <vivekpal.dtu at gmail.com> wrote: > > >> and the details of which weighting schemes were available in which version > >> isn't a key part of the $set command itself. > > > > Do you suggest dropping that piece of information out? Since the reason behind > > a...

> There's a lot of flexibility already, because the log format is just > omegascript. So I don't think you need to implement a new command to > achieve this. (Although you might need a command to generate the query > id. It depends on how you're going to do that.) Ok, I'll try adapting the existing log command to achieve the kind of logging we want. And, about the

Hi Vivek, I saw your comments on IRC, as noted by olly : *<olly> vivekp: (if you check the logs) - you want: ./trec_index config* *<olly> you want to run the compiled binary (no ".cc") not the source file...* But i guess you are not able to compile the setup. I can write steps and send across how to compile and sample files from config. Most of the fi...

> In case I wasn't clear: I don't think you have to modify the command > at all. Just create a template that uses the command as it currently > works. I thought we needed a new template only for the second log file? To generate the first log file using the existing $log command, I have introduced another $log command in query template that looks like:

Hi James, Thanks for clearing doubts I had earlier. >>if we can introduce the variants using optional parameters that default to >>(effectively) 'off' that might be better than distinct ones, Yes, this will definitely be the better approach for introducing the variants of existing weighting functions. Thanks for the suggestion. Next, I will try to come up with a draft of

Hi James, > ID: some identifier for each query > QUERY: text of the query (when the query is run) > URLs: every URL displayed (or alternatively, the Xapian docid — this > might be easier) > OFFSET: otherwise you'll have difficulty coping with result pages other > than the first page (when this happens, the query ID should probably > remain the same, and when you aggregate

Hi, I spent this week mostly understanding how the existing templates work and setting up Omega CGI on my system to have a better grasp over how things actually look like when using different templates. This helped me look at things associated with logging the click data from a better perspective. As already documented on the project's wiki page, we need the following fields in separater

Hi James, > Isn't this from the query template, ie from the main web page of search > results? (It might make sense from opensearch as well, though.) Yes, you are right; it is the query template. The reason I said opensearch template is that I haven't quite read all sections of the Omega docs and I'm still in the process. Thanks for pointing that out. I'm aiming to cover

Hi Olly. Thanks for your reply to the previous email. To have an appropriate subject I've started this new thread for further discussions. > There's a $log{} command available in Omega templates. We can't log from > the result page template, as the clicks happen after that is used, but we > could make result links redirect via a second Omega template which does > the

Hi, My name is Vivek Pal. I had submitted a proposal on weighing schemes project for GSoC. I'm so glad and excited to be selected for working on this project! I'd like to thank mentors for reviewing & selecting my project proposa,l and letting me be a part of Xapian -- open source community. I'll make sure to keep up with all the expectations and try my best to produce good