[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 ?

best regards,
Fúlvio
----- 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

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
>   



________________________________________
EpiData-list at lists.umanitoba.ca
http://lists.umanitoba.ca/mailman/listinfo/epidata-list





       
____________________________________________________________________________________
Novo Yahoo! Cadê? - Experimente uma nova busca.
http://yahoo.com.br/oqueeuganhocomisso 


More information about the EpiData-list mailing list