expand_households fails if zone IDs are floats

[bstabler]

In the example below, the zone IDs in the control data file are stored as floats even though they are whole numbers (i.e they are 5.0 instead of 5 for example). This is fine for some of the steps, but is a problem for expand_households, specifically this line. We should fix this by maybe checking for this on input and/or cast the zone IDs to int(). I confirmed expand_households works if I remove all ".0" from the file.

[toliwaga]

How did this csv file end up with floats in it - was it created by populationsim? (If so, then we should fix that bug?)

Or was it user pilot error? (In which case, there are probably lots of places that could happen and we should talk about whether this is an eventuality that we should allow generally - because it doesn't make sense to just fix it in one place and not otehrs...)

[bstabler]

This is a user created input file. I think we should check for this issue at the beginning when we read in inputs.

[toliwaga]

For every field in every file that ought to have integers? Do we check to make sure it was a float int and not a float that will be rounded/truncated (in which case maybe it is an error?)

Just wondering why we are fixing this particular random bad input?

[bstabler]

We don't have to fix bad data, but I think we should catch bad data / do more error checking / add more informative error messages / etc. It took me quite some time to figure this out and I'm pretty familiar with PopulationSim.

[toliwaga]

Might as well address it opportunistically then - but we should throw an error if the values change when coerced to ints.

[bstabler]

sounds good

[bstabler]

This is also true for the geo crosswalk file as well - the data needs to be ints. We should fix this.

[nick-fournier-rsg]

late follow on.... but I have a fix on a fork. https://github.com/nick-fournier-rsg/populationsim/tree/v0.6.0

very long integers (e.g. full BG ids) resolved to NA or other erroneous values. My solution was to explicitly use np.int64 instead of base int which I think defaults to int32 or maybe something smaller.