This came up in today's chat about missing data. Since "is missingness enabled?" is a flag that sticks to a tree sequence and changes some things about how tskit works with it (including in ways we have not yet thought about or implemented), perhaps that flag should stick to it persistently, and be written out and read from .trees files. We agreed that this is not needed in 0.3.0, and since it's a bunch of work to change the file format, it should be pended until we understand the issues better. However, the next time that we're revising the file format for some other reason, we ought to opportunistically add in this "is missingness enabled" flag to the file format at that time, for future use however we see fit.
@jeromekelleher @petrelharp @benjeffery
Yep, that seems like a good idea to me @bhaller - we should definitely think hard about this when we get to implementing missingness in the stats calculations.
Yeah - I'm not sure that we actually want this flag. We'll need to think it through.
Yeah - I'm not sure that we actually want this flag. We'll need to think it through.
There's certainly no harm in adding it to the file format the next time we revise that, right? But whether/how we would want to actually use that information, when we read the TS back in later, do analysis on it, etc., is an open question. At this point I'm just advocating for persisting the flag, opportunistically, so we have it if we decide that we want to use it later.
Adding a tsk_flags_t flags field to tsk_table_collection_t would prob be the way to do this, giving room for future flags and defaulting to zeros for legacy files.
Most helpful comment
Adding a
tsk_flags_tflagsfield totsk_table_collection_twould prob be the way to do this, giving room for future flags and defaulting to zeros for legacy files.