* other pools: algorithms help.

[Ron Melby]

on my way to organizing families in descendant order, I have: from a chosen root (can be file root) find oldest ancestor for father and mother of that root. we will call these seeds. find the families by descension. that will get near everyone in the file. we come to a few families left over, these are the 'other pools', in every case I see. In my case it is a fairly large set. a comment: I have not seen a family cross pools, that is in the family, if they are a pool 2 they are all a pool 2 never some pool 2 and some pool 3 (and in thinking on this it is logical that this should be so) but I cannot find pool with a family pointer, I must only ask it of an individual. Seems to me there should be a fhGetFamilyPool(famptr)

so, question is kind of this, lets say for the sake of argument there are 23 families in 4 or 5 pools that are unrelated to the rest of my file, (any non-trivial combinations of numbers) but have their own 'hierarchy' Is there a clever way to find their underlying structure 'family heirarchies' that is reasonably free from complexity? To find the FAMs that are not in the descendency is easy but their FAM number gives no clue to their 'order'

[tatewise]

Never mind fhGetFamilyPool(famptr) there is not even a fhGetIndividualPool(indptr) function.
You must use fhCallBuiltInFunction( "RelationPool", ptrIndi ) where for Family records you can use the pointer in either %FAM.HUSB>% or %FAM.WIFE>% or %FAM.CHIL>% whichever exists.

[Ron Melby]

I don't know what the underlying code is, but the callbuiltinfunctions are always heavy lifting. getting the pool is not trivial in cpu, memory, and time, and that gives me a inchoate structure, but a starting point.

I would still have to inspect every individual record to determine some structure in each pool (find those without an (INDI_PTR, '~.FAMC) and run down the (INDI_PTR, '~.FAMS) for those records in each pool, which is akin to what I am doing now, but I cannot hammer it into shape using my current code, I do not think.

in the case where I pick a treetop as my root, the code falls thru to families in numerical order, it is the same if I pick a person not in pool 0 or pool 1 whatever my relational pool is.

If I play it straight and choose a root that is not a treetop and is in my 'base' pool I get a family ordered structure for those in the pool. then I run the leftovers (those in other pools) in order of finding them not already in the family orderings.

I am not doing from pools right now, but using roots and treetops.

It is sort of like chewing gum and drinking coffee-- great start but it fails at the non-conformers.

[tatewise]

You could loop through all Individual records and assign the Pool number to each Individual Record Id in an array.
Then you could loop through each Family record and assign a Pool number to each Family Record Id in an array.
That would let you to write a GetIndividualPool(indptr) function and GetFamilyPool(famptr) function that use the Record Id to lookup Pool number from the arrays.
i.e.
function GetIndividualPool(indptr)
return tblInd2Pool[fhGetRecordId(indptr)]
end

function GetFamilyPool(famptr)
return tblFam2Pool[fhGetRecordId(famptr)]
end

That should minimise the callbuiltinfunctions heavy lifting to just that initial looping phase.