From: Doug B. <dou...@gm...> - 2009-01-31 03:11:00
|
On Fri, Jan 30, 2009 at 2:48 PM, Benny Malengier <ben...@gm...>wrote: > > > 2009/1/30 Doug Blank <dou...@gm...> > >> On Fri, Jan 30, 2009 at 8:10 AM, Benny Malengier < >> ben...@gm...> wrote: >> >>> >>> >>> 2009/1/30 Doug Blank <dou...@gm...> >>> >>>> >>>> >>>> On Fri, Jan 30, 2009 at 4:31 AM, Benny Malengier < >>>> ben...@gm...> wrote: >>>> >>>>> >>>>> >>>>> 2009/1/30 Doug Blank <dou...@gm...> >>>>> >>>>>> I notice that src/Relationship.py looks like it has support to >>>>>> describe in-laws, but in trunk I see that I am not related to my >>>>>> father-in-law in the status bar, nor in the Relationship Calculator Tool. Is >>>>>> that a bug, or by design? I didn't see in the wiki docs any mention of >>>>>> in-laws, and don't remember if this was mentioned when Benny enhanced the >>>>>> relcalc this past year. >>>>> >>>>> >>>>> Only the quick report shows inlaws i believe, as you wait anyway for >>>>> this specific person's relation to the home person to come up. >>>>> Performance reasons are at the basis for not showing it elsewhere. I >>>>> don't have hard data that it is much less performant, but for inlaw you have >>>>> at least 4 (can be much more in multiple marriages) possibilities to scan, >>>>> otherwise only one. >>>>> >>>>> Benny >>>>> >>>>> >>>> >>>> Great, thanks for the pointer. Is that code that could be put in the >>>> calculator? I'm looking for a way to make a "deep relationship finder" (find >>>> any possible relationship) without having to do it by hand, or copying that >>>> code. Or is it necessarily stand-alone? >>>> >>> >>> I'm not following. The code is fully reusable with some parameters. >>> Relationship calc, quickreport and status bar all call the same function. >>> >> >> What is the easiest way to find an arbitrary relationship between two >> people? It looks like the code in the all_relations quick view takes some >> special processing to search the in-laws? I was wondering if that in-law >> logic could be put in one function? >> > > ok, I understand now. > I believe the get_inlaw function could move to utils, it is more usefull > than the usage now. > If the rest can be one function, probably. As this quick report was the > only place I intended using inlaw relationships, it is not like that now. > As always with reports, the way you write to the report is often very > connected to the way you run over the data. Splitting these two is not > always an easy task. If you want to show inlaw relationships somewhere else, > then that would be a good way to start splitting the two things that are > done so as to reuse the common part > > >> Also, I note that the "Quick View" is more thorough than the "Relationship >> Calculator" Tool. I would think that the tool would be at least as thorough >> as the quick view. The tool uses: >> >> rel_strings, common_an = self.relationship.get_all_relationships( >> self.db, self.person, >> other_person) >> > > Yes, wel, not doing in-law relationships allows you to cache all the data > from the person that does not change (the active/home person). Also doing > in-laws makes this 1/more difficult, 2/taking up more memory. This can be a > real problem on slower computers ! Especially as the home person is normally > a person with a large tree. > > >> >> What would that change to to get the in-laws? >> > > Take over the logic from the the all relations quick report. But as the > relcalc tool must be sufficiently fast, some cache of the active person and > it's partners would then be usefull. > This now happens with self.storemap in get_relationship_distance_new in > Relationship.py > It is important for the speed of the relcalc tool (fixed active person), as > well as the message in the status bar (fixed home person). > > >> >> One final question: Does the quick view version find all possible >> connections between two people (up to the max generation limit)? I'm >> wondering because I ended up with a group of people in my tree that I can't >> find how they are related to me. I'm wondering if I can find the link >> (however weak it might be) between any of them and me through the tools >> already in GRAMPS, or do I need to do a "deep search" to recursively find >> the connection? >> > > So the quick report does not give a relation. The search goes to ancestors > looking for common persons. So you must image trees going up in the > branches. Hence it helps to start as low as possible in the tree. > You can think easily of connections that won't be found: parents of spouses > of uncles for example have no relation to you according to the relationship > calculators, if you do not start specifically with the spouse. This is > obviously correct, as you only have a relationship to these people AFTER the > marriage. So you will find the relationship starting from one of their > children (barring remarriages, don't remember now how deep stephchildren > search goes). > Hence a trick is to run a descendant report on the branch you have no > connection with, then run the all relationships tool on all descendants in > your branch and all descendants in that branch, so that inlaw connections > between the lowest roots are found. > Ok, great information in this thread! Thanks all. So, it sounds like we can summarize this as follows: 1) The "Relationship Calculator" Tool gives the same information as the status line. It is quick, and doesn't show in-law relationships. 2) The Quick View "Relation to Home Person" finds the closest common relative between two people, does take into account some in-laws, and is still very quick. 3) The Family Lines show some of these connections, but not all. 4) The Disconnected Person Filter will show you only people that aren't connected to anyone else... it doesn't show people that aren't connected to an arbitrary person So, it turns out that I wasn't really interested in the relationship between two people, I was more interested in how/if they were connected. I also didn't mind if GRAMPS wanted to chug through the data for awhile, as it would save me time from doing it by hand. So, it sounds like a new use. I'm not convinced that we need yet another variation, but I've added an experimental, slow, thorough gramplet called, for the moment, Deep Connections. You can see a picture here: http://gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Gramplets#Deep_Connections_Gramplet Perhaps this should be a 3rd-party plugin? Let me know if you find this useful, and different enough to include in GRAMPS. -Doug > > Benny > >> >> >> -Doug >> >> >>> >>> Benny >>> >>>> >>>> -Doug >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> -Doug >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> This SF.net email is sponsored by: >>>>>> SourcForge Community >>>>>> SourceForge wants to tell your story. >>>>>> http://p.sf.net/sfu/sf-spreadtheword >>>>>> _______________________________________________ >>>>>> Gramps-devel mailing list >>>>>> Gra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>> >>>>>> >>>>> >>>> >>> >> > |