- EpiData-list - University of Manitoba Mailing Lists

stattables error and test principles.
by epidata-list＠lists.umanitoba.ca 08 Jul '06

08 Jul '06

Susanne Widmar pointed out an "estimation" error in a command: > As you can see the missing values are included in the calculation for > the 90th percentile. It's obviously a bug. However you may not detect > the bug if you're interested in the interquartile range: I quickly ran the same analysis with the most recent build available on the test page which does not show the problems. . version Current version: 1.1 Release 8 (Build 68) Latest public release 1.1 Release 1 (Build 62) . stattables sex /idr=km SEX N NKM P10KM P90KM Kvinde 490 423 18.00 265.00 Mand 3537 3197 0.00 265.00 . stattables sex /iqr=km SEX N NKM P25KM P75KM Kvinde 490 423 42.00 237.00 Mand 3537 3197 36.00 192.00 . describe km if sex = 1 Variable N=490 Sum Mean (95% cfi) Min p5 p10 p25 Median p75 p90 p95 Max KM 423 50288.0 118.88 109.42 128.35 0.0 0.0 18.00 42.00 73.00 237.00 265.00 277.00 286.00 . describe km if sex = 2 Variable N=3537 Sum Mean (95% cfi) Min p5 p10 p25 Median p75 p90 p95 Max KM 3197 330796.0 103.47 100.23 106.71 0.0 0.0 0.0 36.00 71.00 192.00 265.00 265.00 286.00 Apparently the bug shown has been corrected in build 68. - To avoid such errors a comprehensive test suite has been developed for analysis. Currently the test involves testing of around 650 different conditions and a test for the problem above has been added. I will update to a later build very soon to remedy the problem. Known other problems are: Estimation of OR in sparse tables The aggregate (stattables) command can create variable names longer than 10 characters Apart from that I am not aware of current problems of estimation. If other definitive bugs are known (not requests for new functions) please report to the new bug database, found at Http://www.epidata.dk/php/mantis Currently development is focused on "long term plans" including rewriting the software for further documentation and testing, experimentation with collaborative editing of documentation and other aspects of the development plan for 2006-2010. The "in-house" build of analysis has come to 85 now, where build 68 is the latest for public testing. When the current aspects are completely finalised a new build will be placed for testing. One of the many new aspects are more user control over the interface, a completely rewritten table command, which includes exact testing of stratified tables, calculation of gamma coefficient for ordinal data and extensive sorting. Working with summarised data is next in line. Other new aspects are further documentation tools within analysis (value labels, missing value assignment), renaming variables and enhanced control over graphics, e.g. axis and ranges. Kind regards Jens Lauritsen EpiData Association

1 0

Bug in EpiData Analysis
by epidata-list＠lists.umanitoba.ca 06 Jul '06

06 Jul '06

This is an email to the folk at EpiData. In my examples below I'm using the data file bromar.rec, one of the example data files that come with EpiData. The variable km has some missing data (.). This data seems to be correctly treated as missing values for some commands but not for all. One example is the StatTables command. Below is an example of the command I typed into EpiData and the resulting output: . StatTables sex /idr=km SEX N NKM P10KM P90KM Female 490 423 42.00 . Male 3537 3197 32.00 . As you can see the missing values are included in the calculation for the 90th percentile. It's obviously a bug. However you may not detect the bug if you're interested in the interquartile range: . StatTables sex /iqr=km SEX N NKM P25KM P75KM Female 490 423 67.00 265.00 Male 3537 3197 42.00 265.00 If you do a "describe" you can see that 265 is definitely not the 75th percentile. Suzanna Vidmar Senior Research Officer Clinical Epidemiology and Biostatistics Unit Royal Children's Hospital Flemington Rd Parkville Victoria 3052 telephone: +61 3 9345 6372 facsimile: +61 3 9345 6000

1 0

Q on jumping between fields from related tables
by epidata-list＠lists.umanitoba.ca 03 Jul '06

03 Jul '06

Hi, Would anyone be able to help me figure out how I can jump from one field in a child table to a parent table and back? I have related two files and depending on how the survey questions are answered, I need to be able to go from the child file to the parent table and back. It doesn't seem as if the jump function allows one to jump from one field in one table to another field in a different (but related) table. Any help would be greatly appreciated. Regards, Thao ~~~~~~~~~~~~~~~ Ms. Thao T. Nguyen CIESIN, Columbia University Lamont-Doherty Earth Observatory tel: 845.365.8994 fax: 845.365.8922 http://www.ciesin.columbia.edu

1 1

bug tracking possibility - new system in test
by epidata-list＠lists.umanitoba.ca 28 Jun '06

28 Jun '06

