January 2005 - EpiData-list - University of Manitoba Mailing Lists

Table command behavior (sort order and alignment)
by epidata-list＠lists.umanitoba.ca 16 Jan '05

16 Jan '05

Controlling alignment and sorting are separate issues. This is the current strategy for implementation: 1. Sorting a. Numerical variables: by numerical code: 1,2,3..etc b. String variables: alfa: a,b,c,d,e,f .....1234 ABCEFG....123... But also that we should introduce options such as: /reverse : meaning reverse order /count: based on how many counts are in each category. if count and reverse are combined smallest counts first /limit: Only show categories with more records than the indicated value The options I do not expect to have ready in first version, but the general sort order will be fixed. WIth the suggestions of Jamie Hockin there is a good work-around of how users could have a string variable containing numerical codes could be sorted according to numerical value correctly. 2. Alignment Alignment is a completely different issue since this is not controlled by the individidual command, but rather by the formatting system of the output. All alignment and format is controlled by a "cascaded style sheet" contained in the file epiout.css. So for instance for the left most column this would be for right alignment: .firstcol {color: black ;font-size: 10pt;font-family: Fixedsys; font-weight: normal; text-align: right; padding-right: 10px; } and for left alignment: .firstcol {color: black ;font-size: 10pt;font-family: Fixedsys; font-weight: normal; text-align: left; padding-right: 10px; } I suggest test persons try to work out different variants of the style sheet and we could provide these with the installation routine. Currently we are working on build 18 of analysis. We have managed to incorporate the same source code for reading chk files as in epidata, such that we secure complete correspondance btw. the two programs. THe other major change has been to increase the precision of the internal representation of real numbers. Both changes require a lot of testing and going over functions, this is why there has been a while since release of last build. Kind regards Jens Lauritsen Initiator and Coordinator of EpiData.

1 0

re: tables
by epidata-list＠lists.umanitoba.ca 14 Jan '05

14 Jan '05

Oops - sorry Kelly. I had FREQ on the brain when I was reading the list the other day. Seems to me this is just a design feature that will come in place when the final work is done on TABLES. The cell & column orders should be handled the same was as for FREQ (i.e. numeric order for integer and float) as you and Jens point out. Jamie

1 0

RE: [EpiData-list] re: tables
by epidata-list＠lists.umanitoba.ca 14 Jan '05

14 Jan '05

Greetings, Jamie. I agree and I do understand "padding" strings. However, the Example I used was age as integer and sex and integer. The reason I chose this example was because using Epi604D Analysis and issuing the command Tables age sex the result was 1-n for age and 1-2 for sex. The data is stored as integers for both. Having to convert to string and then pad sounds a bit much. I suggest that the TABLES command using integers in both Fields be changed to produce the same ordering as FREQ. And, if padding is going to be so important, I agree there should be a function. I do appreciate your response and I have encountered a few other items Of Which I'm keeping track and will send along once I have exhausted my efforts. Have a great weekend and stay safe, Kelly Kelly Bussell CDC Atlanta -----Original Message----- From: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Sent: Thursday, January 13, 2005 3:07 PM To: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] re: tables Numeric fields display in the correct (ascending) order in FREQ. e.g. . freq time TIME No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 98 1 2.50 102 1 2.50 However, text fields are normally left-justified, even though FREQ shows them right-justified. With the same data and . define a ___ . let a = time . freq a A No. % 0 1 2.50 1 1 2.50 102 1 2.50 104 1 2.50 119 1 2.50 123 1 2.50 138 2 5.00 14 1 2.50 154 2 5.00 162 1 2.50 181 1 2.50 202 1 2.50 22 1 2.50 To right-justify the text field (or a copy of the text field would be safer as shown here): . define b ___ . b = copy(" ",1,3-length(trim(a)))+a . freq b B No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 92 1 2.50 97 1 2.50 98 1 2.50 102 1 2.50 104 1 2.50 I've used version 0.9 Build 17. This is a trick that is necessary with other systems as well, as strings tend to be stored left-justified unless you design it otherwise. Rather than have FREQ take care of this, it might be preferable to have a function to do the right-alignment of a field or do the left-padding of a string. e.g. b = LPAD(a) Jamie Hockin Public Health Agency of Canada

1 0

re: tables
by epidata-list＠lists.umanitoba.ca 13 Jan '05

13 Jan '05

Numeric fields display in the correct (ascending) order in FREQ. e.g. . freq time TIME No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 98 1 2.50 102 1 2.50 However, text fields are normally left-justified, even though FREQ shows them right-justified. With the same data and . define a ___ . let a = time . freq a A No. % 0 1 2.50 1 1 2.50 102 1 2.50 104 1 2.50 119 1 2.50 123 1 2.50 138 2 5.00 14 1 2.50 154 2 5.00 162 1 2.50 181 1 2.50 202 1 2.50 22 1 2.50 To right-justify the text field (or a copy of the text field would be safer as shown here): . define b ___ . b = copy(" ",1,3-length(trim(a)))+a . freq b B No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 92 1 2.50 97 1 2.50 98 1 2.50 102 1 2.50 104 1 2.50 I've used version 0.9 Build 17. This is a trick that is necessary with other systems as well, as strings tend to be stored left-justified unless you design it otherwise. Rather than have FREQ take care of this, it might be preferable to have a function to do the right-alignment of a field or do the left-padding of a string. e.g. b = LPAD(a) Jamie Hockin Public Health Agency of Canada

