* a few age related questions

[JoopvB]

I like to show the age of a person in the sentence of his/her death.

The right way to get this is, I think, using {%FACT.DATE:AGE_AT%}.

This gives me the age in years; for children it would be great to have it in more detail (say months/week/days). So, I would have to find out if is a child (say, test the age below 2) and then use something else (but what)?

The other thing is: from older records, the death date is usually not known, so I use the burial date if known. Of course I can use the death solution above; but I would like to appear an age at the burial only when there is no death fact (since it would then be there already). The question then becomes: how do I check in the Burial fact whether a Death fact exists?

[tatewise]

I suggest you use the {age} code in Sentence Templates. I think the default Sentences already do so.

Then enter the Age you want in the Fact you want Age to appear in the Sentence.
i.e. Enter the Age in the Death event, but not the Burial/Cremation event, unless there is no Death event. If the Age box is not shown on the Facts tab then Edit that Fact Definition and tick the Age option.

The Age box allows Years, Months & Days to be entered.

This approach needs no Expressions, Functions, or Data Refs and you are in complete control of exactly what Age is displayed where on a Fact by Fact basis.

[JoopvB]

This usually is not a problem when using death certificates as sources (they record the age at death). But when it's a burial record from older sources, the age at burial is not recorded, which means I have to do the calculations myself (with possibly errors and untraceable inconsistencies).

I have no problem with entering the age in the age field at e.g. Death and get an error indicator to warn me that it is inconsistent with the calculated age. But I really don't see why the age as calculated from a known birthdate should not be readily available to print in a narrative. No problem that (as yet) no template codes to represent this exist in FH, but I would have thought it possible with the data references and functions.

I still hope you can help me out Mike (at least partly) while waiting for FH to implement a calculated age template code.

[LornaCraig]

I really don't see why the age as calculated from a known birthdate should not be readily available to print in a narrative.

A calculated age is available. Just use {age range}. This inserts a calculated age if no age information has been recorded against the fact.
See this information in the Help files:

[JoopvB]

Thanks Lorna, must have overlooked it (maybe put on the wrong track because of the name of the code "date range").

This helps me out in all situations but the burial/death combination. Any ideas on how to test whether that combination exists for an individual?

[tatewise]

{age range} is new in FH V6 and I overlooked that.

It should display an Age in Years, Months & Days if you explicitly enter those details.

However, as we have discussed elsewhere, it is not possible to make a code such as {age range} conditional on a function such as {=Exists(...)} or {=TextIf(...)}.

So what are the options?
A)
The simplest is to always enter a Death event, even if it only has a Before Date prior to the Burial Date and never mention Age in the Burial sentence.
So the sentences say He died before 21 May 1900 aged 99. He was buried on 21 May 1900...
B)
Similar to testing INDI.SEX in Non-English sentences (12564) the way to test for a Death event will be something like:
{=TextIf( Exists( Field( GetRecord(), 'INDI.DEAT' ) ), "X", "Y" )}
or some variant based on =ExistsText(...) or =NotExistsText(...)
BUT the problem is the AGE_AT qualifier or =AgeAt() function, because you have to cater for so many options.
If there is no Birth Date then Age At is null and the whole Age text must be omitted.
If the Age At is less than 2 years then Years, Months & Days must be calculated (I have not started to contemplate that, but =Timespan() function may be a good starting point).
If the Age is actually recorded as Child, Infant, or Stillborn what then?
If the Age is actually recorded as Younger than... or Older than... what then?

[JoopvB]

Hi Mike,

Yes, to me it also seemed complex (given the set of tools currently available in FH). Maybe if we split it up?

1) As Lorna indicated: use {date range} to get the calculated age at the moment of a given fact. Solves 90% of the problem.

2) Find out if, when in a Burial fact, a Death fact exists... Your solution: {=TextIf( Exists( Field( GetRecord(), 'INDI.DEAT' ) ), "X", "Y" )} seems to solve that. However, I don't yet understand what the variants you mentioned are meant to do. If that works (I am going to try it out now) then the problem is 95% solved - which is a very satisfactory score.

