try transducers approach for term life benchmark

[MatthewCaseres]

I'm just curious to see what it looks like

[serenity4]

Transducers may be used at two layers:

• An outer layer, which takes a month to simulate and carries out a simulation. Something like 1:50 |> Simulate(model, policies) |> collect. The result would likely be a single result, i.e. we don't return a collection but the last timestep (we could theoretically return one SimulationEvents per timestep, but that would prevent memory reuse between two timesteps).
• An inner layer, which takes policies to be processed to generate new policies:

  step = SimulationStep(model)
  new_policies = policies |> step |> collect
  # do something with step.events

  This inner transducer would be invoked on current policies for a given iteration of the outer transducer. Inactive policies that become active on the next timestep would need to be preprocessed and added to the list of current policies between two invocations. SimulationStep would be a stateful transducer containing SimulationEvents to be mutated, required for non-intrusive cashflow computations.

Another idea for transducers would be to decompose the different simulation stages (maturity, new policies, deaths, lapses), and then have a simulation step be invoked as a transducer:

events = SimulationEvents()
new_policies = policies |> Maturity(events) |> NewPolicies(events) |> Deaths(events) |> Lapses(events)`

# with maybe something like
SimulationStep(events) = Maturity(events) |> NewPolicies(events) |> Deaths(events) |> Lapses(events)

I'm still not convinced that transducers are the best language to model term life simulations, but we could probably fit our current LifeSimulator.jl implementation as a transducer with the ideas above (and it can be fun to try at least). There can be other designs, although I think this one would be a good one to start with.

I think generally speaking performance might be harder to ensure with transducers, notably I think memory reuse can be tricky. policies |> step |> collect would have to either reuse data from policies by mutating it - which is probably not what a user would want - or use a new vector of policies, in which case memory usage jumps from P to 2P.

[MatthewCaseres]

This issue is being closed, apologies for getting enamored by the shiny object that we ended up not using! If someone wants to do this fine, but this is being put so far in the back log it is just going to be closed for now.