## Re: [Gramps-devel] Checking to see if a person is alive or dead

 Re: [Gramps-devel] Checking to see if a person is alive or dead From: - 2005-12-28 19:31:54 ```Gerald, I like the idea, and one way to make it very general would be if all events of particular types had "typical" distances in years to birth and death. Running through all connected people gives a bunch of estimates (some may have higher weighting based on confidence). Combining the estimates should give a pretty accurate view of birth/death dates for an individual (might be a little scary to apply to those still alive if it were accurate). One could also run through the database and compute accurate "typical" distances for those people that do have dates. These real distances probably change dramatically over time (and vary with gender). But single distance estimates to birth and death would probably be good enough. On a related note, this could also help doing research. The typical event distances suggest when to look for information. For example, one could generate a report based on the evidence: John Doe (male) probably born around 1865 (age 0) probably graduated from high school in 1883 (age 18) probably had children around 1890 (age 25) probably died around 1955 (age 90) A related idea may also work for locations of events; people tend to stay where they are. Find an event that has a location, and propagate that to related people to make a location suggestion. -Doug > I've been thinking much about how to determine if a person is alive or > dead at a given date. I realized that it is a special case of a more > general question: When was a person born? If I know this, I can > compare that date to the given date to answer my question. > > Utils.py has a routine called probably_alive that currently makes the > yes/no decision. It sometimes gets it wrong, however, so I'm looking > for another way. Here's what I have so far: > > The reworked probably_alive routine would call a new function, > birth_year and compare the result to the target year provided by the > caller. The new function birth_year would work like this: > > # NOTE: this is not python code at this point, just some pseudo-code > for discussion > > birth_year(person,flag) > # inputs: "person" is a handle for the person to be checked, > # "flag" is a switch to stop infinite recursions on > spouses and children > > # first, check the obvious > > if there is any birth event (e.g. birth, christening, baptism) that > has a date for it > return the year of that event > > if there is any death event (e.g. death, cause of death, burial, > cremation) that has a date > return the year of that event - maximum age (currently defaults to > 110) > > # now, the not-so-obvious (could be education, occupation, marriage e= tc) > > if there is any other event that has a date > return the year of that event - minimum age (a new parameter, defaul= ts > to 15) > > # check children, unless we are checking the spouse, in which case > we've done this > # already > > if flag <> "spouse" > for each child > b_y =3D birth_year(child,flag=3D"child") > if b_y > minimum birth year (new parameter, defaults to -9999) > return b_y - minimum age # our children are born af= ter > us > end for > > # check parents, unless we are checking children (to stop infinite > recursion) > > if flag <> "child" > for each parent > b_y =3D birth_year(parent) > if b_y > minimum birth year > return b_y + minimum age # we are born after our > parents > end for > > # finally, check the spouse > > if flag <> "spouse" > b_y =3D birth_year(spouse,spouse_flag=3D"yes") > if b_y > minimum birth year > return b_y - minimum difference (defaults to 2 years) > return minimum birth year > end > > When probably_alive calls birth_year, it should set a reasonable > recursion level (defaults to 3) using the built-i setrecursionlimit > function. Note that with a little tweaking, we can make a death_year > routine that works in a similar fashion. > > The main defaults (minimum age, maximum age, minimum difference, > recursion depth) should be user-editable either as system defaults or > prompts before running the probably_alive (or _dead) filter. Probably > we should have both system defaults and user prompts on the filter > definition. > > Please feel free to rip this apart. I only hope we can come up with a > good solution together. > > Jerry Britton > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ```

 [Gramps-devel] Checking to see if a person is alive or dead From: Gerald Britton - 2005-12-28 19:04:49 ```I've been thinking much about how to determine if a person is alive or dead at a given date. I realized that it is a special case of a more general question: When was a person born? If I know this, I can compare that date to the given date to answer my question. Utils.py has a routine called probably_alive that currently makes the yes/no decision. It sometimes gets it wrong, however, so I'm looking for another way. Here's what I have so far: The reworked probably_alive routine would call a new function, birth_year and compare the result to the target year provided by the caller. The new function birth_year would work like this: # NOTE: this is not python code at this point, just some pseudo-code for discussion birth_year(person,flag) # inputs: "person" is a handle for the person to be checked, # "flag" is a switch to stop infinite recursions on spouses and children # first, check the obvious if there is any birth event (e.g. birth, christening, baptism) that has a date for it return the year of that event if there is any death event (e.g. death, cause of death, burial, cremation) that has a date return the year of that event - maximum age (currently defaults to 110) # now, the not-so-obvious (could be education, occupation, marriage etc) if there is any other event that has a date return the year of that event - minimum age (a new parameter, defaults t= o 15) # check children, unless we are checking the spouse, in which case we've done this # already if flag <> "spouse" for each child b_y =3D birth_year(child,flag=3D"child") if b_y > minimum birth year (new parameter, defaults to -9999) return b_y - minimum age # our children are born after = us end for # check parents, unless we are checking children (to stop infinite recurs= ion) if flag <> "child" for each parent b_y =3D birth_year(parent) if b_y > minimum birth year return b_y + minimum age # we are born after our parents end for # finally, check the spouse if flag <> "spouse" b_y =3D birth_year(spouse,spouse_flag=3D"yes") if b_y > minimum birth year return b_y - minimum difference (defaults to 2 years) return minimum birth year end When probably_alive calls birth_year, it should set a reasonable recursion level (defaults to 3) using the built-i setrecursionlimit function. Note that with a little tweaking, we can make a death_year routine that works in a similar fashion. The main defaults (minimum age, maximum age, minimum difference, recursion depth) should be user-editable either as system defaults or prompts before running the probably_alive (or _dead) filter. Probably we should have both system defaults and user prompts on the filter definition. Please feel free to rip this apart. I only hope we can come up with a good solution together. Jerry Britton ```
 Re: [Gramps-devel] Checking to see if a person is alive or dead From: - 2005-12-28 19:31:54 ```Gerald, I like the idea, and one way to make it very general would be if all events of particular types had "typical" distances in years to birth and death. Running through all connected people gives a bunch of estimates (some may have higher weighting based on confidence). Combining the estimates should give a pretty accurate view of birth/death dates for an individual (might be a little scary to apply to those still alive if it were accurate). One could also run through the database and compute accurate "typical" distances for those people that do have dates. These real distances probably change dramatically over time (and vary with gender). But single distance estimates to birth and death would probably be good enough. On a related note, this could also help doing research. The typical event distances suggest when to look for information. For example, one could generate a report based on the evidence: John Doe (male) probably born around 1865 (age 0) probably graduated from high school in 1883 (age 18) probably had children around 1890 (age 25) probably died around 1955 (age 90) A related idea may also work for locations of events; people tend to stay where they are. Find an event that has a location, and propagate that to related people to make a location suggestion. -Doug > I've been thinking much about how to determine if a person is alive or > dead at a given date. I realized that it is a special case of a more > general question: When was a person born? If I know this, I can > compare that date to the given date to answer my question. > > Utils.py has a routine called probably_alive that currently makes the > yes/no decision. It sometimes gets it wrong, however, so I'm looking > for another way. Here's what I have so far: > > The reworked probably_alive routine would call a new function, > birth_year and compare the result to the target year provided by the > caller. The new function birth_year would work like this: > > # NOTE: this is not python code at this point, just some pseudo-code > for discussion > > birth_year(person,flag) > # inputs: "person" is a handle for the person to be checked, > # "flag" is a switch to stop infinite recursions on > spouses and children > > # first, check the obvious > > if there is any birth event (e.g. birth, christening, baptism) that > has a date for it > return the year of that event > > if there is any death event (e.g. death, cause of death, burial, > cremation) that has a date > return the year of that event - maximum age (currently defaults to > 110) > > # now, the not-so-obvious (could be education, occupation, marriage e= tc) > > if there is any other event that has a date > return the year of that event - minimum age (a new parameter, defaul= ts > to 15) > > # check children, unless we are checking the spouse, in which case > we've done this > # already > > if flag <> "spouse" > for each child > b_y =3D birth_year(child,flag=3D"child") > if b_y > minimum birth year (new parameter, defaults to -9999) > return b_y - minimum age # our children are born af= ter > us > end for > > # check parents, unless we are checking children (to stop infinite > recursion) > > if flag <> "child" > for each parent > b_y =3D birth_year(parent) > if b_y > minimum birth year > return b_y + minimum age # we are born after our > parents > end for > > # finally, check the spouse > > if flag <> "spouse" > b_y =3D birth_year(spouse,spouse_flag=3D"yes") > if b_y > minimum birth year > return b_y - minimum difference (defaults to 2 years) > return minimum birth year > end > > When probably_alive calls birth_year, it should set a reasonable > recursion level (defaults to 3) using the built-i setrecursionlimit > function. Note that with a little tweaking, we can make a death_year > routine that works in a similar fashion. > > The main defaults (minimum age, maximum age, minimum difference, > recursion depth) should be user-editable either as system defaults or > prompts before running the probably_alive (or _dead) filter. Probably > we should have both system defaults and user prompts on the filter > definition. > > Please feel free to rip this apart. I only hope we can come up with a > good solution together. > > Jerry Britton > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > Gramps-devel mailing list > Gramps-devel@... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ```
 Re: [Gramps-devel] Checking to see if a person is alive or dead From: Gerald Britton - 2005-12-29 19:02:31 ```Good ideas! You're thinking of uses for my new estimated birth and death date functions that I had not considered. Anyone see any problems here? On 12/28/05, dblank@... wrote: > Gerald, > > I like the idea, and one way to make it very general would be if all > events of particular types had "typical" distances in years to birth and > death. Running through all connected people gives a bunch of estimates > (some may have higher weighting based on confidence). Combining the > estimates should give a pretty accurate view of birth/death dates for an > individual (might be a little scary to apply to those still alive if it > were accurate). > > One could also run through the database and compute accurate "typical" > distances for those people that do have dates. These real distances > probably change dramatically over time (and vary with gender). But single > distance estimates to birth and death would probably be good enough. > > On a related note, this could also help doing research. The typical event > distances suggest when to look for information. For example, one could > generate a report based on the evidence: > > John Doe (male) > probably born around 1865 (age 0) > probably graduated from high school in 1883 (age 18) > probably had children around 1890 (age 25) > probably died around 1955 (age 90) > > A related idea may also work for locations of events; people tend to stay > where they are. Find an event that has a location, and propagate that to > related people to make a location suggestion. > > -Doug > > > I've been thinking much about how to determine if a person is alive or > > dead at a given date. I realized that it is a special case of a more > > general question: When was a person born? If I know this, I can > > compare that date to the given date to answer my question. > > > > Utils.py has a routine called probably_alive that currently makes the > > yes/no decision. It sometimes gets it wrong, however, so I'm looking > > for another way. Here's what I have so far: > > > > The reworked probably_alive routine would call a new function, > > birth_year and compare the result to the target year provided by the > > caller. The new function birth_year would work like this: > > > > # NOTE: this is not python code at this point, just some pseudo-code > > for discussion > > > > birth_year(person,flag) > > # inputs: "person" is a handle for the person to be checked, > > # "flag" is a switch to stop infinite recursions on > > spouses and children > > > > # first, check the obvious > > > > if there is any birth event (e.g. birth, christening, baptism) that > > has a date for it > > return the year of that event > > > > if there is any death event (e.g. death, cause of death, burial, > > cremation) that has a date > > return the year of that event - maximum age (currently defaults to > > 110) > > > > # now, the not-so-obvious (could be education, occupation, marriage e= tc) > > > > if there is any other event that has a date > > return the year of that event - minimum age (a new parameter, defaul= ts > > to 15) > > > > # check children, unless we are checking the spouse, in which case > > we've done this > > # already > > > > if flag <> "spouse" > > for each child > > b_y =3D birth_year(child,flag=3D"child") > > if b_y > minimum birth year (new parameter, defaults to -9999) > > return b_y - minimum age # our children are born af= ter > > us > > end for > > > > # check parents, unless we are checking children (to stop infinite > > recursion) > > > > if flag <> "child" > > for each parent > > b_y =3D birth_year(parent) > > if b_y > minimum birth year > > return b_y + minimum age # we are born after our > > parents > > end for > > > > # finally, check the spouse > > > > if flag <> "spouse" > > b_y =3D birth_year(spouse,spouse_flag=3D"yes") > > if b_y > minimum birth year > > return b_y - minimum difference (defaults to 2 years) > > return minimum birth year > > end > > > > When probably_alive calls birth_year, it should set a reasonable > > recursion level (defaults to 3) using the built-i setrecursionlimit > > function. Note that with a little tweaking, we can make a death_year > > routine that works in a similar fashion. > > > > The main defaults (minimum age, maximum age, minimum difference, > > recursion depth) should be user-editable either as system defaults or > > prompts before running the probably_alive (or _dead) filter. Probably > > we should have both system defaults and user prompts on the filter > > definition. > > > > Please feel free to rip this apart. I only hope we can come up with a > > good solution together. > > > > Jerry Britton > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > > _______________________________________________ > > Gramps-devel mailing list > > Gramps-devel@... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > ```