wscott / fplan Goto Github PK
View Code? Open in Web Editor NEWEarly retirement financial calculator
License: GNU General Public License v3.0
Early retirement financial calculator
License: GNU General Public License v3.0
Hi, I'm Vic. I'd like to contribute to the fplan
project but I'm deathly afraid of breaking something. I think adding a unit test framework and some simple tests is a start toward building up a robust test environment where I and others will feel more comfortable making changes and having some knowledge that the wheels aren't coming off the train.
I've got experience with pytest
so that's an easy place to start. I'm open to other testing frameworks but hope to keep this change simple.
I'm proposing that we create a test
top level directory and that it mirrors src
and looks something like this:
$ ls -R src test
src:
fplan
src/fplan:
fplan.py
test:
fplan
test/fplan:
test_load_file
test/fplan/test_load_file:
test1.toml test_load_file.py
pytest
runs everything named test_*.py
and *_test.py
so the test source files can be simple and isolated from each other. There can be multiple directories in test/fplan
for specific tests and their data. The example above contains some simple tests for the Data
class load_file()
function. Adding some solver tests seems like an obvious next step. Repeat as necessary until we have good coverage.
I suspect some users (or at least one) have an aftertax account where they receive distributions every year even when they don't sell anything. Could this be modeled with a percent dividend parameter?
This is making me wonder if this is why i-orp has a separate capital gains column.
The current model has a 'minimum' spending level and sets up the constraints so that every year has at least that much money to spend. The model maximizes that min spending level.
But this leaves a lot of decisions unconstrained as we probably only have some years that are critical for that min level and other years where the spending options don't matter as much. We should add a secondary constraint that the model minimizes the amount of taxes paid.
Like max: spending + total_tax / years / 10
Or perhaps maximizing the money left at the end will do the same thing...
A web app to allow a user to manage the information from the input file and present the results would make this solver a lot more accessible to people.
This would be something I host on my own perhaps with donations or ads to pay for the overhead.
It would be nice to give people a spreadsheet with all the balances and taxes computed automatically and summary statistics and then fill in the numbers from the model. This way the user that disagrees with an early Roth conversion (for example), they can try changing it and seeing if they can come up with a better plan. It would let them play and see for themselves. Perhaps that is just my engineering brain and "normal" people wouldn't do this...
I might play with something like this http://xlsxwriter.readthedocs.io/ to generate a spreadsheet for the output.
There are different capital gains tax brackets, but the program assumes that all cap gains are taxed at 15%.
Running with --validate does the following:
C:\Users\cmovi\AppData\Local\Programs\Python\Python39\python.exe C:/Users/cmovi/Documents/github/cmovic-fplan/src/fplan/fplan.py ..\..\examples\sample.toml --validate
Traceback (most recent call last):
File "C:\Users\cmovi\Documents\github\cmovic-fplan\src\fplan\fplan.py", line 510, in <module>
main()
File "C:\Users\cmovi\Documents\github\cmovic-fplan\src\fplan\fplan.py", line 506, in main
for y in range(1,nyears):
NameError: name 'nyears' is not defined
Should this be fixed? It doesn't appear to do anything - if that's the case can it be removed?
The desired use of this tool is similar to James Welch's 3PEAT scheme for i-orp.com. Basically, you rerun it each year and adjust the current spending as the projections change over time.
I need to add a testing mode to demonstrate that rerunning the tool with fixed returns gives the same results as the original plan at the beginning of the period. Then we can use that feature to simulate using the tool over some historic period in the past. By running simulations over all possible periods from the last 100 years we should be able to select reasonable rules of thumb about what values should be used for returns and inflation.
A good solution is one where the variation in spending level from one year to the next is as low as possible. We don't want to be giving up possible spending, but a safety margin is needed to minimize the adjustments that are needed during market downturns.
In the 3PEAT paper, a 100% stock investment strategy was assumed. A study framework like this can be used to investigate using a stock/bond mix of investments with yearly rebalancing. It would be interesting to see if there is a sweet spot that obtains much of the average gain from 100% stocks but reducing the variation from market downturns. Similarly, I can see if there is a way to optimally select stock/bond ratios by age rather than just following common wisdom.
Some people have individual stocks that have been around for many years and have a very small basis. Then they have other savings accounts and what to know if the stock should be sold first or later.
For example: http://forum.mrmoneymustache.com/taxes/wrote-a-retirement-calculator-because-i-orp-com-didn't-do-what-i-want/msg1460616/#msg1460616
(In this example, I don't think the modeling would have mattered much)
We can model multiple after-tax accounts to answer this question. Add this issue to give people a place to request this feature.
The model should consider IRA2Roth conversions during the working years. You would have to provide a baseline AGI instead of the current prep.tax_rate
so it can figure the tax impact of additional income from an early conversion.
The current code allows either an IRA distribution or a Roth conversion to exceed the RMD, but I now believe that Roth conversions don't count so I need to change that part.
The idea of this tool is that you rerun in every year with updated balances to plan what to do each year. So it plans 30 years in the future, but you only use the first year of the plan. But currently, if we do a Roth conversion we can't record that in the input so that future runs of this tool will know when that contribution is available to spend.
My plan is to have something like this in the input:
[roth]
bal = 100000 # current balance
contrib = [[ 45, 20000], # previous contributions in [age, ammount] pairs
[ 46, 10000],
[ 47, 10000]]
Then the tool would know that contributions can be spent 5 years after they are added before age 59.5.
But the syntax seems a bit awkward.
Some people have a pension with a sliding scale where they can enable it on different years where the longer they wait the larger the yearly payout. Similarly, Social Security has a sliding scale. It can be started as early as age 62 or benefits can be delayed until age 70 for a larger payout.
An example of this is the following discussion on the MMM forums.
It would be good if this tool would examine the options a select the best option for a user.
Right now the toml file is used for setting but any extra unused settings are just ignored and most everything has a default value.
So if you make a typo in your file that value will just be ignored and it might not be obvious.
A nice feature would be to print a warning about any data items in the user's toml
file that are not used. One way to do this would be to delete each key as it is used and then print warnings about anything remaining. Also include warnings about any keys that have the wrong type.
Some taxes have a progressive tax system, similar to federal taxes. The program currently only supports a single state tax rate. It should support state brackets.
Also you should be able to specify the state standard deduction when it is different from the federal standard deduction.
The law has changed and RMDs no longer begin at 70 for everyone. The program should be updated to reflect that.
Another approach to this type of optimizer is to have the user list the desired spending level for each year and have the program maximize the estate left to heirs at the end of the plan.
The spending level would need to be low enough to be feasible, and it would need an assumed tax bracket for the heir. Then the total after estate taxes would be the result being maximized.
Aftertax contributions during your working years are not accurately reflected in the capital gains tax basis. The capital gains tax basis is based on the initial values of the aftertax account. Working year contributions should cause this tax basis to change but the contributions have no impact.
(I suspect that this would be almost impossible to model in the current program and make very little difference to most users.)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.