BED spec doesn't handle give an opinion on NaN in numeric fields

[cjw85]

Section 3.3 of the specification has:

and links to "IEEE Standard for Binary Floating-Point Arithmetic. IEEE 754–1985, 1985". This IEEE specification does not specify how NaNs should be represented as strings (from section 5.6).

However, the above specification is superceeded by a 2008 version and then also a 2019 minor revision. Section 5.12.1 of the 2008 edition provides more details:

language-defined one of “nan” or a sequence that is equivalent except for case

[jmarshall]

(See also #409 re practicalities encountered when we added NaN etc to VCF's similar descriptions of text-based float fields.)

[cjw85]

Thanks John, I've heard anecdotally that people are using . when they want to mean absent data (as common in VCF fields), but that's not quite the same as NaN. The linked issue is a bit of a non-issue in some respects because just eliding the record where a NaN is occuring would keep people happy.

[cjw85]

@michaelmhoffman When the specification was written was it a deliberate choice to reference an outdated version of the IEEE document, that doesn't say anything about representation of NaN?

Should BED simply follow the VCF pull request John has linked?

[michaelmhoffman]

This was not a deliberate choice. However, section 3 is recommendations, and it is not, strictly speaking, normative. I don't want to get into this level of detail for a change to the recommendations. Better to include them in a future version of a BED standard, where they are normative. (And I think it is quite sensible to use the latest IEEE standard then.)

I am planning on leaving this issue open, as it will be a good reminder for this when considering in-band methods for specifying custom field types.