Not for the same audience but for much the same idea I made a progressive visualization of saving and compound interest in a blog post about pension saving:
A few years ago I was determined to practice, and it was hard, and then it became easy, auto-relaxing, like a cheat.
I lost that practice and now it's hard again.
I think GP is right to question technique vs. attention - I think we don't know much about the answer.
But a point I recall in Nestors book is that there isn't really a lot of scientific study on breath - there is much more study on specific diseases, and e.g. teeth have a full profession of study and development that the everyday act of breathing doesn't have (even though these might be highly related!).
<Opinionated> Some of the best references about breath today are not scientific, but written in the oldest books that survived in different cultures - and anyways, how much does the specific mechanism matter?
Watch this space though - science is catching up! </>
I was blown away by the little functions at first and I too made a clone to experiment with calculang [1].
I added an evaluation feature (F9) so you can select sub-expressions and see what they do, which was helpful to figure out some patterns (video in [2])
Really pretty outputs! And impressive that the code is shown so elegantly and also interactive.
This algorithm is one I use to demo some features in a language I'm making called calculang [0][1]
I like the way you step through the logic.
My only suggestion would be to include a raycasted scene because you can really grab a wide(r) audience (and I'd love to see how you get to voxel scenes!).
Either way - thanks for adding a neat new resource for this algorithm and I'm definitely taking notes Re your clean presentation of the details!
Post-retirement is definitely harder. There are also usually rules about what's allowable with the money that built up with tax relief and such. Since these rules differ from country to country even the starting point of deciding what to model is hard.
Here in Ireland I think in order to get some flexibility with a reasonably sized pension you need to buy an annuity - a guaranteed income paid from some insurance company, up to some amount.
Some day I might settle on some scenario/s to model and take on the visualization challenge... For now hopefully people - especially those who provide the services, can assess if it can be helpful!
> Even when there is tax relief to save for a pension, this doesn’t mean that there aren’t taxes on pension income after retirement
and the footnote to it is:
> often there are taxes on pension income - so that it might be better to say that tax is deferred rather than relieved whenever we save↩
I'll consider bumping the footnote since it's important.
I might try to capture the more complete picture including post-retirement separately - a problem is that there are so many different configurations of this (e.g. in Ireland there are tax-free lump sums permitted at retirement, then there are a few specific options about the rest - and I'm probably still simplifying). But when I get comfortable about something relevant to describe, I might.
Hi - author here - these compound returns are not guaranteed. I reinforce this point under health warnings.
Here the 6% compound returns is an assumption. If that's good or bad to use depends on the purpose of the projection. For long projections in medium-risk funds this might be a reasonable value - but it can also be far off, especially in the short-term.
I made a separate post that surfaces results from an assumed distribution of outcomes rather than a single value, called Visualizing Risk: https://calcwithdec.dev/posts/viz-risk/ (basically a monte carlo simulation)
This blog post is a 'narrative visualization' to show some nice savings incentives visualized in a chart.
I think these are important to have a good understanding about when they are relevant, but the bigger reason I made this is to explore the communication style applied to models and to get closer to the technical patterns to create them.
Since I make calculang [1], all the savings projection calculations are described using it [2] (including income tax calculations: here an example of composition in calculang models).
calculang transpiles into a pure functional JS module, and here I interact with it using reactive OJS and the closeread extension for Quarto [3], plus a reactive Vega visualization.
The programming logic mostly is: Vega signals and calculang parameters condition on a `progress` value that updates as the user scrolls.
It was nice to make: minus no fast reload I would say. I'm considering streamlining some tools with fast reload to facilitate building this type of output for calculang models - like I said I'm interested in the narrative style applied to models, and pure FP calculang and reactive FRP tools around it help a lot.
To get my editor component and compiler interacting with that reactive system it got a little messy, and I'll review and hopefully fix it before I push this to a wider calculang playground. Hopefully it's my own bugs that I can fix anyways.
In this example it might not be so practical, but in calculang everything is a function including constants.
This is because of an emphasis on flexibility. They're a constant here but in another calculang model I can call calculations from this same code while asking for specific pieces of the calculation to be different.
e.g. if I have a population growth assumption then in an exercise I can get all these numbers allowing for population growth - without myself touching these formulas. Population then depends on time and must be a function.
On calculang.dev I say that formulas (functions) are the building blocks of calculations, and they're the mechanism for flexibility (also transparency).
Thanks for checking it out and for the comment! This surprised me, but you are right.
The only thing I can point to referring to this example only is that there is a lot of Javascript in the page, but the calculations are (effectively Javascript also but:) described separately, and this is still useful I'll argue -
Separation of concerns means we can easily first of all point to calculation logic, connect it to numbers where they are used, give some structure to it, build tools to generally interact with that structure (much simpler than with Javascript). calculang code is pure and has no side-effects (*supposed to), which means tools can safely re-run code and expect predictable output. I use a tool taking advantage of some of this in [1] a video exploring a calculang model for a raycasting algorithm in order to understand it and fix a thing. So, I said a lot of buzzwords but I do use these properties to experiment with different DX that is far more challenging to develop for Javascript or a programming language generally.
The calculations in How much is 13 Bn euros are almost trivial - I normally don't put in these types of hardcodes for example - and it does happen to be valid Javascript here. An example to see some technical properties of calculang itself is this (also simple) one: https://new-layout-2--finding-calculang-foc.netlify.app/shop
There are a few tabs in the top left. The first (default) tab is showing calculang code: a few formulas and a few inputs (inputs are denoted by a convention). All are implemented like functions, and there are a lot of function calls - but those brackets have nothing in them. This is because calculang tracks how inputs are used and populates brackets for you - something I call input inference (or input threading). In the second tab you'll see the calculang output.
So it looks like calculang helps you to write pure-functional calculation code in a concise way; by threading inputs through all the function calls automatically.
calculang also supports modularity and effectively lets you re-use one calculation and "overriding" some component calculation/s. In other words: calculang formulas are flexible. And this is the real motivation for calculang taking care of all that input threading: flexibility means it should be done differently in different contexts (even sensible within the same model - for example - "I want this calc with this change, I want the same calc but with this other change or no change, and I want the difference between the two").
The compiler takes care of input threading through some pretty simple graph logic - everything related to compilation is <1k lines in total. Effective modularity, flexibility, and re-use of course is useful for maintainability.
A recycling logo in the calculang.dev examples [2] indicates models which use modularity in some form.
Sorry for the long post. That really is about all the technical details I can mention - but I think separation of concerns takes it very far also - in terms of its goals (that are stated on top of calculang.dev).
https://calcwithdec.dev/posts/pictures-pensions/
I intentionally didn't include numbers at all - they are a bit more effort to interpret.
A visualization might be a nice feature for kids (but it probably depends on the kid!)