Dear all,
I have a general question regarding the layout for the output of the TABLES command.
In version 2 (112) the default option for TABLES is sorted in ascending order. That means that when using boolean fields TABLES will display N,N in the top left cell of a 2 x 2 table, because internally NO=0 and Yes=1. (Jens, is that correct?)
When asking for RR (TABLES VAR1 VAR2 /RR) what we get is the RR of being N in the outcome if you are N in the exposure. Which is clearly the inverse of what we usually are looking for. But because most of the statistical/epidemiological software dispay the table in the other way (Y,Y on the top left cell) EpiData can misslead the users with its results. (obviously users should read the table, but...). And we have /SD as option to change that
My question is: Should EPiData follow the general rule of displaying YY in the too left cell?. (and therefore calculating the RR that usually we are interested in)
Jens has a point saying that if we change that when we are not interested in RR but only in the numbers and %, most of the program follow the rule of sorting the values in ascending order and that if we want to follow this rule we will need an EPITABLE command (in version 2 he is trying to get ride of innecesary commands). I think we alreday have the EPITABLE command, it is TABLES V1 V2 /RR
I would appreciate if can comment on that. Version 2 is almost ready, but i think this is an important issue.
Hope my explantion and question is clear.
Thanks a lot, Pedro Arias EpiData Spanish cotranslator
I am checking the entry in some files using the double entry verification. The data are from a family study so the unique identifying information is a family ID (4 digits), an individual ID (2 digits), and informant ID (in some cases, people will be reporting on others. Each data record, then, is uniquely identified by these 8 digits. I created a key for the entry check file as follows:
rhinf RANGE 1 99 MUSTENTER after entry rhukey=famid*10000+indid*100+rhinf end END
rhukey noenter key unique end
This works fine to prevent entering the same record twice.
I'm trying to use the variable rhukey as the match variable in the double entry program. I have intentionally entered non-matching data, but Epidata doesn't recognize any discrepancies. Is there a problem with a key that is created in the dbl file as well as in the original file?
Thanks.
Richard Herrell NIMH
--------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today!
I prefer the current method as there is no doubt about what the syntax means (lower values in top left unless you specify /SD) and the /SD switch provides a means of inverting the order. Many people code variables as 1=Yes 2=No, which gives a proper RR without the /SD switch. Many others use 0=No 1=Yes, which requires /SD. Since EpiData internally treats Booleans False as 0 and True as 1, the current approach allows programming that does not require exceptions. User help and guides should point this out. The TAB output clearly identifies the meaning of the RR, which is something a number of us requested. This is something that came into later versions of EpiInfo to help the user avoid misunderstanding.
So no need for EPITABLE - just use TAB OUTCOME EXPOSURE /RR /SD
Jamie
My question is: Should EPiData follow the general rule of displaying YY in the too left cell?. (and therefore calculating the RR that usually we are interested in)
Jens has a point saying that if we change that when we are not interested in RR but only in the numbers and %, most of the program follow the rule of sorting the values in ascending order and that if we want to follow this rule we will need an EPITABLE command (in version 2 he is trying to get ride of innecesary commands). I think we alreday have the EPITABLE command, it is TABLES V1 V2 /RR
participants (1)
-
epidata-list＠lists.umanitoba.ca