HN user
CalcWithDec https://calcwithdec.dev
calculang, a language for calculations https://calculang.dev
Actuarial Playground: https://actuarialplayground.com
Socials: - github.com/declann - linkedin.com/in/declann
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:
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!)
People say that it's a practice.
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! </>
Thanks for the prompt! I made a new gallery that's mobile friendly and I almost forgot why I need to land it - adding it to the list!
If you need to know a leap year and it's before the year 6000, I made an interactive calculator and visualization [1].
It's >3 machine instructions (and I admire the mathematical tricks included in the post), but it does do thousands of calculations fairly quickly :)
This is a cool way to teach!
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])
Neat UI, are you using a library for that?
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!
Thanks gordito!
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!
Aha - I get you!
Author here -
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.
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)
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)
Author here -
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
43,333 homes using 13Bn and 300k cost; I guess you changed one of these or did something else ?
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).
I do need to work on this - thanks for the feedback.
I use reactive Javascript which shows errors until a few pieces click together (best that I can understand it atm).
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!
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).
Hi! I made this scroll-based interaction to Visualize risk.
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!
I like your conviction Re "functional programming is very easy to grasp".
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...
One that I'm watching is the Table mark in Graphic Walker [1].
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
Looks great and thanks for sharing!
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.
I followed LFS and BLFS instructions verbatim when I was a kid with so much time on my hands. Enormously informative and also empowering to get from source code to a complex usable system and to be aware of every package.
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.
These are beautiful interactives along with the rest by Sam!
I converted this to formulas in calculang, a language for calculations I'm developing, and visualize the dungeon and its evolution.
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...
Absolutely with you.
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)
I agree.
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
Neat, I also far prefer using in-editor staging & commiting workflows which are excellent by necessity; history tools by comparison are weak unless I'm missing something. So this seems really useful.
I might reuse the pattern to step through tutorial-type developments directly in-editor for presentations and videos.
^ to elaborate on possible logic:
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.