Hi,
I think an interface to configure whether the input is truncated or not, would be pretty handy.
Of course one could handle the truncation before passing the texts into the metric, but that seems like unnecessary overhead for a use case which could appear quite often.
I have seen one fork started fiddling in this direction, but I assume this approach is probably not working. They configured the tokenizer to perform truncation, but if I see things right, the input text is not only processed using the tokenizer. For example DS_Sent in line 153: the creation of the entity graph.
I am wondering what you think would be the best approach to handle this issue?
I assume it would be best to handle the truncation of the text as early as possible, so not every code bit which uses it has to be altered and blown up. So I see 2 options:
- Pass a truncation argument to DiscoScorer() which is then used in all the methods (LexicalChain, DS_SENT_NN ...) to decide truncation.
This would make all calls of one scorer be aligned and the individual calls remain with their easy interface.
But i am not sure if this is flexible enough and whether truncation makes sense for the non DS_... methods.
- Add a truncation argument to the 4 DS_... methods.
Both methods would perform truncation in the scorer file and pass the preprocessed texts into the code DS logic. The disadvantage is that one has to tokenize, truncate and repack the tokens into text, which seems a bit of computational overhead.
Hi,
I think an interface to configure whether the input is truncated or not, would be pretty handy.
Of course one could handle the truncation before passing the texts into the metric, but that seems like unnecessary overhead for a use case which could appear quite often.
I have seen one fork started fiddling in this direction, but I assume this approach is probably not working. They configured the tokenizer to perform truncation, but if I see things right, the input text is not only processed using the tokenizer. For example DS_Sent in line 153: the creation of the entity graph.
I am wondering what you think would be the best approach to handle this issue?
I assume it would be best to handle the truncation of the text as early as possible, so not every code bit which uses it has to be altered and blown up. So I see 2 options:
This would make all calls of one scorer be aligned and the individual calls remain with their easy interface.
But i am not sure if this is flexible enough and whether truncation makes sense for the non DS_... methods.
Both methods would perform truncation in the scorer file and pass the preprocessed texts into the code DS logic. The disadvantage is that one has to tokenize, truncate and repack the tokens into text, which seems a bit of computational overhead.