In the preparation for compliance with GCP guidelines and general handling of the 2006-2010 development plan it is important to document bugs and issues resolved. A new bug tracking system is in test. Anyone who wishes to participate can sign on as reporter at : http://www.epidata.dk/php/mantis Following the testing further setup is required before the site will be operational: e.g.: definition of categories definition of projects definition of maintainers/managers etc. It the system is approved, then a cleanup will be made before final and further usage. But to me it seems as if the maintenance, running and using of the system should be easy. A few other options has been considered, but they seemed to detailed for the purpose. Kind regards Jens Lauritsen EpiData Association

1 1

EpiTables
by epidata-list＠lists.umanitoba.ca 17 Jun '06

17 Jun '06

HI, I am trying to run an EpiTable on some basic food exposure data where 1=Ate the food item, 2=did not eat food item. However when I run the EpiTable it is automatically assuming that the exposure variable is 2 (ie.e not eating food item). How can I change the exposure variable to 1? ----------------------------------------- ******************************************************************* ******* The information contained in the EMail and any attachments is confidential and intended solely and for the attention and use of the named addressee(s). It may not be disclosed to any other person without the express authority of the HPA, or the intended recipient, or both. If you are not the intended recipient, you must not disclose, copy, distribute or retain this message or any part of it. This footnote also confirms that this EMail has been swept for computer viruses, but please re-sweep any attachments before opening or saving. HTTP://www.HPA.org.uk ************************** ************************************************

1 2

searching during entry and development issues
by epidata-list＠lists.umanitoba.ca 12 Jun '06

12 Jun '06

On april 1st. Shavinder Singh questioned about searching principles Actually I see the comment as a wish for this: a. When searching the specification should be done in the same form as where entry is done instead of using a specific search form. b. Apart from showing the next record matching the search criteria all records matching the criteria should be shown in the same form as with AUTOSEARCH c. Or as an alternative to b, show one record at a time and find next one with F3. Clarification of issues like this will be part of the coming development plan. Including possible planning a user survey on usage etc. Comments and views welcomed. Regards Jens Lauritsen EpiData Association

1 0

Convert sting to numeric - Epidata Analysis
by epidata-list＠lists.umanitoba.ca 09 Jun '06

09 Jun '06

Hello How is it possible to convert a string to a numeric value in Epidata Analysis. I have tried all the proposed solutions found on the support list, but the result is always the same 'data type mismach" I have a string variable like var1 = GHXXXXX15 And I want to make statitic(median, means ....) on the last part (15) , I can convert to a numeric value. The function to convert numeric to string exists, but no string to numeric. Thank you very much Yves Yves Dupont Institut of Public Health Rue Juliette Wijtsman 14 1050 Bruxelles Belgium Phone : 32 2 6425785 Fax : 32 2 6425410 ########################################################### Checked as being free of known viruses. Scientific Institute of Public Health, Brussels, Belgium Wetenschappelijk Instituut Volksgezondheid, Brussel, Belgi� Institut scientifique de Sant� publique, Bruxelles, Belgique Visit our website: http://www.iph.fgov.be ###########################################################

1 1

Website now in Spanish also - try www.epidata.dk/sp and other good news
by epidata-list＠lists.umanitoba.ca 05 Jun '06

05 Jun '06

*Website in Spanish (Español) *31. May 06 Due to the work of Pedro Arias and with some assistance from Juan Carlos Merino (Peron) the whole website has been translated to Spanish. Other translations can be placed if someone wishes to translate parts or all. A bit later we will arrange for a news section for the translated version also. ................................................................................................................. Good news - funding received - Financing the conversion plan A first donation of roughly 7000 Euro has been received for the development plan from a Danish Medical research fund. Experimentation with possible principles for implementation of aspects of "audit trail" will start soon based on the funding. I will add a "counter" indicating at all times what percentage of the plan is currently financed. ................................................................................................................ Regards Jens Lauritsen EpiData Association

1 0

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

03 Jun '06

I propose that the principle be established that any appropriate command will eventually allow weights via /w=varname To simplify syntax for many users, /sum=varname can be a synonym for /w=varname on the FREQ command and TABLES command We do not need separate sumfreq and sumtables commands. I never liked this in EpiInfo because you had to learn another command syntax and EpiInfo wasn't know for consistency of syntax. It is good practice to use the variable name COUNT (in English at least) whenever dealing with aggregated data. This becomes self documentation. We do this with an in house system for managing monster national data sets, but still will get people creating frequency tables that do not sum the COUNT variable and they wonder why every category has a frequency of 1 Jamie Hockin Public Health Agency of Canada

1 1

WinGlue menu system
by epidata-list＠lists.umanitoba.ca 03 Jun '06

03 Jun '06

1 0