2012/8/23 Nick Hall <nick__hall@hotmail.com>
On 23/08/12 12:24, W. Trevor King wrote:
It sounds like you left out the todo list phase, where those
parentless individuals are dealt with:
Yes.  How should I process the todo list?  There seems to be a step missing.

At some point we need to adjust the generations in the branches that are too high up in the tree.

My idea was that the todo list people must be assigned an generation based on:

a. step one: determine estimated birth of everyone in the todo list. We have a function for that

b. step two: determine first generation. Those are the oldest in the todo list. These people will not be moved to another generation anymore

Assign every person a moveto list, which is [current_gen] initially, and for the root people None (to indicate they should not move)

c. step tree, determine what the correct generation is for non root people in the todo list

1. do they have a spouse/husband of generation j, then they should be generation j
2. do they have a sibling of generation j, then they should be generation j
3. if not assigned yet, if they have a calculated birth day, look for the generation in the decendants of the root people that fits this birth day best.
4. when assigning a person in todo list a generation, all their descendants must be moved to.
 Say a person goes to generatino 4. Then every descendant of this person should have minimum of current assigned generation + 4.  So moveto list is appended with this new generation.
The move should not happen yet however. Instead, all people in the todo list must be handled first.
After that, the move can happen to the highest generation in the moveto list, so to max(moveto).

I think that closes all holes. Problem will remain with disconnected sets of people, where the root decendants also don't overlap, eg root person of 1600 with decendants to 1750, and another set of people starting in 1820. With some luck, those will nevertheless with above approach start after the last generation of the descendants of 1600