[Babase] Minor census correction
Karl O. Pinc
kop at meme.com
Thu May 31 14:25:22 EDT 2007
On 05/31/2007 12:58:48 PM, kfenn wrote:
>
>
> Karl O. Pinc wrote:
>>
>> On 05/31/2007 11:33:03 AM, Lacey Maryott wrote:
>>> I'm not sure if we are just talking about 1 or both situations, but
>>> for Blue, he wasn't even in the group until the first day he is
>>> marked as there in Demog notes, and then isn't put on the census
>>> sheet until the following census day. Does this make a difference
>>> at all?
>>
>> Yes. CENSUS.Cen records whether or not the individual was censused
>> from the census sheet. Or at least it's supposed to. According
>> to comparetables.out BLU's CENSUS.Cen was 1 in foxpro, which
>> would be wrong. I leave it to you guys to figure out what
>> else might be wrong with other rows.
>>
> Pg 22 of the Amboseli Baboon Project Data Management Systems manual
> (March 18, 2003) says:
>
>
> a) Cen
>
> Whether or not the CENSUS row represents an entry on a census data
> sheet. .T. means the CENSUS row exists because of an entry on a
> census data sheet, .F. means there was no census done and the CENSUS
> row exists to support a demography note, manual notation of absence,
> etc.
The point of this sentence was supposed to mean that Cen was assigned
row-by-row, not whether or not there was any census done on any members
of the group on that day. (From a database design perspective,
if the value does not apply to that row and only that row, then the
column does not belong in the table holding the rows.)
> Cen should only be .T. when Status is “C”, “A”, or “D”. A “C”
> status is marked on the census data sheet as an “X”. An “A” or “D”
> status is marked on the census data sheet as a “0”. This field should
> not be blank.
>
> Note the text: Cen should only be .T. when Status is “C”, “A”, or “D”.
(The new docs say something like this too. Just because it
can be .T. then does not mean that it always must be .T.,
just that must be .F. when Status is not C and not A and
not D.)
>
> This may be why the cen value is 1 (true) for BLU. Census code was
> "D" and there was a census done for that group that day...BLU just
> happened to be seen outside the context of the group census. I think
> that's why the computer allowed/assigned it in FoxPro. I know the
> rules don't read quite the same way for the new system. They say that
> an individual has to be ON a census data sheet to get a cen value of
> 1 (true).
>
> Karl, do you know how the old mechanism for assigning t/f values
> compares to the new mechanism....ie, how does upcen criteria compare
> to the census program you have online? I really think those FoxPro
> values were assigned correctly (according to the rules at the time).
> It sounds like the criteria may have shifted slightly....or our
> interpretation of the older document changed? Any insights into the
> guts of these two uploading programs, Karl?
As far as I know the way it worked in foxpro is that if you used
the upcen program to put the row in
then Cen would be 1 (.T.) otherwise it would be 0
(.F.). The idea was that upcen would be used for the census
data sheets, updemog for the demography notes, and you're on
your own if you go in and manually add or change individual
census rows. Updemog should leave the census Cen value unchanged
if the census row already exists, or set it to .F. if it
has to create the census row.
I wrote all the docs when we came up with the idea of demography
notes in the first place. The intention was always the same.
So the problem's with the clarity of the language, or
maybe because it's easier to run upcen than manually
add/change data values because then you don't have to
also run reinterp.
Karl <kop at meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
More information about the Babase
mailing list