ChrisCScott / forecaster

A personal finances forecasting tool for Canadian retirement planning
Other
1 stars 2 forks source link

Make Ledger vector-based #53

Open ChrisCScott opened 5 years ago

ChrisCScott commented 5 years ago

The recorded_property and recorded_property_cached decorators both use dicts to store their time-series data. To support this, Ledger must receive initial_year as an __init__ arg. This requires initial_year to be passed to a lot of objects!

The current dict-based approach provides two benefits: client code doesn't need to translate between years and 0-based indices and Ledger-based records can be started in different years while still allowing comparison between records of the same year. The former is just syntactic convenience. The latter doesn't currently have any application in the software, but if it's desired it could probably be replicated via an optional parameter.

Using an optional initial_year would require a lot of comparison logic; consider an optional offset (with a default value of 0) which could be added to (or subtracted from) an index to allow harmonization between Ledger objects. In that case, we'd likely want to add history-accessing methods (probably not properties, since we'd likely need to subclass list) that can take an index and apply the offset appropriately. Since this is not currently required, we can leave it for a future revision.

Ledger objects maintain an ordered (and contiguous) set of records. This maps better to list than dict. Accordingly, we should shift recorded_property and recorded_property_cached to use list for value history.

We'll need to consider how to handle user-input values (e.g. via the input parameter or via settings or constants). Those can likely continue to be dicts since those values can be non-contiguous. Whether they should be indexed by year (e.g. 2015) or indices (0-based) should be considered.

ChrisCScott commented 5 years ago

This feature is an efficiency-focused optimization. It's not appropriate for v. 0.1 Pushed back to v. 0.2, since it belongs with Monte Carlo simulation methods.