Xapian devel - Aug 2016 - Letor: Feature sub-classes question

Hello James,

I am working on breaking down Features into sub-classes. Should each of the
features get their own sub-class, or should the grouping be done according
to type? i.e. query-document pair dependent, query-dependent and document
dependent sub-classes.

Using this approach makes more sense if we plan to add support for user to
include query-dependent and document-dependent features in future (we only
support query-doc dependent features at present), however these will remain
empty till the time we don't add features into them.

Regards,
Ayush
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xapian.org/pipermail/xapian-devel/attachments/20160808/d047db40/attachment.html>

On Mon, Aug 08, 2016 at 02:32:01PM -0400, Ayush Tomar wrote:
> I am working on breaking down Features into sub-classes. Should each of the
> features get their own sub-class, or should the grouping be done according
> to type? i.e. query-document pair dependent, query-dependent and document
> dependent sub-classes.
> 
> Using this approach makes more sense if we plan to add support for user to
> include query-dependent and document-dependent features in future (we only
> support query-doc dependent features at present), however these will remain
> empty till the time we don't add features into them.
So I think the main driver for this is going to be: how in both cases
would you choose which features to use? If everything is its own
class, you just pass start/end iterators over objects. If there's a
QueryDocumentPairFeatures class, how would you say "use *this* one but
not *that* one"?

It feels like grouped would be the worst of both worlds to me, but
maybe I'm missing something.

There's also not a huge point in building empty classes, so I'm not
sure how grouped would be significantly different from what we have now.

J

-- 
  James Aylett, occasional trouble-maker
  xapian.org

Yes, grouped feature classes seem like a pointless level of abstraction.
You're right that it wouldn't allow selecting which features to use from
within a group class, and would basically bundle everything together, which
is not what we want.

On Tue, Aug 9, 2016 at 8:09 AM, James Aylett <james-xapian at
tartarus.org>
wrote:
> On Mon, Aug 08, 2016 at 02:32:01PM -0400, Ayush Tomar wrote:
>
> > I am working on breaking down Features into sub-classes. Should each
of
> the
> > features get their own sub-class, or should the grouping be done
> according
> > to type? i.e. query-document pair dependent, query-dependent and
document
> > dependent sub-classes.
> >
> > Using this approach makes more sense if we plan to add support for
user
> to
> > include query-dependent and document-dependent features in future (we
> only
> > support query-doc dependent features at present), however these will
> remain
> > empty till the time we don't add features into them.
>
> So I think the main driver for this is going to be: how in both cases
> would you choose which features to use? If everything is its own
> class, you just pass start/end iterators over objects. If there's a
> QueryDocumentPairFeatures class, how would you say "use *this* one but
> not *that* one"?
>
> It feels like grouped would be the worst of both worlds to me, but
> maybe I'm missing something.
>
> There's also not a huge point in building empty classes, so I'm not
> sure how grouped would be significantly different from what we have now.
>
> J
>
> --
>   James Aylett, occasional trouble-maker
>   xapian.org
>
>

-- 
----------------------------------------------------------------------------
Kind Regards,
Ayush Tomar | My Webpage <http://ayshtmr.xyz> | LinkedIn
<https://in.linkedin.com/in/ayushtomar>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xapian.org/pipermail/xapian-devel/attachments/20160809/36292e78/attachment.html>