3) The last wish I had was differentiating between early age deaths and the ones of grown up's. Maybe we'll have to leave that to some extension of the {date range} code to implement by FH in one of the next releases (it makes no sense to display an age of 0 if one died after 364 days).

BTW You wrote "It should display an Age in Years, Months & Days if you explicitly enter those details.". I assume this only applies when entering the age, not when calculated (as intended)?

[LornaCraig]

I know you want your reports to show the age recorded in the burial register if there is no death fact. However the burial register is recording the age at which someone died, because they don’t go on getting older between death and burial. In fact I’m not sure it makes sense to say how old someone was when they were buried. In normal conversation we would say how old someone was when they died, and then say where/when they were buried.

So I would follow Mike’s suggestion of creating a death fact with an approximate date (usually the same month as burial, unless they were buried at the start of the month) and if the burial register gives an age add that to the death fact, perhaps with a note saying “age recorded in burial register”. Then always include {age range} with the death but never with the burial.

I do realise this might mean you have to go through a large number of records creating death facts, but I think the reports will read more sensibly.

Regarding your third point, you can enter Child to indicate less that 8 years old and Infant to indicate less than one year old. These will then appear in the sentence for the fact.

[tatewise]

To answer your last question first, {age range} is quite clever.
It will handle every explicit Age entry, including Child, Infant, Stillbirth, Younger than, Older than, Yesrs, Months, Days, etc.
If there is no explicit Age but the calculated Age is less than 1 year it says as an Infant.

However, as I said, the snag is you cannot use 1) and 2) together in the Burial event.
i.e. The following does NOT work
{=NotExistsText( Field( GetRecord(), 'INDI.DEAT' ), {age range} )}

So you have to construct the required text from Expressions.
e.g.
{=NotExistsText( Field( GetRecord(), 'INDI.DEAT' ), Text( " aged " . AgeAt( GetRecord(), EstimatedDeathDate( GetRecord(), MID ) ) ) )}
will say something like aged 25 providing there is an estimated death date and no Death event.

BUT, if there are not enough Dates to yield an AgeAt(...) it will just say aged .
(I have tried making the Text(...) conditional on an AgeAt(...) value, but given up.)
If the person was buried as a child then it says aged 0.
Also, if an explicit Burial event Age exists, it is ignored.
We have not even started to consider Years, Months & Days.

So the Expression to create the required text is going to be very extensive, unless I have missed some trick along the way.

[JoopvB]

Thanks Lorna and Mike for all your help.

I also found out that {date range} will use "infant" when < 1 year old, which is not really the end solution but better than 0.

@Mike - I see your point now; it's not the problem of testing whether or not both death and burial facts exist, but the inability to use that knowledge to conditionally show the result of {date range}.

