May 2006 - EpiData-list - University of Manitoba Mailing Lists

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 01 Jun '06

01 Jun '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

Can a certain feature be implemented or extended in EpiData ?
by epidata-list＠lists.umanitoba.ca 19 May '06

19 May '06

Dirk created a very precise description of the problem of the 64k size limitation of a .not file. and asks : > Question: Is there any other solution? Is it possible to improve > EpiData such that longer .not-files are possible? Since we are in control of the software in principle anything can be extended or adapted. As previously announced a conversion plan of EpiData Entry and Analysis to opensource has been made and we are looking for financing sources for the plan. The overwhelming number of downloads, increasing number of scientific publications, field reports and courses made with EpiData Software indicates the relevance of extending and securing the software. The total cost of the reprogramming of the entry module and adaptation of analysis amounts to the price of less than 250 one year licenses for SPSS or a similar number of single user permanent licenses for Stata. (300.000 Euro). In the rewriting all known problems and limitations will be considered, including the size problem of .not files. And I am sure many of them will be fixed. Anyone having knowledge of foundations, larger projects or other sources for funding should contact me directly for further information. Once something starts coming in I will create a "barometer" of achieved funding on the website. Kind regards Jens Lauritsen EpiData Association. "J L at epidata.dk " (remove spaces)

1 0

RE: [EpiData-list] size of EpiData note files
by epidata-list＠lists.umanitoba.ca 18 May '06

18 May '06

The same problem occurs with .chk files that exceed a certain size. Currently I need to split .qes and .chk files in several parts and connect them with RELATE. For our long questionnaires, this is only in some cases due to the 999 lines limitation for the .qes file, but even if the questionnaire fits 999 lines, I need to split the .qes and .chk files because of the fact that the .chk files get truncated at their maximum size. Is it possible to improve EpiData on this point? EpiData is such a useful program for our surveys in the field. It would be really be a great improvement if this limitation was not there! Thanks a lot! Dr Henrica A.F.M. (Henriette) Jansen Epidemiologist, WHO Multi-country Study Violence against Women Department of Gender, Women and Health Tel direct: +41 22 791 3106 Fax direct: +41 22 791 1585 Mobile: +41 78 730 3035 E-mail: jansenh(a)who.int Website: http://www.who.int/gender/violence/multicountry/en/ -----Original Message----- From: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Sent: 17 May 2006 20:06 To: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] size of EpiData note files Unfortunately, if the size of the .not-files into which user-notes and EpiData generated notes are written exceeds about 64k, the coders can't enter further comments (although notes generated "automatically" via .chk-file commands will still be added). One solution to this problem is to close EpiData and to rename the .not-file. A new start of EpiData will then generate a new .not-file automatically. However, this solution is error prone, risky, and tedious: - you have to keep track of the size of the .not-files so that the coders can always enter their comments; - you may not overwrite renamed .not-files accidentally; - you have take care to collect/archive *all* renamed .not-files; - the solution is difficult to implement if the coders work independly and should not change files directly by themselves. Question: Is there any other solution? Is it possible to improve EpiData such that longer .not-files are possible? Current EpiData version: 3.1 (120306) [Sorry for any inconvience: I send this mail a second time because the first went not through - my email-address has changed and I was not recognized as a "member" of the list] 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/Enzman n/Enzmann.html *************************************************

1 0

size of EpiData note files
by epidata-list＠lists.umanitoba.ca 17 May '06

17 May '06

Unfortunately, if the size of the .not-files into which user-notes and EpiData generated notes are written exceeds about 64k, the coders can't enter further comments (although notes generated "automatically" via .chk-file commands will still be added). One solution to this problem is to close EpiData and to rename the .not-file. A new start of EpiData will then generate a new .not-file automatically. However, this solution is error prone, risky, and tedious: - you have to keep track of the size of the .not-files so that the coders can always enter their comments; - you may not overwrite renamed .not-files accidentally; - you have take care to collect/archive *all* renamed .not-files; - the solution is difficult to implement if the coders work independly and should not change files directly by themselves. Question: Is there any other solution? Is it possible to improve EpiData such that longer .not-files are possible? Current EpiData version: 3.1 (120306) [Sorry for any inconvience: I send this mail a second time because the first went not through - my email-address has changed and I was not recognized as a "member" of the list] 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

size of EpiData note files
by epidata-list＠lists.umanitoba.ca 17 May '06

17 May '06

Unfortunately, if the size of the .not-files into which user-notes and EpiData generated notes are written exceeds about 64k, the coders can't enter further comments (although notes generated "automatically" via .chk-file commands will still be added). One solution to this problem is to close EpiData and to rename the .not-file. A new start of EpiData will then generate a new .not-file automatically. However, this solution is error prone, risky, and tedious: - you have to keep track of the size of the .not-files so that the coders can always enter their comments; - you may not overwrite renamed .not-files accidentally; - you have take care to collect/archive *all* renamed .not-files; - the solution is difficult to implement if the coders work independly and should not change files directly by themselves. Question: Is there any other solution? Is it possible to improve EpiData such that longer .not-files are possible? 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