extensibility in models & nested model example ported to calculang

[declann]

Hi,

I think this "minimum reproducible" nested model is a great one to discuss extensibility of models and I ported it to calculang:

Repo: calculang/nested-life-projections-example

Here is the "minimal" version of the code:

I think that both have good separation of logic in important respects (term.cul.js corresponds to the Term base class in nested.py).

But for the calculation of capital requirements, there are differences.

The nested.py model uses subclasses and then runs the prudent subclass inside the realistic subclass in each timestep of capital_requirement. (I wonder is there a noteable performance impact for repeated initialization?)

calculang instead lets a capital-requirement.cul.js calculang model manipulate term.cul.js projection logic in a bespoke way: by overriding q_x to add prudence controls that are enabled in projections called from inside the formula for capital_requirement. This is without refactoring code where q_x is used.

There are more details about the specific calculang functionality being applied here (noteably input inference) inside the repo READMEs. And there is alternative annotated sourcecode inside the repo also.

I'm interested to compare/contrast approaches and have a general discussion about extensibility in actuarial models. Please let me know about issues or smells in the calculang approach to this problem, and I'd like to know about your own experiences extending models or friction you run into while doing so - relating to OOP and alternative paradigms.

If OOP is good for programs, is it great for models? If you got a blank slate to change a language to support flexibility and extensibility, would you add anything? Is the language the right place to do so? Afterall model specs can specify flexible designs too, good adherence to best practices is perhaps more important, etc.

Please let me know your own thoughts and comments on anything mentioned/shared.

Cheers,
Declan