kowey
commented
9 years ago Actually, you know what, we're just going to need a proper interface here. We have all these decoders, they all take different keyword args, etc. Nope. Let's nail this down to have a uniform interface. No, not all decoders are going to use/respect all the args. But that's OK. We can document that. What we can't do is predict how 8 or 9 different subtly different function variants are going to behave.
It might look something like this. If I manage to finish this work, I'll see about throwing in a decorator to promote functions to classes
class Decoder(object):
'''
A decoder is a function which given a probability distribution (see below)
and some control parameters, returns a sequence of predictions.
We have a few informal types to consider here:
- a **link** (`(string, string, string)`) represents a link
between a pair of EDUs. The first two items are their
identifiers, and the third is the link label
- a **proposed link** (`(string, string, float, string)`)
is a link with a probability attached
- a **prediction** is morally a set (in practice a list) of links
- a **distribution** is morally a set of proposed links
:param prob_distrib: the proposed links that we would like to decode over
:type prob_distrib: [(string, string, float, string)]
:param config: how we would like this decoder to behave
:type config: :py:class:`DecoderConfig`
:rtype: [[(string,string,string)]]
'''
def __call__(self, prob_distrib, config):
raise NotImplementedError
This is going to bite us in the collective posterior: when
nbest == 1, we return one result; when it's greater than one, we return a list of results.It may be a good idea to think about always returning a list of results, even a singleton list. Code shouldn't have to deal with surprises like this (I think this was a deliberate change we shoehorned in; previous decoders didn't have a notion of nbest)