From: Douglas S. B. <db...@cs...> - 2007-11-21 20:17:14
|
After thinking a bit more about comparisons for probably_alive, I decided to make it work with "about", "between", "after", "before", "slashdates", ... the whole 9 yards. Now, you can enter any date in the Probably Alive filter, and get the correct answer. So, you can now ask for people that were probably alive "between 1900 and 2000" or those that were probably alive "about 1865" or "before 1600". In addition, it catches some cases it didn't before for regular comparisons. In order to make this work, I added a new parameter to the Date.match() method. Now you can use the same match logic for checking to see if one date happened strictly (or possibly) before/after another date. -Doug On Wed, November 21, 2007 10:42 am, Douglas S. Blank wrote: > On Wed, November 21, 2007 10:32 am, Gerald Britton wrote: >> I believe you will need to gracefully handle fuzzy dates. I, for one, >> use them extensively. > > Gerald, > > Sorry, I should have been more clear. This restriction is only for > checking for "probably alive", and only for the check date, not for the > event. For example, it wouldn't make much since to see who was alive > "about 1865". But if you enter "1865" in the Probably Alive filter, then > those people that were born "about 1865" should show up. (Perhaps there is > a need for this, and for ranges? It might be useful to see who was > probably alive "between 1600 and 1630"...) > > Previously you could only enter specific years. Now you can enter specific > dates ("1965", "Jan 1865", "Jan 6, 1865"). > > Your question does make me think that we are going to have to do some > testing... I don't think probably_alive works (and never did) with fuzzy > nor modified death dates... I'll add a question in the bug tracker. > > Thanks! > > -Doug > >> On Nov 21, 2007 10:27 AM, Douglas S. Blank <db...@cs...> >> wrote: >>> Committed 9379 - 9381: >>> >>> 2007-11-21 Douglas S. Blank <db...@cs...> >>> * src/Utils.py: probably_alive now takes date rather than year >>> * src/gen/proxy/living.py: create date from year >>> * src/gen/lib/date.py: added methods to do date math >>> and return Date object (set_yr_mon_day_offset, >>> copy_offset_ymd) >>> * src/plugins/Calendar.py: updated to use probably alive date >>> * src/Filters/Rules/Person/_ProbablyAlive.py: parse entry as >>> date >>> >>> Please let me know if you see anything acting funny related to >>> probably_alive (for example in the NarrativeWeb in selecting privacy on >>> living people). >>> >>> There are some differences from previous behavior: >>> >>> 1) Setting a Probably Alive filter takes a date rather than a year. An >>> unhandled exception will occur if you apply a Probably Alive filter on >>> a >>> date that is fuzzy ("about") or is "modified" (span or range). >>> >>> 2) The probably_alive function is more discriminating now. Before, if >>> someone died on "April 4, 1865", then they were marked as not alive at >>> all >>> in 1865. Now, a Probably Alive filter for "1865" will list them. Of >>> course, you can be more precise (filter on "April 5, 1865") so that >>> they >>> won't match. >>> >>> 3) The calendar-based reports will only list a birthday if a person was >>> alive on that day (and the alive option is checked); will only list an >>> anniversary if both people were alive on that day (and the alive option >>> is >>> checked). I need to change the text of the alive option now... >>> >>> -Doug >>> >>> >>> On Wed, November 21, 2007 7:39 am, Douglas S. Blank wrote: >>> > On Wed, November 21, 2007 3:53 am, Benny Malengier wrote: >>> >> as long as you don't want to change it next to be correct on the >>> second, >>> >> it >>> >> looks ok to me ;-) >>> > >>> > Now that you mention it, perhaps dates should have nanosecond-level >>> > accuracy... :) >>> > >>> >> Best raise an error if date with qualifier is given I'd think, so as >>> to >>> >> make >>> >> it clear to all future developers using this that their calling >>> method >>> >> is >>> >> wrong. I'm no big fan of procedures guessing what the caller means. >>> > >>> > Yes, good point. Thanks for the feedback! >>> > >>> > -Doug >>> > >>> >> Benny >>> >> >>> >> 2007/11/21, Douglas S. Blank <db...@cs...>: >>> >>> >>> >>> I'm working on making the output in the calendar-based reports not >>> show >>> >>> anniversaries and birthdates for a person after they have died on a >>> >>> particular date. >>> >>> >>> >>> I think that the best solution would be to have a probably_alive >>> >>> function >>> >>> that works on dates rather than years. I propose to change: >>> >>> >>> >>> src/Utils.py: probably_alive(person, db, current_year=None, >>> limit=0) >>> >>> >>> >>> to: >>> >>> >>> >>> src/Utils.py: probably_alive(person, db, current_date=None, >>> limit=0) >>> >>> >>> >>> where current_date would be a GRAMPS date object rather than just a >>> >>> year >>> >>> integer. If None is passed in, it would default to today. >>> >>> >>> >>> Most of the uses of probably_alive use the default value of >>> >>> current_year >>> >>> and should not be effected: >>> >>> >>> >>> src/DataViews/_PedigreeView.py >>> >>> src/plugins/WriteFtree.py >>> >>> src/plugins/WriteGeneWeb.py >>> >>> >>> >>> There are 3 calls that pass in a year value: >>> >>> >>> >>> src/plugins/Calendar.py >>> >>> src/gen/proxy/living.py (used in src/plugins/NarrativeWeb.py) >>> >>> src/Filters/Rules/Person/_ProbablyAlive.py >>> >>> >>> >>> The Calendar I'm working on. Narrative uses the current year. The >>> only >>> >>> big >>> >>> difference that I see would be if we allow the probably_alive >>> filter >>> to >>> >>> take a date entry rather than a year. This has implications if we >>> allow >>> >>> fuzzy dates ("about 1965") or ranges ("between Jan 1, 1800 and Jan >>> 2, >>> >>> 1850"). I'm not even sure what fuzzy dates or ranges would mean >>> here. I >>> >>> think we should restrict the probably_alive filter to dates with >>> >>> variations in specificity ("1900", "Jan 1900", "Jan 5, 1900"). >>> >>> >>> >>> Anyone see a problem with these proposed changes or have other >>> ideas >>> or >>> >>> comments? >>> >>> >>> >>> -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 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 >>> >> >>> > >>> > >>> > -- >>> > 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 >>> > >>> >>> >>> -- >>> 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 >>> >> > > > -- > 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 > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 |