@Lorna - I agree that an age at a burial is somewhat artificial. However, I like to reflect the information from the source in my facts as correctly as possible. This, for me, means that a death fact if not in the source should not be in the fact list. Also, old church records (as well as tax records) tend to record the burial (that's when e.g. the tax was due) and the person's age! This would suggest that our ancestors were (sometimes) less strict about age as an attribute of only living people. Maybe it's got to do with people being buried before death (not unheard of)...

Would a second Burial fact (e.g. Burial-Death) solve my problem? This new fact, effectively a copy of the Burial fact, but with an {age range} in it as opposed to the Burial without it, could then be used in all situations where a death is unknown but the burial is.

[LornaCraig]

I like to reflect the information from the source in my facts as correctly as possible. This, for me, means that a death fact if not in the source should not be in the fact list.

I take your point. I make the assumption that if someone is buried thay have already died, so the death fact is implicit in the burial fact!
I cite the burial record as a source for the death fact, if there is no other evidence for the death. With an approximate date for the death it won't be far wrong, because if they were not dead when they were buried they would have died soon afterwards!

[quarlton]

This is a question asked out of curiosity.

When a new event is added to a person, FH adds an age in brackets.
On occasion this is a dual age e.g. (46-47).

I was idly wondering how FH arrived at these two values.

Reading Lorna Craig's post above, I note that in Sentence there is the option to use {age range} but I can't find the equivalent for use in Queries.


My original thought was that it was using =EstimatedAgeAt(), but in my tests I didn't get the same results.

e.g.
Born: 6 Feb 1879
Marriage: 1926

FH gives the age at marriage as (46-47) which is perfectly understandable as we don't know the exact date of the marriage.


A simple =AgeAt() returns 47

=FACT.DATE:AGE_AT returns 47

I tried the 3 variations (MIN/AVG/MAX) of =EstimatedAgeAt() - all return 47 [Parameter 4 was set to 0,1,2,3,4]


Does anyone have any suggestions?

[tatewise]

The problem is that when using =EstimatedAgeAt( GetRecord(%FACT%), %FACT.DATE%, MIN, 2 ) the %FACT.DATE% is always the earliest possible Date. That problem impacts Date sorting too.
i.e. 1900 is 1 Jan 1900, and from 1900 to 1905 is also 1 Jan 1900, and even after 1990 is 1 Jan 1900

So MIN and MAX only have any impact when there is no actual Birth Date for the person and the close relatives are investigated to estimate the Birth date.

As an experiment I replaced %FACT.DATE% with:
DateIf( Exists(%FACT.DATE:XDATE2%), %FACT.DATE:XDATE2%, %FACT.DATE% )
and when the Date is such as from 1900 to 1905 or between 1900 and 1905 the age shown is 5 years greater than before.

It appears that the {age range} code is using the earliest and latest possible values for any particular Date.
i.e. 1900 is 1 Jan 1900 to 31 Dec 1900, and from 1900 to 1905 is 1 Jan 1900 to 31 Dec 1905, not sure about after 1990

It is quite complicated to achieve similar date ranges in Expressions.
What is needed are =MaxDate( ) and =MinDate( ) functions.

[quarlton]

Many thanks for your reply Mike.

It does seem strange that {age range} exists for use in Sentence but not in query functions.

I've asked the question of Calico Pie - but I'm not holding my breath.

As I said, it was just something that made me curious.

[tatewise]

A few more experiments show that =EstimatedAgeAt( ) does take account of Birth Dates such as between 1900 and 1905.

The function help says:
MIN The person’s youngest possible age at the date in question.
MAX The person’s oldest possible age at the date in question.
But as we have shown, that is not honoured if the date in question doesn't specify the day & month, or spans a period.

You could report that to CP as an error.

There are many scenarios where Sentence Template codes and Expression Functions could be more consistent.
There is the Wish List entry Ref 577 Sentence Template Functions to Replace Codes on that topic that you could Vote for.

[quarlton]

Official response from CP

To: Dave Simpson

Sorry, it's not possible at the moment as the {age_range} does not have an equivalent built in function.



Ros

Family Historian Support
Calico Pie

[tatewise]

You could follow that up by asking why =EstimatedAgeAt( , ,MIN) and =EstimatedAgeAt( , ,MAX) don't provide the same two values as {age_range} and quote the function Help regarding the MIN and MAX options.
i.e. Why do MIN/MAX not provide the person’s youngest/oldest possible age at the date in question?

In other words the =EstimatedAgeAt( ) built-in function is almost equivalent and would provide the {age_range} values if it honoured the Help page specification for MIN and MAX, but it doesn't.

[quarlton]

I have contacted CP regarding =EstimatedAgeAt(), at the same time I asked if they could let me have the algorithm for {age range}.

A little experimenting leads me to believe that it may be how FH interprets dates when they are not fully qualified.
It appears to me that all such dates are interpreted as being the earliest possible date within the example.

Thus:
1871 is interpreted as 1 JAN 1871
MAY 1871 is interpreted as 1 MAY 1871
Q3 1871 is interpreted as 1 JUL 1871

Whilst this may be acceptable in many cases, after all some decision needs to be made as to the value, when used with MIN / MAX I believe that it should take both the minimum and maximum dates in to account.
e.g.
1871 should be checked using both 1 JAN 1871 and 31 DEC 1871

I'll see what CP come back with.

[tatewise]

Yes, and the difference between MIN & MAX is even greater with Period and Range dates.
However, what MIN or MAX should be with after, before, from, and to dates is not clear as they are open-ended.

The same MIN / MAX strategy needs to be applied to the Birth Date too, whether actual or estimated.

So with a Birth Date 'between 1900 and 1905' and a Fact Date 'between 1950 and 1955' the MIN and MAX age would range from MIN = 31 Dec 1905 to 1 Jan 1950 = 44 and MAX = 1 Jan 1900 to 31 Dec 1955 = 57 if my maths is correct.

[quarlton]

I agree, it is not possible to really come up with suitable values for Before and After.

I've had a response from CP.
They appear to have ignored the =EstimatedAgeAt() comments.
And no, they won't let me have the algorithm for the {age range}

To: Dave Simpson

>> Would it be possible to have the algorithm for {age range}?

I'm afraid not. It's a significant chunk of code that generates it. The only thing I can suggest is that you could either write something yourself in a plugin (use the age entry assistant dialog to set up examples in the sample project of all possible ages to work out what it returns) or you could raise a Wish List request for this data to be exposed as a built-in function or FH API function or both.

Martin


It was only an idle thought in the first place...

[tatewise]

Could you press them on the =EstimatedAgeAt() function and emphasize that it does not honour the Help page definition for MIN and MAX, i.e. it does not take the full extent of the date in question.

[quarlton]

I've gone back to CP and reiterated the issue regarding =EstimatedAgeAt().

I also pointed out that whilst I possibly could, as they suggest, write a Plugin to emulate {age range}, that a) I don't really want to reinvent the wheel, and b) if it's in a Plugin it won't be available in a query which is where I am looking to use it.

