As I noticed the table was not implemented correctly in build 18, but
should be correct (for the data I tested) in build 19.
Build 19 was made available early today/late last night depending on
where you live.
The intention was to always have as pointed out by Jamie Hockin:
TABLES outcomevar exposurevar stratifyvar1 stratifyvar2 stratifyvar3
Please review the adapted commands and functions list.
You can search on (ctrl+f) "table epi" and in options for search mark
out "helpfie" and the file will open in the output window.
(the file has a formatting error now - but contents are there)
set table labels=on[off] (Use comment legal "value
labels" as text descriptors in tables)
set table values=on[off] (show category values in
tables)
set table epi=on[off] (With on: tables are inverted (highest values
in top left corner)
set table percents=on[off]
set table percents format="P1()"[off]
(Content percents coloumn) 1: decimals () before after. e.g. "P2
%"
set table percents header="%" (Contents of column header for percents)
set table RR=on[off] show Risk Ratio in 2x2 tables
set table OR=on[off] show Odds Ratios in 2x2 tables
to control statistics output:
set table statistics="OR RR EXACT CHI"
eliminate the ones you do not want. e.g. set table statistics="CHI"
regards
Jens Lauritsen
EpiData Association
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
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.
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
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.
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
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
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
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