- EpiData-list - University of Manitoba Mailing Lists

Sumfreq and Sumtables
by epidata-list＠lists.umanitoba.ca 03 Jun '06

03 Jun '06

1 0

Sumfreq and Sumtables
by epidata-list＠lists.umanitoba.ca 01 Jun '06

01 Jun '06

> Please discuss on the list if the /weight= x principle is what we > want. I have met various > needs for weighting, but assume that the simple frequency weight shown > here is sufficient. > > Regards > Hi everybody, I think there are two different situations where a WEIGTH variable should be necesary: The first situation is when working with data from epidemiologial surveillance. It is very usual that data sent to a upper level (for example National level from a regional level) are sent in an aggregated format. In order to be able to analyze this kind of data a command in the form of sumfreq disease /sum=COUNT (where COUNT is the weigth variable) is essential. The second situation is when working with data comming from a complex sampling design (Not a simple random-sample strategy). In this case it is necesary to specify not only the WEIGHT variable, but the STRATA and Primary Sampling Unit. The sintax for this situation could be something like: CFREQ VAR1 /W=WEIGHTVAR /S=STRATVAR /PSU=PSUVAR Greetings, Pedro Pedro Arias Bohigas John Ericssons gatan, 12 5 tr 112 22 Stockholm Sweden Phone (cell)+46(0)734421130

1 0

Few suggestions about Epi Analysis
by epidata-list＠lists.umanitoba.ca 01 Jun '06

01 Jun '06

Dear Jens, Greetings. I hope Epi Analysis is making good progress. The graphic features are excellent addition.the Epi Ananlysis I tested old PGMs of Epi6 in Epi Analysis. Few more tweakings are further required. You know that long PGMs extendimg into pages are dealt fairly easily by Analysis.exe of Epi6.04. In Epi Analysis, when a particular set of "SELECT" commands do not select any records, the "program aborts the operation" and does not process rest of the commands of the PGM. "RECODE" command does not create e.g. age groups from age data. I strictly adopted the synytax of Epi Analysis. Analysis.exe (323 kb) of Epi info 6.04d could move mountains. It is not appropriate to compare Epi6.04 with Epi Analysis of 1.2. However Epi6 will always remain the inspiration. Long pending requirement of the portability of Epi info has been met by small sized Epidata, Epi-analysis and Flash memmory devices. Kindly keep the work going. Sincerely, Dr. Shavinder Singh

1 0

[Fwd: RE: linux and Epidata]
by epidata-list＠lists.umanitoba.ca 01 Jun '06

01 Jun '06

1 0

Sumfreq and Sumtables
by epidata-list＠lists.umanitoba.ca 01 Jun '06

01 Jun '06

1. Sumfreq / Sumtables (epidata-list(a)lists.umanitoba.ca) >Has anyone an idea on how to replace Sumfreq (or sumtables) with Epidata >analysis? >Thanks! >Gilles / Paris > > > > I understand the sumfreq and sumtables command to be able to do a frequency or crosstable but instead of counting observations the counting would be made with another variable. Example from testdata: read bromar tab agegrp . freq agegrp agegrp Age (10 year intervals) No. % 10 35 0.92 20 489 12.92 30 1198 31.64 40 1337 35.31 50 642 16.96 60 75 1.98 70 9 0.24 80 1 0.03 Total 3786 100% We can now collapse or aggregate the data file like this on agegrp: . agg agegrp /close //"agg" is the same as "aggregate" AGEGRP N 10 35 20 489 30 1198 40 1337 50 642 60 75 70 9 80 1 Now if we do a frequency on agegrp: agegrp Age (10 year intervals) No. % 10 1 12.50 20 1 12.50 30 1 12.50 40 1 12.50 50 1 12.50 60 1 12.50 70 1 12.50 80 1 12.50 Total 8 100% We have one observation for each value of agegrp. 8 records or observations in total. By listing all observations we can see that the variable N tells us how many are in each agegrp: list AGEGRP N 10 35 20 489 30 1198 40 1337 50 642 60 75 70 9 80 1 So in principle we would like a "backwards" aggregate where the weight or counting is by "N":: . freq agegrp /weight=n / Age (10 | year | intervals) | Freq. Percent ------------+-------------------- 10 | 35 0.92 20 | 489 12.92 30 | 1198 31.64 40 | 1337 35.31 50 | 642 16.96 60 | 75 1.98 70 | 9 0.24 80 | 1 0.03 ------------+------------------ Total | 3,786 100.00 Unfortunately the table just shown was made in Stata not in EpiData Analysis, but I have added sumfreq and sumtables to the workplan. Please discuss on the list if the /weight= x principle is what we want. I have met various needs for weighting, but assume that the simple frequency weight shown here is sufficient. Regards Jens Lauritsen EpiData Association

