[Babase] Interpolation (MEMBERS) changes

Catherine Markham babase@www.eco.princeton.edu
Mon, 04 Apr 2005 09:14:36 -0400


Hi all,

If you're making changes to the members table, the only thing that comes 
to mind right off is whether or not it makes sense to have birth act as 
a "census" in members if the bstatus is not 0.  There were a couple 
messages about this on the listserv last month ending with Karl's 
response below:

"Of course it's simplist for the computer if it treats all birthdates 
the same way, and in some sense easiest to understand for the rest of 
us. But this is really a science question so I leave it to the 
scientists. Regardless, I would think that estimated bithdates would 
affect the interpolation of any subsequent censuses within the next 27 
days. (Interpolation goes up to/down from 'halfway' to the next/prior 
census, unless halfway is longer than 14 days.) If we want to consider 
estimated birthdates as "different" we should figure things out face to 
face."

Still hold off on discussing this till later?  Does it even seem like an 
issue to folks who have been working with the database longer? 

Catherine



Karl O. Pinc wrote:

> After conversations with Susan I'm changing the way
> interplation works.  (Both because I think we want
> it changed and because the old foxpro based code is
> too complicated and slow.)  I'll write later and post the
> relevant section of the documentation at some point
> before I wrap this up.  But I wanted to get this
> out there so people could comment if anybody sees
> a problem.
>
> The changes are:
>
> 1) The BIOGRAPH.Statdate will no longer act like
> a census, placing the individual in a group on
> MEMBERS and interplating (backward in time) from
> that date.  (Birth will continue to act "as a
> census" and birthdays will continue to (sometimes)
> have a MEMBERS.Origin of I and a MEMBERS.Interp
> of 0.)
>
> 2) There will be a row on MEMBERS for an individual
> for every day between the individual's Birth and
> Statdate.  Interpolation will continue to place
> the individual in his censused group for 14 days
> on either side of the census, and after that the
> individual will be in the unknown group.  (Group
> 9).
>
> I think we have treated Statdates as 'census dates'
> so that we would always have a MEMBERS row for
> the individual's death date.  With the new
> scheme we will have a row in MEMBERS for the
> individual's death (or disappearance) date
> but when the interval is too long beteween the
> last census and the statdate the individual will
> wind up in the unknown group on his death date
> rather than the group last censused.
>
> So, we'll see a lot more Unknown group memberships
> in MEMBERS, with Origin of I.  I'm thinking that the Interp value
> for these rows will continue to "count up"
> from the nearest (in time) census that places the
> individual in a group, unless the nearest
> census (in time) both before and after are
> 'old style' non-interpolating rows.  In which
> case the MEMBERS.Interp value will be 0.
> (I think that the science folks think that
> this will never happen, but I'm not so sure
> about the data.  If it does show up and is
> not supposed to, then we can fix the data.)
>
>
> Karl <kop@meme.com>
> Free Software:  "You don't pay back, you pay forward."
>                 -- Robert A. Heinlein
>
>
>
> _______________________________________________
> Babase mailing list
> Babase@www.eco.princeton.edu
> http://www.eco.princeton.edu/mailman/listinfo/babase



-- 
Catherine Markham
Department of Ecology and Evolutionary Biology
Princeton University
Phone: (609) 258-6898 
Fax: (609) 258-2712