#319 hfst-lookup [...cyclic...] line please add weight field

[Jussi Piitulainen]

This is very minor. Noticed a line in hfst-lookup when preparing ticket #318. Warning of a cycle. Would appreciate if that line had three fields like all other content lines have. Add an inf weight?
For the convenience of any scripts further down a pipeline. (Attached is the output file from the other ticket that contains the observed instance.)

HFST info version: 0.1
HFST packaging: hfst 3.8.3
HFST version: 3.8.3
HFST long version: 300080002
HFST configuration revision: $Revision: 4409 $
OpenFst supported
SFST supported
foma supported
Unicode support: no (hfst)

[Jussi Piitulainen]

The attachment is plain text, not a "bin" file. Is there a way to declare it's type other than renaming it?

[Sam Hardwick]

It seems wrong to use eg. std::numeric_limits<weight>::infinity() here, because there's no guarantee the weight would overflow (in the example it stays at zero, and negative underflow is another possibility). In fact there can be infinitely many results with more than just one weight.</weight>

Also, the cyclic row isn't a result otherwise either, since [...cyclic...] doesn't represent output.

An idea: that line could be written to stderr rather than stdout. Thoughts?

I don't know of a way to control the attachment file type on sf.

[Anonymous]

Good points. I'm only worried about (1) scripts that expect to get three
fields in each analysis suddenly getting two and not knowing what to do
with them and (2) the number of analysis blocks going out of synch with
input tokens.

As far as I can see, stderr is a good stream for this message (the message
contains the input token so it's perfectly informative on its own) and as
long as you leave a non-zero number of analyses in stdout, the output is
as usable as it can be.

On Mon, 19 Oct 2015, Sam Hardwick wrote:

It seems wrong to use eg. std::numeric_limits<weight>::infinity() here, because there's no guarantee the weight would overflow (in the example it
stays at zero, and negative underflow is another possibility). In fact there can be infinitely many results with more than just one weight.</weight>

Also, the cyclic row isn't a result otherwise either, since [...cyclic...] doesn't represent output.

An idea: that line could be written to stderr rather than stdout. Thoughts?

[Flammie Pirinen]

yeah, stderring that would work fine, the current format was just first I thought of at the time so it can be changed to whatever, I don't think xerox has anything for that situation and no one would expect this one, but might be worth checking out.