worldbank / iefieldkit

Stata commands designed for Impact Evaluations field work. These are tools that are used during/after a survey in the field for data quality monitoring.
MIT License
39 stars 18 forks source link

iecorrect #167

Closed luizaandrade closed 2 years ago

bbdaniels commented 3 years ago

Help file needs a bit more work. Some pieces that are immediately obvious:

Options descriptions Screen Shot(208)

Examples Screen Shot(209)

bbdaniels commented 3 years ago

replace option doesn't seem to work, but I am not sure if it is supposed to be able to overwrite a template

Screen Shot(210)

bbdaniels commented 2 years ago

Solution to the above:

To select the observations, you have to type if x==float(1.1). Same for doubles, presumably.

https://blog.stata.com/2012/04/02/the-penultimate-guide-to-precision/

luizaandrade commented 2 years ago

Solution to the above:

To select the observations, you have to type if x==float(1.1). Same for doubles, presumably.

https://blog.stata.com/2012/04/02/the-penultimate-guide-to-precision/

resolved in #203

luizaandrade commented 2 years ago

There is a small issue with the "other" tab. First, I would expect that it would allow the user to provide value labels for the new categorical variable.

Well, this is an iecodebook functionality. iecorrect only changes the data itself, it does not create labels. I would prefer to not have two commands that do the same thing, or it can become tricky to maintain. I'd rather add a note in the help file pointing to iecodebook for that. What to you think?

Second, if the "strvalue" column is left blank, it deletes the contents of the string variable. I would expect that this would leave it unedited.

I see your point. The point of this column is to edit the value of the string, and that often means deleting the content after recoding it, at least in how I use it. I think, however, we can simply remove this column so that all changes to string variables can only be done in the string tab. What do you think?

bbdaniels commented 2 years ago

Solution to the above: To select the observations, you have to type if x==float(1.1). Same for doubles, presumably. https://blog.stata.com/2012/04/02/the-penultimate-guide-to-precision/

resolved in #203

This isn't quite right -- it needs to check the underlying data type of numeric variables and act appropriately, using the float() function for floats and using the double() function for doubles I believe. I'm not sure what to do in all other cases -- but we certainly would not want to check/pass a float() value against/into an int variable as this might do! We may however want to return an error if a non-integer value is attempted to be used with an integer variable.

bbdaniels commented 2 years ago

There is a small issue with the "other" tab. First, I would expect that it would allow the user to provide value labels for the new categorical variable.

Well, this is an iecodebook functionality. iecorrect only changes the data itself, it does not create labels. I would prefer to not have two commands that do the same thing, or it can become tricky to maintain. I'd rather add a note in the help file pointing to iecodebook for that. What to you think?

I agree. I would even go a little farther and print a note after execution if this feature is used, reminding the user to apply value labels, since it will be soooo easy to lose track of categories if they don't do it right away.

Second, if the "strvalue" column is left blank, it deletes the contents of the string variable. I would expect that this would leave it unedited.

I see your point. The point of this column is to edit the value of the string, and that often means deleting the content after recoding it, at least in how I use it. I think, however, we can simply remove this column so that all changes to string variables can only be done in the string tab. What do you think?

That works great! I definitely don't think this tab should be editing the underlying string.

bbdaniels commented 2 years ago

One last feature request for error handling in #229 and a small comment in #228 which is just to confirm functionality as intended. Otherwise this looks good from me, great work!