- EpiData-list - University of Manitoba Mailing Lists

Initial test of Analysis build 18 - TABLES
by epidata-list＠lists.umanitoba.ca 03 Mar '05

03 Mar '05

My favourite data set for TABLES is RELY.REC as it will eventually be a good test of MATCH. For this data, the 'inverted' table should read =========> tables rely case CASE RELY │ + - │ Total ───────────┼─────────────┼────── + │ 11 13 │ 24 - │ 3 29 │ 32 ───────────┼─────────────┼────── Total │ 14 42 │ 56 (from Epi6) EpiData Analysis gives me CASE RELY Y % N % Total % Y 11 (45.8) 3 (9.4) 14 (25.0) Y 13 (54.2) 29 (90.6) 42 (75.0) N 24 (100.0) 32 (100.0) 56 (100.0) Two problems: 1) The data are not inverted. However, the results are correct (OR, RR, etc) 2) Labelling for rows is not correct "N" row labelled "Y", "Total" row labelled "N" Percentages here are appropriate for Case-control study, but would not be of interest for Cohort study. Of course, the option to remove them is with the user. Turning on/off of OR and RR behaves as expected. if I turn off both OR and RR, I get a correct table: RELY CASE N Y Total N 29 13 42 Y 3 11 14 Total 32 24 56 So the problem is that with OR=on or RR=on, the rows and columns are switched, but the table has not been rotated to put CASE on top. I think that it will be more consistent to always put the first TABLES variable as the column header, or if the preferred practice for tables is to put the first variable as rows then we could accept 2x2 tables with the outcome in rows. The problem is that, looking at the output and the command, I'm confused about how I construct the command to get what I want. We have to enforce TABLES outcomevar exposurevar if we want RR to be calculated correctly. Jamie Hockin

1 0

New build of analysis (build 19)
by epidata-list＠lists.umanitoba.ca 03 Mar '05

03 Mar '05

A new build of analysis was just put out on www.epidata.dk/testing.php The table command was in a mess in build 18 from yesterday due to various technical problems (Apologies for the inconvenience.) Estimates for at least one data file are the same as with Stata 7 (Odds Ratios and RR). Also it has been defined such that the first variable on the tables command (tab) will always go across, the second down and any further will be used for stratification. The "set parameters" have been more standardised. Try "set" to see which ones are currently defined and their names. e.g. for tables: set table statistics="OR RR CHI EXACT" would include all whereas: set table statistics="OR CHI" would only include odds ratios, chi square measures The promised solving of reading unknown fields as character fields will be part of coming builds - not this one. regards Jens Lauritsen EpiData Association.

1 0

[Fwd: Short dates and menus in HTML]
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

This is good, Jens. Epi6 was so forgiving because it treated any unknown field as a string - a nice backwards compatibility feature as it turns out. Unfortunately, this went along with Epi6 producing invalid files from time to time. A good strategy for menus to do different analyses might be to create some .pgm files and simplify the HTML coding to just launch the appropriate .pgm. This would provide better documentation of complicated scripts. Once you get used to the syntax, HTML menus need not be any more complicated than EPI6 .mnu files. Outside of Analysis and with the right javascript tools & code fragments a lot is possible. Jamie Hockin

1 0

out of office reply
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

I will be out of office and not be checking my emails until March 4, 2005. marcel zwahlen

1 0

Svar: RE : [EpiData-list] Re: New analysis build (18) ready for testing(error reading date variables)
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

In the next build we will adopt the strategy that old formats such as <dd/mm>, <dd/mm/yy> or phone number fields will be read into analysis as strings. The user can then convert to date or numerical variables using functions in analysis. Jens Lauritsen EpiData Association.

1 0

RE : [EpiData-list] Re: New analysis build (18) ready for testing(error reading date variables)
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

Thanks Jens When you export oswego.rec to STATA using EpiData, you get a string variable in STATA that you have to work with, but no error I agree that this rather strange format with only mont hand day is not fantastic. Anyway, quite many people did use it because for brief studies it is OK The idea of developping a kind of conversion procedure makes sense, even if some recoding is needed after conversion like in STATA The crucial point is the ability to transfer old files to EpiData whether or not is absolutely "ready to use" Regards Robert -----Message d'origine----- De : epidata-list-bounces(a)lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] De la part de epidata-list(a)lists.umanitoba.ca Envoyé : mercredi 2 mars 2005 13:45 À : epidata-list(a)lists.umanitoba.ca Objet : [EpiData-list] Re: New analysis build (18) ready for testing(error reading date variables) Robert wrote: "The last build does not work : cannot read rec file OSWEGO for example Any idea ??" This is a marvellous example of why end-users should participate in testing. It turns out that the version of OSWEGO.REC I am testing on has been updated with EpiData. When I do so all date fields are changed to full length dates including year. So I did not see the error. I can see now that with the original OSWEGO.REC I get the same error as indicated by Robert. Lesson learned: Make sure that testing includes types of error that you do not want to happen. In practice. We will from now on include a test of how analysis treats files with all the variable formats of Epi6. Even the ones we "abandoned", such as 2 digit year or dates without year. Rules from EpiData for these types of dates will be included in next build. (Extending to 4 digit years and adding current year to fields without year) regards Jens Lauritsen EpiData Association _______________________________________________ EpiData-list mailing list EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list

1 0

Re: New analysis build (18) ready for testing (error reading date variables)
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

