Menu
▾
▴
Re: [Gramps-devel] GRAMPS Philosophy?
|
From: <ann...@co...> - 2007-09-17 05:44:51
|
Looks like I'm a bit late with this, but I'll respond anyway in case it helps further down the track with ideas. I've seen problems of this sort dealt with in other programs by having a Preferences option within the program where the user could specify how many years "about" actually meant. Defaults I've seen have been 10 or 20 (i.e. about 1960 means 1950-1970, or 1940-1980). If the defaults are sensibly chosen, then the naive user will usually get what they actually wanted anyway, and the advanced user can change the defaults. A minor little trivial and unimportant point: >>> So there are two date matches: normal match and loose match >>> The normal match will if you search on 1900 not return 01-01-1900, >>> as it does not match. To me, a "normal" match would mean that 1900 would match both 1900 and 01-01-1900. An "exact" match would mean that 1900 would match 1900 but not 01-01-1900. I hope no one minds me posting these responses to questions regarding what and how GRAMPS does things. My aim is to throw other ideas into the pool of thoughts, to help ensure whatever is implemented is the best solution, after consideration of the alternatives. Cheers, Anne. Douglas S. Blank wrote: > Benny, > > There is a patch on: > > http://bugs.gramps-project.org/view.php?id=1219 > > that fixes all issues with date comparisons (and there were a few). I went > with a very conservative interpretation, but I added an option called > "smart". If we set smart=1 in the future (by making it a user option) then > it does a whole lot more. > > You can run the tests with: > > export PYTHONPATH=/path/to/gramps/src python src/RelLib/_Date.py > > Let me know if you see anything or have comments. > > -Doug > > On Sun, September 16, 2007 7:53 am, Douglas S. Blank wrote: >> I'm cleaning up that code so there won't be a distinction between "loose" >> and "regular" matches, which will make things easy and less prone to >> error. It will do the "right thing" where it needs to. >> >> I could go with a literal interpretation of "before 1960" that would be >> interpreted as "negative infinity to 1960". But then "about 1960" would >> still need a value for N and would have very different results. I'm not >> going scrap the entire date comparison because of this, but will come up >> with something consistent, simple to use, and useful in that it will give >> you what you want. >> >> Should have a fix posted for bug 1219 later today. Thanks all for your >> feedback! >> >> -Doug >> >> On Sun, September 16, 2007 4:53 am, bm...@ca... wrote: >>> To put this in perspective, this thread is a consequence of >>> http://bugs.gramps-project.org/view.php?id=1219 >>> >>> So there are two date matches: normal match and loose match >>> The normal match will if you search on 1900 not return 01-01-1900, as it >>> do >>> es >>> not match. >>> >>> Do we need such a filter match? This filter has a big problem with non >>> regu >>> lar >>> dates, as what is an exact match for a range or a span? This is not >>> defined >>> at >>> the moment. We would need some sort of definition >>> >>> The loose match adds some logic, and matches 01-01-1900 if you search >>> for 1900. >>> >>> For this filter, there might be a problem with before or after. I see >>> two >>> options: >>> 1/do not allow before and after entries in the filter >>> 2/do literally what the user asks. >>> >>> So 1500 is 'before 1930' >>> I would vote for the 2/, as is said by somebody else, one can refine >>> things with >>> a span or range search, giving the user total control. I would not add >>> the >>> N >>> logic >>> >>> An easy solution for the normal match would be to do the normal match >>> for >>> regular dates, and use the loose logic match for non-regular dates. >>> >>> Another option is to replace the normal search by a textual search, so >>> to search >>> the text string that is constructed with ISO format. This would be >>> consiste >>> nt >>> with the other textual searches. Then real date matching searches are >>> alway >>> s >>> done by the loose search, which after all is an exact search if one >>> enters >>> the >>> exact date (eg between 12-12-2001 and 14-12-2001). >>> >>> Benny >>> >>> >>> Quoting Stéphane Charette <ste...@gm...>: >>> >>>> I personally like the idea of adding a bit of extra smarts. >>>> >>>> The trick, however, will be to define "N" -- or maybe to come up with >>>> a different way to do this? But using your same example: >>>> >>>> Filter <whatever> for dates between 1510 and 1520. >>>> >>>> It is easy to say that a record described as "before 1960" shouldn't >>>> matc >>> h. >>>> What about "before 1760"? Or "before 1560"? >>>> >>>> Should "before 1530" match a search criteria of "between 1510 and >>>> 1520"? >>>> >>>> Stéphane >>>> >>>> >>>> On 9/15/07, Douglas S. Blank <db...@cs...> wrote: >>>>> It is clear that GRAMPS has implemented a straightforward, focused, >>>>> and >>>>> clean philosophy: basically don't do anything unless the user has >>>>> explicitly told it to do so. Likewise, GRAMPS makes few assumptions, >>>>> and >>>>> where it does, they are almost always useful and easily undo-able (for >>>>> example, guessing gender based on given name). >>>>> >>>>> I'm working on cleaning up a couple of places in the code, and need >>>>> some >>>>> feedback. The choices are basically: >>>>> >>>>> - assume nothing, but GRAMPS won't be as useful as it could be >>>>> - make some assumptions, and make GRAMPS more useful >>>>> >>>>> For example, I'm working on date comparisons. Say person A was born >>>>> "before 1960". Now, you want to do a PersonView Sidebar filter on >>>>> people >>>>> born "before 1959". It seems clear that we surely want to have person >>>>> A >>>>> come up as a match. But it isn't clear exactly how to handle this in >>>>> general. There seems to be two realistic choices: >>>>> >>>>> 1. "before 1960" means any date < 1960 >>>>> 2. "before 1960" means (1960 - N) < any date < 1960 >>>>> >>>>> If you go with choice 1, then we are being very literal with no >>>>> assumptions. But it would mean that person A would also match a filter >>>>> looking for people born "before 1500" which is silly. Person A would >>>>> als >>> o >>>>> match "between 1510 and 1520". Some of you might say "don't have dates >>>>> like 'before 1960'" but of course we do. >>>>> >>>>> If you go with choice 2, then we make an assumption: when you say >>>>> "befor >>> e >>>>> 1960" you really mean within N number of years. But what is N? Will >>>>> this >>>>> be too confusing for users if we have this assumption? >>>>> >>>>> A similar difficulty arises with "about 1960". Surely we want to make >>>>> so >>> me >>>>> kind of assumption about that? If you were searching for people born >>>>> in >>>>> "1959" you would want them to match, right? >>>>> >>>>> It seems like we have to make some assumptions. We could distill them >>>>> do >>> wn >>>>> to just a few (like we have in probably_alive---people are assumed to >>>>> li >>> ve >>>>> for no more than about 100 years) and even make those user definable. >>>>> Do >>> es >>>>> that sound like the best option? >>>>> >>>>> -Doug >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>> >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >> >> -- >> Douglas S. Blank >> Associate Professor, Bryn Mawr College >> http://cs.brynmawr.edu/~dblank/ >> Office: 610 526 6501 >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > |