specifying response values with squiggly brackets

[COLOR=black]In the MediaLab help files, the "Labels (Questionnaire Files)" page suggests that you can recode Multiple Response answers by adding a bracketed value (e.g., {2}) after the Text label. [/COLOR]
[COLOR=black][/COLOR]
[COLOR=black]However, I find that when I do this, e.g.:[/COLOR]
[COLOR=#000000] I am a student {1}[/COLOR]
[COLOR=#000000] I am a TA {2}[/COLOR]
[COLOR=#000000]then "1" and "2" are always written in the .csv files, whether the item was selected or not. (The Response Time data shows whether an item was touched, but not the participant could have checked it then un-checked it.) [/COLOR]
[COLOR=#000000][/COLOR]
[COLOR=#000000]This seems like a bug, since the data doesn't allow me to distinguish between those who checked a box and those who didn't. -- Or have I misunderstood something?[/COLOR]

I've never heard of this before, but it makes sense. [I]Technically[/I], it's not a bug. Normally, a "0" is written to indicate that a value was not chosen or a "1" to indicate that it [I]was[/I] chosen. Explicitly asking to have a "1" or "2" written instead of the boolean type data--does just that. But, in practice, yes, this seems like an odd and unexpected result. The only use for it, that I can think of offhand, would be in the case where you are allowing only 1 response via the (r1-1) parameter. In such a case, the actual response is written to the data file in a single variable, rather than one variable for each case. Then, I think the recoding could be practical. Not sure of an easy solution to avoid the problem of it being an unexpected outcome in other cases.

I think this might be the same issue as was described in a previous post: [URL="http://www.empirisoft.com/support/showthread.php?t=1298&highlight=recode"]http://www.empirisoft.com/support/showthread.php?t=1298[/URL]

I expected to see the specified {} value if the selection was checked, and the missing data value (99 or whatever) if the item was not checked.

Whether or not it's "technically" a bug, it's a real problem from the experimenter's standpoint, because using the squiggly bracket method on multiple response items (without the r parameter) produces meaningless data.

At any rate, the current Help files do not make the "explicitness" clear; it only says you can specify an alternate value for a given response item, and not what happens when the item is [U]not[/U] selected. I hope you'll at least update the help files to clarify this.

Thanks!

Thank you for the feedback--I agree totally. At the very least we will update the documentation for the next version. Hopefully, we can think also of a way to deal with this while maintaining backward compatibility for anyone who counts on the program to act this way. Unfortunately we need to consider that because we don't have any way to know if such users exist.