Allow Fractional Age Everywhere

[Soel-Philippe]

Hello guys,
Nice project, here!
However, it'd be nice if we had fractional ages allowance by default.
For example, allowing fractional ages directly when instanciating SingleLife
objects knowing the fractional_assump... this implies changing
the way a couple of methods are implemented but it's relatively a light!

Thanks.

[alecloudenback]

Thanks! Do you mind posting a snippet of what you are currently doing? And then potentially what you'd like to do as an alternative?

[Soel-Philippe]

Thanks for your reply.
I think for completeness, it'd be good for fractional ages to be supported.
Example:
Suppose I want to build a constructor of SingleLife objects having a custom life_table built from MortalityTables...
I'd do it as:

sl(age::Real)=SingleLife(life_table,issue_age=age,alive=true,fractional_assump=Uniform())

I'd build a LifeContingency constructor on such a SingleLife as:

lc(age::Real,y::Real=0.0485)=LifeContingency(sl(age),Rate(y,Periodic(1))

As it's implemented now, I can't construct a LifeContingency as lc(23.75), it throws an ERROR.
The SingleLife constructor requires it's second args to be of type Int64.

Since it does interact with MortalityTables' objects, I don't know how much work is
needed to implement this... but I think a layer should be added between SingleLife
objects and MortalityTables' ones...

[alecloudenback]

Got it. I think that maybe that's not actually what you want to be able to do, unless mortality is parametric. That is:

1. if mortality is a vector of rates, then there's an inherent assumption about how issue ages get mapped from a Real to an Integer (see Age Last Birthday vs Age Nearest Birthday). The rates in the mortality assume that you start at an integer age as defined for that table via ALB or ANB
2. if mortality is a parametric model then a fractional starting age makes sense because the force of mortality is continuous and there's no need to map an issue age to ALB or ANB

Number 2 is actually not permitted currently but it should be, I have a draft PR up at #79. Before merging that, I wanted to get your thoughts. I think you were asking about number 1, but I'm not sure that it should be supported.

[Soel-Philippe]

Yes sir, being able to use a general parametric model, not only the Gompertz-Makeham, would be great!
But would you please to tell me how do I deal with non-Int ages? Assuming I have a table of rates (only
rates of Int ages).
If don't want to build the whole thing myself, using your API, how do I issue a policy with issue_age=25.25?

[alecloudenback]

It's the ALB vs ANB thing. When a mortality rate table is constructed, it is assumed that the issue age is an integer by rounding the fractional age to an integer before doing the computations. Mortality tables should say whether they are constructed assuming an integer issue age of ALB or ANB (e.g. 2001 Valuation Basic Table (VBT) Preferred Select and Ultimate Table - Male Nonsmoker. Basis: Age Nearest Birthday. )

In your example, actual issue age of 25.25 means you should use 25 for both age-last-birthday and age-nearest-birthday. However, 25.75 would be 25 or 26 depending on how the underlying table was calculated.

You said: "custom life_table built from MortalityTables" - do you know what the assumption was (ALB/ANB) when the custom table was constructed?

[Soel-Philippe]

That's the thing, I don't know the assumptions but I think it's foundable!
Thanks for your reply.