Dichotomous variables are handled in diverweb like Categorical variables and they need to be treated as their own thing

[Viqsi]

This might be Not A Bug and is extraordinarily vague, and so I have been hesitating to put it in the tracker. There have been vague reports of user tests with dichotomous variables (including by @WValenti) not behaving as expected or behaving "oddly" in diverweb, and so I need to take a look-see at it.

If nothing else, this might give me a chance to finally use the "invalid" label on an issue. ;)

[Viqsi]

Out of the list of dichotomous variables currently available I picked I18000 because, well, it's easy to remember.

The "Top Answers" details do a neat job of showing the "is there semantic meaning here?" puzzle @WValenti has previously described:

I think the design intent, per prior discussion, is to mask all of those answers as effectively "yes" and treat 'em as such throughout the system, and then somehow warn the user that actual downloaded values aren't actually that simple if a dichotomous variable is included in a varset for download. (Right now, dichotomous variables are treated as mostly indistinguishable from categorical, because of an early misunderstanding on my part).

[Viqsi]

...it immediately occurs to me that this is going to make custom vars involving dichotomous variables Very Very Interesting.

[Viqsi]

Very Very Interesting is the wrong term. More like "presently impossible", because custom vars effectively require more than one state to pick from. Ascertain Pedigrees would be easier, but require custom code since right now the only constraint they support is "is equal to".

At this point I'm looking at punting on the custom vars decision 'till Second Public Release, and re-investigating just how involved making it work for Ascertain Pedigrees would be. (If it gets too involved, I just might have to punt on it too...)

[Viqsi]

Ascertain Pedigrees was ultimately doable, so there's also a diverRPC commit incoming.