Re: [Gramps-devel] Proposed changes to probably_alive

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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

Re: [Gramps-devel] Proposed changes to probably_alive

Gramps, the open source genealogy program

Re: [Gramps-devel] Proposed changes to probably_alive