Brian, I had assumed a mechanism of that kind, but more seems involved. As you have put it, outcomes have to be or tend to even and quantized to powers of two. My last major cleanup had numbers to the low/mid 60s by estimation, which did seem clustered to roughly approximate by keystrokes while dismissing "unknown and unknown" parents to zero, finding no (simple) 20-70s, and all the large blocks in the low/mid 70s, spanning about 72-76. No simple doubling scheme works to get that.
What also showed up were cases where upward traversal truncated and the parent was present but embedded, i.e. with multiple "unknowns and unknown" both above and below. More telling were a few cases where a parent and a parent set were both embedded and separated. The parent sets were from the missing spouse being found and added in one file, probably the right hand one in the Intellimerge. Unlike in the major cleanup mentioned, this last one had very few couples with the multiplied spouses, (identical RINs, one being asterisked, the order apparently always matching). None had "unknown and unknown" complications, but that could be happenstance. Dennis' good catch on bad screen refresh did lead to another perhaps revealing datum though. It impelled me to examine the unrelated RINs for link damage, none being found, but RIN 210 was paired with an "unknown", so I dismissed her after noting that that would unlink her from husband and child. After dismissing hundreds of others, mostly parent pairs, plus fixing duplicate pairs, as a last check, I ran Treefinder - and there was RIN 210 as an isolate. Apparently dismissing an "unknown" spouse breaks the other's links too, or the child was only linked to "unknown". The logical and digital expression of "unknowns" raise some questions. I don't know how Legacy and gedcom work, but digital considerations may require space reservation for pointers and that they have targets. Logically, since children commonly have two parents, "unknown and unknown" seems redundant. A single "unknown" may be needed though to indicate child relationship to an unknown parent, distinguishing from those of named - or similarly unknown ones. Both logically and digitally, that leads to different classes and properties for "unknowns", e.g. a tree or branch head without parents merges quietly, but one with "unknown" ones apparently breeds them. Broadly a useful logical division might be "signaling" and "silent". (For programmers, see NaNs and their complexities.) Legacy might have been better designed assigning UID numbers to "unknowns". Certainly, if Legacy automatically assigns an invisible "unknown" to partner an unpaired parent if a child is linked, and silently breeds pairs of them with minimal warning, that's either a bug or at least deserving of written explanation and warning. A simpler alternative might be to simply include purge of all redundant "unknowns" during File Repair, though multiple and embedded parent sets are problematic. Best, obviously, would be acting at data entry time, but it may be too late for that. kb ----- Original Message ----- From: "Brian/Support" <br...@legacyfamilytree.com> They do not have to be duplicate, unless you meant duplicated after the import. Example: Mary has one set of unknown parents and a brother John you send the file with this family to another researcher for work. They amend the file and return it to you You import the file into your Master file and do an Intellimerge After the Intellimerge is finished Mary and John now have two sets of parents, both are unknown. I have not experimented but my feeling is that if you do not correct this duplication and send the file out again. When you do another merge after the file is returned Mary and John will end up with 4 sets of parents. Brian Customer Support On 02/03/2011 5:05 PM, Ron Ferguson wrote: > > > Brian, > > I think I have got you now! Are you saying that if you have duplicate > families, both with an unknown-unknown set of parents, then after using > intellimerge one would have two sets of unknown-unknown parents? > > Ron Ferguson > http://www.fergys.co.uk/ Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyusers.com/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyfamilytree.com/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
