[EpiData-list] RR in TABLES command
epidata-list at lists.umanitoba.ca
epidata-list at lists.umanitoba.ca
Thu Jul 12 18:55:56 CDT 2007
Regarding Pedro Arias' question
Couldn't the default display for TABLES VAR1 VAR2 be NN at the 'a' cell, and YY for
TABLES VAR1 VAR2 /RR ?
----- Mensagem original ----
De: "epidata-list-request at lists.umanitoba.ca" <epidata-list-request at lists.umanitoba.ca>
Para: epidata-list at lists.umanitoba.ca
Enviadas: Quarta-feira, 11 de Julho de 2007 18:00:51
Assunto: EpiData-list Digest, Vol 45, Issue 3
I have a general question regarding the layout for the output of the
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
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,
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:
RANGE 1 99
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?
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
So no need for EPITABLE - just use TAB OUTCOME EXPOSURE /RR /SD
> 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
EpiData-list at lists.umanitoba.ca
Novo Yahoo! Cadê? - Experimente uma nova busca.
More information about the EpiData-list