1 1

RE: linux and Epidata
by epidata-list＠lists.umanitoba.ca 31 May '06

31 May '06

At the moment EpiData has been testet on SuSE Linus 9.3 and Fedora Core 4. If you are running KDE or Gnome on Conectiva you should be able to run EpiData using the newest version of wine. Probably you will be able to run Wine(EpiData) in other environments as well, but it has yet not been testet. The Wine HQ homepage: http://www.winehq.com/ The download page: http://www.winehq.com/site/download After installing wine, install EpiData. If wine doesn't start when you try opening EpiData, open the terminal/konsole and type: wine EpiData.exe (in the appropriate folder) Known problems using EpiData in wine: EpiData will sometimes refuse to close Errors ind the chk-file can resolut in "strange" behaviour

1 0

Sumfreq / Sumtables
by epidata-list＠lists.umanitoba.ca 29 May '06

29 May '06

Has anyone an idea on how to replace Sumfreq (or sumtables) with Epidata analysis? Thanks! Gilles / Paris

1 0

linux and Epidata
by epidata-list＠lists.umanitoba.ca 25 May '06

25 May '06

I am hard user of the Epidata there is a long time and I am very satisfied with the soft. Now, I wish install Epidata in operacional system Linux (Conectiva a Brazilian version) a lot similar to Mandrake. How to do that ? Epi Analysis is already in Linux working perfectly. Best regards Claudio Teixeira e-mail cteixeira(a)fmc.br ou cteixeira(a)terra.com.br Home page da Fac. de Medicina de Campos http://www.fmc.br 2006-05-25

1 0

Problems with double entry validation - warning
by epidata-list＠lists.umanitoba.ca 23 May '06

23 May '06

During the most recent week we have seen a few problems with double-entry validation. Obiously double entry makes no sense if assumed validation is done, but in practice no validation is taking place. The three situations are: 1. Do NOT use double entry if the command AUTOSEARCH is used in the field which is used for the identification of records. 2. If the field for double entry is computed based on some other fields and that computed field only occurs after entry of a number of fields, then the validation is also problematic. 3. In a relate situation. When creating the file for double entry only the top level entries are created automatically. Not for the lower level files. For the situation number two (Created link field) it is quite obvious that the programme cannot validate entry of records before the "linking field" is created. There is no way to find out with which record to compare values in the other file before the "linking" information is created. For situation one (AUTOSEARCH) the situation is that the "pointer" to a given record might change in the autosearch field therefore creating a complicated "link" situation that changes during a given entry. For the development it is essential that such problems are reported. Following detection they are added to a list of known problems to be solved. It is good practice to verify functionality of any software before doing a lot of work in particular with complicated data structures or situations. Jens Lauritsen EpiData Association

1 0

Double Entry and Autosearch: Danger!
by epidata-list＠lists.umanitoba.ca 22 May '06

22 May '06

After having stuggled with the problem that double entry did not work properly we found a solution to the following problem: When we tried to double enter data using the "match records by fields" option, EpiData did only check the data of the first record entered. Starting with a second record we only accidentally noticed that EpiData did actually not check the data. We tried different things to overcome this problem but EpiData behaved erratic if we went back to an already entered record. This behavior is dangerous because you might think that EpiData checks your data during double entry (all the more if you encountered an entry error in the first record). The solution: If the .REC file to enter data in double check mode uses a .CHK-file, don't use "AUTOSEARCH" (at least not for the field/variable that is used in the "match records by fields" option)! You may use "KEY UNIQUE", instead. Current EpiData version: 3.1 (120306) Dirk ************************************************* Dr. Dirk Enzmann Institute of Criminal Sciences Dept. of Criminology Edmund-Siemers-Allee 1 D-20146 Hamburg Germany phone: +49-(0)40-42838.7498 (office) +49-(0)40-42838.4591 (Billon) fax: +49-(0)40-42838.2344 email: dirk.enzmann(a)uni-hamburg.de www: http://www2.jura.uni-hamburg.de/instkrim/kriminologie/Mitarbeiter/Enzmann/E… *************************************************

1 0