1 0

Re: EpiData-list Digest, Vol 15, Issue 5 (Out of the office)
by epidata-list＠lists.umanitoba.ca 13 Jan '05

13 Jan '05

I will be out of the office from Thu. Jan. 13 through Fri. Jan. 14, 2005. I will reply to your email as soon as possible. If you need immediate assistance please call the DPCP Administrative Assistant, Bennie Daughtry at 545-4471.

1 0

EpiData and memory
by epidata-list＠lists.umanitoba.ca 12 Jan '05

12 Jan '05

Hi, How much RAM is required to run EpiData 3.02? One of my coworkers has had problems with her laptop computer freezing after coding 5-6 records. She has Windows 95 and 64MB of RAM. The CHK file that she is using is rather large -- it is 113 KB and 5322 lines long. The REC file is 85 KB. I have tried coding into the same REC file on a computer with 512MB of RAM. I had no problems after coding 15 records. Could my coworker be having a problem with RAM, or could there be a problem with the length of the CHK file? Any guidance would be greatly appreciated. Thanks, Katie

1 0

Tables in analysis and output direction
by epidata-list＠lists.umanitoba.ca 06 Jan '05

06 Jan '05

Regarding printing: The epi6 mode of routing to screen, printer etc. is not possible with windows, but we could consider a printing command, e.g.: print file.txt which would direct that file to printer. The user could then first make a log file (logopen) and then afterwards send that file to the printer I think we could also make a possibility to print the output window as such. Concering the sort order of tables: TABLES AGE SEX (age sex are numeric) resulted in AGE listed as > 1 >10 >11 >Etc. To >19 > 2 >20 Obviously this should be adapted such that there is by default a chronological sort of a numerical field and by values of a field with comment legal. User control of sort order is already on the wish list. I suggest members of the list add name and country when adding information to the list. But do not add e-mail since all mails are available when searching on internet, so SPAM systems could catch the mail adresses. Notice also that return fields of mails are not included in the mail list so the list does not show any e-mail adresses Regards Jens Lauritsen EpiData Association Denmark

1 0

tables
by epidata-list＠lists.umanitoba.ca 06 Jan '05

06 Jan '05

Greetings. Happy New Year! I am starting to use EpiData & Analysis and I think you are doing a nice job. I have not tried to access a printer directly in a .PGM as yet. I like very much the ability of Epi6 to allow me to program For users the destination of output e.g. screen, printer or to a file. I haven't seen any examples yet but in case there are none this Has always been important to site managers in the developing settings. I was doing FREQ and TABLES a moment ago and had the following result. FREQ AGE worked just fine TABLES AGE SEX (age sex are numeric) resulted in AGE listed as 1 10 11 Etc. To 19 2 20 21 22 Ect. To 29 3 30 31 I think this needs to be fixed. Or, what have I done wrong? Thank you and keep up the good work.

1 0

Encrypted fields in EpiData
by epidata-list＠lists.umanitoba.ca 04 Jan '05

04 Jan '05

The reason for placing the encrypted key encrypted in the header is: 1. There must be a place to compare the entered password with the true one Otherwise the decryption cannot work. You could argue that if a false key was provided, then nonsense would be returned and it would be up to the user to see that contents of an encrypted field was garbage. I would feel that was a dangerous situation, since if the user saved the record again, then the wrong key would be applied to garbage giving "double" garbage and no way to retrieve data. Another approach would be to save the key in a different file than the rec file header, but your arguments would apply equally to that. Certainly I can assure: The idea was NOT to provide a backdoor in case the user forgets their password. There is no way for EpiData crew or others to retrieve a forgotten passkey So the core of the reasoning has been: We rely on the "non-breakability" of the AES/Rijndael encryption principle and we need to know if the user uses the correct key - otherwise data could be lost. As a comparison, e.g. the password mechanism provided by WINZIP or Access is not reliable, there are programs on internet which will guess millions of passwords in few seconds for these - and find the one used. regards Jens Lauritsen Initiator and coordinator of EpiData

1 1

Line 640, error message
by epidata-list＠lists.umanitoba.ca 03 Jan '05

03 Jan '05

Thank you for the reply! Here is the answer in your text below: We should know more about the contents of the qes file to answer, e.g.: 1. How many lines in total --> So far it is 1616 lines. 2. How many fields are you planning --> the questionnaire is made of different categories. It is between 70-80 fields. 3. Are you using the "first word" or automatic options for creation of fields. --> First word. 4. which build and version of EpiData --> Version 3.02 5. Have you tried also with the v3.1 release candidate ? --> Unfortunately no. 6. Does preview of the same file work --> Yes! all the time with no problem at all! >>If you have as many fields as you indicate the error is either because you have more than 1000 lines in the qes file (which v3.1. will issue a warning for) or the automatic numbering of fields with similar names ran out of possible combinations. --> Does not EpiData take more than 1000 lines or? Happy 2005! /Ziad > I sent past message related to "field definition error in line > 640" message. > I tried to retype the QES form. So each five questions, I > switched the > QES file into REC file and did "checks" for it. I kept doing the > same > procedure, and I passed the line 640.

1 1