132 karma · joined August 2, 2021
calculang, a language for calculations https://calculang.dev
Actuarial Playground: https://actuarialplayground.com
Socials: - github.com/declann - linkedin.com/in/declann
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!)
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! </>
It's >3 machine instructions (and I admire the mathematical tricks included in the post), but it does do thousands of calculations fairly quickly :)
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])
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!
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!
Health warning third bullet point is:
> 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.
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)
Also, in my pension calculator example on calculang.dev you can change all the assumptions: https://calculang.dev/examples-viewer?id=pension-calculator (excluding tax relief bits - it's just an example)
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.
[2] https://calculang.dev/examples-viewer?id=pension-calculator <3 separation of concerns
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).
So it's normal to have a string of errors and then everything works, but it should work in much less than 2s. I guess that can depend on a few things!
Please let me know if waiting a bit still fails!
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).
The coordinated visuals are using Vega-Lite.
The calculations are from composing calculang models: one which simulates returns, using one which calculates pension savings.
I plan to do a separate Show HN on calculang soon.
Happy if there is feedback or questions!
Many won't but I agree in the purest (sorry) sense.
There is no scattered changing state. I think we all learned input-function-output as a construct in maths class?
Spreadsheets (sans-VBA) is arguably the most prolific programming language and simplest, being used by people who do not recognise they are programming. Felienne Hermans gave a good talk on this subject in GOTO 2016.
Spreadsheets have numerous shortfalls though, and "real" functional programming languages make it difficult to not feel intimidated: in my experience, but this is getting much better.
[1] is a game of life in calculang, functional language I'm developing, where for all it's verbosity at least I hope the rules and development over generation (g) can be reasoned with (sans-state!).
Not very practical but can show calculang computation/workings as it progresses and as parameters change - things that are easy for FP and otherwise intractable, and which further help with reasoning.
But, a big challenge is to be approachable (not intimidating), and I'm trying to make that better. I think it helps enormously to be focused on numbers as calculang is, and not general programming.
[1] https://6615bc99ad130f0008ecc588--calculang-editables.netlif...
There is a license thing about logos to note if you do use it in Pretzel [2].
On GW [1], Create Dataset -> Public Datasets -> Student Performance then change the Mark Type to Table you can play around. It hits the things that I mentioned pretty good! You might have similar issues as you have with Perspective though.
I make calculang [3] and I'm getting ready to plug into a lot of things. A good pivot table generalizes well for my needs (mainly quick feedback during DX).
Perspective is on the list but so is GW and Pretzel.
Perspective might suit my needs perfectly.
But I like DuckDB-WASM approach anyway so I hope you continue and I hope you nail it one way or another! :)
[1] https://graphic-walker.kanaries.net
You mentioned that you went to some length to implement pivots. How far do you think you will take the pivot feature and UI?
For financial type usecases it's pretty much a requirement to be able to map many fields on X/Y, be able to collapse them in the the browser, and also show/control aggregations.
Asking because many apps stop at the simplest level of pivot features and go to great lengths in other areas like more advanced visualization. For mapping many fields though, I think a good pivot table UI is like a secret weapon.
I get that this isn't what you would focus on so much in week 1.
Nice work + love the local-first and direct UI.
Even just skimming the passages about security and other bits now, this is still an epic resource to get real grounded knowledge about pieces of the complex systems I can merely use nowadays.
I really liked this output from a very logical process (although I'll admit, I needed to use one of the commented versions linked in the discussion!)
Here it is: https://declann.observablehq.cloud/calculang-dx-pattern-exam...
Visuals defined in JSON (so perfect for manipulation and generation) and also able to bake-in custom interactions within that is an awesome power.
I like the look of Observable Plot, but it doesn't do interaction like Vega/Vega-Lite. (They are working on some interaction though, and they have quite the team)
Functional programming sits on a difficulty range: spreadsheets on the low-end (debatable but I'll say it!), and on the high-end, well, I think that everything else FP sits there with minor exceptions.
I'm developing a language for numbers that is conceptually closer to spreadsheet formulae than imperative programming or hard-FP, therefore I think hopeful for this kind of task in the long-run. It's "only for numbers", so really think spreadsheet-formula type complexity, but I won't stop anybody from going wild with interpretation.
To see things you pair it with some other language like JS, but code for these "apps" can be simple/declarative and pre-rolled. I have a JS visualization library that will probably be graphical one day.
I'm working on the project website [1]. Following spreadsheet fashion some examples are a little bore, but there is a raycaster rendering to a bar chart and heart shapes, bouncing balls and projectiles, to lighten the mood for early developer-adopters or contributors.
For some more project background: by encapsulating numbers in a language (and not a mad one and one that we can safely and actually run), it can facilitate transparency for numbers. Transparency and education go hand-in-hand. I'm talking about numerical literacy primarily, but I think that too goes hand-in-hand with.. programming on computers.
[1] https://calculang-quarto-site-messing.pages.dev/examples
I might reuse the pattern to step through tutorial-type developments directly in-editor for presentations and videos.
Training an LLM is a low barrier; legal guarantees is a high barrier.
This might turn out to be quite important; without backfiring it seems like a very smart move.