Robert wrote: "The last build does not work : cannot read rec file OSWEGO for example Any idea ??" This is a marvellous example of why end-users should participate in testing. It turns out that the version of OSWEGO.REC I am testing on has been updated with EpiData. When I do so all date fields are changed to full length dates including year. So I did not see the error. I can see now that with the original OSWEGO.REC I get the same error as indicated by Robert. Lesson learned: Make sure that testing includes types of error that you do not want to happen. In practice. We will from now on include a test of how analysis treats files with all the variable formats of Epi6. Even the ones we "abandoned", such as 2 digit year or dates without year. Rules from EpiData for these types of dates will be included in next build. (Extending to 4 digit years and adding current year to fields without year) regards Jens Lauritsen EpiData Association

1 0

RE : [EpiData-list] New analysis build (18) ready for testing
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

The last buid does not work : cannot read rec file OSWEGO for example Any idea ?? Robert -----Message d'origine----- De : epidata-list-bounces(a)lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] De la part de epidata-list(a)lists.umanitoba.ca Envoyé : mercredi 2 mars 2005 12:27 À : epidata-list(a)lists.umanitoba.ca Objet : [EpiData-list] New analysis build (18) ready for testing I have placed build 18 v0.9 of analysis on www.epidata.dk/testing.php earlier today. Many things have been changed since build 17. (Complete list on: http://www.epidata.dk/analysisinfo/docs/versioninfo.htm) Among these handling of OR and RR in tables. 2x2 tables are now "inverted" to make disease and exposed top left corner. Percentages are in different cells in tables than the numbers. Thereby allowing to add e.g. () around percentages APPEND command to read more than one file into memory. In particular it is important to secure that a- the tables produced by stratification are correct b- estimates based on stratified tables are correct. c- tables are formed correctly (counts and percentages) with and without option specifications. An example of set is: set table percents="P1()" *will make output like this: tab kmgrp decgrp KMGRP 2.5-3.4 % 3.5-3.7 % Total % 0- 25 km 120 (15.3) 156 (18.9) 596 (18.7) ..... but set table percents="P1[ %]" set table percents header="[Pct %]" *will for the same command give: tab kmgrp decgrp KMGRP 2.5-3.4 [Pct %] 3.5-3.7 [Pct %] Total [Pct %] 0- 25 km 120 [15.29 %] 156 [18.9 %] 596 [18.66 %] similarly set table or=off set table rr=off controls whether odds ratios and rate ratios are shown or not. To show change off to on. The testsuite used for validation is not fully completed. You can see how much was tested by running the command runtest validate which will run all pgm files in the subfolder validate and make a report at the end. regards jens Lauritsen EpiData Association, Odense Denmark. _______________________________________________ EpiData-list mailing list EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list

1 0

How to learn using stylesheets and html
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

A good introductory text is found at http://www.w3c.org/Style/Examples/011/firstcss But very many similar sites are found around the world. The w3c is an organisation which has established standards for html and css. It can be quite usefull to see if a given stylesheet or web page in html follows these standards. The validators are found on the front page of w3c (http://www.w3c.org). For epidata it is the intention to have all html and style sheets in compliance with the w3c standards. (Note intention - sometimes not accomplished) regards Jens Lauritsen

1 0

Regarding Command line processing:
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

The bad news is: We have not and will not build a dedicated menu program to replace epiglue as part of the EpiData Association activities. The good news is: There are several other possibilities to replace Epi6 menus within the "EpiData frame" To maintain the QES-REC-CHK file principle (see later for other possibilities) 1. Make a qes/rec file which in individual fields uses the "execute" chk file command 2. Create batch files with EpiC which will accomplish many things such as zipping and encryption for backup or maling, importing or exporting of data for analysis, controlling data consistency (CHECKRANGE etc.) 3. In analysis: Build your own form such as the opening info.htm, where you can include commands. To learn how - look at the info.htm in any simple editor and replace commands in the<epi....> tag. And learn a bit of html language coding. You will find textbooks on that everywhere. If you run epidata analysis (the test version) the opening window shows contents of the file "info.htm". Part of this is: Examples of how the programme works: Graph: Bar chart (Click) Statistical Process Control Chart (Click) If the user clicks on "Bar Chart" a bar chart will be shown. Behind the click is a link to the following analysis commands: Graph: <A HREF='epi:close;set echo=off;define fn __________________________ glob;fn= "@sysdir"+"testdata";cd "@fn";read bromar;set warning=on;bar agegrp;cd; set command=off;echo Press F1 to view info again;set echo=on'>Bar chart</a> (Click) This looks a bit complicated to new users, but if you look more closely several words are well known EPI6 commands e.g. close set echo=off read bar So to make a menu point for showing descriptive statistics and let the user define select you would just add to the info.htm fil a line of text in an editor: Statistics <A HREF='epi:close;read datafile;select sex = ?Sex= 1 or 2?; describe;set echo=off;close;view info.htm;>By sex</a>(click) The difficult part of this to understand: select sex = ?Sex= 1 or 2? Analysis starts the select command but instead of running it lets the user input a value in a box on the screen. On that screen the text "Sex=1 or 2" is shown to guide the user. Similarly other select or defines could be made. You could also add two lines for fixed selections: Statistics <A HREF='epi:close;read datafile;select sex = 2; describe;close;view info.htm;>For males</a> Statistics <A HREF='epi:close;read datafile;select sex = 1; describe;close;view info.htm;>For Females</a> Outside the EpiData frame, but within the EPI6 menu principles: Maybe we could persuade EpiConcept and Denis Columbier to make Winglue available. Winglue is a replacement for epiglue. Other possible strategies would be to make a simple html page and include "tags" to run whichever programme you like or use other software - e.g. epi info for windows from CDC or larger server systems. regards jens Lauritsen EpiData Association, Odense Denmark.

1 0