I think I'm probably flogging a dead horse now

[quarlton]

I've had a further email from CP asking me to
Please send us a quote for the description which you believe to be incorrect.

I have done this along with a worked example showing how the =EstimatedAgeAt() function is operating.

To my way of thinking it is straight forward:-
DOB: 06/02/1879
DOM: 1926

This gives a minimum range of 06/02/1879 to 01/01/1926 - then the EstimatedAgeAt(MIN) should return 46
and a maximum range of 06/02/1879 to 31/12/1926 - then the EstimatedAgeAt(MAX) should return 47

We'll just have to wait and see what the reply is.

[tatewise]

Thank you for persisting with this. These days CP seem to need more spoonfeeding to explain a problem!
My bet is they choose to change the function Help page description for MIN & MAX.

[quarlton]

Just had a reply from CP - partial success.

They have clarified why it doesn't work - it appears that MIN/MAX is only applied to the Birth Dates. It also implies that a year is being taken as a whole value, with no discrimination e.g. A person born on 16th May 1910 is taken as exact, but when compared with 1940 it doesn't take in to account that the persons age will change between 29 & 30.

(Highlighting is mine)
Family Historian dates can be complex. A birth date could be recorded as a range - e.g. between 1920 and 1940 say. The parameter date could also be a range - between 1940 and 1960 say. The minimum possible age in that scenario would be 0 (born 1940 and the event happened in 1940) and the maximum would be 40 (born 1920 and the event happened in 1960).

The MIN and MAX values of the EstimatedAgeAt function currently only affect the MIN and MAX possible birth dates, based on the available information - which is why in your example the result is the same. The birth date is known precisely. The help is currently misleading about this. We will look at changing the function to apply the min/max testing to both dates (e.g. for MIN, this would be the latest possible birth date with earliest possible parameter date, etc). Thank you for raising this issue.

So, it's now just a case of wait and see.