Skip to content

Commit

Permalink
spelling
Browse files Browse the repository at this point in the history
  • Loading branch information
alecloudenback committed Jun 4, 2024
1 parent 4de5cfa commit a7d9e64
Showing 1 changed file with 8 additions and 8 deletions.
16 changes: 8 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ function exposure(

### Anniversary

`ExperienceAnalysis.Anniversary(DatePeriod)` will give exposures periods based on the first date. Exposure intervals will fall on annniversaries, `start_date + t * dateperiod`.
`ExperienceAnalysis.Anniversary(DatePeriod)` will give exposures periods based on the first date. Exposure intervals will fall on anniversaries, `start_date + t * dateperiod`.
`DatePeriod` is a [DatePeriod Type from the Dates standard library](https://github.com/JuliaLang/julia/blob/master/stdlib/Dates/src/types.jl#L35).

```julia
Expand Down Expand Up @@ -218,17 +218,16 @@ exposure(

`Calendar` basis does not have `left_partials` and `right_partials` because the same effect can always be achieved by setting `study_start` and `study_end`.


## Principles

- An exposure means a unit exposed to a particular decrement for an interval of time and that the risk *entered into that interval* exposed to that risk.
- When the decrement of interest occurs during an exposure interval, the exposure continues to the end of the *current* interval.
- Calculating an `AnniversaryCalendar(Year(1),Year(1))` is different than splitting an `Anniversary(Year(1))` or `Calendar(Year(1))` basis due to the prior two bullet points. Two implications of this:
- Exposures with `AnniversaryCalendar(Year(1),Year(1))` will tend to end sooner than the latter two because the former is by defnition split into two periods.
- Exposures with `AnniversaryCalendar(Year(1),Year(1))` will tend to end sooner than the latter two because the former is by definition split into two periods.
- This is illustrated by `e2` and `e3` being the same or longer exposures than `e1` in the example below.
- If you take a `Calendar(Year(1))`/`Anniversary(Year(1))` exposure basis and split it into two pieces split by Anniversary / Calendar breakpoints, you need to take into account that in the latter pieces of exposure the expected claims needs to be reduced by the surviving exposures from the prior interval.
- This is saying that if you were to divide the last interval in `e3` into two parts, split by the anniversary date, that the second part of that exposure needs to take into account that not all lives in force on `2012-01-01` would survive past the anniversary that splits the interval. Pretend we actually know that the decrement should be `0.01` per day. Then the expected number of claims over the `(from = Date("2012-01-01"), to = Date("2012-12-31"), policy_timestep = missing)` exposure is `1 - 0.99^366 = 0.97474`. If we split the interval and did not take into account the reduced lives entering in the second part of the split exposure, then we would have `1- 0.99 ^191 + 1 - 0.99^175 = 1.6811` expected claims. To correct for this, the second term needs to be adjusted for the amount suriving from the first.
- It is for this reason that ExperienceAnalyis.jl does not currently provide a way to "split" a `Calendar`/`Anniversary` exposure basis.
- This is saying that if you were to divide the last interval in `e3` into two parts, split by the anniversary date, that the second part of that exposure needs to take into account that not all lives in force on `2012-01-01` would survive past the anniversary that splits the interval. Pretend we actually know that the decrement should be `0.01` per day. Then the expected number of claims over the `(from = Date("2012-01-01"), to = Date("2012-12-31"), policy_timestep = missing)` exposure is `1 - 0.99^366 = 0.97474`. If we split the interval and did not take into account the reduced lives entering in the second part of the split exposure, then we would have `1- 0.99 ^191 + 1 - 0.99^175 = 1.6811` expected claims. To correct for this, the second term needs to be adjusted for the amount surviving from the first.
- It is for this reason that ExperienceAnalysis.jl does not currently provide a way to "split" a `Calendar`/`Anniversary` exposure basis.

Example: Issue: 2011-07-10, death = 2012-06-15, decrement of interest: death

Expand All @@ -250,11 +249,11 @@ julia> e3 = exposure(ExperienceAnalysis.Calendar(Year(1)),Date(2011,07,10),Date(

## Leap Years

When a policy is issued on a leap day (February 29th), it is preferable to have the next policy year start on the 28th. This is as opposed to having the segment begin on March 1st becuase when the leap year does come around again, we wouldn't want the segment to end on February 29th.
When a policy is issued on a leap day (February 29th), it is preferable to have the next policy year start on the 28th. This is as opposed to having the segment begin on March 1st because when the leap year does come around again, we wouldn't want the segment to end on February 29th.

### Example

Exposures are caulcated like this:
Exposures are calculated like this:

```julia-repl
julia> exposure(
Expand All @@ -273,6 +272,7 @@ julia> exposure(
(from = Date("2023-02-28"), to = Date("2024-02-28"), policy_timestep = 8)
(from = Date("2024-02-29"), to = Date("2025-01-02"), policy_timestep = 9)
```

And **not** like this:

```julia-repl
Expand All @@ -283,4 +283,4 @@ And **not** like this:
(from = Date("2019-03-01"), to = Date("2020-02-28"), policy_timestep = 4)
(from = Date("2020-03-01"), to = Date("2021-02-29"), policy_timestep = 5)
...
```
```

0 comments on commit a7d9e64

Please sign in to comment.